aboutsummaryrefslogtreecommitdiff
path: root/doc/paper/rfc.bib
blob: 14934dbd46030d564b925fc22eed8187628ff103 (plain)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
6371
6372
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
6821
6822
6823
6824
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
6923
6924
6925
6926
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
7164
7165
7166
7167
7168
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
7705
7706
7707
7708
7709
7710
7711
7712
7713
7714
7715
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
7842
7843
7844
7845
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
7866
7867
7868
7869
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
7919
7920
7921
7922
7923
7924
7925
7926
7927
7928
7929
7930
7931
7932
7933
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
7956
7957
7958
7959
7960
7961
7962
7963
7964
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
7988
7989
7990
7991
7992
7993
7994
7995
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
8161
8162
8163
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234
8235
8236
8237
8238
8239
8240
8241
8242
8243
8244
8245
8246
8247
8248
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290
8291
8292
8293
8294
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
8329
8330
8331
8332
8333
8334
8335
8336
8337
8338
8339
8340
8341
8342
8343
8344
8345
8346
8347
8348
8349
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
8379
8380
8381
8382
8383
8384
8385
8386
8387
8388
8389
8390
8391
8392
8393
8394
8395
8396
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
8418
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
8485
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
8563
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
8585
8586
8587
8588
8589
8590
8591
8592
8593
8594
8595
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
8640
8641
8642
8643
8644
8645
8646
8647
8648
8649
8650
8651
8652
8653
8654
8655
8656
8657
8658
8659
8660
8661
8662
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
9639
9640
9641
9642
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
9654
9655
9656
9657
9658
9659
9660
9661
9662
9663
9664
9665
9666
9667
9668
9669
9670
9671
9672
9673
9674
9675
9676
9677
9678
9679
9680
9681
9682
9683
9684
9685
9686
9687
9688
9689
9690
9691
9692
9693
9694
9695
9696
9697
9698
9699
9700
9701
9702
9703
9704
9705
9706
9707
9708
9709
9710
9711
9712
9713
9714
9715
9716
9717
9718
9719
9720
9721
9722
9723
9724
9725
9726
9727
9728
9729
9730
9731
9732
9733
9734
9735
9736
9737
9738
9739
9740
9741
9742
9743
9744
9745
9746
9747
9748
9749
9750
9751
9752
9753
9754
9755
9756
9757
9758
9759
9760
9761
9762
9763
9764
9765
9766
9767
9768
9769
9770
9771
9772
9773
9774
9775
9776
9777
9778
9779
9780
9781
9782
9783
9784
9785
9786
9787
9788
9789
9790
9791
9792
9793
9794
9795
9796
9797
9798
9799
9800
9801
9802
9803
9804
9805
9806
9807
9808
9809
9810
9811
9812
9813
9814
9815
9816
9817
9818
9819
9820
9821
9822
9823
9824
9825
9826
9827
9828
9829
9830
9831
9832
9833
9834
9835
9836
9837
9838
9839
9840
9841
9842
9843
9844
9845
9846
9847
9848
9849
9850
9851
9852
9853
9854
9855
9856
9857
9858
9859
9860
9861
9862
9863
9864
9865
9866
9867
9868
9869
9870
9871
9872
9873
9874
9875
9876
9877
9878
9879
9880
9881
9882
9883
9884
9885
9886
9887
9888
9889
9890
9891
9892
9893
9894
9895
9896
9897
9898
9899
9900
9901
9902
9903
9904
9905
9906
9907
9908
9909
9910
9911
9912
9913
9914
9915
9916
9917
9918
9919
9920
9921
9922
9923
9924
9925
9926
9927
9928
9929
9930
9931
9932
9933
9934
9935
9936
9937
9938
9939
9940
9941
9942
9943
9944
9945
9946
9947
9948
9949
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
9960
9961
9962
9963
9964
9965
9966
9967
9968
9969
9970
9971
9972
9973
9974
9975
9976
9977
9978
9979
9980
9981
9982
9983
9984
9985
9986
9987
9988
9989
9990
9991
9992
9993
9994
9995
9996
9997
9998
9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279
11280
11281
11282
11283
11284
11285
11286
11287
11288
11289
11290
11291
11292
11293
11294
11295
11296
11297
11298
11299
11300
11301
11302
11303
11304
11305
11306
11307
11308
11309
11310
11311
11312
11313
11314
11315
11316
11317
11318
11319
11320
11321
11322
11323
11324
11325
11326
11327
11328
11329
11330
11331
11332
11333
11334
11335
11336
11337
11338
11339
11340
11341
11342
11343
11344
11345
11346
11347
11348
11349
11350
11351
11352
11353
11354
11355
11356
11357
11358
11359
11360
11361
11362
11363
11364
11365
11366
11367
11368
11369
11370
11371
11372
11373
11374
11375
11376
11377
11378
11379
11380
11381
11382
11383
11384
11385
11386
11387
11388
11389
11390
11391
11392
11393
11394
11395
11396
11397
11398
11399
11400
11401
11402
11403
11404
11405
11406
11407
11408
11409
11410
11411
11412
11413
11414
11415
11416
11417
11418
11419
11420
11421
11422
11423
11424
11425
11426
11427
11428
11429
11430
11431
11432
11433
11434
11435
11436
11437
11438
11439
11440
11441
11442
11443
11444
11445
11446
11447
11448
11449
11450
11451
11452
11453
11454
11455
11456
11457
11458
11459
11460
11461
11462
11463
11464
11465
11466
11467
11468
11469
11470
11471
11472
11473
11474
11475
11476
11477
11478
11479
11480
11481
11482
11483
11484
11485
11486
11487
11488
11489
11490
11491
11492
11493
11494
11495
11496
11497
11498
11499
11500
11501
11502
11503
11504
11505
11506
11507
11508
11509
11510
11511
11512
11513
11514
11515
11516
11517
11518
11519
11520
11521
11522
11523
11524
11525
11526
11527
11528
11529
11530
11531
11532
11533
11534
11535
11536
11537
11538
11539
11540
11541
11542
11543
11544
11545
11546
11547
11548
11549
11550
11551
11552
11553
11554
11555
11556
11557
11558
11559
11560
11561
11562
11563
11564
11565
11566
11567
11568
11569
11570
11571
11572
11573
11574
11575
11576
11577
11578
11579
11580
11581
11582
11583
11584
11585
11586
11587
11588
11589
11590
11591
11592
11593
11594
11595
11596
11597
11598
11599
11600
11601
11602
11603
11604
11605
11606
11607
11608
11609
11610
11611
11612
11613
11614
11615
11616
11617
11618
11619
11620
11621
11622
11623
11624
11625
11626
11627
11628
11629
11630
11631
11632
11633
11634
11635
11636
11637
11638
11639
11640
11641
11642
11643
11644
11645
11646
11647
11648
11649
11650
11651
11652
11653
11654
11655
11656
11657
11658
11659
11660
11661
11662
11663
11664
11665
11666
11667
11668
11669
11670
11671
11672
11673
11674
11675
11676
11677
11678
11679
11680
11681
11682
11683
11684
11685
11686
11687
11688
11689
11690
11691
11692
11693
11694
11695
11696
11697
11698
11699
11700
11701
11702
11703
11704
11705
11706
11707
11708
11709
11710
11711
11712
11713
11714
11715
11716
11717
11718
11719
11720
11721
11722
11723
11724
11725
11726
11727
11728
11729
11730
11731
11732
11733
11734
11735
11736
11737
11738
11739
11740
11741
11742
11743
11744
11745
11746
11747
11748
11749
11750
11751
11752
11753
11754
11755
11756
11757
11758
11759
11760
11761
11762
11763
11764
11765
11766
11767
11768
11769
11770
11771
11772
11773
11774
11775
11776
11777
11778
11779
11780
11781
11782
11783
11784
11785
11786
11787
11788
11789
11790
11791
11792
11793
11794
11795
11796
11797
11798
11799
11800
11801
11802
11803
11804
11805
11806
11807
11808
11809
11810
11811
11812
11813
11814
11815
11816
11817
11818
11819
11820
11821
11822
11823
11824
11825
11826
11827
11828
11829
11830
11831
11832
11833
11834
11835
11836
11837
11838
11839
11840
11841
11842
11843
11844
11845
11846
11847
11848
11849
11850
11851
11852
11853
11854
11855
11856
11857
11858
11859
11860
11861
11862
11863
11864
11865
11866
11867
11868
11869
11870
11871
11872
11873
11874
11875
11876
11877
11878
11879
11880
11881
11882
11883
11884
11885
11886
11887
11888
11889
11890
11891
11892
11893
11894
11895
11896
11897
11898
11899
11900
11901
11902
11903
11904
11905
11906
11907
11908
11909
11910
11911
11912
11913
11914
11915
11916
11917
11918
11919
11920
11921
11922
11923
11924
11925
11926
11927
11928
11929
11930
11931
11932
11933
11934
11935
11936
11937
11938
11939
11940
11941
11942
11943
11944
11945
11946
11947
11948
11949
11950
11951
11952
11953
11954
11955
11956
11957
11958
11959
11960
11961
11962
11963
11964
11965
11966
11967
11968
11969
11970
11971
11972
11973
11974
11975
11976
11977
11978
11979
11980
11981
11982
11983
11984
11985
11986
11987
11988
11989
11990
11991
11992
11993
11994
11995
11996
11997
11998
11999
12000
12001
12002
12003
12004
12005
12006
12007
12008
12009
12010
12011
12012
12013
12014
12015
12016
12017
12018
12019
12020
12021
12022
12023
12024
12025
12026
12027
12028
12029
12030
12031
12032
12033
12034
12035
12036
12037
12038
12039
12040
12041
12042
12043
12044
12045
12046
12047
12048
12049
12050
12051
12052
12053
12054
12055
12056
12057
12058
12059
12060
12061
12062
12063
12064
12065
12066
12067
12068
12069
12070
12071
12072
12073
12074
12075
12076
12077
12078
12079
12080
12081
12082
12083
12084
12085
12086
12087
12088
12089
12090
12091
12092
12093
12094
12095
12096
12097
12098
12099
12100
12101
12102
12103
12104
12105
12106
12107
12108
12109
12110
12111
12112
12113
12114
12115
12116
12117
12118
12119
12120
12121
12122
12123
12124
12125
12126
12127
12128
12129
12130
12131
12132
12133
12134
12135
12136
12137
12138
12139
12140
12141
12142
12143
12144
12145
12146
12147
12148
12149
12150
12151
12152
12153
12154
12155
12156
12157
12158
12159
12160
12161
12162
12163
12164
12165
12166
12167
12168
12169
12170
12171
12172
12173
12174
12175
12176
12177
12178
12179
12180
12181
12182
12183
12184
12185
12186
12187
12188
12189
12190
12191
12192
12193
12194
12195
12196
12197
12198
12199
12200
12201
12202
12203
12204
12205
12206
12207
12208
12209
12210
12211
12212
12213
12214
12215
12216
12217
12218
12219
12220
12221
12222
12223
12224
12225
12226
12227
12228
12229
12230
12231
12232
12233
12234
12235
12236
12237
12238
12239
12240
12241
12242
12243
12244
12245
12246
12247
12248
12249
12250
12251
12252
12253
12254
12255
12256
12257
12258
12259
12260
12261
12262
12263
12264
12265
12266
12267
12268
12269
12270
12271
12272
12273
12274
12275
12276
12277
12278
12279
12280
12281
12282
12283
12284
12285
12286
12287
12288
12289
12290
12291
12292
12293
12294
12295
12296
12297
12298
12299
12300
12301
12302
12303
12304
12305
12306
12307
12308
12309
12310
12311
12312
12313
12314
12315
12316
12317
12318
12319
12320
12321
12322
12323
12324
12325
12326
12327
12328
12329
12330
12331
12332
12333
12334
12335
12336
12337
12338
12339
12340
12341
12342
12343
12344
12345
12346
12347
12348
12349
12350
12351
12352
12353
12354
12355
12356
12357
12358
12359
12360
12361
12362
12363
12364
12365
12366
12367
12368
12369
12370
12371
12372
12373
12374
12375
12376
12377
12378
12379
12380
12381
12382
12383
12384
12385
12386
12387
12388
12389
12390
12391
12392
12393
12394
12395
12396
12397
12398
12399
12400
12401
12402
12403
12404
12405
12406
12407
12408
12409
12410
12411
12412
12413
12414
12415
12416
12417
12418
12419
12420
12421
12422
12423
12424
12425
12426
12427
12428
12429
12430
12431
12432
12433
12434
12435
12436
12437
12438
12439
12440
12441
12442
12443
12444
12445
12446
12447
12448
12449
12450
12451
12452
12453
12454
12455
12456
12457
12458
12459
12460
12461
12462
12463
12464
12465
12466
12467
12468
12469
12470
12471
12472
12473
12474
12475
12476
12477
12478
12479
12480
12481
12482
12483
12484
12485
12486
12487
12488
12489
12490
12491
12492
12493
12494
12495
12496
12497
12498
12499
12500
12501
12502
12503
12504
12505
12506
12507
12508
12509
12510
12511
12512
12513
12514
12515
12516
12517
12518
12519
12520
12521
12522
12523
12524
12525
12526
12527
12528
12529
12530
12531
12532
12533
12534
12535
12536
12537
12538
12539
12540
12541
12542
12543
12544
12545
12546
12547
12548
12549
12550
12551
12552
12553
12554
12555
12556
12557
12558
12559
12560
12561
12562
12563
12564
12565
12566
12567
12568
12569
12570
12571
12572
12573
12574
12575
12576
12577
12578
12579
12580
12581
12582
12583
12584
12585
12586
12587
12588
12589
12590
12591
12592
12593
12594
12595
12596
12597
12598
12599
12600
12601
12602
12603
12604
12605
12606
12607
12608
12609
12610
12611
12612
12613
12614
12615
12616
12617
12618
12619
12620
12621
12622
12623
12624
12625
12626
12627
12628
12629
12630
12631
12632
12633
12634
12635
12636
12637
12638
12639
12640
12641
12642
12643
12644
12645
12646
12647
12648
12649
12650
12651
12652
12653
12654
12655
12656
12657
12658
12659
12660
12661
12662
12663
12664
12665
12666
12667
12668
12669
12670
12671
12672
12673
12674
12675
12676
12677
12678
12679
12680
12681
12682
12683
12684
12685
12686
12687
12688
12689
12690
12691
12692
12693
12694
12695
12696
12697
12698
12699
12700
12701
12702
12703
12704
12705
12706
12707
12708
12709
12710
12711
12712
12713
12714
12715
12716
12717
12718
12719
12720
12721
12722
12723
12724
12725
12726
12727
12728
12729
12730
12731
12732
12733
12734
12735
12736
12737
12738
12739
12740
12741
12742
12743
12744
12745
12746
12747
12748
12749
12750
12751
12752
12753
12754
12755
12756
12757
12758
12759
12760
12761
12762
12763
12764
12765
12766
12767
12768
12769
12770
12771
12772
12773
12774
12775
12776
12777
12778
12779
12780
12781
12782
12783
12784
12785
12786
12787
12788
12789
12790
12791
12792
12793
12794
12795
12796
12797
12798
12799
12800
12801
12802
12803
12804
12805
12806
12807
12808
12809
12810
12811
12812
12813
12814
12815
12816
12817
12818
12819
12820
12821
12822
12823
12824
12825
12826
12827
12828
12829
12830
12831
12832
12833
12834
12835
12836
12837
12838
12839
12840
12841
12842
12843
12844
12845
12846
12847
12848
12849
12850
12851
12852
12853
12854
12855
12856
12857
12858
12859
12860
12861
12862
12863
12864
12865
12866
12867
12868
12869
12870
12871
12872
12873
12874
12875
12876
12877
12878
12879
12880
12881
12882
12883
12884
12885
12886
12887
12888
12889
12890
12891
12892
12893
12894
12895
12896
12897
12898
12899
12900
12901
12902
12903
12904
12905
12906
12907
12908
12909
12910
12911
12912
12913
12914
12915
12916
12917
12918
12919
12920
12921
12922
12923
12924
12925
12926
12927
12928
12929
12930
12931
12932
12933
12934
12935
12936
12937
12938
12939
12940
12941
12942
12943
12944
12945
12946
12947
12948
12949
12950
12951
12952
12953
12954
12955
12956
12957
12958
12959
12960
12961
12962
12963
12964
12965
12966
12967
12968
12969
12970
12971
12972
12973
12974
12975
12976
12977
12978
12979
12980
12981
12982
12983
12984
12985
12986
12987
12988
12989
12990
12991
12992
12993
12994
12995
12996
12997
12998
12999
13000
13001
13002
13003
13004
13005
13006
13007
13008
13009
13010
13011
13012
13013
13014
13015
13016
13017
13018
13019
13020
13021
13022
13023
13024
13025
13026
13027
13028
13029
13030
13031
13032
13033
13034
13035
13036
13037
13038
13039
13040
13041
13042
13043
13044
13045
13046
13047
13048
13049
13050
13051
13052
13053
13054
13055
13056
13057
13058
13059
13060
13061
13062
13063
13064
13065
13066
13067
13068
13069
13070
13071
13072
13073
13074
13075
13076
13077
13078
13079
13080
13081
13082
13083
13084
13085
13086
13087
13088
13089
13090
13091
13092
13093
13094
13095
13096
13097
13098
13099
13100
13101
13102
13103
13104
13105
13106
13107
13108
13109
13110
13111
13112
13113
13114
13115
13116
13117
13118
13119
13120
13121
13122
13123
13124
13125
13126
13127
13128
13129
13130
13131
13132
13133
13134
13135
13136
13137
13138
13139
13140
13141
13142
13143
13144
13145
13146
13147
13148
13149
13150
13151
13152
13153
13154
13155
13156
13157
13158
13159
13160
13161
13162
13163
13164
13165
13166
13167
13168
13169
13170
13171
13172
13173
13174
13175
13176
13177
13178
13179
13180
13181
13182
13183
13184
13185
13186
13187
13188
13189
13190
13191
13192
13193
13194
13195
13196
13197
13198
13199
13200
13201
13202
13203
13204
13205
13206
13207
13208
13209
13210
13211
13212
13213
13214
13215
13216
13217
13218
13219
13220
13221
13222
13223
13224
13225
13226
13227
13228
13229
13230
13231
13232
13233
13234
13235
13236
13237
13238
13239
13240
13241
13242
13243
13244
13245
13246
13247
13248
13249
13250
13251
13252
13253
13254
13255
13256
13257
13258
13259
13260
13261
13262
13263
13264
13265
13266
13267
13268
13269
13270
13271
13272
13273
13274
13275
13276
13277
13278
13279
13280
13281
13282
13283
13284
13285
13286
13287
13288
13289
13290
13291
13292
13293
13294
13295
13296
13297
13298
13299
13300
13301
13302
13303
13304
13305
13306
13307
13308
13309
13310
13311
13312
13313
13314
13315
13316
13317
13318
13319
13320
13321
13322
13323
13324
13325
13326
13327
13328
13329
13330
13331
13332
13333
13334
13335
13336
13337
13338
13339
13340
13341
13342
13343
13344
13345
13346
13347
13348
13349
13350
13351
13352
13353
13354
13355
13356
13357
13358
13359
13360
13361
13362
13363
13364
13365
13366
13367
13368
13369
13370
13371
13372
13373
13374
13375
13376
13377
13378
13379
13380
13381
13382
13383
13384
13385
13386
13387
13388
13389
13390
13391
13392
13393
13394
13395
13396
13397
13398
13399
13400
13401
13402
13403
13404
13405
13406
13407
13408
13409
13410
13411
13412
13413
13414
13415
13416
13417
13418
13419
13420
13421
13422
13423
13424
13425
13426
13427
13428
13429
13430
13431
13432
13433
13434
13435
13436
13437
13438
13439
13440
13441
13442
13443
13444
13445
13446
13447
13448
13449
13450
13451
13452
13453
13454
13455
13456
13457
13458
13459
13460
13461
13462
13463
13464
13465
13466
13467
13468
13469
13470
13471
13472
13473
13474
13475
13476
13477
13478
13479
13480
13481
13482
13483
13484
13485
13486
13487
13488
13489
13490
13491
13492
13493
13494
13495
13496
13497
13498
13499
13500
13501
13502
13503
13504
13505
13506
13507
13508
13509
13510
13511
13512
13513
13514
13515
13516
13517
13518
13519
13520
13521
13522
13523
13524
13525
13526
13527
13528
13529
13530
13531
13532
13533
13534
13535
13536
13537
13538
13539
13540
13541
13542
13543
13544
13545
13546
13547
13548
13549
13550
13551
13552
13553
13554
13555
13556
13557
13558
13559
13560
13561
13562
13563
13564
13565
13566
13567
13568
13569
13570
13571
13572
13573
13574
13575
13576
13577
13578
13579
13580
13581
13582
13583
13584
13585
13586
13587
13588
13589
13590
13591
13592
13593
13594
13595
13596
13597
13598
13599
13600
13601
13602
13603
13604
13605
13606
13607
13608
13609
13610
13611
13612
13613
13614
13615
13616
13617
13618
13619
13620
13621
13622
13623
13624
13625
13626
13627
13628
13629
13630
13631
13632
13633
13634
13635
13636
13637
13638
13639
13640
13641
13642
13643
13644
13645
13646
13647
13648
13649
13650
13651
13652
13653
13654
13655
13656
13657
13658
13659
13660
13661
13662
13663
13664
13665
13666
13667
13668
13669
13670
13671
13672
13673
13674
13675
13676
13677
13678
13679
13680
13681
13682
13683
13684
13685
13686
13687
13688
13689
13690
13691
13692
13693
13694
13695
13696
13697
13698
13699
13700
13701
13702
13703
13704
13705
13706
13707
13708
13709
13710
13711
13712
13713
13714
13715
13716
13717
13718
13719
13720
13721
13722
13723
13724
13725
13726
13727
13728
13729
13730
13731
13732
13733
13734
13735
13736
13737
13738
13739
13740
13741
13742
13743
13744
13745
13746
13747
13748
13749
13750
13751
13752
13753
13754
13755
13756
13757
13758
13759
13760
13761
13762
13763
13764
13765
13766
13767
13768
13769
13770
13771
13772
13773
13774
13775
13776
13777
13778
13779
13780
13781
13782
13783
13784
13785
13786
13787
13788
13789
13790
13791
13792
13793
13794
13795
13796
13797
13798
13799
13800
13801
13802
13803
13804
13805
13806
13807
13808
13809
13810
13811
13812
13813
13814
13815
13816
13817
13818
13819
13820
13821
13822
13823
13824
13825
13826
13827
13828
13829
13830
13831
13832
13833
13834
13835
13836
13837
13838
13839
13840
13841
13842
13843
13844
13845
13846
13847
13848
13849
13850
13851
13852
13853
13854
13855
13856
13857
13858
13859
13860
13861
13862
13863
13864
13865
13866
13867
13868
13869
13870
13871
13872
13873
13874
13875
13876
13877
13878
13879
13880
13881
13882
13883
13884
13885
13886
13887
13888
13889
13890
13891
13892
13893
13894
13895
13896
13897
13898
13899
13900
13901
13902
13903
13904
13905
13906
13907
13908
13909
13910
13911
13912
13913
13914
13915
13916
13917
13918
13919
13920
13921
13922
13923
13924
13925
13926
13927
13928
13929
13930
13931
13932
13933
13934
13935
13936
13937
13938
13939
13940
13941
13942
13943
13944
13945
13946
13947
13948
13949
13950
13951
13952
13953
13954
13955
13956
13957
13958
13959
13960
13961
13962
13963
13964
13965
13966
13967
13968
13969
13970
13971
13972
13973
13974
13975
13976
13977
13978
13979
13980
13981
13982
13983
13984
13985
13986
13987
13988
13989
13990
13991
13992
13993
13994
13995
13996
13997
13998
13999
14000
14001
14002
14003
14004
14005
14006
14007
14008
14009
14010
14011
14012
14013
14014
14015
14016
14017
14018
14019
14020
14021
14022
14023
14024
14025
14026
14027
14028
14029
14030
14031
14032
14033
14034
14035
14036
14037
14038
14039
14040
14041
14042
14043
14044
14045
14046
14047
14048
14049
14050
14051
14052
14053
14054
14055
14056
14057
14058
14059
14060
14061
14062
14063
14064
14065
14066
14067
14068
14069
14070
14071
14072
14073
14074
14075
14076
14077
14078
14079
14080
14081
14082
14083
14084
14085
14086
14087
14088
14089
14090
14091
14092
14093
14094
14095
14096
14097
14098
14099
14100
14101
14102
14103
14104
14105
14106
14107
14108
14109
14110
14111
14112
14113
14114
14115
14116
14117
14118
14119
14120
14121
14122
14123
14124
14125
14126
14127
14128
14129
14130
14131
14132
14133
14134
14135
14136
14137
14138
14139
14140
14141
14142
14143
14144
14145
14146
14147
14148
14149
14150
14151
14152
14153
14154
14155
14156
14157
14158
14159
14160
14161
14162
14163
14164
14165
14166
14167
14168
14169
14170
14171
14172
14173
14174
14175
14176
14177
14178
14179
14180
14181
14182
14183
14184
14185
14186
14187
14188
14189
14190
14191
14192
14193
14194
14195
14196
14197
14198
14199
14200
14201
14202
14203
14204
14205
14206
14207
14208
14209
14210
14211
14212
14213
14214
14215
14216
14217
14218
14219
14220
14221
14222
14223
14224
14225
14226
14227
14228
14229
14230
14231
14232
14233
14234
14235
14236
14237
14238
14239
14240
14241
14242
14243
14244
14245
14246
14247
14248
14249
14250
14251
14252
14253
14254
14255
14256
14257
14258
14259
14260
14261
14262
14263
14264
14265
14266
14267
14268
14269
14270
14271
14272
14273
14274
14275
14276
14277
14278
14279
14280
14281
14282
14283
14284
14285
14286
14287
14288
14289
14290
14291
14292
14293
14294
14295
14296
14297
14298
14299
14300
14301
14302
14303
14304
14305
14306
14307
14308
14309
14310
14311
14312
14313
14314
14315
14316
14317
14318
14319
14320
14321
14322
14323
14324
14325
14326
14327
14328
14329
14330
14331
14332
14333
14334
14335
14336
14337
14338
14339
14340
14341
14342
14343
14344
14345
14346
14347
14348
14349
14350
14351
14352
14353
14354
14355
14356
14357
14358
14359
14360
14361
14362
14363
14364
14365
14366
14367
14368
14369
14370
14371
14372
14373
14374
14375
14376
14377
14378
14379
14380
14381
14382
14383
14384
14385
14386
14387
14388
14389
14390
14391
14392
14393
14394
14395
14396
14397
14398
14399
14400
14401
14402
14403
14404
14405
14406
14407
14408
14409
14410
14411
14412
14413
14414
14415
14416
14417
14418
14419
14420
14421
14422
14423
14424
14425
14426
14427
14428
14429
14430
14431
14432
14433
14434
14435
14436
14437
14438
14439
14440
14441
14442
14443
14444
14445
14446
14447
14448
14449
14450
14451
14452
14453
14454
14455
14456
14457
14458
14459
14460
14461
14462
14463
14464
14465
14466
14467
14468
14469
14470
14471
14472
14473
14474
14475
14476
14477
14478
14479
14480
14481
14482
14483
14484
14485
14486
14487
14488
14489
14490
14491
14492
14493
14494
14495
14496
14497
14498
14499
14500
14501
14502
14503
14504
14505
14506
14507
14508
14509
14510
14511
14512
14513
14514
14515
14516
14517
14518
14519
14520
14521
14522
14523
14524
14525
14526
14527
14528
14529
14530
14531
14532
14533
14534
14535
14536
14537
14538
14539
14540
14541
14542
14543
14544
14545
14546
14547
14548
14549
14550
14551
14552
14553
14554
14555
14556
14557
14558
14559
14560
14561
14562
14563
14564
14565
14566
14567
14568
14569
14570
14571
14572
14573
14574
14575
14576
14577
14578
14579
14580
14581
14582
14583
14584
14585
14586
14587
14588
14589
14590
14591
14592
14593
14594
14595
14596
14597
14598
14599
14600
14601
14602
14603
14604
14605
14606
14607
14608
14609
14610
14611
14612
14613
14614
14615
14616
14617
14618
14619
14620
14621
14622
14623
14624
14625
14626
14627
14628
14629
14630
14631
14632
14633
14634
14635
14636
14637
14638
14639
14640
14641
14642
14643
14644
14645
14646
14647
14648
14649
14650
14651
14652
14653
14654
14655
14656
14657
14658
14659
14660
14661
14662
14663
14664
14665
14666
14667
14668
14669
14670
14671
14672
14673
14674
14675
14676
14677
14678
14679
14680
14681
14682
14683
14684
14685
14686
14687
14688
14689
14690
14691
14692
14693
14694
14695
14696
14697
14698
14699
14700
14701
14702
14703
14704
14705
14706
14707
14708
14709
14710
14711
14712
14713
14714
14715
14716
14717
14718
14719
14720
14721
14722
14723
14724
14725
14726
14727
14728
14729
14730
14731
14732
14733
14734
14735
14736
14737
14738
14739
14740
14741
14742
14743
14744
14745
14746
14747
14748
14749
14750
14751
14752
14753
14754
14755
14756
14757
14758
14759
14760
14761
14762
14763
14764
14765
14766
14767
14768
14769
14770
14771
14772
14773
14774
14775
14776
14777
14778
14779
14780
14781
14782
14783
14784
14785
14786
14787
14788
14789
14790
14791
14792
14793
14794
14795
14796
14797
14798
14799
14800
14801
14802
14803
14804
14805
14806
14807
14808
14809
14810
14811
14812
14813
14814
14815
14816
14817
14818
14819
14820
14821
14822
14823
14824
14825
14826
14827
14828
14829
14830
14831
14832
14833
14834
14835
14836
14837
14838
14839
14840
14841
14842
14843
14844
14845
14846
14847
14848
14849
14850
14851
14852
14853
14854
14855
14856
14857
14858
14859
14860
14861
14862
14863
14864
14865
14866
14867
14868
14869
14870
14871
14872
14873
14874
14875
14876
14877
14878
14879
14880
14881
14882
14883
14884
14885
14886
14887
14888
14889
14890
14891
14892
14893
14894
14895
14896
14897
14898
14899
14900
14901
14902
14903
14904
14905
14906
14907
14908
14909
14910
14911
14912
14913
14914
14915
14916
14917
14918
14919
14920
14921
14922
14923
14924
14925
14926
14927
14928
14929
14930
14931
14932
14933
14934
14935
14936
14937
14938
14939
14940
14941
14942
14943
14944
14945
14946
14947
14948
14949
14950
14951
14952
14953
14954
14955
14956
14957
14958
14959
14960
14961
14962
14963
14964
14965
14966
14967
14968
14969
14970
14971
14972
14973
14974
14975
14976
14977
14978
14979
14980
14981
14982
14983
14984
14985
14986
14987
14988
14989
14990
14991
14992
14993
14994
14995
14996
14997
14998
14999
15000
15001
15002
15003
15004
15005
15006
15007
15008
15009
15010
15011
15012
15013
15014
15015
15016
15017
15018
15019
15020
15021
15022
15023
15024
15025
15026
15027
15028
15029
15030
15031
15032
15033
15034
15035
15036
15037
15038
15039
15040
15041
15042
15043
15044
15045
15046
15047
15048
15049
15050
15051
15052
15053
15054
15055
15056
15057
15058
15059
15060
15061
15062
15063
15064
15065
15066
15067
15068
15069
15070
15071
15072
15073
15074
15075
15076
15077
15078
15079
15080
15081
15082
15083
15084
15085
15086
15087
15088
15089
15090
15091
15092
15093
15094
15095
15096
15097
15098
15099
15100
15101
15102
15103
15104
15105
15106
15107
15108
15109
15110
15111
15112
15113
15114
15115
15116
15117
15118
15119
15120
15121
15122
15123
15124
15125
15126
15127
15128
15129
15130
15131
15132
15133
15134
15135
15136
15137
15138
15139
15140
15141
15142
15143
15144
15145
15146
15147
15148
15149
15150
15151
15152
15153
15154
15155
15156
15157
15158
15159
15160
15161
15162
15163
15164
15165
15166
15167
15168
15169
15170
15171
15172
15173
15174
15175
15176
15177
15178
15179
15180
15181
15182
15183
15184
15185
15186
15187
15188
15189
15190
15191
15192
15193
15194
15195
15196
15197
15198
15199
15200
15201
15202
15203
15204
15205
15206
15207
15208
15209
15210
15211
15212
15213
15214
15215
15216
15217
15218
15219
15220
15221
15222
15223
15224
15225
15226
15227
15228
15229
15230
15231
15232
15233
15234
15235
15236
15237
15238
15239
15240
15241
15242
15243
15244
15245
15246
15247
15248
15249
15250
15251
15252
15253
15254
15255
15256
15257
15258
15259
15260
15261
15262
15263
15264
15265
15266
15267
15268
15269
15270
15271
15272
15273
15274
15275
15276
15277
15278
15279
15280
15281
15282
15283
15284
15285
15286
15287
15288
15289
15290
15291
15292
15293
15294
15295
15296
15297
15298
15299
15300
15301
15302
15303
15304
15305
15306
15307
15308
15309
15310
15311
15312
15313
15314
15315
15316
15317
15318
15319
15320
15321
15322
15323
15324
15325
15326
15327
15328
15329
15330
15331
15332
15333
15334
15335
15336
15337
15338
15339
15340
15341
15342
15343
15344
15345
15346
15347
15348
15349
15350
15351
15352
15353
15354
15355
15356
15357
15358
15359
15360
15361
15362
15363
15364
15365
15366
15367
15368
15369
15370
15371
15372
15373
15374
15375
15376
15377
15378
15379
15380
15381
15382
15383
15384
15385
15386
15387
15388
15389
15390
15391
15392
15393
15394
15395
15396
15397
15398
15399
15400
15401
15402
15403
15404
15405
15406
15407
15408
15409
15410
15411
15412
15413
15414
15415
15416
15417
15418
15419
15420
15421
15422
15423
15424
15425
15426
15427
15428
15429
15430
15431
15432
15433
15434
15435
15436
15437
15438
15439
15440
15441
15442
15443
15444
15445
15446
15447
15448
15449
15450
15451
15452
15453
15454
15455
15456
15457
15458
15459
15460
15461
15462
15463
15464
15465
15466
15467
15468
15469
15470
15471
15472
15473
15474
15475
15476
15477
15478
15479
15480
15481
15482
15483
15484
15485
15486
15487
15488
15489
15490
15491
15492
15493
15494
15495
15496
15497
15498
15499
15500
15501
15502
15503
15504
15505
15506
15507
15508
15509
15510
15511
15512
15513
15514
15515
15516
15517
15518
15519
15520
15521
15522
15523
15524
15525
15526
15527
15528
15529
15530
15531
15532
15533
15534
15535
15536
15537
15538
15539
15540
15541
15542
15543
15544
15545
15546
15547
15548
15549
15550
15551
15552
15553
15554
15555
15556
15557
15558
15559
15560
15561
15562
15563
15564
15565
15566
15567
15568
15569
15570
15571
15572
15573
15574
15575
15576
15577
15578
15579
15580
15581
15582
15583
15584
15585
15586
15587
15588
15589
15590
15591
15592
15593
15594
15595
15596
15597
15598
15599
15600
15601
15602
15603
15604
15605
15606
15607
15608
15609
15610
15611
15612
15613
15614
15615
15616
15617
15618
15619
15620
15621
15622
15623
15624
15625
15626
15627
15628
15629
15630
15631
15632
15633
15634
15635
15636
15637
15638
15639
15640
15641
15642
15643
15644
15645
15646
15647
15648
15649
15650
15651
15652
15653
15654
15655
15656
15657
15658
15659
15660
15661
15662
15663
15664
15665
15666
15667
15668
15669
15670
15671
15672
15673
15674
15675
15676
15677
15678
15679
15680
15681
15682
15683
15684
15685
15686
15687
15688
15689
15690
15691
15692
15693
15694
15695
15696
15697
15698
15699
15700
15701
15702
15703
15704
15705
15706
15707
15708
15709
15710
15711
15712
15713
15714
15715
15716
15717
15718
15719
15720
15721
15722
15723
15724
15725
15726
15727
15728
15729
15730
15731
15732
15733
15734
15735
15736
15737
15738
15739
15740
15741
15742
15743
15744
15745
15746
15747
15748
15749
15750
15751
15752
15753
15754
15755
15756
15757
15758
15759
15760
15761
15762
15763
15764
15765
15766
15767
15768
15769
15770
15771
15772
15773
15774
15775
15776
15777
15778
15779
15780
15781
15782
15783
15784
15785
15786
15787
15788
15789
15790
15791
15792
15793
15794
15795
15796
15797
15798
15799
15800
15801
15802
15803
15804
15805
15806
15807
15808
15809
15810
15811
15812
15813
15814
15815
15816
15817
15818
15819
15820
15821
15822
15823
15824
15825
15826
15827
15828
15829
15830
15831
15832
15833
15834
15835
15836
15837
15838
15839
15840
15841
15842
15843
15844
15845
15846
15847
15848
15849
15850
15851
15852
15853
15854
15855
15856
15857
15858
15859
15860
15861
15862
15863
15864
15865
15866
15867
15868
15869
15870
15871
15872
15873
15874
15875
15876
15877
15878
15879
15880
15881
15882
15883
15884
15885
15886
15887
15888
15889
15890
15891
15892
15893
15894
15895
15896
15897
15898
15899
15900
15901
15902
15903
15904
15905
15906
15907
15908
15909
15910
15911
15912
15913
15914
15915
15916
15917
15918
15919
15920
15921
15922
15923
15924
15925
15926
15927
15928
15929
15930
15931
15932
15933
15934
15935
15936
15937
15938
15939
15940
15941
15942
15943
15944
15945
15946
15947
15948
15949
15950
15951
15952
15953
15954
15955
15956
15957
15958
15959
15960
15961
15962
15963
15964
15965
15966
15967
15968
15969
15970
15971
15972
15973
15974
15975
15976
15977
15978
15979
15980
15981
15982
15983
15984
15985
15986
15987
15988
15989
15990
15991
15992
15993
15994
15995
15996
15997
15998
15999
16000
16001
16002
16003
16004
16005
16006
16007
16008
16009
16010
16011
16012
16013
16014
16015
16016
16017
16018
16019
16020
16021
16022
16023
16024
16025
16026
16027
16028
16029
16030
16031
16032
16033
16034
16035
16036
16037
16038
16039
16040
16041
16042
16043
16044
16045
16046
16047
16048
16049
16050
16051
16052
16053
16054
16055
16056
16057
16058
16059
16060
16061
16062
16063
16064
16065
16066
16067
16068
16069
16070
16071
16072
16073
16074
16075
16076
16077
16078
16079
16080
16081
16082
16083
16084
16085
16086
16087
16088
16089
16090
16091
16092
16093
16094
16095
16096
16097
16098
16099
16100
16101
16102
16103
16104
16105
16106
16107
16108
16109
16110
16111
16112
16113
16114
16115
16116
16117
16118
16119
16120
16121
16122
16123
16124
16125
16126
16127
16128
16129
16130
16131
16132
16133
16134
16135
16136
16137
16138
16139
16140
16141
16142
16143
16144
16145
16146
16147
16148
16149
16150
16151
16152
16153
16154
16155
16156
16157
16158
16159
16160
16161
16162
16163
16164
16165
16166
16167
16168
16169
16170
16171
16172
16173
16174
16175
16176
16177
16178
16179
16180
16181
16182
16183
16184
16185
16186
16187
16188
16189
16190
16191
16192
16193
16194
16195
16196
16197
16198
16199
16200
16201
16202
16203
16204
16205
16206
16207
16208
16209
16210
16211
16212
16213
16214
16215
16216
16217
16218
16219
16220
16221
16222
16223
16224
16225
16226
16227
16228
16229
16230
16231
16232
16233
16234
16235
16236
16237
16238
16239
16240
16241
16242
16243
16244
16245
16246
16247
16248
16249
16250
16251
16252
16253
16254
16255
16256
16257
16258
16259
16260
16261
16262
16263
16264
16265
16266
16267
16268
16269
16270
16271
16272
16273
16274
16275
16276
16277
16278
16279
16280
16281
16282
16283
16284
16285
16286
16287
16288
16289
16290
16291
16292
16293
16294
16295
16296
16297
16298
16299
16300
16301
16302
16303
16304
16305
16306
16307
16308
16309
16310
16311
16312
16313
16314
16315
16316
16317
16318
16319
16320
16321
16322
16323
16324
16325
16326
16327
16328
16329
16330
16331
16332
16333
16334
16335
16336
16337
16338
16339
16340
16341
16342
16343
16344
16345
16346
16347
16348
16349
16350
16351
16352
16353
16354
16355
16356
16357
16358
16359
16360
16361
16362
16363
16364
16365
16366
16367
16368
16369
16370
16371
16372
16373
16374
16375
16376
16377
16378
16379
16380
16381
16382
16383
16384
16385
16386
16387
16388
16389
16390
16391
16392
16393
16394
16395
16396
16397
16398
16399
16400
16401
16402
16403
16404
16405
16406
16407
16408
16409
16410
16411
16412
16413
16414
16415
16416
16417
16418
16419
16420
16421
16422
16423
16424
16425
16426
16427
16428
16429
16430
16431
16432
16433
16434
16435
16436
16437
16438
16439
16440
16441
16442
16443
16444
16445
16446
16447
16448
16449
16450
16451
16452
16453
16454
16455
16456
16457
16458
16459
16460
16461
16462
16463
16464
16465
16466
16467
16468
16469
16470
16471
16472
16473
16474
16475
16476
16477
16478
16479
16480
16481
16482
16483
16484
16485
16486
16487
16488
16489
16490
16491
16492
16493
16494
16495
16496
16497
16498
16499
16500
16501
16502
16503
16504
16505
16506
16507
16508
16509
16510
16511
16512
16513
16514
16515
16516
16517
16518
16519
16520
16521
16522
16523
16524
16525
16526
16527
16528
16529
16530
16531
16532
16533
16534
16535
16536
16537
16538
16539
16540
16541
16542
16543
16544
16545
16546
16547
16548
16549
16550
16551
16552
16553
16554
16555
16556
16557
16558
16559
16560
16561
16562
16563
16564
16565
16566
16567
16568
16569
16570
16571
16572
16573
16574
16575
16576
16577
16578
16579
16580
16581
16582
16583
16584
16585
16586
16587
16588
16589
16590
16591
16592
16593
16594
16595
16596
16597
16598
16599
16600
16601
16602
16603
16604
16605
16606
16607
16608
16609
16610
16611
16612
16613
16614
16615
16616
16617
16618
16619
16620
16621
16622
16623
16624
16625
16626
16627
16628
16629
16630
16631
16632
16633
16634
16635
16636
16637
16638
16639
16640
16641
16642
16643
16644
16645
16646
16647
16648
16649
16650
16651
16652
16653
16654
16655
16656
16657
16658
16659
16660
16661
16662
16663
16664
16665
16666
16667
16668
16669
16670
16671
16672
16673
16674
16675
16676
16677
16678
16679
16680
16681
16682
16683
16684
16685
16686
16687
16688
16689
16690
16691
16692
16693
16694
16695
16696
16697
16698
16699
16700
16701
16702
16703
16704
16705
16706
16707
16708
16709
16710
16711
16712
16713
16714
16715
16716
16717
16718
16719
16720
16721
16722
16723
16724
16725
16726
16727
16728
16729
16730
16731
16732
16733
16734
16735
16736
16737
16738
16739
16740
16741
16742
16743
16744
16745
16746
16747
16748
16749
16750
16751
16752
16753
16754
16755
16756
16757
16758
16759
16760
16761
16762
16763
16764
16765
16766
16767
16768
16769
16770
16771
16772
16773
16774
16775
16776
16777
16778
16779
16780
16781
16782
16783
16784
16785
16786
16787
16788
16789
16790
16791
16792
16793
16794
16795
16796
16797
16798
16799
16800
16801
16802
16803
16804
16805
16806
16807
16808
16809
16810
16811
16812
16813
16814
16815
16816
16817
16818
16819
16820
16821
16822
16823
16824
16825
16826
16827
16828
16829
16830
16831
16832
16833
16834
16835
16836
16837
16838
16839
16840
16841
16842
16843
16844
16845
16846
16847
16848
16849
16850
16851
16852
16853
16854
16855
16856
16857
16858
16859
16860
16861
16862
16863
16864
16865
16866
16867
16868
16869
16870
16871
16872
16873
16874
16875
16876
16877
16878
16879
16880
16881
16882
16883
16884
16885
16886
16887
16888
16889
16890
16891
16892
16893
16894
16895
16896
16897
16898
16899
16900
16901
16902
16903
16904
16905
16906
16907
16908
16909
16910
16911
16912
16913
16914
16915
16916
16917
16918
16919
16920
16921
16922
16923
16924
16925
16926
16927
16928
16929
16930
16931
16932
16933
16934
16935
16936
16937
16938
16939
16940
16941
16942
16943
16944
16945
16946
16947
16948
16949
16950
16951
16952
16953
16954
16955
16956
16957
16958
16959
16960
16961
16962
16963
16964
16965
16966
16967
16968
16969
16970
16971
16972
16973
16974
16975
16976
16977
16978
16979
16980
16981
16982
16983
16984
16985
16986
16987
16988
16989
16990
16991
16992
16993
16994
16995
16996
16997
16998
16999
17000
17001
17002
17003
17004
17005
17006
17007
17008
17009
17010
17011
17012
17013
17014
17015
17016
17017
17018
17019
17020
17021
17022
17023
17024
17025
17026
17027
17028
17029
17030
17031
17032
17033
17034
17035
17036
17037
17038
17039
17040
17041
17042
17043
17044
17045
17046
17047
17048
17049
17050
17051
17052
17053
17054
17055
17056
17057
17058
17059
17060
17061
17062
17063
17064
17065
17066
17067
17068
17069
17070
17071
17072
17073
17074
17075
17076
17077
17078
17079
17080
17081
17082
17083
17084
17085
17086
17087
17088
17089
17090
17091
17092
17093
17094
17095
17096
17097
17098
17099
17100
17101
17102
17103
17104
17105
17106
17107
17108
17109
17110
17111
17112
17113
17114
17115
17116
17117
17118
17119
17120
17121
17122
17123
17124
17125
17126
17127
17128
17129
17130
17131
17132
17133
17134
17135
17136
17137
17138
17139
17140
17141
17142
17143
17144
17145
17146
17147
17148
17149
17150
17151
17152
17153
17154
17155
17156
17157
17158
17159
17160
17161
17162
17163
17164
17165
17166
17167
17168
17169
17170
17171
17172
17173
17174
17175
17176
17177
17178
17179
17180
17181
17182
17183
17184
17185
17186
17187
17188
17189
17190
17191
17192
17193
17194
17195
17196
17197
17198
17199
17200
17201
17202
17203
17204
17205
17206
17207
17208
17209
17210
17211
17212
17213
17214
17215
17216
17217
17218
17219
17220
17221
17222
17223
17224
17225
17226
17227
17228
17229
17230
17231
17232
17233
17234
17235
17236
17237
17238
17239
17240
17241
17242
17243
17244
17245
17246
17247
17248
17249
17250
17251
17252
17253
17254
17255
17256
17257
17258
17259
17260
17261
17262
17263
17264
17265
17266
17267
17268
17269
17270
17271
17272
17273
17274
17275
17276
17277
17278
17279
17280
17281
17282
17283
17284
17285
17286
17287
17288
17289
17290
17291
17292
17293
17294
17295
17296
17297
17298
17299
17300
17301
17302
17303
17304
17305
17306
17307
17308
17309
17310
17311
17312
17313
17314
17315
17316
17317
17318
17319
17320
17321
17322
17323
17324
17325
17326
17327
17328
17329
17330
17331
17332
17333
17334
17335
17336
17337
17338
17339
17340
17341
17342
17343
17344
17345
17346
17347
17348
17349
17350
17351
17352
17353
17354
17355
17356
17357
17358
17359
17360
17361
17362
17363
17364
17365
17366
17367
17368
17369
17370
17371
17372
17373
17374
17375
17376
17377
17378
17379
17380
17381
17382
17383
17384
17385
17386
17387
17388
17389
17390
17391
17392
17393
17394
17395
17396
17397
17398
17399
17400
17401
17402
17403
17404
17405
17406
17407
17408
17409
17410
17411
17412
17413
17414
17415
17416
17417
17418
17419
17420
17421
17422
17423
17424
17425
17426
17427
17428
17429
17430
17431
17432
17433
17434
17435
17436
17437
17438
17439
17440
17441
17442
17443
17444
17445
17446
17447
17448
17449
17450
17451
17452
17453
17454
17455
17456
17457
17458
17459
17460
17461
17462
17463
17464
17465
17466
17467
17468
17469
17470
17471
17472
17473
17474
17475
17476
17477
17478
17479
17480
17481
17482
17483
17484
17485
17486
17487
17488
17489
17490
17491
17492
17493
17494
17495
17496
17497
17498
17499
17500
17501
17502
17503
17504
17505
17506
17507
17508
17509
17510
17511
17512
17513
17514
17515
17516
17517
17518
17519
17520
17521
17522
17523
17524
17525
17526
17527
17528
17529
17530
17531
17532
17533
17534
17535
17536
17537
17538
17539
17540
17541
17542
17543
17544
17545
17546
17547
17548
17549
17550
17551
17552
17553
17554
17555
17556
17557
17558
17559
17560
17561
17562
17563
17564
17565
17566
17567
17568
17569
17570
17571
17572
17573
17574
17575
17576
17577
17578
17579
17580
17581
17582
17583
17584
17585
17586
17587
17588
17589
17590
17591
17592
17593
17594
17595
17596
17597
17598
17599
17600
17601
17602
17603
17604
17605
17606
17607
17608
17609
17610
17611
17612
17613
17614
17615
17616
17617
17618
17619
17620
17621
17622
17623
17624
17625
17626
17627
17628
17629
17630
17631
17632
17633
17634
17635
17636
17637
17638
17639
17640
17641
17642
17643
17644
17645
17646
17647
17648
17649
17650
17651
17652
17653
17654
17655
17656
17657
17658
17659
17660
17661
17662
17663
17664
17665
17666
17667
17668
17669
17670
17671
17672
17673
17674
17675
17676
17677
17678
17679
17680
17681
17682
17683
17684
17685
17686
17687
17688
17689
17690
17691
17692
17693
17694
17695
17696
17697
17698
17699
17700
17701
17702
17703
17704
17705
17706
17707
17708
17709
17710
17711
17712
17713
17714
17715
17716
17717
17718
17719
17720
17721
17722
17723
17724
17725
17726
17727
17728
17729
17730
17731
17732
17733
17734
17735
17736
17737
17738
17739
17740
17741
17742
17743
17744
17745
17746
17747
17748
17749
17750
17751
17752
17753
17754
17755
17756
17757
17758
17759
17760
17761
17762
17763
17764
17765
17766
17767
17768
17769
17770
17771
17772
17773
17774
17775
17776
17777
17778
17779
17780
17781
17782
17783
17784
17785
17786
17787
17788
17789
17790
17791
17792
17793
17794
17795
17796
17797
17798
17799
17800
17801
17802
17803
17804
17805
17806
17807
17808
17809
17810
17811
17812
17813
17814
17815
17816
17817
17818
17819
17820
17821
17822
17823
17824
17825
17826
17827
17828
17829
17830
17831
17832
17833
17834
17835
17836
17837
17838
17839
17840
17841
17842
17843
17844
17845
17846
17847
17848
17849
17850
17851
17852
17853
17854
17855
17856
17857
17858
17859
17860
17861
17862
17863
17864
17865
17866
17867
17868
17869
17870
17871
17872
17873
17874
17875
17876
17877
17878
17879
17880
17881
17882
17883
17884
17885
17886
17887
17888
17889
17890
17891
17892
17893
17894
17895
17896
17897
17898
17899
17900
17901
17902
17903
17904
17905
17906
17907
17908
17909
17910
17911
17912
17913
17914
17915
17916
17917
17918
17919
17920
17921
17922
17923
17924
17925
17926
17927
17928
17929
17930
17931
17932
17933
17934
17935
17936
17937
17938
17939
17940
17941
17942
17943
17944
17945
17946
17947
17948
17949
17950
17951
17952
17953
17954
17955
17956
17957
17958
17959
17960
17961
17962
17963
17964
17965
17966
17967
17968
17969
17970
17971
17972
17973
17974
17975
17976
17977
17978
17979
17980
17981
17982
17983
17984
17985
17986
17987
17988
17989
17990
17991
17992
17993
17994
17995
17996
17997
17998
17999
18000
18001
18002
18003
18004
18005
18006
18007
18008
18009
18010
18011
18012
18013
18014
18015
18016
18017
18018
18019
18020
18021
18022
18023
18024
18025
18026
18027
18028
18029
18030
18031
18032
18033
18034
18035
18036
18037
18038
18039
18040
18041
18042
18043
18044
18045
18046
18047
18048
18049
18050
18051
18052
18053
18054
18055
18056
18057
18058
18059
18060
18061
18062
18063
18064
18065
18066
18067
18068
18069
18070
18071
18072
18073
18074
18075
18076
18077
18078
18079
18080
18081
18082
18083
18084
18085
18086
18087
18088
18089
18090
18091
18092
18093
18094
18095
18096
18097
18098
18099
18100
18101
18102
18103
18104
18105
18106
18107
18108
18109
18110
18111
18112
18113
18114
18115
18116
18117
18118
18119
18120
18121
18122
18123
18124
18125
18126
18127
18128
18129
18130
18131
18132
18133
18134
18135
18136
18137
18138
18139
18140
18141
18142
18143
18144
18145
18146
18147
18148
18149
18150
18151
18152
18153
18154
18155
18156
18157
18158
18159
18160
18161
18162
18163
18164
18165
18166
18167
18168
18169
18170
18171
18172
18173
18174
18175
18176
18177
18178
18179
18180
18181
18182
18183
18184
18185
18186
18187
18188
18189
18190
18191
18192
18193
18194
18195
18196
18197
18198
18199
18200
18201
18202
18203
18204
18205
18206
18207
18208
18209
18210
18211
18212
18213
18214
18215
18216
18217
18218
18219
18220
18221
18222
18223
18224
18225
18226
18227
18228
18229
18230
18231
18232
18233
18234
18235
18236
18237
18238
18239
18240
18241
18242
18243
18244
18245
18246
18247
18248
18249
18250
18251
18252
18253
18254
18255
18256
18257
18258
18259
18260
18261
18262
18263
18264
18265
18266
18267
18268
18269
18270
18271
18272
18273
18274
18275
18276
18277
18278
18279
18280
18281
18282
18283
18284
18285
18286
18287
18288
18289
18290
18291
18292
18293
18294
18295
18296
18297
18298
18299
18300
18301
18302
18303
18304
18305
18306
18307
18308
18309
18310
18311
18312
18313
18314
18315
18316
18317
18318
18319
18320
18321
18322
18323
18324
18325
18326
18327
18328
18329
18330
18331
18332
18333
18334
18335
18336
18337
18338
18339
18340
18341
18342
18343
18344
18345
18346
18347
18348
18349
18350
18351
18352
18353
18354
18355
18356
18357
18358
18359
18360
18361
18362
18363
18364
18365
18366
18367
18368
18369
18370
18371
18372
18373
18374
18375
18376
18377
18378
18379
18380
18381
18382
18383
18384
18385
18386
18387
18388
18389
18390
18391
18392
18393
18394
18395
18396
18397
18398
18399
18400
18401
18402
18403
18404
18405
18406
18407
18408
18409
18410
18411
18412
18413
18414
18415
18416
18417
18418
18419
18420
18421
18422
18423
18424
18425
18426
18427
18428
18429
18430
18431
18432
18433
18434
18435
18436
18437
18438
18439
18440
18441
18442
18443
18444
18445
18446
18447
18448
18449
18450
18451
18452
18453
18454
18455
18456
18457
18458
18459
18460
18461
18462
18463
18464
18465
18466
18467
18468
18469
18470
18471
18472
18473
18474
18475
18476
18477
18478
18479
18480
18481
18482
18483
18484
18485
18486
18487
18488
18489
18490
18491
18492
18493
18494
18495
18496
18497
18498
18499
18500
18501
18502
18503
18504
18505
18506
18507
18508
18509
18510
18511
18512
18513
18514
18515
18516
18517
18518
18519
18520
18521
18522
18523
18524
18525
18526
18527
18528
18529
18530
18531
18532
18533
18534
18535
18536
18537
18538
18539
18540
18541
18542
18543
18544
18545
18546
18547
18548
18549
18550
18551
18552
18553
18554
18555
18556
18557
18558
18559
18560
18561
18562
18563
18564
18565
18566
18567
18568
18569
18570
18571
18572
18573
18574
18575
18576
18577
18578
18579
18580
18581
18582
18583
18584
18585
18586
18587
18588
18589
18590
18591
18592
18593
18594
18595
18596
18597
18598
18599
18600
18601
18602
18603
18604
18605
18606
18607
18608
18609
18610
18611
18612
18613
18614
18615
18616
18617
18618
18619
18620
18621
18622
18623
18624
18625
18626
18627
18628
18629
18630
18631
18632
18633
18634
18635
18636
18637
18638
18639
18640
18641
18642
18643
18644
18645
18646
18647
18648
18649
18650
18651
18652
18653
18654
18655
18656
18657
18658
18659
18660
18661
18662
18663
18664
18665
18666
18667
18668
18669
18670
18671
18672
18673
18674
18675
18676
18677
18678
18679
18680
18681
18682
18683
18684
18685
18686
18687
18688
18689
18690
18691
18692
18693
18694
18695
18696
18697
18698
18699
18700
18701
18702
18703
18704
18705
18706
18707
18708
18709
18710
18711
18712
18713
18714
18715
18716
18717
18718
18719
18720
18721
18722
18723
18724
18725
18726
18727
18728
18729
18730
18731
18732
18733
18734
18735
18736
18737
18738
18739
18740
18741
18742
18743
18744
18745
18746
18747
18748
18749
18750
18751
18752
18753
18754
18755
18756
18757
18758
18759
18760
18761
18762
18763
18764
18765
18766
18767
18768
18769
18770
18771
18772
18773
18774
18775
18776
18777
18778
18779
18780
18781
18782
18783
18784
18785
18786
18787
18788
18789
18790
18791
18792
18793
18794
18795
18796
18797
18798
18799
18800
18801
18802
18803
18804
18805
18806
18807
18808
18809
18810
18811
18812
18813
18814
18815
18816
18817
18818
18819
18820
18821
18822
18823
18824
18825
18826
18827
18828
18829
18830
18831
18832
18833
18834
18835
18836
18837
18838
18839
18840
18841
18842
18843
18844
18845
18846
18847
18848
18849
18850
18851
18852
18853
18854
18855
18856
18857
18858
18859
18860
18861
18862
18863
18864
18865
18866
18867
18868
18869
18870
18871
18872
18873
18874
18875
18876
18877
18878
18879
18880
18881
18882
18883
18884
18885
18886
18887
18888
18889
18890
18891
18892
18893
18894
18895
18896
18897
18898
18899
18900
18901
18902
18903
18904
18905
18906
18907
18908
18909
18910
18911
18912
18913
18914
18915
18916
18917
18918
18919
18920
18921
18922
18923
18924
18925
18926
18927
18928
18929
18930
18931
18932
18933
18934
18935
18936
18937
18938
18939
18940
18941
18942
18943
18944
18945
18946
18947
18948
18949
18950
18951
18952
18953
18954
18955
18956
18957
18958
18959
18960
18961
18962
18963
18964
18965
18966
18967
18968
18969
18970
18971
18972
18973
18974
18975
18976
18977
18978
18979
18980
18981
18982
18983
18984
18985
18986
18987
18988
18989
18990
18991
18992
18993
18994
18995
18996
18997
18998
18999
19000
19001
19002
19003
19004
19005
19006
19007
19008
19009
19010
19011
19012
19013
19014
19015
19016
19017
19018
19019
19020
19021
19022
19023
19024
19025
19026
19027
19028
19029
19030
19031
19032
19033
19034
19035
19036
19037
19038
19039
19040
19041
19042
19043
19044
19045
19046
19047
19048
19049
19050
19051
19052
19053
19054
19055
19056
19057
19058
19059
19060
19061
19062
19063
19064
19065
19066
19067
19068
19069
19070
19071
19072
19073
19074
19075
19076
19077
19078
19079
19080
19081
19082
19083
19084
19085
19086
19087
19088
19089
19090
19091
19092
19093
19094
19095
19096
19097
19098
19099
19100
19101
19102
19103
19104
19105
19106
19107
19108
19109
19110
19111
19112
19113
19114
19115
19116
19117
19118
19119
19120
19121
19122
19123
19124
19125
19126
19127
19128
19129
19130
19131
19132
19133
19134
19135
19136
19137
19138
19139
19140
19141
19142
19143
19144
19145
19146
19147
19148
19149
19150
19151
19152
19153
19154
19155
19156
19157
19158
19159
19160
19161
19162
19163
19164
19165
19166
19167
19168
19169
19170
19171
19172
19173
19174
19175
19176
19177
19178
19179
19180
19181
19182
19183
19184
19185
19186
19187
19188
19189
19190
19191
19192
19193
19194
19195
19196
19197
19198
19199
19200
19201
19202
19203
19204
19205
19206
19207
19208
19209
19210
19211
19212
19213
19214
19215
19216
19217
19218
19219
19220
19221
19222
19223
19224
19225
19226
19227
19228
19229
19230
19231
19232
19233
19234
19235
19236
19237
19238
19239
19240
19241
19242
19243
19244
19245
19246
19247
19248
19249
19250
19251
19252
19253
19254
19255
19256
19257
19258
19259
19260
19261
19262
19263
19264
19265
19266
19267
19268
19269
19270
19271
19272
19273
19274
19275
19276
19277
19278
19279
19280
19281
19282
19283
19284
19285
19286
19287
19288
19289
19290
19291
19292
19293
19294
19295
19296
19297
19298
19299
19300
19301
19302
19303
19304
19305
19306
19307
19308
19309
19310
19311
19312
19313
19314
19315
19316
19317
19318
19319
19320
19321
19322
19323
19324
19325
19326
19327
19328
19329
19330
19331
19332
19333
19334
19335
19336
19337
19338
19339
19340
19341
19342
19343
19344
19345
19346
19347
19348
19349
19350
19351
19352
19353
19354
19355
19356
19357
19358
19359
19360
19361
19362
19363
19364
19365
19366
19367
19368
19369
19370
19371
19372
19373
19374
19375
19376
19377
19378
19379
19380
19381
19382
19383
19384
19385
19386
19387
19388
19389
19390
19391
19392
19393
19394
19395
19396
19397
19398
19399
19400
19401
19402
19403
19404
19405
19406
19407
19408
19409
19410
19411
19412
19413
19414
19415
19416
19417
19418
19419
19420
19421
19422
19423
19424
19425
19426
19427
19428
19429
19430
19431
19432
19433
19434
19435
19436
19437
19438
19439
19440
19441
19442
19443
19444
19445
19446
19447
19448
19449
19450
19451
19452
19453
19454
19455
19456
19457
19458
19459
19460
19461
19462
19463
19464
19465
19466
19467
19468
19469
19470
19471
19472
19473
19474
19475
19476
19477
19478
19479
19480
19481
19482
19483
19484
19485
19486
19487
19488
19489
19490
19491
19492
19493
19494
19495
19496
19497
19498
19499
19500
19501
19502
19503
19504
19505
19506
19507
19508
19509
19510
19511
19512
19513
19514
19515
19516
19517
19518
19519
19520
19521
19522
19523
19524
19525
19526
19527
19528
19529
19530
19531
19532
19533
19534
19535
19536
19537
19538
19539
19540
19541
19542
19543
19544
19545
19546
19547
19548
19549
19550
19551
19552
19553
19554
19555
19556
19557
19558
19559
19560
19561
19562
19563
19564
19565
19566
19567
19568
19569
19570
19571
19572
19573
19574
19575
19576
19577
19578
19579
19580
19581
19582
19583
19584
19585
19586
19587
19588
19589
19590
19591
19592
19593
19594
19595
19596
19597
19598
19599
19600
19601
19602
19603
19604
19605
19606
19607
19608
19609
19610
19611
19612
19613
19614
19615
19616
19617
19618
19619
19620
19621
19622
19623
19624
19625
19626
19627
19628
19629
19630
19631
19632
19633
19634
19635
19636
19637
19638
19639
19640
19641
19642
19643
19644
19645
19646
19647
19648
19649
19650
19651
19652
19653
19654
19655
19656
19657
19658
19659
19660
19661
19662
19663
19664
19665
19666
19667
19668
19669
19670
19671
19672
19673
19674
19675
19676
19677
19678
19679
19680
19681
19682
19683
19684
19685
19686
19687
19688
19689
19690
19691
19692
19693
19694
19695
19696
19697
19698
19699
19700
19701
19702
19703
19704
19705
19706
19707
19708
19709
19710
19711
19712
19713
19714
19715
19716
19717
19718
19719
19720
19721
19722
19723
19724
19725
19726
19727
19728
19729
19730
19731
19732
19733
19734
19735
19736
19737
19738
19739
19740
19741
19742
19743
19744
19745
19746
19747
19748
19749
19750
19751
19752
19753
19754
19755
19756
19757
19758
19759
19760
19761
19762
19763
19764
19765
19766
19767
19768
19769
19770
19771
19772
19773
19774
19775
19776
19777
19778
19779
19780
19781
19782
19783
19784
19785
19786
19787
19788
19789
19790
19791
19792
19793
19794
19795
19796
19797
19798
19799
19800
19801
19802
19803
19804
19805
19806
19807
19808
19809
19810
19811
19812
19813
19814
19815
19816
19817
19818
19819
19820
19821
19822
19823
19824
19825
19826
19827
19828
19829
19830
19831
19832
19833
19834
19835
19836
19837
19838
19839
19840
19841
19842
19843
19844
19845
19846
19847
19848
19849
19850
19851
19852
19853
19854
19855
19856
19857
19858
19859
19860
19861
19862
19863
19864
19865
19866
19867
19868
19869
19870
19871
19872
19873
19874
19875
19876
19877
19878
19879
19880
19881
19882
19883
19884
19885
19886
19887
19888
19889
19890
19891
19892
19893
19894
19895
19896
19897
19898
19899
19900
19901
19902
19903
19904
19905
19906
19907
19908
19909
19910
19911
19912
19913
19914
19915
19916
19917
19918
19919
19920
19921
19922
19923
19924
19925
19926
19927
19928
19929
19930
19931
19932
19933
19934
19935
19936
19937
19938
19939
19940
19941
19942
19943
19944
19945
19946
19947
19948
19949
19950
19951
19952
19953
19954
19955
19956
19957
19958
19959
19960
19961
19962
19963
19964
19965
19966
19967
19968
19969
19970
19971
19972
19973
19974
19975
19976
19977
19978
19979
19980
19981
19982
19983
19984
19985
19986
19987
19988
19989
19990
19991
19992
19993
19994
19995
19996
19997
19998
19999
20000
20001
20002
20003
20004
20005
20006
20007
20008
20009
20010
20011
20012
20013
20014
20015
20016
20017
20018
20019
20020
20021
20022
20023
20024
20025
20026
20027
20028
20029
20030
20031
20032
20033
20034
20035
20036
20037
20038
20039
20040
20041
20042
20043
20044
20045
20046
20047
20048
20049
20050
20051
20052
20053
20054
20055
20056
20057
20058
20059
20060
20061
20062
20063
20064
20065
20066
20067
20068
20069
20070
20071
20072
20073
20074
20075
20076
20077
20078
20079
20080
20081
20082
20083
20084
20085
20086
20087
20088
20089
20090
20091
20092
20093
20094
20095
20096
20097
20098
20099
20100
20101
20102
20103
20104
20105
20106
20107
20108
20109
20110
20111
20112
20113
20114
20115
20116
20117
20118
20119
20120
20121
20122
20123
20124
20125
20126
20127
20128
20129
20130
20131
20132
20133
20134
20135
20136
20137
20138
20139
20140
20141
20142
20143
20144
20145
20146
20147
20148
20149
20150
20151
20152
20153
20154
20155
20156
20157
20158
20159
20160
20161
20162
20163
20164
20165
20166
20167
20168
20169
20170
20171
20172
20173
20174
20175
20176
20177
20178
20179
20180
20181
20182
20183
20184
20185
20186
20187
20188
20189
20190
20191
20192
20193
20194
20195
20196
20197
20198
20199
20200
20201
20202
20203
20204
20205
20206
20207
20208
20209
20210
20211
20212
20213
20214
20215
20216
20217
20218
20219
20220
20221
20222
20223
20224
20225
20226
20227
20228
20229
20230
20231
20232
20233
20234
20235
20236
20237
20238
20239
20240
20241
20242
20243
20244
20245
20246
20247
20248
20249
20250
20251
20252
20253
20254
20255
20256
20257
20258
20259
20260
20261
20262
20263
20264
20265
20266
20267
20268
20269
20270
20271
20272
20273
20274
20275
20276
20277
20278
20279
20280
20281
20282
20283
20284
20285
20286
20287
20288
20289
20290
20291
20292
20293
20294
20295
20296
20297
20298
20299
20300
20301
20302
20303
20304
20305
20306
20307
20308
20309
20310
20311
20312
20313
20314
20315
20316
20317
20318
20319
20320
20321
20322
20323
20324
20325
20326
20327
20328
20329
20330
20331
20332
20333
20334
20335
20336
20337
20338
20339
20340
20341
20342
20343
20344
20345
20346
20347
20348
20349
20350
20351
20352
20353
20354
20355
20356
20357
20358
20359
20360
20361
20362
20363
20364
20365
20366
20367
20368
20369
20370
20371
20372
20373
20374
20375
20376
20377
20378
20379
20380
20381
20382
20383
20384
20385
20386
20387
20388
20389
20390
20391
20392
20393
20394
20395
20396
20397
20398
20399
20400
20401
20402
20403
20404
20405
20406
20407
20408
20409
20410
20411
20412
20413
20414
20415
20416
20417
20418
20419
20420
20421
20422
20423
20424
20425
20426
20427
20428
20429
20430
20431
20432
20433
20434
20435
20436
20437
20438
20439
20440
20441
20442
20443
20444
20445
20446
20447
20448
20449
20450
20451
20452
20453
20454
20455
20456
20457
20458
20459
20460
20461
20462
20463
20464
20465
20466
20467
20468
20469
20470
20471
20472
20473
20474
20475
20476
20477
20478
20479
20480
20481
20482
20483
20484
20485
20486
20487
20488
20489
20490
20491
20492
20493
20494
20495
20496
20497
20498
20499
20500
20501
20502
20503
20504
20505
20506
20507
20508
20509
20510
20511
20512
20513
20514
20515
20516
20517
20518
20519
20520
20521
20522
20523
20524
20525
20526
20527
20528
20529
20530
20531
20532
20533
20534
20535
20536
20537
20538
20539
20540
20541
20542
20543
20544
20545
20546
20547
20548
20549
20550
20551
20552
20553
20554
20555
20556
20557
20558
20559
20560
20561
20562
20563
20564
20565
20566
20567
20568
20569
20570
20571
20572
20573
20574
20575
20576
20577
20578
20579
20580
20581
20582
20583
20584
20585
20586
20587
20588
20589
20590
20591
20592
20593
20594
20595
20596
20597
20598
20599
20600
20601
20602
20603
20604
20605
20606
20607
20608
20609
20610
20611
20612
20613
20614
20615
20616
20617
20618
20619
20620
20621
20622
20623
20624
20625
20626
20627
20628
20629
20630
20631
20632
20633
20634
20635
20636
20637
20638
20639
20640
20641
20642
20643
20644
20645
20646
20647
20648
20649
20650
20651
20652
20653
20654
20655
20656
20657
20658
20659
20660
20661
20662
20663
20664
20665
20666
20667
20668
20669
20670
20671
20672
20673
20674
20675
20676
20677
20678
20679
20680
20681
20682
20683
20684
20685
20686
20687
20688
20689
20690
20691
20692
20693
20694
20695
20696
20697
20698
20699
20700
20701
20702
20703
20704
20705
20706
20707
20708
20709
20710
20711
20712
20713
20714
20715
20716
20717
20718
20719
20720
20721
20722
20723
20724
20725
20726
20727
20728
20729
20730
20731
20732
20733
20734
20735
20736
20737
20738
20739
20740
20741
20742
20743
20744
20745
20746
20747
20748
20749
20750
20751
20752
20753
20754
20755
20756
20757
20758
20759
20760
20761
20762
20763
20764
20765
20766
20767
20768
20769
20770
20771
20772
20773
20774
20775
20776
20777
20778
20779
20780
20781
20782
20783
20784
20785
20786
20787
20788
20789
20790
20791
20792
20793
20794
20795
20796
20797
20798
20799
20800
20801
20802
20803
20804
20805
20806
20807
20808
20809
20810
20811
20812
20813
20814
20815
20816
20817
20818
20819
20820
20821
20822
20823
20824
20825
20826
20827
20828
20829
20830
20831
20832
20833
20834
20835
20836
20837
20838
20839
20840
20841
20842
20843
20844
20845
20846
20847
20848
20849
20850
20851
20852
20853
20854
20855
20856
20857
20858
20859
20860
20861
20862
20863
20864
20865
20866
20867
20868
20869
20870
20871
20872
20873
20874
20875
20876
20877
20878
20879
20880
20881
20882
20883
20884
20885
20886
20887
20888
20889
20890
20891
20892
20893
20894
20895
20896
20897
20898
20899
20900
20901
20902
20903
20904
20905
20906
20907
20908
20909
20910
20911
20912
20913
20914
20915
20916
20917
20918
20919
20920
20921
20922
20923
20924
20925
20926
20927
20928
20929
20930
20931
20932
20933
20934
20935
20936
20937
20938
20939
20940
20941
20942
20943
20944
20945
20946
20947
20948
20949
20950
20951
20952
20953
20954
20955
20956
20957
20958
20959
20960
20961
20962
20963
20964
20965
20966
20967
20968
20969
20970
20971
20972
20973
20974
20975
20976
20977
20978
20979
20980
20981
20982
20983
20984
20985
20986
20987
20988
20989
20990
20991
20992
20993
20994
20995
20996
20997
20998
20999
21000
21001
21002
21003
21004
21005
21006
21007
21008
21009
21010
21011
21012
21013
21014
21015
21016
21017
21018
21019
21020
21021
21022
21023
21024
21025
21026
21027
21028
21029
21030
21031
21032
21033
21034
21035
21036
21037
21038
21039
21040
21041
21042
21043
21044
21045
21046
21047
21048
21049
21050
21051
21052
21053
21054
21055
21056
21057
21058
21059
21060
21061
21062
21063
21064
21065
21066
21067
21068
21069
21070
21071
21072
21073
21074
21075
21076
21077
21078
21079
21080
21081
21082
21083
21084
21085
21086
21087
21088
21089
21090
21091
21092
21093
21094
21095
21096
21097
21098
21099
21100
21101
21102
21103
21104
21105
21106
21107
21108
21109
21110
21111
21112
21113
21114
21115
21116
21117
21118
21119
21120
21121
21122
21123
21124
21125
21126
21127
21128
21129
21130
21131
21132
21133
21134
21135
21136
21137
21138
21139
21140
21141
21142
21143
21144
21145
21146
21147
21148
21149
21150
21151
21152
21153
21154
21155
21156
21157
21158
21159
21160
21161
21162
21163
21164
21165
21166
21167
21168
21169
21170
21171
21172
21173
21174
21175
21176
21177
21178
21179
21180
21181
21182
21183
21184
21185
21186
21187
21188
21189
21190
21191
21192
21193
21194
21195
21196
21197
21198
21199
21200
21201
21202
21203
21204
21205
21206
21207
21208
21209
21210
21211
21212
21213
21214
21215
21216
21217
21218
21219
21220
21221
21222
21223
21224
21225
21226
21227
21228
21229
21230
21231
21232
21233
21234
21235
21236
21237
21238
21239
21240
21241
21242
21243
21244
21245
21246
21247
21248
21249
21250
21251
21252
21253
21254
21255
21256
21257
21258
21259
21260
21261
21262
21263
21264
21265
21266
21267
21268
21269
21270
21271
21272
21273
21274
21275
21276
21277
21278
21279
21280
21281
21282
21283
21284
21285
21286
21287
21288
21289
21290
21291
21292
21293
21294
21295
21296
21297
21298
21299
21300
21301
21302
21303
21304
21305
21306
21307
21308
21309
21310
21311
21312
21313
21314
21315
21316
21317
21318
21319
21320
21321
21322
21323
21324
21325
21326
21327
21328
21329
21330
21331
21332
21333
21334
21335
21336
21337
21338
21339
21340
21341
21342
21343
21344
21345
21346
21347
21348
21349
21350
21351
21352
21353
21354
21355
21356
21357
21358
21359
21360
21361
21362
21363
21364
21365
21366
21367
21368
21369
21370
21371
21372
21373
21374
21375
21376
21377
21378
21379
21380
21381
21382
21383
21384
21385
21386
21387
21388
21389
21390
21391
21392
21393
21394
21395
21396
21397
21398
21399
21400
21401
21402
21403
21404
21405
21406
21407
21408
21409
21410
21411
21412
21413
21414
21415
21416
21417
21418
21419
21420
21421
21422
21423
21424
21425
21426
21427
21428
21429
21430
21431
21432
21433
21434
21435
21436
21437
21438
21439
21440
21441
21442
21443
21444
21445
21446
21447
21448
21449
21450
21451
21452
21453
21454
21455
21456
21457
21458
21459
21460
21461
21462
21463
21464
21465
21466
21467
21468
21469
21470
21471
21472
21473
21474
21475
21476
21477
21478
21479
21480
21481
21482
21483
21484
21485
21486
21487
21488
21489
21490
21491
21492
21493
21494
21495
21496
21497
21498
21499
21500
21501
21502
21503
21504
21505
21506
21507
21508
21509
21510
21511
21512
21513
21514
21515
21516
21517
21518
21519
21520
21521
21522
21523
21524
21525
21526
21527
21528
21529
21530
21531
21532
21533
21534
21535
21536
21537
21538
21539
21540
21541
21542
21543
21544
21545
21546
21547
21548
21549
21550
21551
21552
21553
21554
21555
21556
21557
21558
21559
21560
21561
21562
21563
21564
21565
21566
21567
21568
21569
21570
21571
21572
21573
21574
21575
21576
21577
21578
21579
21580
21581
21582
21583
21584
21585
21586
21587
21588
21589
21590
21591
21592
21593
21594
21595
21596
21597
21598
21599
21600
21601
21602
21603
21604
21605
21606
21607
21608
21609
21610
21611
21612
21613
21614
21615
21616
21617
21618
21619
21620
21621
21622
21623
21624
21625
21626
21627
21628
21629
21630
21631
21632
21633
21634
21635
21636
21637
21638
21639
21640
21641
21642
21643
21644
21645
21646
21647
21648
21649
21650
21651
21652
21653
21654
21655
21656
21657
21658
21659
21660
21661
21662
21663
21664
21665
21666
21667
21668
21669
21670
21671
21672
21673
21674
21675
21676
21677
21678
21679
21680
21681
21682
21683
21684
21685
21686
21687
21688
21689
21690
21691
21692
21693
21694
21695
21696
21697
21698
21699
21700
21701
21702
21703
21704
21705
21706
21707
21708
21709
21710
21711
21712
21713
21714
21715
21716
21717
21718
21719
21720
21721
21722
21723
21724
21725
21726
21727
21728
21729
21730
21731
21732
21733
21734
21735
21736
21737
21738
21739
21740
21741
21742
21743
21744
21745
21746
21747
21748
21749
21750
21751
21752
21753
21754
21755
21756
21757
21758
21759
21760
21761
21762
21763
21764
21765
21766
21767
21768
21769
21770
21771
21772
21773
21774
21775
21776
21777
21778
21779
21780
21781
21782
21783
21784
21785
21786
21787
21788
21789
21790
21791
21792
21793
21794
21795
21796
21797
21798
21799
21800
21801
21802
21803
21804
21805
21806
21807
21808
21809
21810
21811
21812
21813
21814
21815
21816
21817
21818
21819
21820
21821
21822
21823
21824
21825
21826
21827
21828
21829
21830
21831
21832
21833
21834
21835
21836
21837
21838
21839
21840
21841
21842
21843
21844
21845
21846
21847
21848
21849
21850
21851
21852
21853
21854
21855
21856
21857
21858
21859
21860
21861
21862
21863
21864
21865
21866
21867
21868
21869
21870
21871
21872
21873
21874
21875
21876
21877
21878
21879
21880
21881
21882
21883
21884
21885
21886
21887
21888
21889
21890
21891
21892
21893
21894
21895
21896
21897
21898
21899
21900
21901
21902
21903
21904
21905
21906
21907
21908
21909
21910
21911
21912
21913
21914
21915
21916
21917
21918
21919
21920
21921
21922
21923
21924
21925
21926
21927
21928
21929
21930
21931
21932
21933
21934
21935
21936
21937
21938
21939
21940
21941
21942
21943
21944
21945
21946
21947
21948
21949
21950
21951
21952
21953
21954
21955
21956
21957
21958
21959
21960
21961
21962
21963
21964
21965
21966
21967
21968
21969
21970
21971
21972
21973
21974
21975
21976
21977
21978
21979
21980
21981
21982
21983
21984
21985
21986
21987
21988
21989
21990
21991
21992
21993
21994
21995
21996
21997
21998
21999
22000
22001
22002
22003
22004
22005
22006
22007
22008
22009
22010
22011
22012
22013
22014
22015
22016
22017
22018
22019
22020
22021
22022
22023
22024
22025
22026
22027
22028
22029
22030
22031
22032
22033
22034
22035
22036
22037
22038
22039
22040
22041
22042
22043
22044
22045
22046
22047
22048
22049
22050
22051
22052
22053
22054
22055
22056
22057
22058
22059
22060
22061
22062
22063
22064
22065
22066
22067
22068
22069
22070
22071
22072
22073
22074
22075
22076
22077
22078
22079
22080
22081
22082
22083
22084
22085
22086
22087
22088
22089
22090
22091
22092
22093
22094
22095
22096
22097
22098
22099
22100
22101
22102
22103
22104
22105
22106
22107
22108
22109
22110
22111
22112
22113
22114
22115
22116
22117
22118
22119
22120
22121
22122
22123
22124
22125
22126
22127
22128
22129
22130
22131
22132
22133
22134
22135
22136
22137
22138
22139
22140
22141
22142
22143
22144
22145
22146
22147
22148
22149
22150
22151
22152
22153
22154
22155
22156
22157
22158
22159
22160
22161
22162
22163
22164
22165
22166
22167
22168
22169
22170
22171
22172
22173
22174
22175
22176
22177
22178
22179
22180
22181
22182
22183
22184
22185
22186
22187
22188
22189
22190
22191
22192
22193
22194
22195
22196
22197
22198
22199
22200
22201
22202
22203
22204
22205
22206
22207
22208
22209
22210
22211
22212
22213
22214
22215
22216
22217
22218
22219
22220
22221
22222
22223
22224
22225
22226
22227
22228
22229
22230
22231
22232
22233
22234
22235
22236
22237
22238
22239
22240
22241
22242
22243
22244
22245
22246
22247
22248
22249
22250
22251
22252
22253
22254
22255
22256
22257
22258
22259
22260
22261
22262
22263
22264
22265
22266
22267
22268
22269
22270
22271
22272
22273
22274
22275
22276
22277
22278
22279
22280
22281
22282
22283
22284
22285
22286
22287
22288
22289
22290
22291
22292
22293
22294
22295
22296
22297
22298
22299
22300
22301
22302
22303
22304
22305
22306
22307
22308
22309
22310
22311
22312
22313
22314
22315
22316
22317
22318
22319
22320
22321
22322
22323
22324
22325
22326
22327
22328
22329
22330
22331
22332
22333
22334
22335
22336
22337
22338
22339
22340
22341
22342
22343
22344
22345
22346
22347
22348
22349
22350
22351
22352
22353
22354
22355
22356
22357
22358
22359
22360
22361
22362
22363
22364
22365
22366
22367
22368
22369
22370
22371
22372
22373
22374
22375
22376
22377
22378
22379
22380
22381
22382
22383
22384
22385
22386
22387
22388
22389
22390
22391
22392
22393
22394
22395
22396
22397
22398
22399
22400
22401
22402
22403
22404
22405
22406
22407
22408
22409
22410
22411
22412
22413
22414
22415
22416
22417
22418
22419
22420
22421
22422
22423
22424
22425
22426
22427
22428
22429
22430
22431
22432
22433
22434
22435
22436
22437
22438
22439
22440
22441
22442
22443
22444
22445
22446
22447
22448
22449
22450
22451
22452
22453
22454
22455
22456
22457
22458
22459
22460
22461
22462
22463
22464
22465
22466
22467
22468
22469
22470
22471
22472
22473
22474
22475
22476
22477
22478
22479
22480
22481
22482
22483
22484
22485
22486
22487
22488
22489
22490
22491
22492
22493
22494
22495
22496
22497
22498
22499
22500
22501
22502
22503
22504
22505
22506
22507
22508
22509
22510
22511
22512
22513
22514
22515
22516
22517
22518
22519
22520
22521
22522
22523
22524
22525
22526
22527
22528
22529
22530
22531
22532
22533
22534
22535
22536
22537
22538
22539
22540
22541
22542
22543
22544
22545
22546
22547
22548
22549
22550
22551
22552
22553
22554
22555
22556
22557
22558
22559
22560
22561
22562
22563
22564
22565
22566
22567
22568
22569
22570
22571
22572
22573
22574
22575
22576
22577
22578
22579
22580
22581
22582
22583
22584
22585
22586
22587
22588
22589
22590
22591
22592
22593
22594
22595
22596
22597
22598
22599
22600
22601
22602
22603
22604
22605
22606
22607
22608
22609
22610
22611
22612
22613
22614
22615
22616
22617
22618
22619
22620
22621
22622
22623
22624
22625
22626
22627
22628
22629
22630
22631
22632
22633
22634
22635
22636
22637
22638
22639
22640
22641
22642
22643
22644
22645
22646
22647
22648
22649
22650
22651
22652
22653
22654
22655
22656
22657
22658
22659
22660
22661
22662
22663
22664
22665
22666
22667
22668
22669
22670
22671
22672
22673
22674
22675
22676
22677
22678
22679
22680
22681
22682
22683
22684
22685
22686
22687
22688
22689
22690
22691
22692
22693
22694
22695
22696
22697
22698
22699
22700
22701
22702
22703
22704
22705
22706
22707
22708
22709
22710
22711
22712
22713
22714
22715
22716
22717
22718
22719
22720
22721
22722
22723
22724
22725
22726
22727
22728
22729
22730
22731
22732
22733
22734
22735
22736
22737
22738
22739
22740
22741
22742
22743
22744
22745
22746
22747
22748
22749
22750
22751
22752
22753
22754
22755
22756
22757
22758
22759
22760
22761
22762
22763
22764
22765
22766
22767
22768
22769
22770
22771
22772
22773
22774
22775
22776
22777
22778
22779
22780
22781
22782
22783
22784
22785
22786
22787
22788
22789
22790
22791
22792
22793
22794
22795
22796
22797
22798
22799
22800
22801
22802
22803
22804
22805
22806
22807
22808
22809
22810
22811
22812
22813
22814
22815
22816
22817
22818
22819
22820
22821
22822
22823
22824
22825
22826
22827
22828
22829
22830
22831
22832
22833
22834
22835
22836
22837
22838
22839
22840
22841
22842
22843
22844
22845
22846
22847
22848
22849
22850
22851
22852
22853
22854
22855
22856
22857
22858
22859
22860
22861
22862
22863
22864
22865
22866
22867
22868
22869
22870
22871
22872
22873
22874
22875
22876
22877
22878
22879
22880
22881
22882
22883
22884
22885
22886
22887
22888
22889
22890
22891
22892
22893
22894
22895
22896
22897
22898
22899
22900
22901
22902
22903
22904
22905
22906
22907
22908
22909
22910
22911
22912
22913
22914
22915
22916
22917
22918
22919
22920
22921
22922
22923
22924
22925
22926
22927
22928
22929
22930
22931
22932
22933
22934
22935
22936
22937
22938
22939
22940
22941
22942
22943
22944
22945
22946
22947
22948
22949
22950
22951
22952
22953
22954
22955
22956
22957
22958
22959
22960
22961
22962
22963
22964
22965
22966
22967
22968
22969
22970
22971
22972
22973
22974
22975
22976
22977
22978
22979
22980
22981
22982
22983
22984
22985
22986
22987
22988
22989
22990
22991
22992
22993
22994
22995
22996
22997
22998
22999
23000
23001
23002
23003
23004
23005
23006
23007
23008
23009
23010
23011
23012
23013
23014
23015
23016
23017
23018
23019
23020
23021
23022
23023
23024
23025
23026
23027
23028
23029
23030
23031
23032
23033
23034
23035
23036
23037
23038
23039
23040
23041
23042
23043
23044
23045
23046
23047
23048
23049
23050
23051
23052
23053
23054
23055
23056
23057
23058
23059
23060
23061
23062
23063
23064
23065
23066
23067
23068
23069
23070
23071
23072
23073
23074
23075
23076
23077
23078
23079
23080
23081
23082
23083
23084
23085
23086
23087
23088
23089
23090
23091
23092
23093
23094
23095
23096
23097
23098
23099
23100
23101
23102
23103
23104
23105
23106
23107
23108
23109
23110
23111
23112
23113
23114
23115
23116
23117
23118
23119
23120
23121
23122
23123
23124
23125
23126
23127
23128
23129
23130
23131
23132
23133
23134
23135
23136
23137
23138
23139
23140
23141
23142
23143
23144
23145
23146
23147
23148
23149
23150
23151
23152
23153
23154
23155
23156
23157
23158
23159
23160
23161
23162
23163
23164
23165
23166
23167
23168
23169
23170
23171
23172
23173
23174
23175
23176
23177
23178
23179
23180
23181
23182
23183
23184
23185
23186
23187
23188
23189
23190
23191
23192
23193
23194
23195
23196
23197
23198
23199
23200
23201
23202
23203
23204
23205
23206
23207
23208
23209
23210
23211
23212
23213
23214
23215
23216
23217
23218
23219
23220
23221
23222
23223
23224
23225
23226
23227
23228
23229
23230
23231
23232
23233
23234
23235
23236
23237
23238
23239
23240
23241
23242
23243
23244
23245
23246
23247
23248
23249
23250
23251
23252
23253
23254
23255
23256
23257
23258
23259
23260
23261
23262
23263
23264
23265
23266
23267
23268
23269
23270
23271
23272
23273
23274
23275
23276
23277
23278
23279
23280
23281
23282
23283
23284
23285
23286
23287
23288
23289
23290
23291
23292
23293
23294
23295
23296
23297
23298
23299
23300
23301
23302
23303
23304
23305
23306
23307
23308
23309
23310
23311
23312
23313
23314
23315
23316
23317
23318
23319
23320
23321
23322
23323
23324
23325
23326
23327
23328
23329
23330
23331
23332
23333
23334
23335
23336
23337
23338
23339
23340
23341
23342
23343
23344
23345
23346
23347
23348
23349
23350
23351
23352
23353
23354
23355
23356
23357
23358
23359
23360
23361
23362
23363
23364
23365
23366
23367
23368
23369
23370
23371
23372
23373
23374
23375
23376
23377
23378
23379
23380
23381
23382
23383
23384
23385
23386
23387
23388
23389
23390
23391
23392
23393
23394
23395
23396
23397
23398
23399
23400
23401
23402
23403
23404
23405
23406
23407
23408
23409
23410
23411
23412
23413
23414
23415
23416
23417
23418
23419
23420
23421
23422
23423
23424
23425
23426
23427
23428
23429
23430
23431
23432
23433
23434
23435
23436
23437
23438
23439
23440
23441
23442
23443
23444
23445
23446
23447
23448
23449
23450
23451
23452
23453
23454
23455
23456
23457
23458
23459
23460
23461
23462
23463
23464
23465
23466
23467
23468
23469
23470
23471
23472
23473
23474
23475
23476
23477
23478
23479
23480
23481
23482
23483
23484
23485
23486
23487
23488
23489
23490
23491
23492
23493
23494
23495
23496
23497
23498
23499
23500
23501
23502
23503
23504
23505
23506
23507
23508
23509
23510
23511
23512
23513
23514
23515
23516
23517
23518
23519
23520
23521
23522
23523
23524
23525
23526
23527
23528
23529
23530
23531
23532
23533
23534
23535
23536
23537
23538
23539
23540
23541
23542
23543
23544
23545
23546
23547
23548
23549
23550
23551
23552
23553
23554
23555
23556
23557
23558
23559
23560
23561
23562
23563
23564
23565
23566
23567
23568
23569
23570
23571
23572
23573
23574
23575
23576
23577
23578
23579
23580
23581
23582
23583
23584
23585
23586
23587
23588
23589
23590
23591
23592
23593
23594
23595
23596
23597
23598
23599
23600
23601
23602
23603
23604
23605
23606
23607
23608
23609
23610
23611
23612
23613
23614
23615
23616
23617
23618
23619
23620
23621
23622
23623
23624
23625
23626
23627
23628
23629
23630
23631
23632
23633
23634
23635
23636
23637
23638
23639
23640
23641
23642
23643
23644
23645
23646
23647
23648
23649
23650
23651
23652
23653
23654
23655
23656
23657
23658
23659
23660
23661
23662
23663
23664
23665
23666
23667
23668
23669
23670
23671
23672
23673
23674
23675
23676
23677
23678
23679
23680
23681
23682
23683
23684
23685
23686
23687
23688
23689
23690
23691
23692
23693
23694
23695
23696
23697
23698
23699
23700
23701
23702
23703
23704
23705
23706
23707
23708
23709
23710
23711
23712
23713
23714
23715
23716
23717
23718
23719
23720
23721
23722
23723
23724
23725
23726
23727
23728
23729
23730
23731
23732
23733
23734
23735
23736
23737
23738
23739
23740
23741
23742
23743
23744
23745
23746
23747
23748
23749
23750
23751
23752
23753
23754
23755
23756
23757
23758
23759
23760
23761
23762
23763
23764
23765
23766
23767
23768
23769
23770
23771
23772
23773
23774
23775
23776
23777
23778
23779
23780
23781
23782
23783
23784
23785
23786
23787
23788
23789
23790
23791
23792
23793
23794
23795
23796
23797
23798
23799
23800
23801
23802
23803
23804
23805
23806
23807
23808
23809
23810
23811
23812
23813
23814
23815
23816
23817
23818
23819
23820
23821
23822
23823
23824
23825
23826
23827
23828
23829
23830
23831
23832
23833
23834
23835
23836
23837
23838
23839
23840
23841
23842
23843
23844
23845
23846
23847
23848
23849
23850
23851
23852
23853
23854
23855
23856
23857
23858
23859
23860
23861
23862
23863
23864
23865
23866
23867
23868
23869
23870
23871
23872
23873
23874
23875
23876
23877
23878
23879
23880
23881
23882
23883
23884
23885
23886
23887
23888
23889
23890
23891
23892
23893
23894
23895
23896
23897
23898
23899
23900
23901
23902
23903
23904
23905
23906
23907
23908
23909
23910
23911
23912
23913
23914
23915
23916
23917
23918
23919
23920
23921
23922
23923
23924
23925
23926
23927
23928
23929
23930
23931
23932
23933
23934
23935
23936
23937
23938
23939
23940
23941
23942
23943
23944
23945
23946
23947
23948
23949
23950
23951
23952
23953
23954
23955
23956
23957
23958
23959
23960
23961
23962
23963
23964
23965
23966
23967
23968
23969
23970
23971
23972
23973
23974
23975
23976
23977
23978
23979
23980
23981
23982
23983
23984
23985
23986
23987
23988
23989
23990
23991
23992
23993
23994
23995
23996
23997
23998
23999
24000
24001
24002
24003
24004
24005
24006
24007
24008
24009
24010
24011
24012
24013
24014
24015
24016
24017
24018
24019
24020
24021
24022
24023
24024
24025
24026
24027
24028
24029
24030
24031
24032
24033
24034
24035
24036
24037
24038
24039
24040
24041
24042
24043
24044
24045
24046
24047
24048
24049
24050
24051
24052
24053
24054
24055
24056
24057
24058
24059
24060
24061
24062
24063
24064
24065
24066
24067
24068
24069
24070
24071
24072
24073
24074
24075
24076
24077
24078
24079
24080
24081
24082
24083
24084
24085
24086
24087
24088
24089
24090
24091
24092
24093
24094
24095
24096
24097
24098
24099
24100
24101
24102
24103
24104
24105
24106
24107
24108
24109
24110
24111
24112
24113
24114
24115
24116
24117
24118
24119
24120
24121
24122
24123
24124
24125
24126
24127
24128
24129
24130
24131
24132
24133
24134
24135
24136
24137
24138
24139
24140
24141
24142
24143
24144
24145
24146
24147
24148
24149
24150
24151
24152
24153
24154
24155
24156
24157
24158
24159
24160
24161
24162
24163
24164
24165
24166
24167
24168
24169
24170
24171
24172
24173
24174
24175
24176
24177
24178
24179
24180
24181
24182
24183
24184
24185
24186
24187
24188
24189
24190
24191
24192
24193
24194
24195
24196
24197
24198
24199
24200
24201
24202
24203
24204
24205
24206
24207
24208
24209
24210
24211
24212
24213
24214
24215
24216
24217
24218
24219
24220
24221
24222
24223
24224
24225
24226
24227
24228
24229
24230
24231
24232
24233
24234
24235
24236
24237
24238
24239
24240
24241
24242
24243
24244
24245
24246
24247
24248
24249
24250
24251
24252
24253
24254
24255
24256
24257
24258
24259
24260
24261
24262
24263
24264
24265
24266
24267
24268
24269
24270
24271
24272
24273
24274
24275
24276
24277
24278
24279
24280
24281
24282
24283
24284
24285
24286
24287
24288
24289
24290
24291
24292
24293
24294
24295
24296
24297
24298
24299
24300
24301
24302
24303
24304
24305
24306
24307
24308
24309
24310
24311
24312
24313
24314
24315
24316
24317
24318
24319
24320
24321
24322
24323
24324
24325
24326
24327
24328
24329
24330
24331
24332
24333
24334
24335
24336
24337
24338
24339
24340
24341
24342
24343
24344
24345
24346
24347
24348
24349
24350
24351
24352
24353
24354
24355
24356
24357
24358
24359
24360
24361
24362
24363
24364
24365
24366
24367
24368
24369
24370
24371
24372
24373
24374
24375
24376
24377
24378
24379
24380
24381
24382
24383
24384
24385
24386
24387
24388
24389
24390
24391
24392
24393
24394
24395
24396
24397
24398
24399
24400
24401
24402
24403
24404
24405
24406
24407
24408
24409
24410
24411
24412
24413
24414
24415
24416
24417
24418
24419
24420
24421
24422
24423
24424
24425
24426
24427
24428
24429
24430
24431
24432
24433
24434
24435
24436
24437
24438
24439
24440
24441
24442
24443
24444
24445
24446
24447
24448
24449
24450
24451
24452
24453
24454
24455
24456
24457
24458
24459
24460
24461
24462
24463
24464
24465
24466
24467
24468
24469
24470
24471
24472
24473
24474
24475
24476
24477
24478
24479
24480
24481
24482
24483
24484
24485
24486
24487
24488
24489
24490
24491
24492
24493
24494
24495
24496
24497
24498
24499
24500
24501
24502
24503
24504
24505
24506
24507
24508
24509
24510
24511
24512
24513
24514
24515
24516
24517
24518
24519
24520
24521
24522
24523
24524
24525
24526
24527
24528
24529
24530
24531
24532
24533
24534
24535
24536
24537
24538
24539
24540
24541
24542
24543
24544
24545
24546
24547
24548
24549
24550
24551
24552
24553
24554
24555
24556
24557
24558
24559
24560
24561
24562
24563
24564
24565
24566
24567
24568
24569
24570
24571
24572
24573
24574
24575
24576
24577
24578
24579
24580
24581
24582
24583
24584
24585
24586
24587
24588
24589
24590
24591
24592
24593
24594
24595
24596
24597
24598
24599
24600
24601
24602
24603
24604
24605
24606
24607
24608
24609
24610
24611
24612
24613
24614
24615
24616
24617
24618
24619
24620
24621
24622
24623
24624
24625
24626
24627
24628
24629
24630
24631
24632
24633
24634
24635
24636
24637
24638
24639
24640
24641
24642
24643
24644
24645
24646
24647
24648
24649
24650
24651
24652
24653
24654
24655
24656
24657
24658
24659
24660
24661
24662
24663
24664
24665
24666
24667
24668
24669
24670
24671
24672
24673
24674
24675
24676
24677
24678
24679
24680
24681
24682
24683
24684
24685
24686
24687
24688
24689
24690
24691
24692
24693
24694
24695
24696
24697
24698
24699
24700
24701
24702
24703
24704
24705
24706
24707
24708
24709
24710
24711
24712
24713
24714
24715
24716
24717
24718
24719
24720
24721
24722
24723
24724
24725
24726
24727
24728
24729
24730
24731
24732
24733
24734
24735
24736
24737
24738
24739
24740
24741
24742
24743
24744
24745
24746
24747
24748
24749
24750
24751
24752
24753
24754
24755
24756
24757
24758
24759
24760
24761
24762
24763
24764
24765
24766
24767
24768
24769
24770
24771
24772
24773
24774
24775
24776
24777
24778
24779
24780
24781
24782
24783
24784
24785
24786
24787
24788
24789
24790
24791
24792
24793
24794
24795
24796
24797
24798
24799
24800
24801
24802
24803
24804
24805
24806
24807
24808
24809
24810
24811
24812
24813
24814
24815
24816
24817
24818
24819
24820
24821
24822
24823
24824
24825
24826
24827
24828
24829
24830
24831
24832
24833
24834
24835
24836
24837
24838
24839
24840
24841
24842
24843
24844
24845
24846
24847
24848
24849
24850
24851
24852
24853
24854
24855
24856
24857
24858
24859
24860
24861
24862
24863
24864
24865
24866
24867
24868
24869
24870
24871
24872
24873
24874
24875
24876
24877
24878
24879
24880
24881
24882
24883
24884
24885
24886
24887
24888
24889
24890
24891
24892
24893
24894
24895
24896
24897
24898
24899
24900
24901
24902
24903
24904
24905
24906
24907
24908
24909
24910
24911
24912
24913
24914
24915
24916
24917
24918
24919
24920
24921
24922
24923
24924
24925
24926
24927
24928
24929
24930
24931
24932
24933
24934
24935
24936
24937
24938
24939
24940
24941
24942
24943
24944
24945
24946
24947
24948
24949
24950
24951
24952
24953
24954
24955
24956
24957
24958
24959
24960
24961
24962
24963
24964
24965
24966
24967
24968
24969
24970
24971
24972
24973
24974
24975
24976
24977
24978
24979
24980
24981
24982
24983
24984
24985
24986
24987
24988
24989
24990
24991
24992
24993
24994
24995
24996
24997
24998
24999
25000
25001
25002
25003
25004
25005
25006
25007
25008
25009
25010
25011
25012
25013
25014
25015
25016
25017
25018
25019
25020
25021
25022
25023
25024
25025
25026
25027
25028
25029
25030
25031
25032
25033
25034
25035
25036
25037
25038
25039
25040
25041
25042
25043
25044
25045
25046
25047
25048
25049
25050
25051
25052
25053
25054
25055
25056
25057
25058
25059
25060
25061
25062
25063
25064
25065
25066
25067
25068
25069
25070
25071
25072
25073
25074
25075
25076
25077
25078
25079
25080
25081
25082
25083
25084
25085
25086
25087
25088
25089
25090
25091
25092
25093
25094
25095
25096
25097
25098
25099
25100
25101
25102
25103
25104
25105
25106
25107
25108
25109
25110
25111
25112
25113
25114
25115
25116
25117
25118
25119
25120
25121
25122
25123
25124
25125
25126
25127
25128
25129
25130
25131
25132
25133
25134
25135
25136
25137
25138
25139
25140
25141
25142
25143
25144
25145
25146
25147
25148
25149
25150
25151
25152
25153
25154
25155
25156
25157
25158
25159
25160
25161
25162
25163
25164
25165
25166
25167
25168
25169
25170
25171
25172
25173
25174
25175
25176
25177
25178
25179
25180
25181
25182
25183
25184
25185
25186
25187
25188
25189
25190
25191
25192
25193
25194
25195
25196
25197
25198
25199
25200
25201
25202
25203
25204
25205
25206
25207
25208
25209
25210
25211
25212
25213
25214
25215
25216
25217
25218
25219
25220
25221
25222
25223
25224
25225
25226
25227
25228
25229
25230
25231
25232
25233
25234
25235
25236
25237
25238
25239
25240
25241
25242
25243
25244
25245
25246
25247
25248
25249
25250
25251
25252
25253
25254
25255
25256
25257
25258
25259
25260
25261
25262
25263
25264
25265
25266
25267
25268
25269
25270
25271
25272
25273
25274
25275
25276
25277
25278
25279
25280
25281
25282
25283
25284
25285
25286
25287
25288
25289
25290
25291
25292
25293
25294
25295
25296
25297
25298
25299
25300
25301
25302
25303
25304
25305
25306
25307
25308
25309
25310
25311
25312
25313
25314
25315
25316
25317
25318
25319
25320
25321
25322
25323
25324
25325
25326
25327
25328
25329
25330
25331
25332
25333
25334
25335
25336
25337
25338
25339
25340
25341
25342
25343
25344
25345
25346
25347
25348
25349
25350
25351
25352
25353
25354
25355
25356
25357
25358
25359
25360
25361
25362
25363
25364
25365
25366
25367
25368
25369
25370
25371
25372
25373
25374
25375
25376
25377
25378
25379
25380
25381
25382
25383
25384
25385
25386
25387
25388
25389
25390
25391
25392
25393
25394
25395
25396
25397
25398
25399
25400
25401
25402
25403
25404
25405
25406
25407
25408
25409
25410
25411
25412
25413
25414
25415
25416
25417
25418
25419
25420
25421
25422
25423
25424
25425
25426
25427
25428
25429
25430
25431
25432
25433
25434
25435
25436
25437
25438
25439
25440
25441
25442
25443
25444
25445
25446
25447
25448
25449
25450
25451
25452
25453
25454
25455
25456
25457
25458
25459
25460
25461
25462
25463
25464
25465
25466
25467
25468
25469
25470
25471
25472
25473
25474
25475
25476
25477
25478
25479
25480
25481
25482
25483
25484
25485
25486
25487
25488
25489
25490
25491
25492
25493
25494
25495
25496
25497
25498
25499
25500
25501
25502
25503
25504
25505
25506
25507
25508
25509
25510
25511
25512
25513
25514
25515
25516
25517
25518
25519
25520
25521
25522
25523
25524
25525
25526
25527
25528
25529
25530
25531
25532
25533
25534
25535
25536
25537
25538
25539
25540
25541
25542
25543
25544
25545
25546
25547
25548
25549
25550
25551
25552
25553
25554
25555
25556
25557
25558
25559
25560
25561
25562
25563
25564
25565
25566
25567
25568
25569
25570
25571
25572
25573
25574
25575
25576
25577
25578
25579
25580
25581
25582
25583
25584
25585
25586
25587
25588
25589
25590
25591
25592
25593
25594
25595
25596
25597
25598
25599
25600
25601
25602
25603
25604
25605
25606
25607
25608
25609
25610
25611
25612
25613
25614
25615
25616
25617
25618
25619
25620
25621
25622
25623
25624
25625
25626
25627
25628
25629
25630
25631
25632
25633
25634
25635
25636
25637
25638
25639
25640
25641
25642
25643
25644
25645
25646
25647
25648
25649
25650
25651
25652
25653
25654
25655
25656
25657
25658
25659
25660
25661
25662
25663
25664
25665
25666
25667
25668
25669
25670
25671
25672
25673
25674
25675
25676
25677
25678
25679
25680
25681
25682
25683
25684
25685
25686
25687
25688
25689
25690
25691
25692
25693
25694
25695
25696
25697
25698
25699
25700
25701
25702
25703
25704
25705
25706
25707
25708
25709
25710
25711
25712
25713
25714
25715
25716
25717
25718
25719
25720
25721
25722
25723
25724
25725
25726
25727
25728
25729
25730
25731
25732
25733
25734
25735
25736
25737
25738
25739
25740
25741
25742
25743
25744
25745
25746
25747
25748
25749
25750
25751
25752
25753
25754
25755
25756
25757
25758
25759
25760
25761
25762
25763
25764
25765
25766
25767
25768
25769
25770
25771
25772
25773
25774
25775
25776
25777
25778
25779
25780
25781
25782
25783
25784
25785
25786
25787
25788
25789
25790
25791
25792
25793
25794
25795
25796
25797
25798
25799
25800
25801
25802
25803
25804
25805
25806
25807
25808
25809
25810
25811
25812
25813
25814
25815
25816
25817
25818
25819
25820
25821
25822
25823
25824
25825
25826
25827
25828
25829
25830
25831
25832
25833
25834
25835
25836
25837
25838
25839
25840
25841
25842
25843
25844
25845
25846
25847
25848
25849
25850
25851
25852
25853
25854
25855
25856
25857
25858
25859
25860
25861
25862
25863
25864
25865
25866
25867
25868
25869
25870
25871
25872
25873
25874
25875
25876
25877
25878
25879
25880
25881
25882
25883
25884
25885
25886
25887
25888
25889
25890
25891
25892
25893
25894
25895
25896
25897
25898
25899
25900
25901
25902
25903
25904
25905
25906
25907
25908
25909
25910
25911
25912
25913
25914
25915
25916
25917
25918
25919
25920
25921
25922
25923
25924
25925
25926
25927
25928
25929
25930
25931
25932
25933
25934
25935
25936
25937
25938
25939
25940
25941
25942
25943
25944
25945
25946
25947
25948
25949
25950
25951
25952
25953
25954
25955
25956
25957
25958
25959
25960
25961
25962
25963
25964
25965
25966
25967
25968
25969
25970
25971
25972
25973
25974
25975
25976
25977
25978
25979
25980
25981
25982
25983
25984
25985
25986
25987
25988
25989
25990
25991
25992
25993
25994
25995
25996
25997
25998
25999
26000
26001
26002
26003
26004
26005
26006
26007
26008
26009
26010
26011
26012
26013
26014
26015
26016
26017
26018
26019
26020
26021
26022
26023
26024
26025
26026
26027
26028
26029
26030
26031
26032
26033
26034
26035
26036
26037
26038
26039
26040
26041
26042
26043
26044
26045
26046
26047
26048
26049
26050
26051
26052
26053
26054
26055
26056
26057
26058
26059
26060
26061
26062
26063
26064
26065
26066
26067
26068
26069
26070
26071
26072
26073
26074
26075
26076
26077
26078
26079
26080
26081
26082
26083
26084
26085
26086
26087
26088
26089
26090
26091
26092
26093
26094
26095
26096
26097
26098
26099
26100
26101
26102
26103
26104
26105
26106
26107
26108
26109
26110
26111
26112
26113
26114
26115
26116
26117
26118
26119
26120
26121
26122
26123
26124
26125
26126
26127
26128
26129
26130
26131
26132
26133
26134
26135
26136
26137
26138
26139
26140
26141
26142
26143
26144
26145
26146
26147
26148
26149
26150
26151
26152
26153
26154
26155
26156
26157
26158
26159
26160
26161
26162
26163
26164
26165
26166
26167
26168
26169
26170
26171
26172
26173
26174
26175
26176
26177
26178
26179
26180
26181
26182
26183
26184
26185
26186
26187
26188
26189
26190
26191
26192
26193
26194
26195
26196
26197
26198
26199
26200
26201
26202
26203
26204
26205
26206
26207
26208
26209
26210
26211
26212
26213
26214
26215
26216
26217
26218
26219
26220
26221
26222
26223
26224
26225
26226
26227
26228
26229
26230
26231
26232
26233
26234
26235
26236
26237
26238
26239
26240
26241
26242
26243
26244
26245
26246
26247
26248
26249
26250
26251
26252
26253
26254
26255
26256
26257
26258
26259
26260
26261
26262
26263
26264
26265
26266
26267
26268
26269
26270
26271
26272
26273
26274
26275
26276
26277
26278
26279
26280
26281
26282
26283
26284
26285
26286
26287
26288
26289
26290
26291
26292
26293
26294
26295
26296
26297
26298
26299
26300
26301
26302
26303
26304
26305
26306
26307
26308
26309
26310
26311
26312
26313
26314
26315
26316
26317
26318
26319
26320
26321
26322
26323
26324
26325
26326
26327
26328
26329
26330
26331
26332
26333
26334
26335
26336
26337
26338
26339
26340
26341
26342
26343
26344
26345
26346
26347
26348
26349
26350
26351
26352
26353
26354
26355
26356
26357
26358
26359
26360
26361
26362
26363
26364
26365
26366
26367
26368
26369
26370
26371
26372
26373
26374
26375
26376
26377
26378
26379
26380
26381
26382
26383
26384
26385
26386
26387
26388
26389
26390
26391
26392
26393
26394
26395
26396
26397
26398
26399
26400
26401
26402
26403
26404
26405
26406
26407
26408
26409
26410
26411
26412
26413
26414
26415
26416
26417
26418
26419
26420
26421
26422
26423
26424
26425
26426
26427
26428
26429
26430
26431
26432
26433
26434
26435
26436
26437
26438
26439
26440
26441
26442
26443
26444
26445
26446
26447
26448
26449
26450
26451
26452
26453
26454
26455
26456
26457
26458
26459
26460
26461
26462
26463
26464
26465
26466
26467
26468
26469
26470
26471
26472
26473
26474
26475
26476
26477
26478
26479
26480
26481
26482
26483
26484
26485
26486
26487
26488
26489
26490
26491
26492
26493
26494
26495
26496
26497
26498
26499
26500
26501
26502
26503
26504
26505
26506
26507
26508
26509
26510
26511
26512
26513
26514
26515
26516
26517
26518
26519
26520
26521
26522
26523
26524
26525
26526
26527
26528
26529
26530
26531
26532
26533
26534
26535
26536
26537
26538
26539
26540
26541
26542
26543
26544
26545
26546
26547
26548
26549
26550
26551
26552
26553
26554
26555
26556
26557
26558
26559
26560
26561
26562
26563
26564
26565
26566
26567
26568
26569
26570
26571
26572
26573
26574
26575
26576
26577
26578
26579
26580
26581
26582
26583
26584
26585
26586
26587
26588
26589
26590
26591
26592
26593
26594
26595
26596
26597
26598
26599
26600
26601
26602
26603
26604
26605
26606
26607
26608
26609
26610
26611
26612
26613
26614
26615
26616
26617
26618
26619
26620
26621
26622
26623
26624
26625
26626
26627
26628
26629
26630
26631
26632
26633
26634
26635
26636
26637
26638
26639
26640
26641
26642
26643
26644
26645
26646
26647
26648
26649
26650
26651
26652
26653
26654
26655
26656
26657
26658
26659
26660
26661
26662
26663
26664
26665
26666
26667
26668
26669
26670
26671
26672
26673
26674
26675
26676
26677
26678
26679
26680
26681
26682
26683
26684
26685
26686
26687
26688
26689
26690
26691
26692
26693
26694
26695
26696
26697
26698
26699
26700
26701
26702
26703
26704
26705
26706
26707
26708
26709
26710
26711
26712
26713
26714
26715
26716
26717
26718
26719
26720
26721
26722
26723
26724
26725
26726
26727
26728
26729
26730
26731
26732
26733
26734
26735
26736
26737
26738
26739
26740
26741
26742
26743
26744
26745
26746
26747
26748
26749
26750
26751
26752
26753
26754
26755
26756
26757
26758
26759
26760
26761
26762
26763
26764
26765
26766
26767
26768
26769
26770
26771
26772
26773
26774
26775
26776
26777
26778
26779
26780
26781
26782
26783
26784
26785
26786
26787
26788
26789
26790
26791
26792
26793
26794
26795
26796
26797
26798
26799
26800
26801
26802
26803
26804
26805
26806
26807
26808
26809
26810
26811
26812
26813
26814
26815
26816
26817
26818
26819
26820
26821
26822
26823
26824
26825
26826
26827
26828
26829
26830
26831
26832
26833
26834
26835
26836
26837
26838
26839
26840
26841
26842
26843
26844
26845
26846
26847
26848
26849
26850
26851
26852
26853
26854
26855
26856
26857
26858
26859
26860
26861
26862
26863
26864
26865
26866
26867
26868
26869
26870
26871
26872
26873
26874
26875
26876
26877
26878
26879
26880
26881
26882
26883
26884
26885
26886
26887
26888
26889
26890
26891
26892
26893
26894
26895
26896
26897
26898
26899
26900
26901
26902
26903
26904
26905
26906
26907
26908
26909
26910
26911
26912
26913
26914
26915
26916
26917
26918
26919
26920
26921
26922
26923
26924
26925
26926
26927
26928
26929
26930
26931
26932
26933
26934
26935
26936
26937
26938
26939
26940
26941
26942
26943
26944
26945
26946
26947
26948
26949
26950
26951
26952
26953
26954
26955
26956
26957
26958
26959
26960
26961
26962
26963
26964
26965
26966
26967
26968
26969
26970
26971
26972
26973
26974
26975
26976
26977
26978
26979
26980
26981
26982
26983
26984
26985
26986
26987
26988
26989
26990
26991
26992
26993
26994
26995
26996
26997
26998
26999
27000
27001
27002
27003
27004
27005
27006
27007
27008
27009
27010
27011
27012
27013
27014
27015
27016
27017
27018
27019
27020
27021
27022
27023
27024
27025
27026
27027
27028
27029
27030
27031
27032
27033
27034
27035
27036
27037
27038
27039
27040
27041
27042
27043
27044
27045
27046
27047
27048
27049
27050
27051
27052
27053
27054
27055
27056
27057
27058
27059
27060
27061
27062
27063
27064
27065
27066
27067
27068
27069
27070
27071
27072
27073
27074
27075
27076
27077
27078
27079
27080
27081
27082
27083
27084
27085
27086
27087
27088
27089
27090
27091
27092
27093
27094
27095
27096
27097
27098
27099
27100
27101
27102
27103
27104
27105
27106
27107
27108
27109
27110
27111
27112
27113
27114
27115
27116
27117
27118
27119
27120
27121
27122
27123
27124
27125
27126
27127
27128
27129
27130
27131
27132
27133
27134
27135
27136
27137
27138
27139
27140
27141
27142
27143
27144
27145
27146
27147
27148
27149
27150
27151
27152
27153
27154
27155
27156
27157
27158
27159
27160
27161
27162
27163
27164
27165
27166
27167
27168
27169
27170
27171
27172
27173
27174
27175
27176
27177
27178
27179
27180
27181
27182
27183
27184
27185
27186
27187
27188
27189
27190
27191
27192
27193
27194
27195
27196
27197
27198
27199
27200
27201
27202
27203
27204
27205
27206
27207
27208
27209
27210
27211
27212
27213
27214
27215
27216
27217
27218
27219
27220
27221
27222
27223
27224
27225
27226
27227
27228
27229
27230
27231
27232
27233
27234
27235
27236
27237
27238
27239
27240
27241
27242
27243
27244
27245
27246
27247
27248
27249
27250
27251
27252
27253
27254
27255
27256
27257
27258
27259
27260
27261
27262
27263
27264
27265
27266
27267
27268
27269
27270
27271
27272
27273
27274
27275
27276
27277
27278
27279
27280
27281
27282
27283
27284
27285
27286
27287
27288
27289
27290
27291
27292
27293
27294
27295
27296
27297
27298
27299
27300
27301
27302
27303
27304
27305
27306
27307
27308
27309
27310
27311
27312
27313
27314
27315
27316
27317
27318
27319
27320
27321
27322
27323
27324
27325
27326
27327
27328
27329
27330
27331
27332
27333
27334
27335
27336
27337
27338
27339
27340
27341
27342
27343
27344
27345
27346
27347
27348
27349
27350
27351
27352
27353
27354
27355
27356
27357
27358
27359
27360
27361
27362
27363
27364
27365
27366
27367
27368
27369
27370
27371
27372
27373
27374
27375
27376
27377
27378
27379
27380
27381
27382
27383
27384
27385
27386
27387
27388
27389
27390
27391
27392
27393
27394
27395
27396
27397
27398
27399
27400
27401
27402
27403
27404
27405
27406
27407
27408
27409
27410
27411
27412
27413
27414
27415
27416
27417
27418
27419
27420
27421
27422
27423
27424
27425
27426
27427
27428
27429
27430
27431
27432
27433
27434
27435
27436
27437
27438
27439
27440
27441
27442
27443
27444
27445
27446
27447
27448
27449
27450
27451
27452
27453
27454
27455
27456
27457
27458
27459
27460
27461
27462
27463
27464
27465
27466
27467
27468
27469
27470
27471
27472
27473
27474
27475
27476
27477
27478
27479
27480
27481
27482
27483
27484
27485
27486
27487
27488
27489
27490
27491
27492
27493
27494
27495
27496
27497
27498
27499
27500
27501
27502
27503
27504
27505
27506
27507
27508
27509
27510
27511
27512
27513
27514
27515
27516
27517
27518
27519
27520
27521
27522
27523
27524
27525
27526
27527
27528
27529
27530
27531
27532
27533
27534
27535
27536
27537
27538
27539
27540
27541
27542
27543
27544
27545
27546
27547
27548
27549
27550
27551
27552
27553
27554
27555
27556
27557
27558
27559
27560
27561
27562
27563
27564
27565
27566
27567
27568
27569
27570
27571
27572
27573
27574
27575
27576
27577
27578
27579
27580
27581
27582
27583
27584
27585
27586
27587
27588
27589
27590
27591
27592
27593
27594
27595
27596
27597
27598
27599
27600
27601
27602
27603
27604
27605
27606
27607
27608
27609
27610
27611
27612
27613
27614
27615
27616
27617
27618
27619
27620
27621
27622
27623
27624
27625
27626
27627
27628
27629
27630
27631
27632
27633
27634
27635
27636
27637
27638
27639
27640
27641
27642
27643
27644
27645
27646
27647
27648
27649
27650
27651
27652
27653
27654
27655
27656
27657
27658
27659
27660
27661
27662
27663
27664
27665
27666
27667
27668
27669
27670
27671
27672
27673
27674
27675
27676
27677
27678
27679
27680
27681
27682
27683
27684
27685
27686
27687
27688
27689
27690
27691
27692
27693
27694
27695
27696
27697
27698
27699
27700
27701
27702
27703
27704
27705
27706
27707
27708
27709
27710
27711
27712
27713
27714
27715
27716
27717
27718
27719
27720
27721
27722
27723
27724
27725
27726
27727
27728
27729
27730
27731
27732
27733
27734
27735
27736
27737
27738
27739
27740
27741
27742
27743
27744
27745
27746
27747
27748
27749
27750
27751
27752
27753
27754
27755
27756
27757
27758
27759
27760
27761
27762
27763
27764
27765
27766
27767
27768
27769
27770
27771
27772
27773
27774
27775
27776
27777
27778
27779
27780
27781
27782
27783
27784
27785
27786
27787
27788
27789
27790
27791
27792
27793
27794
27795
27796
27797
27798
27799
27800
27801
27802
27803
27804
27805
27806
27807
27808
27809
27810
27811
27812
27813
27814
27815
27816
27817
27818
27819
27820
27821
27822
27823
27824
27825
27826
27827
27828
27829
27830
27831
27832
27833
27834
27835
27836
27837
27838
27839
27840
27841
27842
27843
27844
27845
27846
27847
27848
27849
27850
27851
27852
27853
27854
27855
27856
27857
27858
27859
27860
27861
27862
27863
27864
27865
27866
27867
27868
27869
27870
27871
27872
27873
27874
27875
27876
27877
27878
27879
27880
27881
27882
27883
27884
27885
27886
27887
27888
27889
27890
27891
27892
27893
27894
27895
27896
27897
27898
27899
27900
27901
27902
27903
27904
27905
27906
27907
27908
27909
27910
27911
27912
27913
27914
27915
27916
27917
27918
27919
27920
27921
27922
27923
27924
27925
27926
27927
27928
27929
27930
27931
27932
27933
27934
27935
27936
27937
27938
27939
27940
27941
27942
27943
27944
27945
27946
27947
27948
27949
27950
27951
27952
27953
27954
27955
27956
27957
27958
27959
27960
27961
27962
27963
27964
27965
27966
27967
27968
27969
27970
27971
27972
27973
27974
27975
27976
27977
27978
27979
27980
27981
27982
27983
27984
27985
27986
27987
27988
27989
27990
27991
27992
27993
27994
27995
27996
27997
27998
27999
28000
28001
28002
28003
28004
28005
28006
28007
28008
28009
28010
28011
28012
28013
28014
28015
28016
28017
28018
28019
28020
28021
28022
28023
28024
28025
28026
28027
28028
28029
28030
28031
28032
28033
28034
28035
28036
28037
28038
28039
28040
28041
28042
28043
28044
28045
28046
28047
28048
28049
28050
28051
28052
28053
28054
28055
28056
28057
28058
28059
28060
28061
28062
28063
28064
28065
28066
28067
28068
28069
28070
28071
28072
28073
28074
28075
28076
28077
28078
28079
28080
28081
28082
28083
28084
28085
28086
28087
28088
28089
28090
28091
28092
28093
28094
28095
28096
28097
28098
28099
28100
28101
28102
28103
28104
28105
28106
28107
28108
28109
28110
28111
28112
28113
28114
28115
28116
28117
28118
28119
28120
28121
28122
28123
28124
28125
28126
28127
28128
28129
28130
28131
28132
28133
28134
28135
28136
28137
28138
28139
28140
28141
28142
28143
28144
28145
28146
28147
28148
28149
28150
28151
28152
28153
28154
28155
28156
28157
28158
28159
28160
28161
28162
28163
28164
28165
28166
28167
28168
28169
28170
28171
28172
28173
28174
28175
28176
28177
28178
28179
28180
28181
28182
28183
28184
28185
28186
28187
28188
28189
28190
28191
28192
28193
28194
28195
28196
28197
28198
28199
28200
28201
28202
28203
28204
28205
28206
28207
28208
28209
28210
28211
28212
28213
28214
28215
28216
28217
28218
28219
28220
28221
28222
28223
28224
28225
28226
28227
28228
28229
28230
28231
28232
28233
28234
28235
28236
28237
28238
28239
28240
28241
28242
28243
28244
28245
28246
28247
28248
28249
28250
28251
28252
28253
28254
28255
28256
28257
28258
28259
28260
28261
28262
28263
28264
28265
28266
28267
28268
28269
28270
28271
28272
28273
28274
28275
28276
28277
28278
28279
28280
28281
28282
28283
28284
28285
28286
28287
28288
28289
28290
28291
28292
28293
28294
28295
28296
28297
28298
28299
28300
28301
28302
28303
28304
28305
28306
28307
28308
28309
28310
28311
28312
28313
28314
28315
28316
28317
28318
28319
28320
28321
28322
28323
28324
28325
28326
28327
28328
28329
28330
28331
28332
28333
28334
28335
28336
28337
28338
28339
28340
28341
28342
28343
28344
28345
28346
28347
28348
28349
28350
28351
28352
28353
28354
28355
28356
28357
28358
28359
28360
28361
28362
28363
28364
28365
28366
28367
28368
28369
28370
28371
28372
28373
28374
28375
28376
28377
28378
28379
28380
28381
28382
28383
28384
28385
28386
28387
28388
28389
28390
28391
28392
28393
28394
28395
28396
28397
28398
28399
28400
28401
28402
28403
28404
28405
28406
28407
28408
28409
28410
28411
28412
28413
28414
28415
28416
28417
28418
28419
28420
28421
28422
28423
28424
28425
28426
28427
28428
28429
28430
28431
28432
28433
28434
28435
28436
28437
28438
28439
28440
28441
28442
28443
28444
28445
28446
28447
28448
28449
28450
28451
28452
28453
28454
28455
28456
28457
28458
28459
28460
28461
28462
28463
28464
28465
28466
28467
28468
28469
28470
28471
28472
28473
28474
28475
28476
28477
28478
28479
28480
28481
28482
28483
28484
28485
28486
28487
28488
28489
28490
28491
28492
28493
28494
28495
28496
28497
28498
28499
28500
28501
28502
28503
28504
28505
28506
28507
28508
28509
28510
28511
28512
28513
28514
28515
28516
28517
28518
28519
28520
28521
28522
28523
28524
28525
28526
28527
28528
28529
28530
28531
28532
28533
28534
28535
28536
28537
28538
28539
28540
28541
28542
28543
28544
28545
28546
28547
28548
28549
28550
28551
28552
28553
28554
28555
28556
28557
28558
28559
28560
28561
28562
28563
28564
28565
28566
28567
28568
28569
28570
28571
28572
28573
28574
28575
28576
28577
28578
28579
28580
28581
28582
28583
28584
28585
28586
28587
28588
28589
28590
28591
28592
28593
28594
28595
28596
28597
28598
28599
28600
28601
28602
28603
28604
28605
28606
28607
28608
28609
28610
28611
28612
28613
28614
28615
28616
28617
28618
28619
28620
28621
28622
28623
28624
28625
28626
28627
28628
28629
28630
28631
28632
28633
28634
28635
28636
28637
28638
28639
28640
28641
28642
28643
28644
28645
28646
28647
28648
28649
28650
28651
28652
28653
28654
28655
28656
28657
28658
28659
28660
28661
28662
28663
28664
28665
28666
28667
28668
28669
28670
28671
28672
28673
28674
28675
28676
28677
28678
28679
28680
28681
28682
28683
28684
28685
28686
28687
28688
28689
28690
28691
28692
28693
28694
28695
28696
28697
28698
28699
28700
28701
28702
28703
28704
28705
28706
28707
28708
28709
28710
28711
28712
28713
28714
28715
28716
28717
28718
28719
28720
28721
28722
28723
28724
28725
28726
28727
28728
28729
28730
28731
28732
28733
28734
28735
28736
28737
28738
28739
28740
28741
28742
28743
28744
28745
28746
28747
28748
28749
28750
28751
28752
28753
28754
28755
28756
28757
28758
28759
28760
28761
28762
28763
28764
28765
28766
28767
28768
28769
28770
28771
28772
28773
28774
28775
28776
28777
28778
28779
28780
28781
28782
28783
28784
28785
28786
28787
28788
28789
28790
28791
28792
28793
28794
28795
28796
28797
28798
28799
28800
28801
28802
28803
28804
28805
28806
28807
28808
28809
28810
28811
28812
28813
28814
28815
28816
28817
28818
28819
28820
28821
28822
28823
28824
28825
28826
28827
28828
28829
28830
28831
28832
28833
28834
28835
28836
28837
28838
28839
28840
28841
28842
28843
28844
28845
28846
28847
28848
28849
28850
28851
28852
28853
28854
28855
28856
28857
28858
28859
28860
28861
28862
28863
28864
28865
28866
28867
28868
28869
28870
28871
28872
28873
28874
28875
28876
28877
28878
28879
28880
28881
28882
28883
28884
28885
28886
28887
28888
28889
28890
28891
28892
28893
28894
28895
28896
28897
28898
28899
28900
28901
28902
28903
28904
28905
28906
28907
28908
28909
28910
28911
28912
28913
28914
28915
28916
28917
28918
28919
28920
28921
28922
28923
28924
28925
28926
28927
28928
28929
28930
28931
28932
28933
28934
28935
28936
28937
28938
28939
28940
28941
28942
28943
28944
28945
28946
28947
28948
28949
28950
28951
28952
28953
28954
28955
28956
28957
28958
28959
28960
28961
28962
28963
28964
28965
28966
28967
28968
28969
28970
28971
28972
28973
28974
28975
28976
28977
28978
28979
28980
28981
28982
28983
28984
28985
28986
28987
28988
28989
28990
28991
28992
28993
28994
28995
28996
28997
28998
28999
29000
29001
29002
29003
29004
29005
29006
29007
29008
29009
29010
29011
29012
29013
29014
29015
29016
29017
29018
29019
29020
29021
29022
29023
29024
29025
29026
29027
29028
29029
29030
29031
29032
29033
29034
29035
29036
29037
29038
29039
29040
29041
29042
29043
29044
29045
29046
29047
29048
29049
29050
29051
29052
29053
29054
29055
29056
29057
29058
29059
29060
29061
29062
29063
29064
29065
29066
29067
29068
29069
29070
29071
29072
29073
29074
29075
29076
29077
29078
29079
29080
29081
29082
29083
29084
29085
29086
29087
29088
29089
29090
29091
29092
29093
29094
29095
29096
29097
29098
29099
29100
29101
29102
29103
29104
29105
29106
29107
29108
29109
29110
29111
29112
29113
29114
29115
29116
29117
29118
29119
29120
29121
29122
29123
29124
29125
29126
29127
29128
29129
29130
29131
29132
29133
29134
29135
29136
29137
29138
29139
29140
29141
29142
29143
29144
29145
29146
29147
29148
29149
29150
29151
29152
29153
29154
29155
29156
29157
29158
29159
29160
29161
29162
29163
29164
29165
29166
29167
29168
29169
29170
29171
29172
29173
29174
29175
29176
29177
29178
29179
29180
29181
29182
29183
29184
29185
29186
29187
29188
29189
29190
29191
29192
29193
29194
29195
29196
29197
29198
29199
29200
29201
29202
29203
29204
29205
29206
29207
29208
29209
29210
29211
29212
29213
29214
29215
29216
29217
29218
29219
29220
29221
29222
29223
29224
29225
29226
29227
29228
29229
29230
29231
29232
29233
29234
29235
29236
29237
29238
29239
29240
29241
29242
29243
29244
29245
29246
29247
29248
29249
29250
29251
29252
29253
29254
29255
29256
29257
29258
29259
29260
29261
29262
29263
29264
29265
29266
29267
29268
29269
29270
29271
29272
29273
29274
29275
29276
29277
29278
29279
29280
29281
29282
29283
29284
29285
29286
29287
29288
29289
29290
29291
29292
29293
29294
29295
29296
29297
29298
29299
29300
29301
29302
29303
29304
29305
29306
29307
29308
29309
29310
29311
29312
29313
29314
29315
29316
29317
29318
29319
29320
29321
29322
29323
29324
29325
29326
29327
29328
29329
29330
29331
29332
29333
29334
29335
29336
29337
29338
29339
29340
29341
29342
29343
29344
29345
29346
29347
29348
29349
29350
29351
29352
29353
29354
29355
29356
29357
29358
29359
29360
29361
29362
29363
29364
29365
29366
29367
29368
29369
29370
29371
29372
29373
29374
29375
29376
29377
29378
29379
29380
29381
29382
29383
29384
29385
29386
29387
29388
29389
29390
29391
29392
29393
29394
29395
29396
29397
29398
29399
29400
29401
29402
29403
29404
29405
29406
29407
29408
29409
29410
29411
29412
29413
29414
29415
29416
29417
29418
29419
29420
29421
29422
29423
29424
29425
29426
29427
29428
29429
29430
29431
29432
29433
29434
29435
29436
29437
29438
29439
29440
29441
29442
29443
29444
29445
29446
29447
29448
29449
29450
29451
29452
29453
29454
29455
29456
29457
29458
29459
29460
29461
29462
29463
29464
29465
29466
29467
29468
29469
29470
29471
29472
29473
29474
29475
29476
29477
29478
29479
29480
29481
29482
29483
29484
29485
29486
29487
29488
29489
29490
29491
29492
29493
29494
29495
29496
29497
29498
29499
29500
29501
29502
29503
29504
29505
29506
29507
29508
29509
29510
29511
29512
29513
29514
29515
29516
29517
29518
29519
29520
29521
29522
29523
29524
29525
29526
29527
29528
29529
29530
29531
29532
29533
29534
29535
29536
29537
29538
29539
29540
29541
29542
29543
29544
29545
29546
29547
29548
29549
29550
29551
29552
29553
29554
29555
29556
29557
29558
29559
29560
29561
29562
29563
29564
29565
29566
29567
29568
29569
29570
29571
29572
29573
29574
29575
29576
29577
29578
29579
29580
29581
29582
29583
29584
29585
29586
29587
29588
29589
29590
29591
29592
29593
29594
29595
29596
29597
29598
29599
29600
29601
29602
29603
29604
29605
29606
29607
29608
29609
29610
29611
29612
29613
29614
29615
29616
29617
29618
29619
29620
29621
29622
29623
29624
29625
29626
29627
29628
29629
29630
29631
29632
29633
29634
29635
29636
29637
29638
29639
29640
29641
29642
29643
29644
29645
29646
29647
29648
29649
29650
29651
29652
29653
29654
29655
29656
29657
29658
29659
29660
29661
29662
29663
29664
29665
29666
29667
29668
29669
29670
29671
29672
29673
29674
29675
29676
29677
29678
29679
29680
29681
29682
29683
29684
29685
29686
29687
29688
29689
29690
29691
29692
29693
29694
29695
29696
29697
29698
29699
29700
29701
29702
29703
29704
29705
29706
29707
29708
29709
29710
29711
29712
29713
29714
29715
29716
29717
29718
29719
29720
29721
29722
29723
29724
29725
29726
29727
29728
29729
29730
29731
29732
29733
29734
29735
29736
29737
29738
29739
29740
29741
29742
29743
29744
29745
29746
29747
29748
29749
29750
29751
29752
29753
29754
29755
29756
29757
29758
29759
29760
29761
29762
29763
29764
29765
29766
29767
29768
29769
29770
29771
29772
29773
29774
29775
29776
29777
29778
29779
29780
29781
29782
29783
29784
29785
29786
29787
29788
29789
29790
29791
29792
29793
29794
29795
29796
29797
29798
29799
29800
29801
29802
29803
29804
29805
29806
29807
29808
29809
29810
29811
29812
29813
29814
29815
29816
29817
29818
29819
29820
29821
29822
29823
29824
29825
29826
29827
29828
29829
29830
29831
29832
29833
29834
29835
29836
29837
29838
29839
29840
29841
29842
29843
29844
29845
29846
29847
29848
29849
29850
29851
29852
29853
29854
29855
29856
29857
29858
29859
29860
29861
29862
29863
29864
29865
29866
29867
29868
29869
29870
29871
29872
29873
29874
29875
29876
29877
29878
29879
29880
29881
29882
29883
29884
29885
29886
29887
29888
29889
29890
29891
29892
29893
29894
29895
29896
29897
29898
29899
29900
29901
29902
29903
29904
29905
29906
29907
29908
29909
29910
29911
29912
29913
29914
29915
29916
29917
29918
29919
29920
29921
29922
29923
29924
29925
29926
29927
29928
29929
29930
29931
29932
29933
29934
29935
29936
29937
29938
29939
29940
29941
29942
29943
29944
29945
29946
29947
29948
29949
29950
29951
29952
29953
29954
29955
29956
29957
29958
29959
29960
29961
29962
29963
29964
29965
29966
29967
29968
29969
29970
29971
29972
29973
29974
29975
29976
29977
29978
29979
29980
29981
29982
29983
29984
29985
29986
29987
29988
29989
29990
29991
29992
29993
29994
29995
29996
29997
29998
29999
30000
30001
30002
30003
30004
30005
30006
30007
30008
30009
30010
30011
30012
30013
30014
30015
30016
30017
30018
30019
30020
30021
30022
30023
30024
30025
30026
30027
30028
30029
30030
30031
30032
30033
30034
30035
30036
30037
30038
30039
30040
30041
30042
30043
30044
30045
30046
30047
30048
30049
30050
30051
30052
30053
30054
30055
30056
30057
30058
30059
30060
30061
30062
30063
30064
30065
30066
30067
30068
30069
30070
30071
30072
30073
30074
30075
30076
30077
30078
30079
30080
30081
30082
30083
30084
30085
30086
30087
30088
30089
30090
30091
30092
30093
30094
30095
30096
30097
30098
30099
30100
30101
30102
30103
30104
30105
30106
30107
30108
30109
30110
30111
30112
30113
30114
30115
30116
30117
30118
30119
30120
30121
30122
30123
30124
30125
30126
30127
30128
30129
30130
30131
30132
30133
30134
30135
30136
30137
30138
30139
30140
30141
30142
30143
30144
30145
30146
30147
30148
30149
30150
30151
30152
30153
30154
30155
30156
30157
30158
30159
30160
30161
30162
30163
30164
30165
30166
30167
30168
30169
30170
30171
30172
30173
30174
30175
30176
30177
30178
30179
30180
30181
30182
30183
30184
30185
30186
30187
30188
30189
30190
30191
30192
30193
30194
30195
30196
30197
30198
30199
30200
30201
30202
30203
30204
30205
30206
30207
30208
30209
30210
30211
30212
30213
30214
30215
30216
30217
30218
30219
30220
30221
30222
30223
30224
30225
30226
30227
30228
30229
30230
30231
30232
30233
30234
30235
30236
30237
30238
30239
30240
30241
30242
30243
30244
30245
30246
30247
30248
30249
30250
30251
30252
30253
30254
30255
30256
30257
30258
30259
30260
30261
30262
30263
30264
30265
30266
30267
30268
30269
30270
30271
30272
30273
30274
30275
30276
30277
30278
30279
30280
30281
30282
30283
30284
30285
30286
30287
30288
30289
30290
30291
30292
30293
30294
30295
30296
30297
30298
30299
30300
30301
30302
30303
30304
30305
30306
30307
30308
30309
30310
30311
30312
30313
30314
30315
30316
30317
30318
30319
30320
30321
30322
30323
30324
30325
30326
30327
30328
30329
30330
30331
30332
30333
30334
30335
30336
30337
30338
30339
30340
30341
30342
30343
30344
30345
30346
30347
30348
30349
30350
30351
30352
30353
30354
30355
30356
30357
30358
30359
30360
30361
30362
30363
30364
30365
30366
30367
30368
30369
30370
30371
30372
30373
30374
30375
30376
30377
30378
30379
30380
30381
30382
30383
30384
30385
30386
30387
30388
30389
30390
30391
30392
30393
30394
30395
30396
30397
30398
30399
30400
30401
30402
30403
30404
30405
30406
30407
30408
30409
30410
30411
30412
30413
30414
30415
30416
30417
30418
30419
30420
30421
30422
30423
30424
30425
30426
30427
30428
30429
30430
30431
30432
30433
30434
30435
30436
30437
30438
30439
30440
30441
30442
30443
30444
30445
30446
30447
30448
30449
30450
30451
30452
30453
30454
30455
30456
30457
30458
30459
30460
30461
30462
30463
30464
30465
30466
30467
30468
30469
30470
30471
30472
30473
30474
30475
30476
30477
30478
30479
30480
30481
30482
30483
30484
30485
30486
30487
30488
30489
30490
30491
30492
30493
30494
30495
30496
30497
30498
30499
30500
30501
30502
30503
30504
30505
30506
30507
30508
30509
30510
30511
30512
30513
30514
30515
30516
30517
30518
30519
30520
30521
30522
30523
30524
30525
30526
30527
30528
30529
30530
30531
30532
30533
30534
30535
30536
30537
30538
30539
30540
30541
30542
30543
30544
30545
30546
30547
30548
30549
30550
30551
30552
30553
30554
30555
30556
30557
30558
30559
30560
30561
30562
30563
30564
30565
30566
30567
30568
30569
30570
30571
30572
30573
30574
30575
30576
30577
30578
30579
30580
30581
30582
30583
30584
30585
30586
30587
30588
30589
30590
30591
30592
30593
30594
30595
30596
30597
30598
30599
30600
30601
30602
30603
30604
30605
30606
30607
30608
30609
30610
30611
30612
30613
30614
30615
30616
30617
30618
30619
30620
30621
30622
30623
30624
30625
30626
30627
30628
30629
30630
30631
30632
30633
30634
30635
30636
30637
30638
30639
30640
30641
30642
30643
30644
30645
30646
30647
30648
30649
30650
30651
30652
30653
30654
30655
30656
30657
30658
30659
30660
30661
30662
30663
30664
30665
30666
30667
30668
30669
30670
30671
30672
30673
30674
30675
30676
30677
30678
30679
30680
30681
30682
30683
30684
30685
30686
30687
30688
30689
30690
30691
30692
30693
30694
30695
30696
30697
30698
30699
30700
30701
30702
30703
30704
30705
30706
30707
30708
30709
30710
30711
30712
30713
30714
30715
30716
30717
30718
30719
30720
30721
30722
30723
30724
30725
30726
30727
30728
30729
30730
30731
30732
30733
30734
30735
30736
30737
30738
30739
30740
30741
30742
30743
30744
30745
30746
30747
30748
30749
30750
30751
30752
30753
30754
30755
30756
30757
30758
30759
30760
30761
30762
30763
30764
30765
30766
30767
30768
30769
30770
30771
30772
30773
30774
30775
30776
30777
30778
30779
30780
30781
30782
30783
30784
30785
30786
30787
30788
30789
30790
30791
30792
30793
30794
30795
30796
30797
30798
30799
30800
30801
30802
30803
30804
30805
30806
30807
30808
30809
30810
30811
30812
30813
30814
30815
30816
30817
30818
30819
30820
30821
30822
30823
30824
30825
30826
30827
30828
30829
30830
30831
30832
30833
30834
30835
30836
30837
30838
30839
30840
30841
30842
30843
30844
30845
30846
30847
30848
30849
30850
30851
30852
30853
30854
30855
30856
30857
30858
30859
30860
30861
30862
30863
30864
30865
30866
30867
30868
30869
30870
30871
30872
30873
30874
30875
30876
30877
30878
30879
30880
30881
30882
30883
30884
30885
30886
30887
30888
30889
30890
30891
30892
30893
30894
30895
30896
30897
30898
30899
30900
30901
30902
30903
30904
30905
30906
30907
30908
30909
30910
30911
30912
30913
30914
30915
30916
30917
30918
30919
30920
30921
30922
30923
30924
30925
30926
30927
30928
30929
30930
30931
30932
30933
30934
30935
30936
30937
30938
30939
30940
30941
30942
30943
30944
30945
30946
30947
30948
30949
30950
30951
30952
30953
30954
30955
30956
30957
30958
30959
30960
30961
30962
30963
30964
30965
30966
30967
30968
30969
30970
30971
30972
30973
30974
30975
30976
30977
30978
30979
30980
30981
30982
30983
30984
30985
30986
30987
30988
30989
30990
30991
30992
30993
30994
30995
30996
30997
30998
30999
31000
31001
31002
31003
31004
31005
31006
31007
31008
31009
31010
31011
31012
31013
31014
31015
31016
31017
31018
31019
31020
31021
31022
31023
31024
31025
31026
31027
31028
31029
31030
31031
31032
31033
31034
31035
31036
31037
31038
31039
31040
31041
31042
31043
31044
31045
31046
31047
31048
31049
31050
31051
31052
31053
31054
31055
31056
31057
31058
31059
31060
31061
31062
31063
31064
31065
31066
31067
31068
31069
31070
31071
31072
31073
31074
31075
31076
31077
31078
31079
31080
31081
31082
31083
31084
31085
31086
31087
31088
31089
31090
31091
31092
31093
31094
31095
31096
31097
31098
31099
31100
31101
31102
31103
31104
31105
31106
31107
31108
31109
31110
31111
31112
31113
31114
31115
31116
31117
31118
31119
31120
31121
31122
31123
31124
31125
31126
31127
31128
31129
31130
31131
31132
31133
31134
31135
31136
31137
31138
31139
31140
31141
31142
31143
31144
31145
31146
31147
31148
31149
31150
31151
31152
31153
31154
31155
31156
31157
31158
31159
31160
31161
31162
31163
31164
31165
31166
31167
31168
31169
31170
31171
31172
31173
31174
31175
31176
31177
31178
31179
31180
31181
31182
31183
31184
31185
31186
31187
31188
31189
31190
31191
31192
31193
31194
31195
31196
31197
31198
31199
31200
31201
31202
31203
31204
31205
31206
31207
31208
31209
31210
31211
31212
31213
31214
31215
31216
31217
31218
31219
31220
31221
31222
31223
31224
31225
31226
31227
31228
31229
31230
31231
31232
31233
31234
31235
31236
31237
31238
31239
31240
31241
31242
31243
31244
31245
31246
31247
31248
31249
31250
31251
31252
31253
31254
31255
31256
31257
31258
31259
31260
31261
31262
31263
31264
31265
31266
31267
31268
31269
31270
31271
31272
31273
31274
31275
31276
31277
31278
31279
31280
31281
31282
31283
31284
31285
31286
31287
31288
31289
31290
31291
31292
31293
31294
31295
31296
31297
31298
31299
31300
31301
31302
31303
31304
31305
31306
31307
31308
31309
31310
31311
31312
31313
31314
31315
31316
31317
31318
31319
31320
31321
31322
31323
31324
31325
31326
31327
31328
31329
31330
31331
31332
31333
31334
31335
31336
31337
31338
31339
31340
31341
31342
31343
31344
31345
31346
31347
31348
31349
31350
31351
31352
31353
31354
31355
31356
31357
31358
31359
31360
31361
31362
31363
31364
31365
31366
31367
31368
31369
31370
31371
31372
31373
31374
31375
31376
31377
31378
31379
31380
31381
31382
31383
31384
31385
31386
31387
31388
31389
31390
31391
31392
31393
31394
31395
31396
31397
31398
31399
31400
31401
31402
31403
31404
31405
31406
31407
31408
31409
31410
31411
31412
31413
31414
31415
31416
31417
31418
31419
31420
31421
31422
31423
31424
31425
31426
31427
31428
31429
31430
31431
31432
31433
31434
31435
31436
31437
31438
31439
31440
31441
31442
31443
31444
31445
31446
31447
31448
31449
31450
31451
31452
31453
31454
31455
31456
31457
31458
31459
31460
31461
31462
31463
31464
31465
31466
31467
31468
31469
31470
31471
31472
31473
31474
31475
31476
31477
31478
31479
31480
31481
31482
31483
31484
31485
31486
31487
31488
31489
31490
31491
31492
31493
31494
31495
31496
31497
31498
31499
31500
31501
31502
31503
31504
31505
31506
31507
31508
31509
31510
31511
31512
31513
31514
31515
31516
31517
31518
31519
31520
31521
31522
31523
31524
31525
31526
31527
31528
31529
31530
31531
31532
31533
31534
31535
31536
31537
31538
31539
31540
31541
31542
31543
31544
31545
31546
31547
31548
31549
31550
31551
31552
31553
31554
31555
31556
31557
31558
31559
31560
31561
31562
31563
31564
31565
31566
31567
31568
31569
31570
31571
31572
31573
31574
31575
31576
31577
31578
31579
31580
31581
31582
31583
31584
31585
31586
31587
31588
31589
31590
31591
31592
31593
31594
31595
31596
31597
31598
31599
31600
31601
31602
31603
31604
31605
31606
31607
31608
31609
31610
31611
31612
31613
31614
31615
31616
31617
31618
31619
31620
31621
31622
31623
31624
31625
31626
31627
31628
31629
31630
31631
31632
31633
31634
31635
31636
31637
31638
31639
31640
31641
31642
31643
31644
31645
31646
31647
31648
31649
31650
31651
31652
31653
31654
31655
31656
31657
31658
31659
31660
31661
31662
31663
31664
31665
31666
31667
31668
31669
31670
31671
31672
31673
31674
31675
31676
31677
31678
31679
31680
31681
31682
31683
31684
31685
31686
31687
31688
31689
31690
31691
31692
31693
31694
31695
31696
31697
31698
31699
31700
31701
31702
31703
31704
31705
31706
31707
31708
31709
31710
31711
31712
31713
31714
31715
31716
31717
31718
31719
31720
31721
31722
31723
31724
31725
31726
31727
31728
31729
31730
31731
31732
31733
31734
31735
31736
31737
31738
31739
31740
31741
31742
31743
31744
31745
31746
31747
31748
31749
31750
31751
31752
31753
31754
31755
31756
31757
31758
31759
31760
31761
31762
31763
31764
31765
31766
31767
31768
31769
31770
31771
31772
31773
31774
31775
31776
31777
31778
31779
31780
31781
31782
31783
31784
31785
31786
31787
31788
31789
31790
31791
31792
31793
31794
31795
31796
31797
31798
31799
31800
31801
31802
31803
31804
31805
31806
31807
31808
31809
31810
31811
31812
31813
31814
31815
31816
31817
31818
31819
31820
31821
31822
31823
31824
31825
31826
31827
31828
31829
31830
31831
31832
31833
31834
31835
31836
31837
31838
31839
31840
31841
31842
31843
31844
31845
31846
31847
31848
31849
31850
31851
31852
31853
31854
31855
31856
31857
31858
31859
31860
31861
31862
31863
31864
31865
31866
31867
31868
31869
31870
31871
31872
31873
31874
31875
31876
31877
31878
31879
31880
31881
31882
31883
31884
31885
31886
31887
31888
31889
31890
31891
31892
31893
31894
31895
31896
31897
31898
31899
31900
31901
31902
31903
31904
31905
31906
31907
31908
31909
31910
31911
31912
31913
31914
31915
31916
31917
31918
31919
31920
31921
31922
31923
31924
31925
31926
31927
31928
31929
31930
31931
31932
31933
31934
31935
31936
31937
31938
31939
31940
31941
31942
31943
31944
31945
31946
31947
31948
31949
31950
31951
31952
31953
31954
31955
31956
31957
31958
31959
31960
31961
31962
31963
31964
31965
31966
31967
31968
31969
31970
31971
31972
31973
31974
31975
31976
31977
31978
31979
31980
31981
31982
31983
31984
31985
31986
31987
31988
31989
31990
31991
31992
31993
31994
31995
31996
31997
31998
31999
32000
32001
32002
32003
32004
32005
32006
32007
32008
32009
32010
32011
32012
32013
32014
32015
32016
32017
32018
32019
32020
32021
32022
32023
32024
32025
32026
32027
32028
32029
32030
32031
32032
32033
32034
32035
32036
32037
32038
32039
32040
32041
32042
32043
32044
32045
32046
32047
32048
32049
32050
32051
32052
32053
32054
32055
32056
32057
32058
32059
32060
32061
32062
32063
32064
32065
32066
32067
32068
32069
32070
32071
32072
32073
32074
32075
32076
32077
32078
32079
32080
32081
32082
32083
32084
32085
32086
32087
32088
32089
32090
32091
32092
32093
32094
32095
32096
32097
32098
32099
32100
32101
32102
32103
32104
32105
32106
32107
32108
32109
32110
32111
32112
32113
32114
32115
32116
32117
32118
32119
32120
32121
32122
32123
32124
32125
32126
32127
32128
32129
32130
32131
32132
32133
32134
32135
32136
32137
32138
32139
32140
32141
32142
32143
32144
32145
32146
32147
32148
32149
32150
32151
32152
32153
32154
32155
32156
32157
32158
32159
32160
32161
32162
32163
32164
32165
32166
32167
32168
32169
32170
32171
32172
32173
32174
32175
32176
32177
32178
32179
32180
32181
32182
32183
32184
32185
32186
32187
32188
32189
32190
32191
32192
32193
32194
32195
32196
32197
32198
32199
32200
32201
32202
32203
32204
32205
32206
32207
32208
32209
32210
32211
32212
32213
32214
32215
32216
32217
32218
32219
32220
32221
32222
32223
32224
32225
32226
32227
32228
32229
32230
32231
32232
32233
32234
32235
32236
32237
32238
32239
32240
32241
32242
32243
32244
32245
32246
32247
32248
32249
32250
32251
32252
32253
32254
32255
32256
32257
32258
32259
32260
32261
32262
32263
32264
32265
32266
32267
32268
32269
32270
32271
32272
32273
32274
32275
32276
32277
32278
32279
32280
32281
32282
32283
32284
32285
32286
32287
32288
32289
32290
32291
32292
32293
32294
32295
32296
32297
32298
32299
32300
32301
32302
32303
32304
32305
32306
32307
32308
32309
32310
32311
32312
32313
32314
32315
32316
32317
32318
32319
32320
32321
32322
32323
32324
32325
32326
32327
32328
32329
32330
32331
32332
32333
32334
32335
32336
32337
32338
32339
32340
32341
32342
32343
32344
32345
32346
32347
32348
32349
32350
32351
32352
32353
32354
32355
32356
32357
32358
32359
32360
32361
32362
32363
32364
32365
32366
32367
32368
32369
32370
32371
32372
32373
32374
32375
32376
32377
32378
32379
32380
32381
32382
32383
32384
32385
32386
32387
32388
32389
32390
32391
32392
32393
32394
32395
32396
32397
32398
32399
32400
32401
32402
32403
32404
32405
32406
32407
32408
32409
32410
32411
32412
32413
32414
32415
32416
32417
32418
32419
32420
32421
32422
32423
32424
32425
32426
32427
32428
32429
32430
32431
32432
32433
32434
32435
32436
32437
32438
32439
32440
32441
32442
32443
32444
32445
32446
32447
32448
32449
32450
32451
32452
32453
32454
32455
32456
32457
32458
32459
32460
32461
32462
32463
32464
32465
32466
32467
32468
32469
32470
32471
32472
32473
32474
32475
32476
32477
32478
32479
32480
32481
32482
32483
32484
32485
32486
32487
32488
32489
32490
32491
32492
32493
32494
32495
32496
32497
32498
32499
32500
32501
32502
32503
32504
32505
32506
32507
32508
32509
32510
32511
32512
32513
32514
32515
32516
32517
32518
32519
32520
32521
32522
32523
32524
32525
32526
32527
32528
32529
32530
32531
32532
32533
32534
32535
32536
32537
32538
32539
32540
32541
32542
32543
32544
32545
32546
32547
32548
32549
32550
32551
32552
32553
32554
32555
32556
32557
32558
32559
32560
32561
32562
32563
32564
32565
32566
32567
32568
32569
32570
32571
32572
32573
32574
32575
32576
32577
32578
32579
32580
32581
32582
32583
32584
32585
32586
32587
32588
32589
32590
32591
32592
32593
32594
32595
32596
32597
32598
32599
32600
32601
32602
32603
32604
32605
32606
32607
32608
32609
32610
32611
32612
32613
32614
32615
32616
32617
32618
32619
32620
32621
32622
32623
32624
32625
32626
32627
32628
32629
32630
32631
32632
32633
32634
32635
32636
32637
32638
32639
32640
32641
32642
32643
32644
32645
32646
32647
32648
32649
32650
32651
32652
32653
32654
32655
32656
32657
32658
32659
32660
32661
32662
32663
32664
32665
32666
32667
32668
32669
32670
32671
32672
32673
32674
32675
32676
32677
32678
32679
32680
32681
32682
32683
32684
32685
32686
32687
32688
32689
32690
32691
32692
32693
32694
32695
32696
32697
32698
32699
32700
32701
32702
32703
32704
32705
32706
32707
32708
32709
32710
32711
32712
32713
32714
32715
32716
32717
32718
32719
32720
32721
32722
32723
32724
32725
32726
32727
32728
32729
32730
32731
32732
32733
32734
32735
32736
32737
32738
32739
32740
32741
32742
32743
32744
32745
32746
32747
32748
32749
32750
32751
32752
32753
32754
32755
32756
32757
32758
32759
32760
32761
32762
32763
32764
32765
32766
32767
32768
32769
32770
32771
32772
32773
32774
32775
32776
32777
32778
32779
32780
32781
32782
32783
32784
32785
32786
32787
32788
32789
32790
32791
32792
32793
32794
32795
32796
32797
32798
32799
32800
32801
32802
32803
32804
32805
32806
32807
32808
32809
32810
32811
32812
32813
32814
32815
32816
32817
32818
32819
32820
32821
32822
32823
32824
32825
32826
32827
32828
32829
32830
32831
32832
32833
32834
32835
32836
32837
32838
32839
32840
32841
32842
32843
32844
32845
32846
32847
32848
32849
32850
32851
32852
32853
32854
32855
32856
32857
32858
32859
32860
32861
32862
32863
32864
32865
32866
32867
32868
32869
32870
32871
32872
32873
32874
32875
32876
32877
32878
32879
32880
32881
32882
32883
32884
32885
32886
32887
32888
32889
32890
32891
32892
32893
32894
32895
32896
32897
32898
32899
32900
32901
32902
32903
32904
32905
32906
32907
32908
32909
32910
32911
32912
32913
32914
32915
32916
32917
32918
32919
32920
32921
32922
32923
32924
32925
32926
32927
32928
32929
32930
32931
32932
32933
32934
32935
32936
32937
32938
32939
32940
32941
32942
32943
32944
32945
32946
32947
32948
32949
32950
32951
32952
32953
32954
32955
32956
32957
32958
32959
32960
32961
32962
32963
32964
32965
32966
32967
32968
32969
32970
32971
32972
32973
32974
32975
32976
32977
32978
32979
32980
32981
32982
32983
32984
32985
32986
32987
32988
32989
32990
32991
32992
32993
32994
32995
32996
32997
32998
32999
33000
33001
33002
33003
33004
33005
33006
33007
33008
33009
33010
33011
33012
33013
33014
33015
33016
33017
33018
33019
33020
33021
33022
33023
33024
33025
33026
33027
33028
33029
33030
33031
33032
33033
33034
33035
33036
33037
33038
33039
33040
33041
33042
33043
33044
33045
33046
33047
33048
33049
33050
33051
33052
33053
33054
33055
33056
33057
33058
33059
33060
33061
33062
33063
33064
33065
33066
33067
33068
33069
33070
33071
33072
33073
33074
33075
33076
33077
33078
33079
33080
33081
33082
33083
33084
33085
33086
33087
33088
33089
33090
33091
33092
33093
33094
33095
33096
33097
33098
33099
33100
33101
33102
33103
33104
33105
33106
33107
33108
33109
33110
33111
33112
33113
33114
33115
33116
33117
33118
33119
33120
33121
33122
33123
33124
33125
33126
33127
33128
33129
33130
33131
33132
33133
33134
33135
33136
33137
33138
33139
33140
33141
33142
33143
33144
33145
33146
33147
33148
33149
33150
33151
33152
33153
33154
33155
33156
33157
33158
33159
33160
33161
33162
33163
33164
33165
33166
33167
33168
33169
33170
33171
33172
33173
33174
33175
33176
33177
33178
33179
33180
33181
33182
33183
33184
33185
33186
33187
33188
33189
33190
33191
33192
33193
33194
33195
33196
33197
33198
33199
33200
33201
33202
33203
33204
33205
33206
33207
33208
33209
33210
33211
33212
33213
33214
33215
33216
33217
33218
33219
33220
33221
33222
33223
33224
33225
33226
33227
33228
33229
33230
33231
33232
33233
33234
33235
33236
33237
33238
33239
33240
33241
33242
33243
33244
33245
33246
33247
33248
33249
33250
33251
33252
33253
33254
33255
33256
33257
33258
33259
33260
33261
33262
33263
33264
33265
33266
33267
33268
33269
33270
33271
33272
33273
33274
33275
33276
33277
33278
33279
33280
33281
33282
33283
33284
33285
33286
33287
33288
33289
33290
33291
33292
33293
33294
33295
33296
33297
33298
33299
33300
33301
33302
33303
33304
33305
33306
33307
33308
33309
33310
33311
33312
33313
33314
33315
33316
33317
33318
33319
33320
33321
33322
33323
33324
33325
33326
33327
33328
33329
33330
33331
33332
33333
33334
33335
33336
33337
33338
33339
33340
33341
33342
33343
33344
33345
33346
33347
33348
33349
33350
33351
33352
33353
33354
33355
33356
33357
33358
33359
33360
33361
33362
33363
33364
33365
33366
33367
33368
33369
33370
33371
33372
33373
33374
33375
33376
33377
33378
33379
33380
33381
33382
33383
33384
33385
33386
33387
33388
33389
33390
33391
33392
33393
33394
33395
33396
33397
33398
33399
33400
33401
33402
33403
33404
33405
33406
33407
33408
33409
33410
33411
33412
33413
33414
33415
33416
33417
33418
33419
33420
33421
33422
33423
33424
33425
33426
33427
33428
33429
33430
33431
33432
33433
33434
33435
33436
33437
33438
33439
33440
33441
33442
33443
33444
33445
33446
33447
33448
33449
33450
33451
33452
33453
33454
33455
33456
33457
33458
33459
33460
33461
33462
33463
33464
33465
33466
33467
33468
33469
33470
33471
33472
33473
33474
33475
33476
33477
33478
33479
33480
33481
33482
33483
33484
33485
33486
33487
33488
33489
33490
33491
33492
33493
33494
33495
33496
33497
33498
33499
33500
33501
33502
33503
33504
33505
33506
33507
33508
33509
33510
33511
33512
33513
33514
33515
33516
33517
33518
33519
33520
33521
33522
33523
33524
33525
33526
33527
33528
33529
33530
33531
33532
33533
33534
33535
33536
33537
33538
33539
33540
33541
33542
33543
33544
33545
33546
33547
33548
33549
33550
33551
33552
33553
33554
33555
33556
33557
33558
33559
33560
33561
33562
33563
33564
33565
33566
33567
33568
33569
33570
33571
33572
33573
33574
33575
33576
33577
33578
33579
33580
33581
33582
33583
33584
33585
33586
33587
33588
33589
33590
33591
33592
33593
33594
33595
33596
33597
33598
33599
33600
33601
33602
33603
33604
33605
33606
33607
33608
33609
33610
33611
33612
33613
33614
33615
33616
33617
33618
33619
33620
33621
33622
33623
33624
33625
33626
33627
33628
33629
33630
33631
33632
33633
33634
33635
33636
33637
33638
33639
33640
33641
33642
33643
33644
33645
33646
33647
33648
33649
33650
33651
33652
33653
33654
33655
33656
33657
33658
33659
33660
33661
33662
33663
33664
33665
33666
33667
33668
33669
33670
33671
33672
33673
33674
33675
33676
33677
33678
33679
33680
33681
33682
33683
33684
33685
33686
33687
33688
33689
33690
33691
33692
33693
33694
33695
33696
33697
33698
33699
33700
33701
33702
33703
33704
33705
33706
33707
33708
33709
33710
33711
33712
33713
33714
33715
33716
33717
33718
33719
33720
33721
33722
33723
33724
33725
33726
33727
33728
33729
33730
33731
33732
33733
33734
33735
33736
33737
33738
33739
33740
33741
33742
33743
33744
33745
33746
33747
33748
33749
33750
33751
33752
33753
33754
33755
33756
33757
33758
33759
33760
33761
33762
33763
33764
33765
33766
33767
33768
33769
33770
33771
33772
33773
33774
33775
33776
33777
33778
33779
33780
33781
33782
33783
33784
33785
33786
33787
33788
33789
33790
33791
33792
33793
33794
33795
33796
33797
33798
33799
33800
33801
33802
33803
33804
33805
33806
33807
33808
33809
33810
33811
33812
33813
33814
33815
33816
33817
33818
33819
33820
33821
33822
33823
33824
33825
33826
33827
33828
33829
33830
33831
33832
33833
33834
33835
33836
33837
33838
33839
33840
33841
33842
33843
33844
33845
33846
33847
33848
33849
33850
33851
33852
33853
33854
33855
33856
33857
33858
33859
33860
33861
33862
33863
33864
33865
33866
33867
33868
33869
33870
33871
33872
33873
33874
33875
33876
33877
33878
33879
33880
33881
33882
33883
33884
33885
33886
33887
33888
33889
33890
33891
33892
33893
33894
33895
33896
33897
33898
33899
33900
33901
33902
33903
33904
33905
33906
33907
33908
33909
33910
33911
33912
33913
33914
33915
33916
33917
33918
33919
33920
33921
33922
33923
33924
33925
33926
33927
33928
33929
33930
33931
33932
33933
33934
33935
33936
33937
33938
33939
33940
33941
33942
33943
33944
33945
33946
33947
33948
33949
33950
33951
33952
33953
33954
33955
33956
33957
33958
33959
33960
33961
33962
33963
33964
33965
33966
33967
33968
33969
33970
33971
33972
33973
33974
33975
33976
33977
33978
33979
33980
33981
33982
33983
33984
33985
33986
33987
33988
33989
33990
33991
33992
33993
33994
33995
33996
33997
33998
33999
34000
34001
34002
34003
34004
34005
34006
34007
34008
34009
34010
34011
34012
34013
34014
34015
34016
34017
34018
34019
34020
34021
34022
34023
34024
34025
34026
34027
34028
34029
34030
34031
34032
34033
34034
34035
34036
34037
34038
34039
34040
34041
34042
34043
34044
34045
34046
34047
34048
34049
34050
34051
34052
34053
34054
34055
34056
34057
34058
34059
34060
34061
34062
34063
34064
34065
34066
34067
34068
34069
34070
34071
34072
34073
34074
34075
34076
34077
34078
34079
34080
34081
34082
34083
34084
34085
34086
34087
34088
34089
34090
34091
34092
34093
34094
34095
34096
34097
34098
34099
34100
34101
34102
34103
34104
34105
34106
34107
34108
34109
34110
34111
34112
34113
34114
34115
34116
34117
34118
34119
34120
34121
34122
34123
34124
34125
34126
34127
34128
34129
34130
34131
34132
34133
34134
34135
34136
34137
34138
34139
34140
34141
34142
34143
34144
34145
34146
34147
34148
34149
34150
34151
34152
34153
34154
34155
34156
34157
34158
34159
34160
34161
34162
34163
34164
34165
34166
34167
34168
34169
34170
34171
34172
34173
34174
34175
34176
34177
34178
34179
34180
34181
34182
34183
34184
34185
34186
34187
34188
34189
34190
34191
34192
34193
34194
34195
34196
34197
34198
34199
34200
34201
34202
34203
34204
34205
34206
34207
34208
34209
34210
34211
34212
34213
34214
34215
34216
34217
34218
34219
34220
34221
34222
34223
34224
34225
34226
34227
34228
34229
34230
34231
34232
34233
34234
34235
34236
34237
34238
34239
34240
34241
34242
34243
34244
34245
34246
34247
34248
34249
34250
34251
34252
34253
34254
34255
34256
34257
34258
34259
34260
34261
34262
34263
34264
34265
34266
34267
34268
34269
34270
34271
34272
34273
34274
34275
34276
34277
34278
34279
34280
34281
34282
34283
34284
34285
34286
34287
34288
34289
34290
34291
34292
34293
34294
34295
34296
34297
34298
34299
34300
34301
34302
34303
34304
34305
34306
34307
34308
34309
34310
34311
34312
34313
34314
34315
34316
34317
34318
34319
34320
34321
34322
34323
34324
34325
34326
34327
34328
34329
34330
34331
34332
34333
34334
34335
34336
34337
34338
34339
34340
34341
34342
34343
34344
34345
34346
34347
34348
34349
34350
34351
34352
34353
34354
34355
34356
34357
34358
34359
34360
34361
34362
34363
34364
34365
34366
34367
34368
34369
34370
34371
34372
34373
34374
34375
34376
34377
34378
34379
34380
34381
34382
34383
34384
34385
34386
34387
34388
34389
34390
34391
34392
34393
34394
34395
34396
34397
34398
34399
34400
34401
34402
34403
34404
34405
34406
34407
34408
34409
34410
34411
34412
34413
34414
34415
34416
34417
34418
34419
34420
34421
34422
34423
34424
34425
34426
34427
34428
34429
34430
34431
34432
34433
34434
34435
34436
34437
34438
34439
34440
34441
34442
34443
34444
34445
34446
34447
34448
34449
34450
34451
34452
34453
34454
34455
34456
34457
34458
34459
34460
34461
34462
34463
34464
34465
34466
34467
34468
34469
34470
34471
34472
34473
34474
34475
34476
34477
34478
34479
34480
34481
34482
34483
34484
34485
34486
34487
34488
34489
34490
34491
34492
34493
34494
34495
34496
34497
34498
34499
34500
34501
34502
34503
34504
34505
34506
34507
34508
34509
34510
34511
34512
34513
34514
34515
34516
34517
34518
34519
34520
34521
34522
34523
34524
34525
34526
34527
34528
34529
34530
34531
34532
34533
34534
34535
34536
34537
34538
34539
34540
34541
34542
34543
34544
34545
34546
34547
34548
34549
34550
34551
34552
34553
34554
34555
34556
34557
34558
34559
34560
34561
34562
34563
34564
34565
34566
34567
34568
34569
34570
34571
34572
34573
34574
34575
34576
34577
34578
34579
34580
34581
34582
34583
34584
34585
34586
34587
34588
34589
34590
34591
34592
34593
34594
34595
34596
34597
34598
34599
34600
34601
34602
34603
34604
34605
34606
34607
34608
34609
34610
34611
34612
34613
34614
34615
34616
34617
34618
34619
34620
34621
34622
34623
34624
34625
34626
34627
34628
34629
34630
34631
34632
34633
34634
34635
34636
34637
34638
34639
34640
34641
34642
34643
34644
34645
34646
34647
34648
34649
34650
34651
34652
34653
34654
34655
34656
34657
34658
34659
34660
34661
34662
34663
34664
34665
34666
34667
34668
34669
34670
34671
34672
34673
34674
34675
34676
34677
34678
34679
34680
34681
34682
34683
34684
34685
34686
34687
34688
34689
34690
34691
34692
34693
34694
34695
34696
34697
34698
34699
34700
34701
34702
34703
34704
34705
34706
34707
34708
34709
34710
34711
34712
34713
34714
34715
34716
34717
34718
34719
34720
34721
34722
34723
34724
34725
34726
34727
34728
34729
34730
34731
34732
34733
34734
34735
34736
34737
34738
34739
34740
34741
34742
34743
34744
34745
34746
34747
34748
34749
34750
34751
34752
34753
34754
34755
34756
34757
34758
34759
34760
34761
34762
34763
34764
34765
34766
34767
34768
34769
34770
34771
34772
34773
34774
34775
34776
34777
34778
34779
34780
34781
34782
34783
34784
34785
34786
34787
34788
34789
34790
34791
34792
34793
34794
34795
34796
34797
34798
34799
34800
34801
34802
34803
34804
34805
34806
34807
34808
34809
34810
34811
34812
34813
34814
34815
34816
34817
34818
34819
34820
34821
34822
34823
34824
34825
34826
34827
34828
34829
34830
34831
34832
34833
34834
34835
34836
34837
34838
34839
34840
34841
34842
34843
34844
34845
34846
34847
34848
34849
34850
34851
34852
34853
34854
34855
34856
34857
34858
34859
34860
34861
34862
34863
34864
34865
34866
34867
34868
34869
34870
34871
34872
34873
34874
34875
34876
34877
34878
34879
34880
34881
34882
34883
34884
34885
34886
34887
34888
34889
34890
34891
34892
34893
34894
34895
34896
34897
34898
34899
34900
34901
34902
34903
34904
34905
34906
34907
34908
34909
34910
34911
34912
34913
34914
34915
34916
34917
34918
34919
34920
34921
34922
34923
34924
34925
34926
34927
34928
34929
34930
34931
34932
34933
34934
34935
34936
34937
34938
34939
34940
34941
34942
34943
34944
34945
34946
34947
34948
34949
34950
34951
34952
34953
34954
34955
34956
34957
34958
34959
34960
34961
34962
34963
34964
34965
34966
34967
34968
34969
34970
34971
34972
34973
34974
34975
34976
34977
34978
34979
34980
34981
34982
34983
34984
34985
34986
34987
34988
34989
34990
34991
34992
34993
34994
34995
34996
34997
34998
34999
35000
35001
35002
35003
35004
35005
35006
35007
35008
35009
35010
35011
35012
35013
35014
35015
35016
35017
35018
35019
35020
35021
35022
35023
35024
35025
35026
35027
35028
35029
35030
35031
35032
35033
35034
35035
35036
35037
35038
35039
35040
35041
35042
35043
35044
35045
35046
35047
35048
35049
35050
35051
35052
35053
35054
35055
35056
35057
35058
35059
35060
35061
35062
35063
35064
35065
35066
35067
35068
35069
35070
35071
35072
35073
35074
35075
35076
35077
35078
35079
35080
35081
35082
35083
35084
35085
35086
35087
35088
35089
35090
35091
35092
35093
35094
35095
35096
35097
35098
35099
35100
35101
35102
35103
35104
35105
35106
35107
35108
35109
35110
35111
35112
35113
35114
35115
35116
35117
35118
35119
35120
35121
35122
35123
35124
35125
35126
35127
35128
35129
35130
35131
35132
35133
35134
35135
35136
35137
35138
35139
35140
35141
35142
35143
35144
35145
35146
35147
35148
35149
35150
35151
35152
35153
35154
35155
35156
35157
35158
35159
35160
35161
35162
35163
35164
35165
35166
35167
35168
35169
35170
35171
35172
35173
35174
35175
35176
35177
35178
35179
35180
35181
35182
35183
35184
35185
35186
35187
35188
35189
35190
35191
35192
35193
35194
35195
35196
35197
35198
35199
35200
35201
35202
35203
35204
35205
35206
35207
35208
35209
35210
35211
35212
35213
35214
35215
35216
35217
35218
35219
35220
35221
35222
35223
35224
35225
35226
35227
35228
35229
35230
35231
35232
35233
35234
35235
35236
35237
35238
35239
35240
35241
35242
35243
35244
35245
35246
35247
35248
35249
35250
35251
35252
35253
35254
35255
35256
35257
35258
35259
35260
35261
35262
35263
35264
35265
35266
35267
35268
35269
35270
35271
35272
35273
35274
35275
35276
35277
35278
35279
35280
35281
35282
35283
35284
35285
35286
35287
35288
35289
35290
35291
35292
35293
35294
35295
35296
35297
35298
35299
35300
35301
35302
35303
35304
35305
35306
35307
35308
35309
35310
35311
35312
35313
35314
35315
35316
35317
35318
35319
35320
35321
35322
35323
35324
35325
35326
35327
35328
35329
35330
35331
35332
35333
35334
35335
35336
35337
35338
35339
35340
35341
35342
35343
35344
35345
35346
35347
35348
35349
35350
35351
35352
35353
35354
35355
35356
35357
35358
35359
35360
35361
35362
35363
35364
35365
35366
35367
35368
35369
35370
35371
35372
35373
35374
35375
35376
35377
35378
35379
35380
35381
35382
35383
35384
35385
35386
35387
35388
35389
35390
35391
35392
35393
35394
35395
35396
35397
35398
35399
35400
35401
35402
35403
35404
35405
35406
35407
35408
35409
35410
35411
35412
35413
35414
35415
35416
35417
35418
35419
35420
35421
35422
35423
35424
35425
35426
35427
35428
35429
35430
35431
35432
35433
35434
35435
35436
35437
35438
35439
35440
35441
35442
35443
35444
35445
35446
35447
35448
35449
35450
35451
35452
35453
35454
35455
35456
35457
35458
35459
35460
35461
35462
35463
35464
35465
35466
35467
35468
35469
35470
35471
35472
35473
35474
35475
35476
35477
35478
35479
35480
35481
35482
35483
35484
35485
35486
35487
35488
35489
35490
35491
35492
35493
35494
35495
35496
35497
35498
35499
35500
35501
35502
35503
35504
35505
35506
35507
35508
35509
35510
35511
35512
35513
35514
35515
35516
35517
35518
35519
35520
35521
35522
35523
35524
35525
35526
35527
35528
35529
35530
35531
35532
35533
35534
35535
35536
35537
35538
35539
35540
35541
35542
35543
35544
35545
35546
35547
35548
35549
35550
35551
35552
35553
35554
35555
35556
35557
35558
35559
35560
35561
35562
35563
35564
35565
35566
35567
35568
35569
35570
35571
35572
35573
35574
35575
35576
35577
35578
35579
35580
35581
35582
35583
35584
35585
35586
35587
35588
35589
35590
35591
35592
35593
35594
35595
35596
35597
35598
35599
35600
35601
35602
35603
35604
35605
35606
35607
35608
35609
35610
35611
35612
35613
35614
35615
35616
35617
35618
35619
35620
35621
35622
35623
35624
35625
35626
35627
35628
35629
35630
35631
35632
35633
35634
35635
35636
35637
35638
35639
35640
35641
35642
35643
35644
35645
35646
35647
35648
35649
35650
35651
35652
35653
35654
35655
35656
35657
35658
35659
35660
35661
35662
35663
35664
35665
35666
35667
35668
35669
35670
35671
35672
35673
35674
35675
35676
35677
35678
35679
35680
35681
35682
35683
35684
35685
35686
35687
35688
35689
35690
35691
35692
35693
35694
35695
35696
35697
35698
35699
35700
35701
35702
35703
35704
35705
35706
35707
35708
35709
35710
35711
35712
35713
35714
35715
35716
35717
35718
35719
35720
35721
35722
35723
35724
35725
35726
35727
35728
35729
35730
35731
35732
35733
35734
35735
35736
35737
35738
35739
35740
35741
35742
35743
35744
35745
35746
35747
35748
35749
35750
35751
35752
35753
35754
35755
35756
35757
35758
35759
35760
35761
35762
35763
35764
35765
35766
35767
35768
35769
35770
35771
35772
35773
35774
35775
35776
35777
35778
35779
35780
35781
35782
35783
35784
35785
35786
35787
35788
35789
35790
35791
35792
35793
35794
35795
35796
35797
35798
35799
35800
35801
35802
35803
35804
35805
35806
35807
35808
35809
35810
35811
35812
35813
35814
35815
35816
35817
35818
35819
35820
35821
35822
35823
35824
35825
35826
35827
35828
35829
35830
35831
35832
35833
35834
35835
35836
35837
35838
35839
35840
35841
35842
35843
35844
35845
35846
35847
35848
35849
35850
35851
35852
35853
35854
35855
35856
35857
35858
35859
35860
35861
35862
35863
35864
35865
35866
35867
35868
35869
35870
35871
35872
35873
35874
35875
35876
35877
35878
35879
35880
35881
35882
35883
35884
35885
35886
35887
35888
35889
35890
35891
35892
35893
35894
35895
35896
35897
35898
35899
35900
35901
35902
35903
35904
35905
35906
35907
35908
35909
35910
35911
35912
35913
35914
35915
35916
35917
35918
35919
35920
35921
35922
35923
35924
35925
35926
35927
35928
35929
35930
35931
35932
35933
35934
35935
35936
35937
35938
35939
35940
35941
35942
35943
35944
35945
35946
35947
35948
35949
35950
35951
35952
35953
35954
35955
35956
35957
35958
35959
35960
35961
35962
35963
35964
35965
35966
35967
35968
35969
35970
35971
35972
35973
35974
35975
35976
35977
35978
35979
35980
35981
35982
35983
35984
35985
35986
35987
35988
35989
35990
35991
35992
35993
35994
35995
35996
35997
35998
35999
36000
36001
36002
36003
36004
36005
36006
36007
36008
36009
36010
36011
36012
36013
36014
36015
36016
36017
36018
36019
36020
36021
36022
36023
36024
36025
36026
36027
36028
36029
36030
36031
36032
36033
36034
36035
36036
36037
36038
36039
36040
36041
36042
36043
36044
36045
36046
36047
36048
36049
36050
36051
36052
36053
36054
36055
36056
36057
36058
36059
36060
36061
36062
36063
36064
36065
36066
36067
36068
36069
36070
36071
36072
36073
36074
36075
36076
36077
36078
36079
36080
36081
36082
36083
36084
36085
36086
36087
36088
36089
36090
36091
36092
36093
36094
36095
36096
36097
36098
36099
36100
36101
36102
36103
36104
36105
36106
36107
36108
36109
36110
36111
36112
36113
36114
36115
36116
36117
36118
36119
36120
36121
36122
36123
36124
36125
36126
36127
36128
36129
36130
36131
36132
36133
36134
36135
36136
36137
36138
36139
36140
36141
36142
36143
36144
36145
36146
36147
36148
36149
36150
36151
36152
36153
36154
36155
36156
36157
36158
36159
36160
36161
36162
36163
36164
36165
36166
36167
36168
36169
36170
36171
36172
36173
36174
36175
36176
36177
36178
36179
36180
36181
36182
36183
36184
36185
36186
36187
36188
36189
36190
36191
36192
36193
36194
36195
36196
36197
36198
36199
36200
36201
36202
36203
36204
36205
36206
36207
36208
36209
36210
36211
36212
36213
36214
36215
36216
36217
36218
36219
36220
36221
36222
36223
36224
36225
36226
36227
36228
36229
36230
36231
36232
36233
36234
36235
36236
36237
36238
36239
36240
36241
36242
36243
36244
36245
36246
36247
36248
36249
36250
36251
36252
36253
36254
36255
36256
36257
36258
36259
36260
36261
36262
36263
36264
36265
36266
36267
36268
36269
36270
36271
36272
36273
36274
36275
36276
36277
36278
36279
36280
36281
36282
36283
36284
36285
36286
36287
36288
36289
36290
36291
36292
36293
36294
36295
36296
36297
36298
36299
36300
36301
36302
36303
36304
36305
36306
36307
36308
36309
36310
36311
36312
36313
36314
36315
36316
36317
36318
36319
36320
36321
36322
36323
36324
36325
36326
36327
36328
36329
36330
36331
36332
36333
36334
36335
36336
36337
36338
36339
36340
36341
36342
36343
36344
36345
36346
36347
36348
36349
36350
36351
36352
36353
36354
36355
36356
36357
36358
36359
36360
36361
36362
36363
36364
36365
36366
36367
36368
36369
36370
36371
36372
36373
36374
36375
36376
36377
36378
36379
36380
36381
36382
36383
36384
36385
36386
36387
36388
36389
36390
36391
36392
36393
36394
36395
36396
36397
36398
36399
36400
36401
36402
36403
36404
36405
36406
36407
36408
36409
36410
36411
36412
36413
36414
36415
36416
36417
36418
36419
36420
36421
36422
36423
36424
36425
36426
36427
36428
36429
36430
36431
36432
36433
36434
36435
36436
36437
36438
36439
36440
36441
36442
36443
36444
36445
36446
36447
36448
36449
36450
36451
36452
36453
36454
36455
36456
36457
36458
36459
36460
36461
36462
36463
36464
36465
36466
36467
36468
36469
36470
36471
36472
36473
36474
36475
36476
36477
36478
36479
36480
36481
36482
36483
36484
36485
36486
36487
36488
36489
36490
36491
36492
36493
36494
36495
36496
36497
36498
36499
36500
36501
36502
36503
36504
36505
36506
36507
36508
36509
36510
36511
36512
36513
36514
36515
36516
36517
36518
36519
36520
36521
36522
36523
36524
36525
36526
36527
36528
36529
36530
36531
36532
36533
36534
36535
36536
36537
36538
36539
36540
36541
36542
36543
36544
36545
36546
36547
36548
36549
36550
36551
36552
36553
36554
36555
36556
36557
36558
36559
36560
36561
36562
36563
36564
36565
36566
36567
36568
36569
36570
36571
36572
36573
36574
36575
36576
36577
36578
36579
36580
36581
36582
36583
36584
36585
36586
36587
36588
36589
36590
36591
36592
36593
36594
36595
36596
36597
36598
36599
36600
36601
36602
36603
36604
36605
36606
36607
36608
36609
36610
36611
36612
36613
36614
36615
36616
36617
36618
36619
36620
36621
36622
36623
36624
36625
36626
36627
36628
36629
36630
36631
36632
36633
36634
36635
36636
36637
36638
36639
36640
36641
36642
36643
36644
36645
36646
36647
36648
36649
36650
36651
36652
36653
36654
36655
36656
36657
36658
36659
36660
36661
36662
36663
36664
36665
36666
36667
36668
36669
36670
36671
36672
36673
36674
36675
36676
36677
36678
36679
36680
36681
36682
36683
36684
36685
36686
36687
36688
36689
36690
36691
36692
36693
36694
36695
36696
36697
36698
36699
36700
36701
36702
36703
36704
36705
36706
36707
36708
36709
36710
36711
36712
36713
36714
36715
36716
36717
36718
36719
36720
36721
36722
36723
36724
36725
36726
36727
36728
36729
36730
36731
36732
36733
36734
36735
36736
36737
36738
36739
36740
36741
36742
36743
36744
36745
36746
36747
36748
36749
36750
36751
36752
36753
36754
36755
36756
36757
36758
36759
36760
36761
36762
36763
36764
36765
36766
36767
36768
36769
36770
36771
36772
36773
36774
36775
36776
36777
36778
36779
36780
36781
36782
36783
36784
36785
36786
36787
36788
36789
36790
36791
36792
36793
36794
36795
36796
36797
36798
36799
36800
36801
36802
36803
36804
36805
36806
36807
36808
36809
36810
36811
36812
36813
36814
36815
36816
36817
36818
36819
36820
36821
36822
36823
36824
36825
36826
36827
36828
36829
36830
36831
36832
36833
36834
36835
36836
36837
36838
36839
36840
36841
36842
36843
36844
36845
36846
36847
36848
36849
36850
36851
36852
36853
36854
36855
36856
36857
36858
36859
36860
36861
36862
36863
36864
36865
36866
36867
36868
36869
36870
36871
36872
36873
36874
36875
36876
36877
36878
36879
36880
36881
36882
36883
36884
36885
36886
36887
36888
36889
36890
36891
36892
36893
36894
36895
36896
36897
36898
36899
36900
36901
36902
36903
36904
36905
36906
36907
36908
36909
36910
36911
36912
36913
36914
36915
36916
36917
36918
36919
36920
36921
36922
36923
36924
36925
36926
36927
36928
36929
36930
36931
36932
36933
36934
36935
36936
36937
36938
36939
36940
36941
36942
36943
36944
36945
36946
36947
36948
36949
36950
36951
36952
36953
36954
36955
36956
36957
36958
36959
36960
36961
36962
36963
36964
36965
36966
36967
36968
36969
36970
36971
36972
36973
36974
36975
36976
36977
36978
36979
36980
36981
36982
36983
36984
36985
36986
36987
36988
36989
36990
36991
36992
36993
36994
36995
36996
36997
36998
36999
37000
37001
37002
37003
37004
37005
37006
37007
37008
37009
37010
37011
37012
37013
37014
37015
37016
37017
37018
37019
37020
37021
37022
37023
37024
37025
37026
37027
37028
37029
37030
37031
37032
37033
37034
37035
37036
37037
37038
37039
37040
37041
37042
37043
37044
37045
37046
37047
37048
37049
37050
37051
37052
37053
37054
37055
37056
37057
37058
37059
37060
37061
37062
37063
37064
37065
37066
37067
37068
37069
37070
37071
37072
37073
37074
37075
37076
37077
37078
37079
37080
37081
37082
37083
37084
37085
37086
37087
37088
37089
37090
37091
37092
37093
37094
37095
37096
37097
37098
37099
37100
37101
37102
37103
37104
37105
37106
37107
37108
37109
37110
37111
37112
37113
37114
37115
37116
37117
37118
37119
37120
37121
37122
37123
37124
37125
37126
37127
37128
37129
37130
37131
37132
37133
37134
37135
37136
37137
37138
37139
37140
37141
37142
37143
37144
37145
37146
37147
37148
37149
37150
37151
37152
37153
37154
37155
37156
37157
37158
37159
37160
37161
37162
37163
37164
37165
37166
37167
37168
37169
37170
37171
37172
37173
37174
37175
37176
37177
37178
37179
37180
37181
37182
37183
37184
37185
37186
37187
37188
37189
37190
37191
37192
37193
37194
37195
37196
37197
37198
37199
37200
37201
37202
37203
37204
37205
37206
37207
37208
37209
37210
37211
37212
37213
37214
37215
37216
37217
37218
37219
37220
37221
37222
37223
37224
37225
37226
37227
37228
37229
37230
37231
37232
37233
37234
37235
37236
37237
37238
37239
37240
37241
37242
37243
37244
37245
37246
37247
37248
37249
37250
37251
37252
37253
37254
37255
37256
37257
37258
37259
37260
37261
37262
37263
37264
37265
37266
37267
37268
37269
37270
37271
37272
37273
37274
37275
37276
37277
37278
37279
37280
37281
37282
37283
37284
37285
37286
37287
37288
37289
37290
37291
37292
37293
37294
37295
37296
37297
37298
37299
37300
37301
37302
37303
37304
37305
37306
37307
37308
37309
37310
37311
37312
37313
37314
37315
37316
37317
37318
37319
37320
37321
37322
37323
37324
37325
37326
37327
37328
37329
37330
37331
37332
37333
37334
37335
37336
37337
37338
37339
37340
37341
37342
37343
37344
37345
37346
37347
37348
37349
37350
37351
37352
37353
37354
37355
37356
37357
37358
37359
37360
37361
37362
37363
37364
37365
37366
37367
37368
37369
37370
37371
37372
37373
37374
37375
37376
37377
37378
37379
37380
37381
37382
37383
37384
37385
37386
37387
37388
37389
37390
37391
37392
37393
37394
37395
37396
37397
37398
37399
37400
37401
37402
37403
37404
37405
37406
37407
37408
37409
37410
37411
37412
37413
37414
37415
37416
37417
37418
37419
37420
37421
37422
37423
37424
37425
37426
37427
37428
37429
37430
37431
37432
37433
37434
37435
37436
37437
37438
37439
37440
37441
37442
37443
37444
37445
37446
37447
37448
37449
37450
37451
37452
37453
37454
37455
37456
37457
37458
37459
37460
37461
37462
37463
37464
37465
37466
37467
37468
37469
37470
37471
37472
37473
37474
37475
37476
37477
37478
37479
37480
37481
37482
37483
37484
37485
37486
37487
37488
37489
37490
37491
37492
37493
37494
37495
37496
37497
37498
37499
37500
37501
37502
37503
37504
37505
37506
37507
37508
37509
37510
37511
37512
37513
37514
37515
37516
37517
37518
37519
37520
37521
37522
37523
37524
37525
37526
37527
37528
37529
37530
37531
37532
37533
37534
37535
37536
37537
37538
37539
37540
37541
37542
37543
37544
37545
37546
37547
37548
37549
37550
37551
37552
37553
37554
37555
37556
37557
37558
37559
37560
37561
37562
37563
37564
37565
37566
37567
37568
37569
37570
37571
37572
37573
37574
37575
37576
37577
37578
37579
37580
37581
37582
37583
37584
37585
37586
37587
37588
37589
37590
37591
37592
37593
37594
37595
37596
37597
37598
37599
37600
37601
37602
37603
37604
37605
37606
37607
37608
37609
37610
37611
37612
37613
37614
37615
37616
37617
37618
37619
37620
37621
37622
37623
37624
37625
37626
37627
37628
37629
37630
37631
37632
37633
37634
37635
37636
37637
37638
37639
37640
37641
37642
37643
37644
37645
37646
37647
37648
37649
37650
37651
37652
37653
37654
37655
37656
37657
37658
37659
37660
37661
37662
37663
37664
37665
37666
37667
37668
37669
37670
37671
37672
37673
37674
37675
37676
37677
37678
37679
37680
37681
37682
37683
37684
37685
37686
37687
37688
37689
37690
37691
37692
37693
37694
37695
37696
37697
37698
37699
37700
37701
37702
37703
37704
37705
37706
37707
37708
37709
37710
37711
37712
37713
37714
37715
37716
37717
37718
37719
37720
37721
37722
37723
37724
37725
37726
37727
37728
37729
37730
37731
37732
37733
37734
37735
37736
37737
37738
37739
37740
37741
37742
37743
37744
37745
37746
37747
37748
37749
37750
37751
37752
37753
37754
37755
37756
37757
37758
37759
37760
37761
37762
37763
37764
37765
37766
37767
37768
37769
37770
37771
37772
37773
37774
37775
37776
37777
37778
37779
37780
37781
37782
37783
37784
37785
37786
37787
37788
37789
37790
37791
37792
37793
37794
37795
37796
37797
37798
37799
37800
37801
37802
37803
37804
37805
37806
37807
37808
37809
37810
37811
37812
37813
37814
37815
37816
37817
37818
37819
37820
37821
37822
37823
37824
37825
37826
37827
37828
37829
37830
37831
37832
37833
37834
37835
37836
37837
37838
37839
37840
37841
37842
37843
37844
37845
37846
37847
37848
37849
37850
37851
37852
37853
37854
37855
37856
37857
37858
37859
37860
37861
37862
37863
37864
37865
37866
37867
37868
37869
37870
37871
37872
37873
37874
37875
37876
37877
37878
37879
37880
37881
37882
37883
37884
37885
37886
37887
37888
37889
37890
37891
37892
37893
37894
37895
37896
37897
37898
37899
37900
37901
37902
37903
37904
37905
37906
37907
37908
37909
37910
37911
37912
37913
37914
37915
37916
37917
37918
37919
37920
37921
37922
37923
37924
37925
37926
37927
37928
37929
37930
37931
37932
37933
37934
37935
37936
37937
37938
37939
37940
37941
37942
37943
37944
37945
37946
37947
37948
37949
37950
37951
37952
37953
37954
37955
37956
37957
37958
37959
37960
37961
37962
37963
37964
37965
37966
37967
37968
37969
37970
37971
37972
37973
37974
37975
37976
37977
37978
37979
37980
37981
37982
37983
37984
37985
37986
37987
37988
37989
37990
37991
37992
37993
37994
37995
37996
37997
37998
37999
38000
38001
38002
38003
38004
38005
38006
38007
38008
38009
38010
38011
38012
38013
38014
38015
38016
38017
38018
38019
38020
38021
38022
38023
38024
38025
38026
38027
38028
38029
38030
38031
38032
38033
38034
38035
38036
38037
38038
38039
38040
38041
38042
38043
38044
38045
38046
38047
38048
38049
38050
38051
38052
38053
38054
38055
38056
38057
38058
38059
38060
38061
38062
38063
38064
38065
38066
38067
38068
38069
38070
38071
38072
38073
38074
38075
38076
38077
38078
38079
38080
38081
38082
38083
38084
38085
38086
38087
38088
38089
38090
38091
38092
38093
38094
38095
38096
38097
38098
38099
38100
38101
38102
38103
38104
38105
38106
38107
38108
38109
38110
38111
38112
38113
38114
38115
38116
38117
38118
38119
38120
38121
38122
38123
38124
38125
38126
38127
38128
38129
38130
38131
38132
38133
38134
38135
38136
38137
38138
38139
38140
38141
38142
38143
38144
38145
38146
38147
38148
38149
38150
38151
38152
38153
38154
38155
38156
38157
38158
38159
38160
38161
38162
38163
38164
38165
38166
38167
38168
38169
38170
38171
38172
38173
38174
38175
38176
38177
38178
38179
38180
38181
38182
38183
38184
38185
38186
38187
38188
38189
38190
38191
38192
38193
38194
38195
38196
38197
38198
38199
38200
38201
38202
38203
38204
38205
38206
38207
38208
38209
38210
38211
38212
38213
38214
38215
38216
38217
38218
38219
38220
38221
38222
38223
38224
38225
38226
38227
38228
38229
38230
38231
38232
38233
38234
38235
38236
38237
38238
38239
38240
38241
38242
38243
38244
38245
38246
38247
38248
38249
38250
38251
38252
38253
38254
38255
38256
38257
38258
38259
38260
38261
38262
38263
38264
38265
38266
38267
38268
38269
38270
38271
38272
38273
38274
38275
38276
38277
38278
38279
38280
38281
38282
38283
38284
38285
38286
38287
38288
38289
38290
38291
38292
38293
38294
38295
38296
38297
38298
38299
38300
38301
38302
38303
38304
38305
38306
38307
38308
38309
38310
38311
38312
38313
38314
38315
38316
38317
38318
38319
38320
38321
38322
38323
38324
38325
38326
38327
38328
38329
38330
38331
38332
38333
38334
38335
38336
38337
38338
38339
38340
38341
38342
38343
38344
38345
38346
38347
38348
38349
38350
38351
38352
38353
38354
38355
38356
38357
38358
38359
38360
38361
38362
38363
38364
38365
38366
38367
38368
38369
38370
38371
38372
38373
38374
38375
38376
38377
38378
38379
38380
38381
38382
38383
38384
38385
38386
38387
38388
38389
38390
38391
38392
38393
38394
38395
38396
38397
38398
38399
38400
38401
38402
38403
38404
38405
38406
38407
38408
38409
38410
38411
38412
38413
38414
38415
38416
38417
38418
38419
38420
38421
38422
38423
38424
38425
38426
38427
38428
38429
38430
38431
38432
38433
38434
38435
38436
38437
38438
38439
38440
38441
38442
38443
38444
38445
38446
38447
38448
38449
38450
38451
38452
38453
38454
38455
38456
38457
38458
38459
38460
38461
38462
38463
38464
38465
38466
38467
38468
38469
38470
38471
38472
38473
38474
38475
38476
38477
38478
38479
38480
38481
38482
38483
38484
38485
38486
38487
38488
38489
38490
38491
38492
38493
38494
38495
38496
38497
38498
38499
38500
38501
38502
38503
38504
38505
38506
38507
38508
38509
38510
38511
38512
38513
38514
38515
38516
38517
38518
38519
38520
38521
38522
38523
38524
38525
38526
38527
38528
38529
38530
38531
38532
38533
38534
38535
38536
38537
38538
38539
38540
38541
38542
38543
38544
38545
38546
38547
38548
38549
38550
38551
38552
38553
38554
38555
38556
38557
38558
38559
38560
38561
38562
38563
38564
38565
38566
38567
38568
38569
38570
38571
38572
38573
38574
38575
38576
38577
38578
38579
38580
38581
38582
38583
38584
38585
38586
38587
38588
38589
38590
38591
38592
38593
38594
38595
38596
38597
38598
38599
38600
38601
38602
38603
38604
38605
38606
38607
38608
38609
38610
38611
38612
38613
38614
38615
38616
38617
38618
38619
38620
38621
38622
38623
38624
38625
38626
38627
38628
38629
38630
38631
38632
38633
38634
38635
38636
38637
38638
38639
38640
38641
38642
38643
38644
38645
38646
38647
38648
38649
38650
38651
38652
38653
38654
38655
38656
38657
38658
38659
38660
38661
38662
38663
38664
38665
38666
38667
38668
38669
38670
38671
38672
38673
38674
38675
38676
38677
38678
38679
38680
38681
38682
38683
38684
38685
38686
38687
38688
38689
38690
38691
38692
38693
38694
38695
38696
38697
38698
38699
38700
38701
38702
38703
38704
38705
38706
38707
38708
38709
38710
38711
38712
38713
38714
38715
38716
38717
38718
38719
38720
38721
38722
38723
38724
38725
38726
38727
38728
38729
38730
38731
38732
38733
38734
38735
38736
38737
38738
38739
38740
38741
38742
38743
38744
38745
38746
38747
38748
38749
38750
38751
38752
38753
38754
38755
38756
38757
38758
38759
38760
38761
38762
38763
38764
38765
38766
38767
38768
38769
38770
38771
38772
38773
38774
38775
38776
38777
38778
38779
38780
38781
38782
38783
38784
38785
38786
38787
38788
38789
38790
38791
38792
38793
38794
38795
38796
38797
38798
38799
38800
38801
38802
38803
38804
38805
38806
38807
38808
38809
38810
38811
38812
38813
38814
38815
38816
38817
38818
38819
38820
38821
38822
38823
38824
38825
38826
38827
38828
38829
38830
38831
38832
38833
38834
38835
38836
38837
38838
38839
38840
38841
38842
38843
38844
38845
38846
38847
38848
38849
38850
38851
38852
38853
38854
38855
38856
38857
38858
38859
38860
38861
38862
38863
38864
38865
38866
38867
38868
38869
38870
38871
38872
38873
38874
38875
38876
38877
38878
38879
38880
38881
38882
38883
38884
38885
38886
38887
38888
38889
38890
38891
38892
38893
38894
38895
38896
38897
38898
38899
38900
38901
38902
38903
38904
38905
38906
38907
38908
38909
38910
38911
38912
38913
38914
38915
38916
38917
38918
38919
38920
38921
38922
38923
38924
38925
38926
38927
38928
38929
38930
38931
38932
38933
38934
38935
38936
38937
38938
38939
38940
38941
38942
38943
38944
38945
38946
38947
38948
38949
38950
38951
38952
38953
38954
38955
38956
38957
38958
38959
38960
38961
38962
38963
38964
38965
38966
38967
38968
38969
38970
38971
38972
38973
38974
38975
38976
38977
38978
38979
38980
38981
38982
38983
38984
38985
38986
38987
38988
38989
38990
38991
38992
38993
38994
38995
38996
38997
38998
38999
39000
39001
39002
39003
39004
39005
39006
39007
39008
39009
39010
39011
39012
39013
39014
39015
39016
39017
39018
39019
39020
39021
39022
39023
39024
39025
39026
39027
39028
39029
39030
39031
39032
39033
39034
39035
39036
39037
39038
39039
39040
39041
39042
39043
39044
39045
39046
39047
39048
39049
39050
39051
39052
39053
39054
39055
39056
39057
39058
39059
39060
39061
39062
39063
39064
39065
39066
39067
39068
39069
39070
39071
39072
39073
39074
39075
39076
39077
39078
39079
39080
39081
39082
39083
39084
39085
39086
39087
39088
39089
39090
39091
39092
39093
39094
39095
39096
39097
39098
39099
39100
39101
39102
39103
39104
39105
39106
39107
39108
39109
39110
39111
39112
39113
39114
39115
39116
39117
39118
39119
39120
39121
39122
39123
39124
39125
39126
39127
39128
39129
39130
39131
39132
39133
39134
39135
39136
39137
39138
39139
39140
39141
39142
39143
39144
39145
39146
39147
39148
39149
39150
39151
39152
39153
39154
39155
39156
39157
39158
39159
39160
39161
39162
39163
39164
39165
39166
39167
39168
39169
39170
39171
39172
39173
39174
39175
39176
39177
39178
39179
39180
39181
39182
39183
39184
39185
39186
39187
39188
39189
39190
39191
39192
39193
39194
39195
39196
39197
39198
39199
39200
39201
39202
39203
39204
39205
39206
39207
39208
39209
39210
39211
39212
39213
39214
39215
39216
39217
39218
39219
39220
39221
39222
39223
39224
39225
39226
39227
39228
39229
39230
39231
39232
39233
39234
39235
39236
39237
39238
39239
39240
39241
39242
39243
39244
39245
39246
39247
39248
39249
39250
39251
39252
39253
39254
39255
39256
39257
39258
39259
39260
39261
39262
39263
39264
39265
39266
39267
39268
39269
39270
39271
39272
39273
39274
39275
39276
39277
39278
39279
39280
39281
39282
39283
39284
39285
39286
39287
39288
39289
39290
39291
39292
39293
39294
39295
39296
39297
39298
39299
39300
39301
39302
39303
39304
39305
39306
39307
39308
39309
39310
39311
39312
39313
39314
39315
39316
39317
39318
39319
39320
39321
39322
39323
39324
39325
39326
39327
39328
39329
39330
39331
39332
39333
39334
39335
39336
39337
39338
39339
39340
39341
39342
39343
39344
39345
39346
39347
39348
39349
39350
39351
39352
39353
39354
39355
39356
39357
39358
39359
39360
39361
39362
39363
39364
39365
39366
39367
39368
39369
39370
39371
39372
39373
39374
39375
39376
39377
39378
39379
39380
39381
39382
39383
39384
39385
39386
39387
39388
39389
39390
39391
39392
39393
39394
39395
39396
39397
39398
39399
39400
39401
39402
39403
39404
39405
39406
39407
39408
39409
39410
39411
39412
39413
39414
39415
39416
39417
39418
39419
39420
39421
39422
39423
39424
39425
39426
39427
39428
39429
39430
39431
39432
39433
39434
39435
39436
39437
39438
39439
39440
39441
39442
39443
39444
39445
39446
39447
39448
39449
39450
39451
39452
39453
39454
39455
39456
39457
39458
39459
39460
39461
39462
39463
39464
39465
39466
39467
39468
39469
39470
39471
39472
39473
39474
39475
39476
39477
39478
39479
39480
39481
39482
39483
39484
39485
39486
39487
39488
39489
39490
39491
39492
39493
39494
39495
39496
39497
39498
39499
39500
39501
39502
39503
39504
39505
39506
39507
39508
39509
39510
39511
39512
39513
39514
39515
39516
39517
39518
39519
39520
39521
39522
39523
39524
39525
39526
39527
39528
39529
39530
39531
39532
39533
39534
39535
39536
39537
39538
39539
39540
39541
39542
39543
39544
39545
39546
39547
39548
39549
39550
39551
39552
39553
39554
39555
39556
39557
39558
39559
39560
39561
39562
39563
39564
39565
39566
39567
39568
39569
39570
39571
39572
39573
39574
39575
39576
39577
39578
39579
39580
39581
39582
39583
39584
39585
39586
39587
39588
39589
39590
39591
39592
39593
39594
39595
39596
39597
39598
39599
39600
39601
39602
39603
39604
39605
39606
39607
39608
39609
39610
39611
39612
39613
39614
39615
39616
39617
39618
39619
39620
39621
39622
39623
39624
39625
39626
39627
39628
39629
39630
39631
39632
39633
39634
39635
39636
39637
39638
39639
39640
39641
39642
39643
39644
39645
39646
39647
39648
39649
39650
39651
39652
39653
39654
39655
39656
39657
39658
39659
39660
39661
39662
39663
39664
39665
39666
39667
39668
39669
39670
39671
39672
39673
39674
39675
39676
39677
39678
39679
39680
39681
39682
39683
39684
39685
39686
39687
39688
39689
39690
39691
39692
39693
39694
39695
39696
39697
39698
39699
39700
39701
39702
39703
39704
39705
39706
39707
39708
39709
39710
39711
39712
39713
39714
39715
39716
39717
39718
39719
39720
39721
39722
39723
39724
39725
39726
39727
39728
39729
39730
39731
39732
39733
39734
39735
39736
39737
39738
39739
39740
39741
39742
39743
39744
39745
39746
39747
39748
39749
39750
39751
39752
39753
39754
39755
39756
39757
39758
39759
39760
39761
39762
39763
39764
39765
39766
39767
39768
39769
39770
39771
39772
39773
39774
39775
39776
39777
39778
39779
39780
39781
39782
39783
39784
39785
39786
39787
39788
39789
39790
39791
39792
39793
39794
39795
39796
39797
39798
39799
39800
39801
39802
39803
39804
39805
39806
39807
39808
39809
39810
39811
39812
39813
39814
39815
39816
39817
39818
39819
39820
39821
39822
39823
39824
39825
39826
39827
39828
39829
39830
39831
39832
39833
39834
39835
39836
39837
39838
39839
39840
39841
39842
39843
39844
39845
39846
39847
39848
39849
39850
39851
39852
39853
39854
39855
39856
39857
39858
39859
39860
39861
39862
39863
39864
39865
39866
39867
39868
39869
39870
39871
39872
39873
39874
39875
39876
39877
39878
39879
39880
39881
39882
39883
39884
39885
39886
39887
39888
39889
39890
39891
39892
39893
39894
39895
39896
39897
39898
39899
39900
39901
39902
39903
39904
39905
39906
39907
39908
39909
39910
39911
39912
39913
39914
39915
39916
39917
39918
39919
39920
39921
39922
39923
39924
39925
39926
39927
39928
39929
39930
39931
39932
39933
39934
39935
39936
39937
39938
39939
39940
39941
39942
39943
39944
39945
39946
39947
39948
39949
39950
39951
39952
39953
39954
39955
39956
39957
39958
39959
39960
39961
39962
39963
39964
39965
39966
39967
39968
39969
39970
39971
39972
39973
39974
39975
39976
39977
39978
39979
39980
39981
39982
39983
39984
39985
39986
39987
39988
39989
39990
39991
39992
39993
39994
39995
39996
39997
39998
39999
40000
40001
40002
40003
40004
40005
40006
40007
40008
40009
40010
40011
40012
40013
40014
40015
40016
40017
40018
40019
40020
40021
40022
40023
40024
40025
40026
40027
40028
40029
40030
40031
40032
40033
40034
40035
40036
40037
40038
40039
40040
40041
40042
40043
40044
40045
40046
40047
40048
40049
40050
40051
40052
40053
40054
40055
40056
40057
40058
40059
40060
40061
40062
40063
40064
40065
40066
40067
40068
40069
40070
40071
40072
40073
40074
40075
40076
40077
40078
40079
40080
40081
40082
40083
40084
40085
40086
40087
40088
40089
40090
40091
40092
40093
40094
40095
40096
40097
40098
40099
40100
40101
40102
40103
40104
40105
40106
40107
40108
40109
40110
40111
40112
40113
40114
40115
40116
40117
40118
40119
40120
40121
40122
40123
40124
40125
40126
40127
40128
40129
40130
40131
40132
40133
40134
40135
40136
40137
40138
40139
40140
40141
40142
40143
40144
40145
40146
40147
40148
40149
40150
40151
40152
40153
40154
40155
40156
40157
40158
40159
40160
40161
40162
40163
40164
40165
40166
40167
40168
40169
40170
40171
40172
40173
40174
40175
40176
40177
40178
40179
40180
40181
40182
40183
40184
40185
40186
40187
40188
40189
40190
40191
40192
40193
40194
40195
40196
40197
40198
40199
40200
40201
40202
40203
40204
40205
40206
40207
40208
40209
40210
40211
40212
40213
40214
40215
40216
40217
40218
40219
40220
40221
40222
40223
40224
40225
40226
40227
40228
40229
40230
40231
40232
40233
40234
40235
40236
40237
40238
40239
40240
40241
40242
40243
40244
40245
40246
40247
40248
40249
40250
40251
40252
40253
40254
40255
40256
40257
40258
40259
40260
40261
40262
40263
40264
40265
40266
40267
40268
40269
40270
40271
40272
40273
40274
40275
40276
40277
40278
40279
40280
40281
40282
40283
40284
40285
40286
40287
40288
40289
40290
40291
40292
40293
40294
40295
40296
40297
40298
40299
40300
40301
40302
40303
40304
40305
40306
40307
40308
40309
40310
40311
40312
40313
40314
40315
40316
40317
40318
40319
40320
40321
40322
40323
40324
40325
40326
40327
40328
40329
40330
40331
40332
40333
40334
40335
40336
40337
40338
40339
40340
40341
40342
40343
40344
40345
40346
40347
40348
40349
40350
40351
40352
40353
40354
40355
40356
40357
40358
40359
40360
40361
40362
40363
40364
40365
40366
40367
40368
40369
40370
40371
40372
40373
40374
40375
40376
40377
40378
40379
40380
40381
40382
40383
40384
40385
40386
40387
40388
40389
40390
40391
40392
40393
40394
40395
40396
40397
40398
40399
40400
40401
40402
40403
40404
40405
40406
40407
40408
40409
40410
40411
40412
40413
40414
40415
40416
40417
40418
40419
40420
40421
40422
40423
40424
40425
40426
40427
40428
40429
40430
40431
40432
40433
40434
40435
40436
40437
40438
40439
40440
40441
40442
40443
40444
40445
40446
40447
40448
40449
40450
40451
40452
40453
40454
40455
40456
40457
40458
40459
40460
40461
40462
40463
40464
40465
40466
40467
40468
40469
40470
40471
40472
40473
40474
40475
40476
40477
40478
40479
40480
40481
40482
40483
40484
40485
40486
40487
40488
40489
40490
40491
40492
40493
40494
40495
40496
40497
40498
40499
40500
40501
40502
40503
40504
40505
40506
40507
40508
40509
40510
40511
40512
40513
40514
40515
40516
40517
40518
40519
40520
40521
40522
40523
40524
40525
40526
40527
40528
40529
40530
40531
40532
40533
40534
40535
40536
40537
40538
40539
40540
40541
40542
40543
40544
40545
40546
40547
40548
40549
40550
40551
40552
40553
40554
40555
40556
40557
40558
40559
40560
40561
40562
40563
40564
40565
40566
40567
40568
40569
40570
40571
40572
40573
40574
40575
40576
40577
40578
40579
40580
40581
40582
40583
40584
40585
40586
40587
40588
40589
40590
40591
40592
40593
40594
40595
40596
40597
40598
40599
40600
40601
40602
40603
40604
40605
40606
40607
40608
40609
40610
40611
40612
40613
40614
40615
40616
40617
40618
40619
40620
40621
40622
40623
40624
40625
40626
40627
40628
40629
40630
40631
40632
40633
40634
40635
40636
40637
40638
40639
40640
40641
40642
40643
40644
40645
40646
40647
40648
40649
40650
40651
40652
40653
40654
40655
40656
40657
40658
40659
40660
40661
40662
40663
40664
40665
40666
40667
40668
40669
40670
40671
40672
40673
40674
40675
40676
40677
40678
40679
40680
40681
40682
40683
40684
40685
40686
40687
40688
40689
40690
40691
40692
40693
40694
40695
40696
40697
40698
40699
40700
40701
40702
40703
40704
40705
40706
40707
40708
40709
40710
40711
40712
40713
40714
40715
40716
40717
40718
40719
40720
40721
40722
40723
40724
40725
40726
40727
40728
40729
40730
40731
40732
40733
40734
40735
40736
40737
40738
40739
40740
40741
40742
40743
40744
40745
40746
40747
40748
40749
40750
40751
40752
40753
40754
40755
40756
40757
40758
40759
40760
40761
40762
40763
40764
40765
40766
40767
40768
40769
40770
40771
40772
40773
40774
40775
40776
40777
40778
40779
40780
40781
40782
40783
40784
40785
40786
40787
40788
40789
40790
40791
40792
40793
40794
40795
40796
40797
40798
40799
40800
40801
40802
40803
40804
40805
40806
40807
40808
40809
40810
40811
40812
40813
40814
40815
40816
40817
40818
40819
40820
40821
40822
40823
40824
40825
40826
40827
40828
40829
40830
40831
40832
40833
40834
40835
40836
40837
40838
40839
40840
40841
40842
40843
40844
40845
40846
40847
40848
40849
40850
40851
40852
40853
40854
40855
40856
40857
40858
40859
40860
40861
40862
40863
40864
40865
40866
40867
40868
40869
40870
40871
40872
40873
40874
40875
40876
40877
40878
40879
40880
40881
40882
40883
40884
40885
40886
40887
40888
40889
40890
40891
40892
40893
40894
40895
40896
40897
40898
40899
40900
40901
40902
40903
40904
40905
40906
40907
40908
40909
40910
40911
40912
40913
40914
40915
40916
40917
40918
40919
40920
40921
40922
40923
40924
40925
40926
40927
40928
40929
40930
40931
40932
40933
40934
40935
40936
40937
40938
40939
40940
40941
40942
40943
40944
40945
40946
40947
40948
40949
40950
40951
40952
40953
40954
40955
40956
40957
40958
40959
40960
40961
40962
40963
40964
40965
40966
40967
40968
40969
40970
40971
40972
40973
40974
40975
40976
40977
40978
40979
40980
40981
40982
40983
40984
40985
40986
40987
40988
40989
40990
40991
40992
40993
40994
40995
40996
40997
40998
40999
41000
41001
41002
41003
41004
41005
41006
41007
41008
41009
41010
41011
41012
41013
41014
41015
41016
41017
41018
41019
41020
41021
41022
41023
41024
41025
41026
41027
41028
41029
41030
41031
41032
41033
41034
41035
41036
41037
41038
41039
41040
41041
41042
41043
41044
41045
41046
41047
41048
41049
41050
41051
41052
41053
41054
41055
41056
41057
41058
41059
41060
41061
41062
41063
41064
41065
41066
41067
41068
41069
41070
41071
41072
41073
41074
41075
41076
41077
41078
41079
41080
41081
41082
41083
41084
41085
41086
41087
41088
41089
41090
41091
41092
41093
41094
41095
41096
41097
41098
41099
41100
41101
41102
41103
41104
41105
41106
41107
41108
41109
41110
41111
41112
41113
41114
41115
41116
41117
41118
41119
41120
41121
41122
41123
41124
41125
41126
41127
41128
41129
41130
41131
41132
41133
41134
41135
41136
41137
41138
41139
41140
41141
41142
41143
41144
41145
41146
41147
41148
41149
41150
41151
41152
41153
41154
41155
41156
41157
41158
41159
41160
41161
41162
41163
41164
41165
41166
41167
41168
41169
41170
41171
41172
41173
41174
41175
41176
41177
41178
41179
41180
41181
41182
41183
41184
41185
41186
41187
41188
41189
41190
41191
41192
41193
41194
41195
41196
41197
41198
41199
41200
41201
41202
41203
41204
41205
41206
41207
41208
41209
41210
41211
41212
41213
41214
41215
41216
41217
41218
41219
41220
41221
41222
41223
41224
41225
41226
41227
41228
41229
41230
41231
41232
41233
41234
41235
41236
41237
41238
41239
41240
41241
41242
41243
41244
41245
41246
41247
41248
41249
41250
41251
41252
41253
41254
41255
41256
41257
41258
41259
41260
41261
41262
41263
41264
41265
41266
41267
41268
41269
41270
41271
41272
41273
41274
41275
41276
41277
41278
41279
41280
41281
41282
41283
41284
41285
41286
41287
41288
41289
41290
41291
41292
41293
41294
41295
41296
41297
41298
41299
41300
41301
41302
41303
41304
41305
41306
41307
41308
41309
41310
41311
41312
41313
41314
41315
41316
41317
41318
41319
41320
41321
41322
41323
41324
41325
41326
41327
41328
41329
41330
41331
41332
41333
41334
41335
41336
41337
41338
41339
41340
41341
41342
41343
41344
41345
41346
41347
41348
41349
41350
41351
41352
41353
41354
41355
41356
41357
41358
41359
41360
41361
41362
41363
41364
41365
41366
41367
41368
41369
41370
41371
41372
41373
41374
41375
41376
41377
41378
41379
41380
41381
41382
41383
41384
41385
41386
41387
41388
41389
41390
41391
41392
41393
41394
41395
41396
41397
41398
41399
41400
41401
41402
41403
41404
41405
41406
41407
41408
41409
41410
41411
41412
41413
41414
41415
41416
41417
41418
41419
41420
41421
41422
41423
41424
41425
41426
41427
41428
41429
41430
41431
41432
41433
41434
41435
41436
41437
41438
41439
41440
41441
41442
41443
41444
41445
41446
41447
41448
41449
41450
41451
41452
41453
41454
41455
41456
41457
41458
41459
41460
41461
41462
41463
41464
41465
41466
41467
41468
41469
41470
41471
41472
41473
41474
41475
41476
41477
41478
41479
41480
41481
41482
41483
41484
41485
41486
41487
41488
41489
41490
41491
41492
41493
41494
41495
41496
41497
41498
41499
41500
41501
41502
41503
41504
41505
41506
41507
41508
41509
41510
41511
41512
41513
41514
41515
41516
41517
41518
41519
41520
41521
41522
41523
41524
41525
41526
41527
41528
41529
41530
41531
41532
41533
41534
41535
41536
41537
41538
41539
41540
41541
41542
41543
41544
41545
41546
41547
41548
41549
41550
41551
41552
41553
41554
41555
41556
41557
41558
41559
41560
41561
41562
41563
41564
41565
41566
41567
41568
41569
41570
41571
41572
41573
41574
41575
41576
41577
41578
41579
41580
41581
41582
41583
41584
41585
41586
41587
41588
41589
41590
41591
41592
41593
41594
41595
41596
41597
41598
41599
41600
41601
41602
41603
41604
41605
41606
41607
41608
41609
41610
41611
41612
41613
41614
41615
41616
41617
41618
41619
41620
41621
41622
41623
41624
41625
41626
41627
41628
41629
41630
41631
41632
41633
41634
41635
41636
41637
41638
41639
41640
41641
41642
41643
41644
41645
41646
41647
41648
41649
41650
41651
41652
41653
41654
41655
41656
41657
41658
41659
41660
41661
41662
41663
41664
41665
41666
41667
41668
41669
41670
41671
41672
41673
41674
41675
41676
41677
41678
41679
41680
41681
41682
41683
41684
41685
41686
41687
41688
41689
41690
41691
41692
41693
41694
41695
41696
41697
41698
41699
41700
41701
41702
41703
41704
41705
41706
41707
41708
41709
41710
41711
41712
41713
41714
41715
41716
41717
41718
41719
41720
41721
41722
41723
41724
41725
41726
41727
41728
41729
41730
41731
41732
41733
41734
41735
41736
41737
41738
41739
41740
41741
41742
41743
41744
41745
41746
41747
41748
41749
41750
41751
41752
41753
41754
41755
41756
41757
41758
41759
41760
41761
41762
41763
41764
41765
41766
41767
41768
41769
41770
41771
41772
41773
41774
41775
41776
41777
41778
41779
41780
41781
41782
41783
41784
41785
41786
41787
41788
41789
41790
41791
41792
41793
41794
41795
41796
41797
41798
41799
41800
41801
41802
41803
41804
41805
41806
41807
41808
41809
41810
41811
41812
41813
41814
41815
41816
41817
41818
41819
41820
41821
41822
41823
41824
41825
41826
41827
41828
41829
41830
41831
41832
41833
41834
41835
41836
41837
41838
41839
41840
41841
41842
41843
41844
41845
41846
41847
41848
41849
41850
41851
41852
41853
41854
41855
41856
41857
41858
41859
41860
41861
41862
41863
41864
41865
41866
41867
41868
41869
41870
41871
41872
41873
41874
41875
41876
41877
41878
41879
41880
41881
41882
41883
41884
41885
41886
41887
41888
41889
41890
41891
41892
41893
41894
41895
41896
41897
41898
41899
41900
41901
41902
41903
41904
41905
41906
41907
41908
41909
41910
41911
41912
41913
41914
41915
41916
41917
41918
41919
41920
41921
41922
41923
41924
41925
41926
41927
41928
41929
41930
41931
41932
41933
41934
41935
41936
41937
41938
41939
41940
41941
41942
41943
41944
41945
41946
41947
41948
41949
41950
41951
41952
41953
41954
41955
41956
41957
41958
41959
41960
41961
41962
41963
41964
41965
41966
41967
41968
41969
41970
41971
41972
41973
41974
41975
41976
41977
41978
41979
41980
41981
41982
41983
41984
41985
41986
41987
41988
41989
41990
41991
41992
41993
41994
41995
41996
41997
41998
41999
42000
42001
42002
42003
42004
42005
42006
42007
42008
42009
42010
42011
42012
42013
42014
42015
42016
42017
42018
42019
42020
42021
42022
42023
42024
42025
42026
42027
42028
42029
42030
42031
42032
42033
42034
42035
42036
42037
42038
42039
42040
42041
42042
42043
42044
42045
42046
42047
42048
42049
42050
42051
42052
42053
42054
42055
42056
42057
42058
42059
42060
42061
42062
42063
42064
42065
42066
42067
42068
42069
42070
42071
42072
42073
42074
42075
42076
42077
42078
42079
42080
42081
42082
42083
42084
42085
42086
42087
42088
42089
42090
42091
42092
42093
42094
42095
42096
42097
42098
42099
42100
42101
42102
42103
42104
42105
42106
42107
42108
42109
42110
42111
42112
42113
42114
42115
42116
42117
42118
42119
42120
42121
42122
42123
42124
42125
42126
42127
42128
42129
42130
42131
42132
42133
42134
42135
42136
42137
42138
42139
42140
42141
42142
42143
42144
42145
42146
42147
42148
42149
42150
42151
42152
42153
42154
42155
42156
42157
42158
42159
42160
42161
42162
42163
42164
42165
42166
42167
42168
42169
42170
42171
42172
42173
42174
42175
42176
42177
42178
42179
42180
42181
42182
42183
42184
42185
42186
42187
42188
42189
42190
42191
42192
42193
42194
42195
42196
42197
42198
42199
42200
42201
42202
42203
42204
42205
42206
42207
42208
42209
42210
42211
42212
42213
42214
42215
42216
42217
42218
42219
42220
42221
42222
42223
42224
42225
42226
42227
42228
42229
42230
42231
42232
42233
42234
42235
42236
42237
42238
42239
42240
42241
42242
42243
42244
42245
42246
42247
42248
42249
42250
42251
42252
42253
42254
42255
42256
42257
42258
42259
42260
42261
42262
42263
42264
42265
42266
42267
42268
42269
42270
42271
42272
42273
42274
42275
42276
42277
42278
42279
42280
42281
42282
42283
42284
42285
42286
42287
42288
42289
42290
42291
42292
42293
42294
42295
42296
42297
42298
42299
42300
42301
42302
42303
42304
42305
42306
42307
42308
42309
42310
42311
42312
42313
42314
42315
42316
42317
42318
42319
42320
42321
42322
42323
42324
42325
42326
42327
42328
42329
42330
42331
42332
42333
42334
42335
42336
42337
42338
42339
42340
42341
42342
42343
42344
42345
42346
42347
42348
42349
42350
42351
42352
42353
42354
42355
42356
42357
42358
42359
42360
42361
42362
42363
42364
42365
42366
42367
42368
42369
42370
42371
42372
42373
42374
42375
42376
42377
42378
42379
42380
42381
42382
42383
42384
42385
42386
42387
42388
42389
42390
42391
42392
42393
42394
42395
42396
42397
42398
42399
42400
42401
42402
42403
42404
42405
42406
42407
42408
42409
42410
42411
42412
42413
42414
42415
42416
42417
42418
42419
42420
42421
42422
42423
42424
42425
42426
42427
42428
42429
42430
42431
42432
42433
42434
42435
42436
42437
42438
42439
42440
42441
42442
42443
42444
42445
42446
42447
42448
42449
42450
42451
42452
42453
42454
42455
42456
42457
42458
42459
42460
42461
42462
42463
42464
42465
42466
42467
42468
42469
42470
42471
42472
42473
42474
42475
42476
42477
42478
42479
42480
42481
42482
42483
42484
42485
42486
42487
42488
42489
42490
42491
42492
42493
42494
42495
42496
42497
42498
42499
42500
42501
42502
42503
42504
42505
42506
42507
42508
42509
42510
42511
42512
42513
42514
42515
42516
42517
42518
42519
42520
42521
42522
42523
42524
42525
42526
42527
42528
42529
42530
42531
42532
42533
42534
42535
42536
42537
42538
42539
42540
42541
42542
42543
42544
42545
42546
42547
42548
42549
42550
42551
42552
42553
42554
42555
42556
42557
42558
42559
42560
42561
42562
42563
42564
42565
42566
42567
42568
42569
42570
42571
42572
42573
42574
42575
42576
42577
42578
42579
42580
42581
42582
42583
42584
42585
42586
42587
42588
42589
42590
42591
42592
42593
42594
42595
42596
42597
42598
42599
42600
42601
42602
42603
42604
42605
42606
42607
42608
42609
42610
42611
42612
42613
42614
42615
42616
42617
42618
42619
42620
42621
42622
42623
42624
42625
42626
42627
42628
42629
42630
42631
42632
42633
42634
42635
42636
42637
42638
42639
42640
42641
42642
42643
42644
42645
42646
42647
42648
42649
42650
42651
42652
42653
42654
42655
42656
42657
42658
42659
42660
42661
42662
42663
42664
42665
42666
42667
42668
42669
42670
42671
42672
42673
42674
42675
42676
42677
42678
42679
42680
42681
42682
42683
42684
42685
42686
42687
42688
42689
42690
42691
42692
42693
42694
42695
42696
42697
42698
42699
42700
42701
42702
42703
42704
42705
42706
42707
42708
42709
42710
42711
42712
42713
42714
42715
42716
42717
42718
42719
42720
42721
42722
42723
42724
42725
42726
42727
42728
42729
42730
42731
42732
42733
42734
42735
42736
42737
42738
42739
42740
42741
42742
42743
42744
42745
42746
42747
42748
42749
42750
42751
42752
42753
42754
42755
42756
42757
42758
42759
42760
42761
42762
42763
42764
42765
42766
42767
42768
42769
42770
42771
42772
42773
42774
42775
42776
42777
42778
42779
42780
42781
42782
42783
42784
42785
42786
42787
42788
42789
42790
42791
42792
42793
42794
42795
42796
42797
42798
42799
42800
42801
42802
42803
42804
42805
42806
42807
42808
42809
42810
42811
42812
42813
42814
42815
42816
42817
42818
42819
42820
42821
42822
42823
42824
42825
42826
42827
42828
42829
42830
42831
42832
42833
42834
42835
42836
42837
42838
42839
42840
42841
42842
42843
42844
42845
42846
42847
42848
42849
42850
42851
42852
42853
42854
42855
42856
42857
42858
42859
42860
42861
42862
42863
42864
42865
42866
42867
42868
42869
42870
42871
42872
42873
42874
42875
42876
42877
42878
42879
42880
42881
42882
42883
42884
42885
42886
42887
42888
42889
42890
42891
42892
42893
42894
42895
42896
42897
42898
42899
42900
42901
42902
42903
42904
42905
42906
42907
42908
42909
42910
42911
42912
42913
42914
42915
42916
42917
42918
42919
42920
42921
42922
42923
42924
42925
42926
42927
42928
42929
42930
42931
42932
42933
42934
42935
42936
42937
42938
42939
42940
42941
42942
42943
42944
42945
42946
42947
42948
42949
42950
42951
42952
42953
42954
42955
42956
42957
42958
42959
42960
42961
42962
42963
42964
42965
42966
42967
42968
42969
42970
42971
42972
42973
42974
42975
42976
42977
42978
42979
42980
42981
42982
42983
42984
42985
42986
42987
42988
42989
42990
42991
42992
42993
42994
42995
42996
42997
42998
42999
43000
43001
43002
43003
43004
43005
43006
43007
43008
43009
43010
43011
43012
43013
43014
43015
43016
43017
43018
43019
43020
43021
43022
43023
43024
43025
43026
43027
43028
43029
43030
43031
43032
43033
43034
43035
43036
43037
43038
43039
43040
43041
43042
43043
43044
43045
43046
43047
43048
43049
43050
43051
43052
43053
43054
43055
43056
43057
43058
43059
43060
43061
43062
43063
43064
43065
43066
43067
43068
43069
43070
43071
43072
43073
43074
43075
43076
43077
43078
43079
43080
43081
43082
43083
43084
43085
43086
43087
43088
43089
43090
43091
43092
43093
43094
43095
43096
43097
43098
43099
43100
43101
43102
43103
43104
43105
43106
43107
43108
43109
43110
43111
43112
43113
43114
43115
43116
43117
43118
43119
43120
43121
43122
43123
43124
43125
43126
43127
43128
43129
43130
43131
43132
43133
43134
43135
43136
43137
43138
43139
43140
43141
43142
43143
43144
43145
43146
43147
43148
43149
43150
43151
43152
43153
43154
43155
43156
43157
43158
43159
43160
43161
43162
43163
43164
43165
43166
43167
43168
43169
43170
43171
43172
43173
43174
43175
43176
43177
43178
43179
43180
43181
43182
43183
43184
43185
43186
43187
43188
43189
43190
43191
43192
43193
43194
43195
43196
43197
43198
43199
43200
43201
43202
43203
43204
43205
43206
43207
43208
43209
43210
43211
43212
43213
43214
43215
43216
43217
43218
43219
43220
43221
43222
43223
43224
43225
43226
43227
43228
43229
43230
43231
43232
43233
43234
43235
43236
43237
43238
43239
43240
43241
43242
43243
43244
43245
43246
43247
43248
43249
43250
43251
43252
43253
43254
43255
43256
43257
43258
43259
43260
43261
43262
43263
43264
43265
43266
43267
43268
43269
43270
43271
43272
43273
43274
43275
43276
43277
43278
43279
43280
43281
43282
43283
43284
43285
43286
43287
43288
43289
43290
43291
43292
43293
43294
43295
43296
43297
43298
43299
43300
43301
43302
43303
43304
43305
43306
43307
43308
43309
43310
43311
43312
43313
43314
43315
43316
43317
43318
43319
43320
43321
43322
43323
43324
43325
43326
43327
43328
43329
43330
43331
43332
43333
43334
43335
43336
43337
43338
43339
43340
43341
43342
43343
43344
43345
43346
43347
43348
43349
43350
43351
43352
43353
43354
43355
43356
43357
43358
43359
43360
43361
43362
43363
43364
43365
43366
43367
43368
43369
43370
43371
43372
43373
43374
43375
43376
43377
43378
43379
43380
43381
43382
43383
43384
43385
43386
43387
43388
43389
43390
43391
43392
43393
43394
43395
43396
43397
43398
43399
43400
43401
43402
43403
43404
43405
43406
43407
43408
43409
43410
43411
43412
43413
43414
43415
43416
43417
43418
43419
43420
43421
43422
43423
43424
43425
43426
43427
43428
43429
43430
43431
43432
43433
43434
43435
43436
43437
43438
43439
43440
43441
43442
43443
43444
43445
43446
43447
43448
43449
43450
43451
43452
43453
43454
43455
43456
43457
43458
43459
43460
43461
43462
43463
43464
43465
43466
43467
43468
43469
43470
43471
43472
43473
43474
43475
43476
43477
43478
43479
43480
43481
43482
43483
43484
43485
43486
43487
43488
43489
43490
43491
43492
43493
43494
43495
43496
43497
43498
43499
43500
43501
43502
43503
43504
43505
43506
43507
43508
43509
43510
43511
43512
43513
43514
43515
43516
43517
43518
43519
43520
43521
43522
43523
43524
43525
43526
43527
43528
43529
43530
43531
43532
43533
43534
43535
43536
43537
43538
43539
43540
43541
43542
43543
43544
43545
43546
43547
43548
43549
43550
43551
43552
43553
43554
43555
43556
43557
43558
43559
43560
43561
43562
43563
43564
43565
43566
43567
43568
43569
43570
43571
43572
43573
43574
43575
43576
43577
43578
43579
43580
43581
43582
43583
43584
43585
43586
43587
43588
43589
43590
43591
43592
43593
43594
43595
43596
43597
43598
43599
43600
43601
43602
43603
43604
43605
43606
43607
43608
43609
43610
43611
43612
43613
43614
43615
43616
43617
43618
43619
43620
43621
43622
43623
43624
43625
43626
43627
43628
43629
43630
43631
43632
43633
43634
43635
43636
43637
43638
43639
43640
43641
43642
43643
43644
43645
43646
43647
43648
43649
43650
43651
43652
43653
43654
43655
43656
43657
43658
43659
43660
43661
43662
43663
43664
43665
43666
43667
43668
43669
43670
43671
43672
43673
43674
43675
43676
43677
43678
43679
43680
43681
43682
43683
43684
43685
43686
43687
43688
43689
43690
43691
43692
43693
43694
43695
43696
43697
43698
43699
43700
43701
43702
43703
43704
43705
43706
43707
43708
43709
43710
43711
43712
43713
43714
43715
43716
43717
43718
43719
43720
43721
43722
43723
43724
43725
43726
43727
43728
43729
43730
43731
43732
43733
43734
43735
43736
43737
43738
43739
43740
43741
43742
43743
43744
43745
43746
43747
43748
43749
43750
43751
43752
43753
43754
43755
43756
43757
43758
43759
43760
43761
43762
43763
43764
43765
43766
43767
43768
43769
43770
43771
43772
43773
43774
43775
43776
43777
43778
43779
43780
43781
43782
43783
43784
43785
43786
43787
43788
43789
43790
43791
43792
43793
43794
43795
43796
43797
43798
43799
43800
43801
43802
43803
43804
43805
43806
43807
43808
43809
43810
43811
43812
43813
43814
43815
43816
43817
43818
43819
43820
43821
43822
43823
43824
43825
43826
43827
43828
43829
43830
43831
43832
43833
43834
43835
43836
43837
43838
43839
43840
43841
43842
43843
43844
43845
43846
43847
43848
43849
43850
43851
43852
43853
43854
43855
43856
43857
43858
43859
43860
43861
43862
43863
43864
43865
43866
43867
43868
43869
43870
43871
43872
43873
43874
43875
43876
43877
43878
43879
43880
43881
43882
43883
43884
43885
43886
43887
43888
43889
43890
43891
43892
43893
43894
43895
43896
43897
43898
43899
43900
43901
43902
43903
43904
43905
43906
43907
43908
43909
43910
43911
43912
43913
43914
43915
43916
43917
43918
43919
43920
43921
43922
43923
43924
43925
43926
43927
43928
43929
43930
43931
43932
43933
43934
43935
43936
43937
43938
43939
43940
43941
43942
43943
43944
43945
43946
43947
43948
43949
43950
43951
43952
43953
43954
43955
43956
43957
43958
43959
43960
43961
43962
43963
43964
43965
43966
43967
43968
43969
43970
43971
43972
43973
43974
43975
43976
43977
43978
43979
43980
43981
43982
43983
43984
43985
43986
43987
43988
43989
43990
43991
43992
43993
43994
43995
43996
43997
43998
43999
44000
44001
44002
44003
44004
44005
44006
44007
44008
44009
44010
44011
44012
44013
44014
44015
44016
44017
44018
44019
44020
44021
44022
44023
44024
44025
44026
44027
44028
44029
44030
44031
44032
44033
44034
44035
44036
44037
44038
44039
44040
44041
44042
44043
44044
44045
44046
44047
44048
44049
44050
44051
44052
44053
44054
44055
44056
44057
44058
44059
44060
44061
44062
44063
44064
44065
44066
44067
44068
44069
44070
44071
44072
44073
44074
44075
44076
44077
44078
44079
44080
44081
44082
44083
44084
44085
44086
44087
44088
44089
44090
44091
44092
44093
44094
44095
44096
44097
44098
44099
44100
44101
44102
44103
44104
44105
44106
44107
44108
44109
44110
44111
44112
44113
44114
44115
44116
44117
44118
44119
44120
44121
44122
44123
44124
44125
44126
44127
44128
44129
44130
44131
44132
44133
44134
44135
44136
44137
44138
44139
44140
44141
44142
44143
44144
44145
44146
44147
44148
44149
44150
44151
44152
44153
44154
44155
44156
44157
44158
44159
44160
44161
44162
44163
44164
44165
44166
44167
44168
44169
44170
44171
44172
44173
44174
44175
44176
44177
44178
44179
44180
44181
44182
44183
44184
44185
44186
44187
44188
44189
44190
44191
44192
44193
44194
44195
44196
44197
44198
44199
44200
44201
44202
44203
44204
44205
44206
44207
44208
44209
44210
44211
44212
44213
44214
44215
44216
44217
44218
44219
44220
44221
44222
44223
44224
44225
44226
44227
44228
44229
44230
44231
44232
44233
44234
44235
44236
44237
44238
44239
44240
44241
44242
44243
44244
44245
44246
44247
44248
44249
44250
44251
44252
44253
44254
44255
44256
44257
44258
44259
44260
44261
44262
44263
44264
44265
44266
44267
44268
44269
44270
44271
44272
44273
44274
44275
44276
44277
44278
44279
44280
44281
44282
44283
44284
44285
44286
44287
44288
44289
44290
44291
44292
44293
44294
44295
44296
44297
44298
44299
44300
44301
44302
44303
44304
44305
44306
44307
44308
44309
44310
44311
44312
44313
44314
44315
44316
44317
44318
44319
44320
44321
44322
44323
44324
44325
44326
44327
44328
44329
44330
44331
44332
44333
44334
44335
44336
44337
44338
44339
44340
44341
44342
44343
44344
44345
44346
44347
44348
44349
44350
44351
44352
44353
44354
44355
44356
44357
44358
44359
44360
44361
44362
44363
44364
44365
44366
44367
44368
44369
44370
44371
44372
44373
44374
44375
44376
44377
44378
44379
44380
44381
44382
44383
44384
44385
44386
44387
44388
44389
44390
44391
44392
44393
44394
44395
44396
44397
44398
44399
44400
44401
44402
44403
44404
44405
44406
44407
44408
44409
44410
44411
44412
44413
44414
44415
44416
44417
44418
44419
44420
44421
44422
44423
44424
44425
44426
44427
44428
44429
44430
44431
44432
44433
44434
44435
44436
44437
44438
44439
44440
44441
44442
44443
44444
44445
44446
44447
44448
44449
44450
44451
44452
44453
44454
44455
44456
44457
44458
44459
44460
44461
44462
44463
44464
44465
44466
44467
44468
44469
44470
44471
44472
44473
44474
44475
44476
44477
44478
44479
44480
44481
44482
44483
44484
44485
44486
44487
44488
44489
44490
44491
44492
44493
44494
44495
44496
44497
44498
44499
44500
44501
44502
44503
44504
44505
44506
44507
44508
44509
44510
44511
44512
44513
44514
44515
44516
44517
44518
44519
44520
44521
44522
44523
44524
44525
44526
44527
44528
44529
44530
44531
44532
44533
44534
44535
44536
44537
44538
44539
44540
44541
44542
44543
44544
44545
44546
44547
44548
44549
44550
44551
44552
44553
44554
44555
44556
44557
44558
44559
44560
44561
44562
44563
44564
44565
44566
44567
44568
44569
44570
44571
44572
44573
44574
44575
44576
44577
44578
44579
44580
44581
44582
44583
44584
44585
44586
44587
44588
44589
44590
44591
44592
44593
44594
44595
44596
44597
44598
44599
44600
44601
44602
44603
44604
44605
44606
44607
44608
44609
44610
44611
44612
44613
44614
44615
44616
44617
44618
44619
44620
44621
44622
44623
44624
44625
44626
44627
44628
44629
44630
44631
44632
44633
44634
44635
44636
44637
44638
44639
44640
44641
44642
44643
44644
44645
44646
44647
44648
44649
44650
44651
44652
44653
44654
44655
44656
44657
44658
44659
44660
44661
44662
44663
44664
44665
44666
44667
44668
44669
44670
44671
44672
44673
44674
44675
44676
44677
44678
44679
44680
44681
44682
44683
44684
44685
44686
44687
44688
44689
44690
44691
44692
44693
44694
44695
44696
44697
44698
44699
44700
44701
44702
44703
44704
44705
44706
44707
44708
44709
44710
44711
44712
44713
44714
44715
44716
44717
44718
44719
44720
44721
44722
44723
44724
44725
44726
44727
44728
44729
44730
44731
44732
44733
44734
44735
44736
44737
44738
44739
44740
44741
44742
44743
44744
44745
44746
44747
44748
44749
44750
44751
44752
44753
44754
44755
44756
44757
44758
44759
44760
44761
44762
44763
44764
44765
44766
44767
44768
44769
44770
44771
44772
44773
44774
44775
44776
44777
44778
44779
44780
44781
44782
44783
44784
44785
44786
44787
44788
44789
44790
44791
44792
44793
44794
44795
44796
44797
44798
44799
44800
44801
44802
44803
44804
44805
44806
44807
44808
44809
44810
44811
44812
44813
44814
44815
44816
44817
44818
44819
44820
44821
44822
44823
44824
44825
44826
44827
44828
44829
44830
44831
44832
44833
44834
44835
44836
44837
44838
44839
44840
44841
44842
44843
44844
44845
44846
44847
44848
44849
44850
44851
44852
44853
44854
44855
44856
44857
44858
44859
44860
44861
44862
44863
44864
44865
44866
44867
44868
44869
44870
44871
44872
44873
44874
44875
44876
44877
44878
44879
44880
44881
44882
44883
44884
44885
44886
44887
44888
44889
44890
44891
44892
44893
44894
44895
44896
44897
44898
44899
44900
44901
44902
44903
44904
44905
44906
44907
44908
44909
44910
44911
44912
44913
44914
44915
44916
44917
44918
44919
44920
44921
44922
44923
44924
44925
44926
44927
44928
44929
44930
44931
44932
44933
44934
44935
44936
44937
44938
44939
44940
44941
44942
44943
44944
44945
44946
44947
44948
44949
44950
44951
44952
44953
44954
44955
44956
44957
44958
44959
44960
44961
44962
44963
44964
44965
44966
44967
44968
44969
44970
44971
44972
44973
44974
44975
44976
44977
44978
44979
44980
44981
44982
44983
44984
44985
44986
44987
44988
44989
44990
44991
44992
44993
44994
44995
44996
44997
44998
44999
45000
45001
45002
45003
45004
45005
45006
45007
45008
45009
45010
45011
45012
45013
45014
45015
45016
45017
45018
45019
45020
45021
45022
45023
45024
45025
45026
45027
45028
45029
45030
45031
45032
45033
45034
45035
45036
45037
45038
45039
45040
45041
45042
45043
45044
45045
45046
45047
45048
45049
45050
45051
45052
45053
45054
45055
45056
45057
45058
45059
45060
45061
45062
45063
45064
45065
45066
45067
45068
45069
45070
45071
45072
45073
45074
45075
45076
45077
45078
45079
45080
45081
45082
45083
45084
45085
45086
45087
45088
45089
45090
45091
45092
45093
45094
45095
45096
45097
45098
45099
45100
45101
45102
45103
45104
45105
45106
45107
45108
45109
45110
45111
45112
45113
45114
45115
45116
45117
45118
45119
45120
45121
45122
45123
45124
45125
45126
45127
45128
45129
45130
45131
45132
45133
45134
45135
45136
45137
45138
45139
45140
45141
45142
45143
45144
45145
45146
45147
45148
45149
45150
45151
45152
45153
45154
45155
45156
45157
45158
45159
45160
45161
45162
45163
45164
45165
45166
45167
45168
45169
45170
45171
45172
45173
45174
45175
45176
45177
45178
45179
45180
45181
45182
45183
45184
45185
45186
45187
45188
45189
45190
45191
45192
45193
45194
45195
45196
45197
45198
45199
45200
45201
45202
45203
45204
45205
45206
45207
45208
45209
45210
45211
45212
45213
45214
45215
45216
45217
45218
45219
45220
45221
45222
45223
45224
45225
45226
45227
45228
45229
45230
45231
45232
45233
45234
45235
45236
45237
45238
45239
45240
45241
45242
45243
45244
45245
45246
45247
45248
45249
45250
45251
45252
45253
45254
45255
45256
45257
45258
45259
45260
45261
45262
45263
45264
45265
45266
45267
45268
45269
45270
45271
45272
45273
45274
45275
45276
45277
45278
45279
45280
45281
45282
45283
45284
45285
45286
45287
45288
45289
45290
45291
45292
45293
45294
45295
45296
45297
45298
45299
45300
45301
45302
45303
45304
45305
45306
45307
45308
45309
45310
45311
45312
45313
45314
45315
45316
45317
45318
45319
45320
45321
45322
45323
45324
45325
45326
45327
45328
45329
45330
45331
45332
45333
45334
45335
45336
45337
45338
45339
45340
45341
45342
45343
45344
45345
45346
45347
45348
45349
45350
45351
45352
45353
45354
45355
45356
45357
45358
45359
45360
45361
45362
45363
45364
45365
45366
45367
45368
45369
45370
45371
45372
45373
45374
45375
45376
45377
45378
45379
45380
45381
45382
45383
45384
45385
45386
45387
45388
45389
45390
45391
45392
45393
45394
45395
45396
45397
45398
45399
45400
45401
45402
45403
45404
45405
45406
45407
45408
45409
45410
45411
45412
45413
45414
45415
45416
45417
45418
45419
45420
45421
45422
45423
45424
45425
45426
45427
45428
45429
45430
45431
45432
45433
45434
45435
45436
45437
45438
45439
45440
45441
45442
45443
45444
45445
45446
45447
45448
45449
45450
45451
45452
45453
45454
45455
45456
45457
45458
45459
45460
45461
45462
45463
45464
45465
45466
45467
45468
45469
45470
45471
45472
45473
45474
45475
45476
45477
45478
45479
45480
45481
45482
45483
45484
45485
45486
45487
45488
45489
45490
45491
45492
45493
45494
45495
45496
45497
45498
45499
45500
45501
45502
45503
45504
45505
45506
45507
45508
45509
45510
45511
45512
45513
45514
45515
45516
45517
45518
45519
45520
45521
45522
45523
45524
45525
45526
45527
45528
45529
45530
45531
45532
45533
45534
45535
45536
45537
45538
45539
45540
45541
45542
45543
45544
45545
45546
45547
45548
45549
45550
45551
45552
45553
45554
45555
45556
45557
45558
45559
45560
45561
45562
45563
45564
45565
45566
45567
45568
45569
45570
45571
45572
45573
45574
45575
45576
45577
45578
45579
45580
45581
45582
45583
45584
45585
45586
45587
45588
45589
45590
45591
45592
45593
45594
45595
45596
45597
45598
45599
45600
45601
45602
45603
45604
45605
45606
45607
45608
45609
45610
45611
45612
45613
45614
45615
45616
45617
45618
45619
45620
45621
45622
45623
45624
45625
45626
45627
45628
45629
45630
45631
45632
45633
45634
45635
45636
45637
45638
45639
45640
45641
45642
45643
45644
45645
45646
45647
45648
45649
45650
45651
45652
45653
45654
45655
45656
45657
45658
45659
45660
45661
45662
45663
45664
45665
45666
45667
45668
45669
45670
45671
45672
45673
45674
45675
45676
45677
45678
45679
45680
45681
45682
45683
45684
45685
45686
45687
45688
45689
45690
45691
45692
45693
45694
45695
45696
45697
45698
45699
45700
45701
45702
45703
45704
45705
45706
45707
45708
45709
45710
45711
45712
45713
45714
45715
45716
45717
45718
45719
45720
45721
45722
45723
45724
45725
45726
45727
45728
45729
45730
45731
45732
45733
45734
45735
45736
45737
45738
45739
45740
45741
45742
45743
45744
45745
45746
45747
45748
45749
45750
45751
45752
45753
45754
45755
45756
45757
45758
45759
45760
45761
45762
45763
45764
45765
45766
45767
45768
45769
45770
45771
45772
45773
45774
45775
45776
45777
45778
45779
45780
45781
45782
45783
45784
45785
45786
45787
45788
45789
45790
45791
45792
45793
45794
45795
45796
45797
45798
45799
45800
45801
45802
45803
45804
45805
45806
45807
45808
45809
45810
45811
45812
45813
45814
45815
45816
45817
45818
45819
45820
45821
45822
45823
45824
45825
45826
45827
45828
45829
45830
45831
45832
45833
45834
45835
45836
45837
45838
45839
45840
45841
45842
45843
45844
45845
45846
45847
45848
45849
45850
45851
45852
45853
45854
45855
45856
45857
45858
45859
45860
45861
45862
45863
45864
45865
45866
45867
45868
45869
45870
45871
45872
45873
45874
45875
45876
45877
45878
45879
45880
45881
45882
45883
45884
45885
45886
45887
45888
45889
45890
45891
45892
45893
45894
45895
45896
45897
45898
45899
45900
45901
45902
45903
45904
45905
45906
45907
45908
45909
45910
45911
45912
45913
45914
45915
45916
45917
45918
45919
45920
45921
45922
45923
45924
45925
45926
45927
45928
45929
45930
45931
45932
45933
45934
45935
45936
45937
45938
45939
45940
45941
45942
45943
45944
45945
45946
45947
45948
45949
45950
45951
45952
45953
45954
45955
45956
45957
45958
45959
45960
45961
45962
45963
45964
45965
45966
45967
45968
45969
45970
45971
45972
45973
45974
45975
45976
45977
45978
45979
45980
45981
45982
45983
45984
45985
45986
45987
45988
45989
45990
45991
45992
45993
45994
45995
45996
45997
45998
45999
46000
46001
46002
46003
46004
46005
46006
46007
46008
46009
46010
46011
46012
46013
46014
46015
46016
46017
46018
46019
46020
46021
46022
46023
46024
46025
46026
46027
46028
46029
46030
46031
46032
46033
46034
46035
46036
46037
46038
46039
46040
46041
46042
46043
46044
46045
46046
46047
46048
46049
46050
46051
46052
46053
46054
46055
46056
46057
46058
46059
46060
46061
46062
46063
46064
46065
46066
46067
46068
46069
46070
46071
46072
46073
46074
46075
46076
46077
46078
46079
46080
46081
46082
46083
46084
46085
46086
46087
46088
46089
46090
46091
46092
46093
46094
46095
46096
46097
46098
46099
46100
46101
46102
46103
46104
46105
46106
46107
46108
46109
46110
46111
46112
46113
46114
46115
46116
46117
46118
46119
46120
46121
46122
46123
46124
46125
46126
46127
46128
46129
46130
46131
46132
46133
46134
46135
46136
46137
46138
46139
46140
46141
46142
46143
46144
46145
46146
46147
46148
46149
46150
46151
46152
46153
46154
46155
46156
46157
46158
46159
46160
46161
46162
46163
46164
46165
46166
46167
46168
46169
46170
46171
46172
46173
46174
46175
46176
46177
46178
46179
46180
46181
46182
46183
46184
46185
46186
46187
46188
46189
46190
46191
46192
46193
46194
46195
46196
46197
46198
46199
46200
46201
46202
46203
46204
46205
46206
46207
46208
46209
46210
46211
46212
46213
46214
46215
46216
46217
46218
46219
46220
46221
46222
46223
46224
46225
46226
46227
46228
46229
46230
46231
46232
46233
46234
46235
46236
46237
46238
46239
46240
46241
46242
46243
46244
46245
46246
46247
46248
46249
46250
46251
46252
46253
46254
46255
46256
46257
46258
46259
46260
46261
46262
46263
46264
46265
46266
46267
46268
46269
46270
46271
46272
46273
46274
46275
46276
46277
46278
46279
46280
46281
46282
46283
46284
46285
46286
46287
46288
46289
46290
46291
46292
46293
46294
46295
46296
46297
46298
46299
46300
46301
46302
46303
46304
46305
46306
46307
46308
46309
46310
46311
46312
46313
46314
46315
46316
46317
46318
46319
46320
46321
46322
46323
46324
46325
46326
46327
46328
46329
46330
46331
46332
46333
46334
46335
46336
46337
46338
46339
46340
46341
46342
46343
46344
46345
46346
46347
46348
46349
46350
46351
46352
46353
46354
46355
46356
46357
46358
46359
46360
46361
46362
46363
46364
46365
46366
46367
46368
46369
46370
46371
46372
46373
46374
46375
46376
46377
46378
46379
46380
46381
46382
46383
46384
46385
46386
46387
46388
46389
46390
46391
46392
46393
46394
46395
46396
46397
46398
46399
46400
46401
46402
46403
46404
46405
46406
46407
46408
46409
46410
46411
46412
46413
46414
46415
46416
46417
46418
46419
46420
46421
46422
46423
46424
46425
46426
46427
46428
46429
46430
46431
46432
46433
46434
46435
46436
46437
46438
46439
46440
46441
46442
46443
46444
46445
46446
46447
46448
46449
46450
46451
46452
46453
46454
46455
46456
46457
46458
46459
46460
46461
46462
46463
46464
46465
46466
46467
46468
46469
46470
46471
46472
46473
46474
46475
46476
46477
46478
46479
46480
46481
46482
46483
46484
46485
46486
46487
46488
46489
46490
46491
46492
46493
46494
46495
46496
46497
46498
46499
46500
46501
46502
46503
46504
46505
46506
46507
46508
46509
46510
46511
46512
46513
46514
46515
46516
46517
46518
46519
46520
46521
46522
46523
46524
46525
46526
46527
46528
46529
46530
46531
46532
46533
46534
46535
46536
46537
46538
46539
46540
46541
46542
46543
46544
46545
46546
46547
46548
46549
46550
46551
46552
46553
46554
46555
46556
46557
46558
46559
46560
46561
46562
46563
46564
46565
46566
46567
46568
46569
46570
46571
46572
46573
46574
46575
46576
46577
46578
46579
46580
46581
46582
46583
46584
46585
46586
46587
46588
46589
46590
46591
46592
46593
46594
46595
46596
46597
46598
46599
46600
46601
46602
46603
46604
46605
46606
46607
46608
46609
46610
46611
46612
46613
46614
46615
46616
46617
46618
46619
46620
46621
46622
46623
46624
46625
46626
46627
46628
46629
46630
46631
46632
46633
46634
46635
46636
46637
46638
46639
46640
46641
46642
46643
46644
46645
46646
46647
46648
46649
46650
46651
46652
46653
46654
46655
46656
46657
46658
46659
46660
46661
46662
46663
46664
46665
46666
46667
46668
46669
46670
46671
46672
46673
46674
46675
46676
46677
46678
46679
46680
46681
46682
46683
46684
46685
46686
46687
46688
46689
46690
46691
46692
46693
46694
46695
46696
46697
46698
46699
46700
46701
46702
46703
46704
46705
46706
46707
46708
46709
46710
46711
46712
46713
46714
46715
46716
46717
46718
46719
46720
46721
46722
46723
46724
46725
46726
46727
46728
46729
46730
46731
46732
46733
46734
46735
46736
46737
46738
46739
46740
46741
46742
46743
46744
46745
46746
46747
46748
46749
46750
46751
46752
46753
46754
46755
46756
46757
46758
46759
46760
46761
46762
46763
46764
46765
46766
46767
46768
46769
46770
46771
46772
46773
46774
46775
46776
46777
46778
46779
46780
46781
46782
46783
46784
46785
46786
46787
46788
46789
46790
46791
46792
46793
46794
46795
46796
46797
46798
46799
46800
46801
46802
46803
46804
46805
46806
46807
46808
46809
46810
46811
46812
46813
46814
46815
46816
46817
46818
46819
46820
46821
46822
46823
46824
46825
46826
46827
46828
46829
46830
46831
46832
46833
46834
46835
46836
46837
46838
46839
46840
46841
46842
46843
46844
46845
46846
46847
46848
46849
46850
46851
46852
46853
46854
46855
46856
46857
46858
46859
46860
46861
46862
46863
46864
46865
46866
46867
46868
46869
46870
46871
46872
46873
46874
46875
46876
46877
46878
46879
46880
46881
46882
46883
46884
46885
46886
46887
46888
46889
46890
46891
46892
46893
46894
46895
46896
46897
46898
46899
46900
46901
46902
46903
46904
46905
46906
46907
46908
46909
46910
46911
46912
46913
46914
46915
46916
46917
46918
46919
46920
46921
46922
46923
46924
46925
46926
46927
46928
46929
46930
46931
46932
46933
46934
46935
46936
46937
46938
46939
46940
46941
46942
46943
46944
46945
46946
46947
46948
46949
46950
46951
46952
46953
46954
46955
46956
46957
46958
46959
46960
46961
46962
46963
46964
46965
46966
46967
46968
46969
46970
46971
46972
46973
46974
46975
46976
46977
46978
46979
46980
46981
46982
46983
46984
46985
46986
46987
46988
46989
46990
46991
46992
46993
46994
46995
46996
46997
46998
46999
47000
47001
47002
47003
47004
47005
47006
47007
47008
47009
47010
47011
47012
47013
47014
47015
47016
47017
47018
47019
47020
47021
47022
47023
47024
47025
47026
47027
47028
47029
47030
47031
47032
47033
47034
47035
47036
47037
47038
47039
47040
47041
47042
47043
47044
47045
47046
47047
47048
47049
47050
47051
47052
47053
47054
47055
47056
47057
47058
47059
47060
47061
47062
47063
47064
47065
47066
47067
47068
47069
47070
47071
47072
47073
47074
47075
47076
47077
47078
47079
47080
47081
47082
47083
47084
47085
47086
47087
47088
47089
47090
47091
47092
47093
47094
47095
47096
47097
47098
47099
47100
47101
47102
47103
47104
47105
47106
47107
47108
47109
47110
47111
47112
47113
47114
47115
47116
47117
47118
47119
47120
47121
47122
47123
47124
47125
47126
47127
47128
47129
47130
47131
47132
47133
47134
47135
47136
47137
47138
47139
47140
47141
47142
47143
47144
47145
47146
47147
47148
47149
47150
47151
47152
47153
47154
47155
47156
47157
47158
47159
47160
47161
47162
47163
47164
47165
47166
47167
47168
47169
47170
47171
47172
47173
47174
47175
47176
47177
47178
47179
47180
47181
47182
47183
47184
47185
47186
47187
47188
47189
47190
47191
47192
47193
47194
47195
47196
47197
47198
47199
47200
47201
47202
47203
47204
47205
47206
47207
47208
47209
47210
47211
47212
47213
47214
47215
47216
47217
47218
47219
47220
47221
47222
47223
47224
47225
47226
47227
47228
47229
47230
47231
47232
47233
47234
47235
47236
47237
47238
47239
47240
47241
47242
47243
47244
47245
47246
47247
47248
47249
47250
47251
47252
47253
47254
47255
47256
47257
47258
47259
47260
47261
47262
47263
47264
47265
47266
47267
47268
47269
47270
47271
47272
47273
47274
47275
47276
47277
47278
47279
47280
47281
47282
47283
47284
47285
47286
47287
47288
47289
47290
47291
47292
47293
47294
47295
47296
47297
47298
47299
47300
47301
47302
47303
47304
47305
47306
47307
47308
47309
47310
47311
47312
47313
47314
47315
47316
47317
47318
47319
47320
47321
47322
47323
47324
47325
47326
47327
47328
47329
47330
47331
47332
47333
47334
47335
47336
47337
47338
47339
47340
47341
47342
47343
47344
47345
47346
47347
47348
47349
47350
47351
47352
47353
47354
47355
47356
47357
47358
47359
47360
47361
47362
47363
47364
47365
47366
47367
47368
47369
47370
47371
47372
47373
47374
47375
47376
47377
47378
47379
47380
47381
47382
47383
47384
47385
47386
47387
47388
47389
47390
47391
47392
47393
47394
47395
47396
47397
47398
47399
47400
47401
47402
47403
47404
47405
47406
47407
47408
47409
47410
47411
47412
47413
47414
47415
47416
47417
47418
47419
47420
47421
47422
47423
47424
47425
47426
47427
47428
47429
47430
47431
47432
47433
47434
47435
47436
47437
47438
47439
47440
47441
47442
47443
47444
47445
47446
47447
47448
47449
47450
47451
47452
47453
47454
47455
47456
47457
47458
47459
47460
47461
47462
47463
47464
47465
47466
47467
47468
47469
47470
47471
47472
47473
47474
47475
47476
47477
47478
47479
47480
47481
47482
47483
47484
47485
47486
47487
47488
47489
47490
47491
47492
47493
47494
47495
47496
47497
47498
47499
47500
47501
47502
47503
47504
47505
47506
47507
47508
47509
47510
47511
47512
47513
47514
47515
47516
47517
47518
47519
47520
47521
47522
47523
47524
47525
47526
47527
47528
47529
47530
47531
47532
47533
47534
47535
47536
47537
47538
47539
47540
47541
47542
47543
47544
47545
47546
47547
47548
47549
47550
47551
47552
47553
47554
47555
47556
47557
47558
47559
47560
47561
47562
47563
47564
47565
47566
47567
47568
47569
47570
47571
47572
47573
47574
47575
47576
47577
47578
47579
47580
47581
47582
47583
47584
47585
47586
47587
47588
47589
47590
47591
47592
47593
47594
47595
47596
47597
47598
47599
47600
47601
47602
47603
47604
47605
47606
47607
47608
47609
47610
47611
47612
47613
47614
47615
47616
47617
47618
47619
47620
47621
47622
47623
47624
47625
47626
47627
47628
47629
47630
47631
47632
47633
47634
47635
47636
47637
47638
47639
47640
47641
47642
47643
47644
47645
47646
47647
47648
47649
47650
47651
47652
47653
47654
47655
47656
47657
47658
47659
47660
47661
47662
47663
47664
47665
47666
47667
47668
47669
47670
47671
47672
47673
47674
47675
47676
47677
47678
47679
47680
47681
47682
47683
47684
47685
47686
47687
47688
47689
47690
47691
47692
47693
47694
47695
47696
47697
47698
47699
47700
47701
47702
47703
47704
47705
47706
47707
47708
47709
47710
47711
47712
47713
47714
47715
47716
47717
47718
47719
47720
47721
47722
47723
47724
47725
47726
47727
47728
47729
47730
47731
47732
47733
47734
47735
47736
47737
47738
47739
47740
47741
47742
47743
47744
47745
47746
47747
47748
47749
47750
47751
47752
47753
47754
47755
47756
47757
47758
47759
47760
47761
47762
47763
47764
47765
47766
47767
47768
47769
47770
47771
47772
47773
47774
47775
47776
47777
47778
47779
47780
47781
47782
47783
47784
47785
47786
47787
47788
47789
47790
47791
47792
47793
47794
47795
47796
47797
47798
47799
47800
47801
47802
47803
47804
47805
47806
47807
47808
47809
47810
47811
47812
47813
47814
47815
47816
47817
47818
47819
47820
47821
47822
47823
47824
47825
47826
47827
47828
47829
47830
47831
47832
47833
47834
47835
47836
47837
47838
47839
47840
47841
47842
47843
47844
47845
47846
47847
47848
47849
47850
47851
47852
47853
47854
47855
47856
47857
47858
47859
47860
47861
47862
47863
47864
47865
47866
47867
47868
47869
47870
47871
47872
47873
47874
47875
47876
47877
47878
47879
47880
47881
47882
47883
47884
47885
47886
47887
47888
47889
47890
47891
47892
47893
47894
47895
47896
47897
47898
47899
47900
47901
47902
47903
47904
47905
47906
47907
47908
47909
47910
47911
47912
47913
47914
47915
47916
47917
47918
47919
47920
47921
47922
47923
47924
47925
47926
47927
47928
47929
47930
47931
47932
47933
47934
47935
47936
47937
47938
47939
47940
47941
47942
47943
47944
47945
47946
47947
47948
47949
47950
47951
47952
47953
47954
47955
47956
47957
47958
47959
47960
47961
47962
47963
47964
47965
47966
47967
47968
47969
47970
47971
47972
47973
47974
47975
47976
47977
47978
47979
47980
47981
47982
47983
47984
47985
47986
47987
47988
47989
47990
47991
47992
47993
47994
47995
47996
47997
47998
47999
48000
48001
48002
48003
48004
48005
48006
48007
48008
48009
48010
48011
48012
48013
48014
48015
48016
48017
48018
48019
48020
48021
48022
48023
48024
48025
48026
48027
48028
48029
48030
48031
48032
48033
48034
48035
48036
48037
48038
48039
48040
48041
48042
48043
48044
48045
48046
48047
48048
48049
48050
48051
48052
48053
48054
48055
48056
48057
48058
48059
48060
48061
48062
48063
48064
48065
48066
48067
48068
48069
48070
48071
48072
48073
48074
48075
48076
48077
48078
48079
48080
48081
48082
48083
48084
48085
48086
48087
48088
48089
48090
48091
48092
48093
48094
48095
48096
48097
48098
48099
48100
48101
48102
48103
48104
48105
48106
48107
48108
48109
48110
48111
48112
48113
48114
48115
48116
48117
48118
48119
48120
48121
48122
48123
48124
48125
48126
48127
48128
48129
48130
48131
48132
48133
48134
48135
48136
48137
48138
48139
48140
48141
48142
48143
48144
48145
48146
48147
48148
48149
48150
48151
48152
48153
48154
48155
48156
48157
48158
48159
48160
48161
48162
48163
48164
48165
48166
48167
48168
48169
48170
48171
48172
48173
48174
48175
48176
48177
48178
48179
48180
48181
48182
48183
48184
48185
48186
48187
48188
48189
48190
48191
48192
48193
48194
48195
48196
48197
48198
48199
48200
48201
48202
48203
48204
48205
48206
48207
48208
48209
48210
48211
48212
48213
48214
48215
48216
48217
48218
48219
48220
48221
48222
48223
48224
48225
48226
48227
48228
48229
48230
48231
48232
48233
48234
48235
48236
48237
48238
48239
48240
48241
48242
48243
48244
48245
48246
48247
48248
48249
48250
48251
48252
48253
48254
48255
48256
48257
48258
48259
48260
48261
48262
48263
48264
48265
48266
48267
48268
48269
48270
48271
48272
48273
48274
48275
48276
48277
48278
48279
48280
48281
48282
48283
48284
48285
48286
48287
48288
48289
48290
48291
48292
48293
48294
48295
48296
48297
48298
48299
48300
48301
48302
48303
48304
48305
48306
48307
48308
48309
48310
48311
48312
48313
48314
48315
48316
48317
48318
48319
48320
48321
48322
48323
48324
48325
48326
48327
48328
48329
48330
48331
48332
48333
48334
48335
48336
48337
48338
48339
48340
48341
48342
48343
48344
48345
48346
48347
48348
48349
48350
48351
48352
48353
48354
48355
48356
48357
48358
48359
48360
48361
48362
48363
48364
48365
48366
48367
48368
48369
48370
48371
48372
48373
48374
48375
48376
48377
48378
48379
48380
48381
48382
48383
48384
48385
48386
48387
48388
48389
48390
48391
48392
48393
48394
48395
48396
48397
48398
48399
48400
48401
48402
48403
48404
48405
48406
48407
48408
48409
48410
48411
48412
48413
48414
48415
48416
48417
48418
48419
48420
48421
48422
48423
48424
48425
48426
48427
48428
48429
48430
48431
48432
48433
48434
48435
48436
48437
48438
48439
48440
48441
48442
48443
48444
48445
48446
48447
48448
48449
48450
48451
48452
48453
48454
48455
48456
48457
48458
48459
48460
48461
48462
48463
48464
48465
48466
48467
48468
48469
48470
48471
48472
48473
48474
48475
48476
48477
48478
48479
48480
48481
48482
48483
48484
48485
48486
48487
48488
48489
48490
48491
48492
48493
48494
48495
48496
48497
48498
48499
48500
48501
48502
48503
48504
48505
48506
48507
48508
48509
48510
48511
48512
48513
48514
48515
48516
48517
48518
48519
48520
48521
48522
48523
48524
48525
48526
48527
48528
48529
48530
48531
48532
48533
48534
48535
48536
48537
48538
48539
48540
48541
48542
48543
48544
48545
48546
48547
48548
48549
48550
48551
48552
48553
48554
48555
48556
48557
48558
48559
48560
48561
48562
48563
48564
48565
48566
48567
48568
48569
48570
48571
48572
48573
48574
48575
48576
48577
48578
48579
48580
48581
48582
48583
48584
48585
48586
48587
48588
48589
48590
48591
48592
48593
48594
48595
48596
48597
48598
48599
48600
48601
48602
48603
48604
48605
48606
48607
48608
48609
48610
48611
48612
48613
48614
48615
48616
48617
48618
48619
48620
48621
48622
48623
48624
48625
48626
48627
48628
48629
48630
48631
48632
48633
48634
48635
48636
48637
48638
48639
48640
48641
48642
48643
48644
48645
48646
48647
48648
48649
48650
48651
48652
48653
48654
48655
48656
48657
48658
48659
48660
48661
48662
48663
48664
48665
48666
48667
48668
48669
48670
48671
48672
48673
48674
48675
48676
48677
48678
48679
48680
48681
48682
48683
48684
48685
48686
48687
48688
48689
48690
48691
48692
48693
48694
48695
48696
48697
48698
48699
48700
48701
48702
48703
48704
48705
48706
48707
48708
48709
48710
48711
48712
48713
48714
48715
48716
48717
48718
48719
48720
48721
48722
48723
48724
48725
48726
48727
48728
48729
48730
48731
48732
48733
48734
48735
48736
48737
48738
48739
48740
48741
48742
48743
48744
48745
48746
48747
48748
48749
48750
48751
48752
48753
48754
48755
48756
48757
48758
48759
48760
48761
48762
48763
48764
48765
48766
48767
48768
48769
48770
48771
48772
48773
48774
48775
48776
48777
48778
48779
48780
48781
48782
48783
48784
48785
48786
48787
48788
48789
48790
48791
48792
48793
48794
48795
48796
48797
48798
48799
48800
48801
48802
48803
48804
48805
48806
48807
48808
48809
48810
48811
48812
48813
48814
48815
48816
48817
48818
48819
48820
48821
48822
48823
48824
48825
48826
48827
48828
48829
48830
48831
48832
48833
48834
48835
48836
48837
48838
48839
48840
48841
48842
48843
48844
48845
48846
48847
48848
48849
48850
48851
48852
48853
48854
48855
48856
48857
48858
48859
48860
48861
48862
48863
48864
48865
48866
48867
48868
48869
48870
48871
48872
48873
48874
48875
48876
48877
48878
48879
48880
48881
48882
48883
48884
48885
48886
48887
48888
48889
48890
48891
48892
48893
48894
48895
48896
48897
48898
48899
48900
48901
48902
48903
48904
48905
48906
48907
48908
48909
48910
48911
48912
48913
48914
48915
48916
48917
48918
48919
48920
48921
48922
48923
48924
48925
48926
48927
48928
48929
48930
48931
48932
48933
48934
48935
48936
48937
48938
48939
48940
48941
48942
48943
48944
48945
48946
48947
48948
48949
48950
48951
48952
48953
48954
48955
48956
48957
48958
48959
48960
48961
48962
48963
48964
48965
48966
48967
48968
48969
48970
48971
48972
48973
48974
48975
48976
48977
48978
48979
48980
48981
48982
48983
48984
48985
48986
48987
48988
48989
48990
48991
48992
48993
48994
48995
48996
48997
48998
48999
49000
49001
49002
49003
49004
49005
49006
49007
49008
49009
49010
49011
49012
49013
49014
49015
49016
49017
49018
49019
49020
49021
49022
49023
49024
49025
49026
49027
49028
49029
49030
49031
49032
49033
49034
49035
49036
49037
49038
49039
49040
49041
49042
49043
49044
49045
49046
49047
49048
49049
49050
49051
49052
49053
49054
49055
49056
49057
49058
49059
49060
49061
49062
49063
49064
49065
49066
49067
49068
49069
49070
49071
49072
49073
49074
49075
49076
49077
49078
49079
49080
49081
49082
49083
49084
49085
49086
49087
49088
49089
49090
49091
49092
49093
49094
49095
49096
49097
49098
49099
49100
49101
49102
49103
49104
49105
49106
49107
49108
49109
49110
49111
49112
49113
49114
49115
49116
49117
49118
49119
49120
49121
49122
49123
49124
49125
49126
49127
49128
49129
49130
49131
49132
49133
49134
49135
49136
49137
49138
49139
49140
49141
49142
49143
49144
49145
49146
49147
49148
49149
49150
49151
49152
49153
49154
49155
49156
49157
49158
49159
49160
49161
49162
49163
49164
49165
49166
49167
49168
49169
49170
49171
49172
49173
49174
49175
49176
49177
49178
49179
49180
49181
49182
49183
49184
49185
49186
49187
49188
49189
49190
49191
49192
49193
49194
49195
49196
49197
49198
49199
49200
49201
49202
49203
49204
49205
49206
49207
49208
49209
49210
49211
49212
49213
49214
49215
49216
49217
49218
49219
49220
49221
49222
49223
49224
49225
49226
49227
49228
49229
49230
49231
49232
49233
49234
49235
49236
49237
49238
49239
49240
49241
49242
49243
49244
49245
49246
49247
49248
49249
49250
49251
49252
49253
49254
49255
49256
49257
49258
49259
49260
49261
49262
49263
49264
49265
49266
49267
49268
49269
49270
49271
49272
49273
49274
49275
49276
49277
49278
49279
49280
49281
49282
49283
49284
49285
49286
49287
49288
49289
49290
49291
49292
49293
49294
49295
49296
49297
49298
49299
49300
49301
49302
49303
49304
49305
49306
49307
49308
49309
49310
49311
49312
49313
49314
49315
49316
49317
49318
49319
49320
49321
49322
49323
49324
49325
49326
49327
49328
49329
49330
49331
49332
49333
49334
49335
49336
49337
49338
49339
49340
49341
49342
49343
49344
49345
49346
49347
49348
49349
49350
49351
49352
49353
49354
49355
49356
49357
49358
49359
49360
49361
49362
49363
49364
49365
49366
49367
49368
49369
49370
49371
49372
49373
49374
49375
49376
49377
49378
49379
49380
49381
49382
49383
49384
49385
49386
49387
49388
49389
49390
49391
49392
49393
49394
49395
49396
49397
49398
49399
49400
49401
49402
49403
49404
49405
49406
49407
49408
49409
49410
49411
49412
49413
49414
49415
49416
49417
49418
49419
49420
49421
49422
49423
49424
49425
49426
49427
49428
49429
49430
49431
49432
49433
49434
49435
49436
49437
49438
49439
49440
49441
49442
49443
49444
49445
49446
49447
49448
49449
49450
49451
49452
49453
49454
49455
49456
49457
49458
49459
49460
49461
49462
49463
49464
49465
49466
49467
49468
49469
49470
49471
49472
49473
49474
49475
49476
49477
49478
49479
49480
49481
49482
49483
49484
49485
49486
49487
49488
49489
49490
49491
49492
49493
49494
49495
49496
49497
49498
49499
49500
49501
49502
49503
49504
49505
49506
49507
49508
49509
49510
49511
49512
49513
49514
49515
49516
49517
49518
49519
49520
49521
49522
49523
49524
49525
49526
49527
49528
49529
49530
49531
49532
49533
49534
49535
49536
49537
49538
49539
49540
49541
49542
49543
49544
49545
49546
49547
49548
49549
49550
49551
49552
49553
49554
49555
49556
49557
49558
49559
49560
49561
49562
49563
49564
49565
49566
49567
49568
49569
49570
49571
49572
49573
49574
49575
49576
49577
49578
49579
49580
49581
49582
49583
49584
49585
49586
49587
49588
49589
49590
49591
49592
49593
49594
49595
49596
49597
49598
49599
49600
49601
49602
49603
49604
49605
49606
49607
49608
49609
49610
49611
49612
49613
49614
49615
49616
49617
49618
49619
49620
49621
49622
49623
49624
49625
49626
49627
49628
49629
49630
49631
49632
49633
49634
49635
49636
49637
49638
49639
49640
49641
49642
49643
49644
49645
49646
49647
49648
49649
49650
49651
49652
49653
49654
49655
49656
49657
49658
49659
49660
49661
49662
49663
49664
49665
49666
49667
49668
49669
49670
49671
49672
49673
49674
49675
49676
49677
49678
49679
49680
49681
49682
49683
49684
49685
49686
49687
49688
49689
49690
49691
49692
49693
49694
49695
49696
49697
49698
49699
49700
49701
49702
49703
49704
49705
49706
49707
49708
49709
49710
49711
49712
49713
49714
49715
49716
49717
49718
49719
49720
49721
49722
49723
49724
49725
49726
49727
49728
49729
49730
49731
49732
49733
49734
49735
49736
49737
49738
49739
49740
49741
49742
49743
49744
49745
49746
49747
49748
49749
49750
49751
49752
49753
49754
49755
49756
49757
49758
49759
49760
49761
49762
49763
49764
49765
49766
49767
49768
49769
49770
49771
49772
49773
49774
49775
49776
49777
49778
49779
49780
49781
49782
49783
49784
49785
49786
49787
49788
49789
49790
49791
49792
49793
49794
49795
49796
49797
49798
49799
49800
49801
49802
49803
49804
49805
49806
49807
49808
49809
49810
49811
49812
49813
49814
49815
49816
49817
49818
49819
49820
49821
49822
49823
49824
49825
49826
49827
49828
49829
49830
49831
49832
49833
49834
49835
49836
49837
49838
49839
49840
49841
49842
49843
49844
49845
49846
49847
49848
49849
49850
49851
49852
49853
49854
49855
49856
49857
49858
49859
49860
49861
49862
49863
49864
49865
49866
49867
49868
49869
49870
49871
49872
49873
49874
49875
49876
49877
49878
49879
49880
49881
49882
49883
49884
49885
49886
49887
49888
49889
49890
49891
49892
49893
49894
49895
49896
49897
49898
49899
49900
49901
49902
49903
49904
49905
49906
49907
49908
49909
49910
49911
49912
49913
49914
49915
49916
49917
49918
49919
49920
49921
49922
49923
49924
49925
49926
49927
49928
49929
49930
49931
49932
49933
49934
49935
49936
49937
49938
49939
49940
49941
49942
49943
49944
49945
49946
49947
49948
49949
49950
49951
49952
49953
49954
49955
49956
49957
49958
49959
49960
49961
49962
49963
49964
49965
49966
49967
49968
49969
49970
49971
49972
49973
49974
49975
49976
49977
49978
49979
49980
49981
49982
49983
49984
49985
49986
49987
49988
49989
49990
49991
49992
49993
49994
49995
49996
49997
49998
49999
50000
50001
50002
50003
50004
50005
50006
50007
50008
50009
50010
50011
50012
50013
50014
50015
50016
50017
50018
50019
50020
50021
50022
50023
50024
50025
50026
50027
50028
50029
50030
50031
50032
50033
50034
50035
50036
50037
50038
50039
50040
50041
50042
50043
50044
50045
50046
50047
50048
50049
50050
50051
50052
50053
50054
50055
50056
50057
50058
50059
50060
50061
50062
50063
50064
50065
50066
50067
50068
50069
50070
50071
50072
50073
50074
50075
50076
50077
50078
50079
50080
50081
50082
50083
50084
50085
50086
50087
50088
50089
50090
50091
50092
50093
50094
50095
50096
50097
50098
50099
50100
50101
50102
50103
50104
50105
50106
50107
50108
50109
50110
50111
50112
50113
50114
50115
50116
50117
50118
50119
50120
50121
50122
50123
50124
50125
50126
50127
50128
50129
50130
50131
50132
50133
50134
50135
50136
50137
50138
50139
50140
50141
50142
50143
50144
50145
50146
50147
50148
50149
50150
50151
50152
50153
50154
50155
50156
50157
50158
50159
50160
50161
50162
50163
50164
50165
50166
50167
50168
50169
50170
50171
50172
50173
50174
50175
50176
50177
50178
50179
50180
50181
50182
50183
50184
50185
50186
50187
50188
50189
50190
50191
50192
50193
50194
50195
50196
50197
50198
50199
50200
50201
50202
50203
50204
50205
50206
50207
50208
50209
50210
50211
50212
50213
50214
50215
50216
50217
50218
50219
50220
50221
50222
50223
50224
50225
50226
50227
50228
50229
50230
50231
50232
50233
50234
50235
50236
50237
50238
50239
50240
50241
50242
50243
50244
50245
50246
50247
50248
50249
50250
50251
50252
50253
50254
50255
50256
50257
50258
50259
50260
50261
50262
50263
50264
50265
50266
50267
50268
50269
50270
50271
50272
50273
50274
50275
50276
50277
50278
50279
50280
50281
50282
50283
50284
50285
50286
50287
50288
50289
50290
50291
50292
50293
50294
50295
50296
50297
50298
50299
50300
50301
50302
50303
50304
50305
50306
50307
50308
50309
50310
50311
50312
50313
50314
50315
50316
50317
50318
50319
50320
50321
50322
50323
50324
50325
50326
50327
50328
50329
50330
50331
50332
50333
50334
50335
50336
50337
50338
50339
50340
50341
50342
50343
50344
50345
50346
50347
50348
50349
50350
50351
50352
50353
50354
50355
50356
50357
50358
50359
50360
50361
50362
50363
50364
50365
50366
50367
50368
50369
50370
50371
50372
50373
50374
50375
50376
50377
50378
50379
50380
50381
50382
50383
50384
50385
50386
50387
50388
50389
50390
50391
50392
50393
50394
50395
50396
50397
50398
50399
50400
50401
50402
50403
50404
50405
50406
50407
50408
50409
50410
50411
50412
50413
50414
50415
50416
50417
50418
50419
50420
50421
50422
50423
50424
50425
50426
50427
50428
50429
50430
50431
50432
50433
50434
50435
50436
50437
50438
50439
50440
50441
50442
50443
50444
50445
50446
50447
50448
50449
50450
50451
50452
50453
50454
50455
50456
50457
50458
50459
50460
50461
50462
50463
50464
50465
50466
50467
50468
50469
50470
50471
50472
50473
50474
50475
50476
50477
50478
50479
50480
50481
50482
50483
50484
50485
50486
50487
50488
50489
50490
50491
50492
50493
50494
50495
50496
50497
50498
50499
50500
50501
50502
50503
50504
50505
50506
50507
50508
50509
50510
50511
50512
50513
50514
50515
50516
50517
50518
50519
50520
50521
50522
50523
50524
50525
50526
50527
50528
50529
50530
50531
50532
50533
50534
50535
50536
50537
50538
50539
50540
50541
50542
50543
50544
50545
50546
50547
50548
50549
50550
50551
50552
50553
50554
50555
50556
50557
50558
50559
50560
50561
50562
50563
50564
50565
50566
50567
50568
50569
50570
50571
50572
50573
50574
50575
50576
50577
50578
50579
50580
50581
50582
50583
50584
50585
50586
50587
50588
50589
50590
50591
50592
50593
50594
50595
50596
50597
50598
50599
50600
50601
50602
50603
50604
50605
50606
50607
50608
50609
50610
50611
50612
50613
50614
50615
50616
50617
50618
50619
50620
50621
50622
50623
50624
50625
50626
50627
50628
50629
50630
50631
50632
50633
50634
50635
50636
50637
50638
50639
50640
50641
50642
50643
50644
50645
50646
50647
50648
50649
50650
50651
50652
50653
50654
50655
50656
50657
50658
50659
50660
50661
50662
50663
50664
50665
50666
50667
50668
50669
50670
50671
50672
50673
50674
50675
50676
50677
50678
50679
50680
50681
50682
50683
50684
50685
50686
50687
50688
50689
50690
50691
50692
50693
50694
50695
50696
50697
50698
50699
50700
50701
50702
50703
50704
50705
50706
50707
50708
50709
50710
50711
50712
50713
50714
50715
50716
50717
50718
50719
50720
50721
50722
50723
50724
50725
50726
50727
50728
50729
50730
50731
50732
50733
50734
50735
50736
50737
50738
50739
50740
50741
50742
50743
50744
50745
50746
50747
50748
50749
50750
50751
50752
50753
50754
50755
50756
50757
50758
50759
50760
50761
50762
50763
50764
50765
50766
50767
50768
50769
50770
50771
50772
50773
50774
50775
50776
50777
50778
50779
50780
50781
50782
50783
50784
50785
50786
50787
50788
50789
50790
50791
50792
50793
50794
50795
50796
50797
50798
50799
50800
50801
50802
50803
50804
50805
50806
50807
50808
50809
50810
50811
50812
50813
50814
50815
50816
50817
50818
50819
50820
50821
50822
50823
50824
50825
50826
50827
50828
50829
50830
50831
50832
50833
50834
50835
50836
50837
50838
50839
50840
50841
50842
50843
50844
50845
50846
50847
50848
50849
50850
50851
50852
50853
50854
50855
50856
50857
50858
50859
50860
50861
50862
50863
50864
50865
50866
50867
50868
50869
50870
50871
50872
50873
50874
50875
50876
50877
50878
50879
50880
50881
50882
50883
50884
50885
50886
50887
50888
50889
50890
50891
50892
50893
50894
50895
50896
50897
50898
50899
50900
50901
50902
50903
50904
50905
50906
50907
50908
50909
50910
50911
50912
50913
50914
50915
50916
50917
50918
50919
50920
50921
50922
50923
50924
50925
50926
50927
50928
50929
50930
50931
50932
50933
50934
50935
50936
50937
50938
50939
50940
50941
50942
50943
50944
50945
50946
50947
50948
50949
50950
50951
50952
50953
50954
50955
50956
50957
50958
50959
50960
50961
50962
50963
50964
50965
50966
50967
50968
50969
50970
50971
50972
50973
50974
50975
50976
50977
50978
50979
50980
50981
50982
50983
50984
50985
50986
50987
50988
50989
50990
50991
50992
50993
50994
50995
50996
50997
50998
50999
51000
51001
51002
51003
51004
51005
51006
51007
51008
51009
51010
51011
51012
51013
51014
51015
51016
51017
51018
51019
51020
51021
51022
51023
51024
51025
51026
51027
51028
51029
51030
51031
51032
51033
51034
51035
51036
51037
51038
51039
51040
51041
51042
51043
51044
51045
51046
51047
51048
51049
51050
51051
51052
51053
51054
51055
51056
51057
51058
51059
51060
51061
51062
51063
51064
51065
51066
51067
51068
51069
51070
51071
51072
51073
51074
51075
51076
51077
51078
51079
51080
51081
51082
51083
51084
51085
51086
51087
51088
51089
51090
51091
51092
51093
51094
51095
51096
51097
51098
51099
51100
51101
51102
51103
51104
51105
51106
51107
51108
51109
51110
51111
51112
51113
51114
51115
51116
51117
51118
51119
51120
51121
51122
51123
51124
51125
51126
51127
51128
51129
51130
51131
51132
51133
51134
51135
51136
51137
51138
51139
51140
51141
51142
51143
51144
51145
51146
51147
51148
51149
51150
51151
51152
51153
51154
51155
51156
51157
51158
51159
51160
51161
51162
51163
51164
51165
51166
51167
51168
51169
51170
51171
51172
51173
51174
51175
51176
51177
51178
51179
51180
51181
51182
51183
51184
51185
51186
51187
51188
51189
51190
51191
51192
51193
51194
51195
51196
51197
51198
51199
51200
51201
51202
51203
51204
51205
51206
51207
51208
51209
51210
51211
51212
51213
51214
51215
51216
51217
51218
51219
51220
51221
51222
51223
51224
51225
51226
51227
51228
51229
51230
51231
51232
51233
51234
51235
51236
51237
51238
51239
51240
51241
51242
51243
51244
51245
51246
51247
51248
51249
51250
51251
51252
51253
51254
51255
51256
51257
51258
51259
51260
51261
51262
51263
51264
51265
51266
51267
51268
51269
51270
51271
51272
51273
51274
51275
51276
51277
51278
51279
51280
51281
51282
51283
51284
51285
51286
51287
51288
51289
51290
51291
51292
51293
51294
51295
51296
51297
51298
51299
51300
51301
51302
51303
51304
51305
51306
51307
51308
51309
51310
51311
51312
51313
51314
51315
51316
51317
51318
51319
51320
51321
51322
51323
51324
51325
51326
51327
51328
51329
51330
51331
51332
51333
51334
51335
51336
51337
51338
51339
51340
51341
51342
51343
51344
51345
51346
51347
51348
51349
51350
51351
51352
51353
51354
51355
51356
51357
51358
51359
51360
51361
51362
51363
51364
51365
51366
51367
51368
51369
51370
51371
51372
51373
51374
51375
51376
51377
51378
51379
51380
51381
51382
51383
51384
51385
51386
51387
51388
51389
51390
51391
51392
51393
51394
51395
51396
51397
51398
51399
51400
51401
51402
51403
51404
51405
51406
51407
51408
51409
51410
51411
51412
51413
51414
51415
51416
51417
51418
51419
51420
51421
51422
51423
51424
51425
51426
51427
51428
51429
51430
51431
51432
51433
51434
51435
51436
51437
51438
51439
51440
51441
51442
51443
51444
51445
51446
51447
51448
51449
51450
51451
51452
51453
51454
51455
51456
51457
51458
51459
51460
51461
51462
51463
51464
51465
51466
51467
51468
51469
51470
51471
51472
51473
51474
51475
51476
51477
51478
51479
51480
51481
51482
51483
51484
51485
51486
51487
51488
51489
51490
51491
51492
51493
51494
51495
51496
51497
51498
51499
51500
51501
51502
51503
51504
51505
51506
51507
51508
51509
51510
51511
51512
51513
51514
51515
51516
51517
51518
51519
51520
51521
51522
51523
51524
51525
51526
51527
51528
51529
51530
51531
51532
51533
51534
51535
51536
51537
51538
51539
51540
51541
51542
51543
51544
51545
51546
51547
51548
51549
51550
51551
51552
51553
51554
51555
51556
51557
51558
51559
51560
51561
51562
51563
51564
51565
51566
51567
51568
51569
51570
51571
51572
51573
51574
51575
51576
51577
51578
51579
51580
51581
51582
51583
51584
51585
51586
51587
51588
51589
51590
51591
51592
51593
51594
51595
51596
51597
51598
51599
51600
51601
51602
51603
51604
51605
51606
51607
51608
51609
51610
51611
51612
51613
51614
51615
51616
51617
51618
51619
51620
51621
51622
51623
51624
51625
51626
51627
51628
51629
51630
51631
51632
51633
51634
51635
51636
51637
51638
51639
51640
51641
51642
51643
51644
51645
51646
51647
51648
51649
51650
51651
51652
51653
51654
51655
51656
51657
51658
51659
51660
51661
51662
51663
51664
51665
51666
51667
51668
51669
51670
51671
51672
51673
51674
51675
51676
51677
51678
51679
51680
51681
51682
51683
51684
51685
51686
51687
51688
51689
51690
51691
51692
51693
51694
51695
51696
51697
51698
51699
51700
51701
51702
51703
51704
51705
51706
51707
51708
51709
51710
51711
51712
51713
51714
51715
51716
51717
51718
51719
51720
51721
51722
51723
51724
51725
51726
51727
51728
51729
51730
51731
51732
51733
51734
51735
51736
51737
51738
51739
51740
51741
51742
51743
51744
51745
51746
51747
51748
51749
51750
51751
51752
51753
51754
51755
51756
51757
51758
51759
51760
51761
51762
51763
51764
51765
51766
51767
51768
51769
51770
51771
51772
51773
51774
51775
51776
51777
51778
51779
51780
51781
51782
51783
51784
51785
51786
51787
51788
51789
51790
51791
51792
51793
51794
51795
51796
51797
51798
51799
51800
51801
51802
51803
51804
51805
51806
51807
51808
51809
51810
51811
51812
51813
51814
51815
51816
51817
51818
51819
51820
51821
51822
51823
51824
51825
51826
51827
51828
51829
51830
51831
51832
51833
51834
51835
51836
51837
51838
51839
51840
51841
51842
51843
51844
51845
51846
51847
51848
51849
51850
51851
51852
51853
51854
51855
51856
51857
51858
51859
51860
51861
51862
51863
51864
51865
51866
51867
51868
51869
51870
51871
51872
51873
51874
51875
51876
51877
51878
51879
51880
51881
51882
51883
51884
51885
51886
51887
51888
51889
51890
51891
51892
51893
51894
51895
51896
51897
51898
51899
51900
51901
51902
51903
51904
51905
51906
51907
51908
51909
51910
51911
51912
51913
51914
51915
51916
51917
51918
51919
51920
51921
51922
51923
51924
51925
51926
51927
51928
51929
51930
51931
51932
51933
51934
51935
51936
51937
51938
51939
51940
51941
51942
51943
51944
51945
51946
51947
51948
51949
51950
51951
51952
51953
51954
51955
51956
51957
51958
51959
51960
51961
51962
51963
51964
51965
51966
51967
51968
51969
51970
51971
51972
51973
51974
51975
51976
51977
51978
51979
51980
51981
51982
51983
51984
51985
51986
51987
51988
51989
51990
51991
51992
51993
51994
51995
51996
51997
51998
51999
52000
52001
52002
52003
52004
52005
52006
52007
52008
52009
52010
52011
52012
52013
52014
52015
52016
52017
52018
52019
52020
52021
52022
52023
52024
52025
52026
52027
52028
52029
52030
52031
52032
52033
52034
52035
52036
52037
52038
52039
52040
52041
52042
52043
52044
52045
52046
52047
52048
52049
52050
52051
52052
52053
52054
52055
52056
52057
52058
52059
52060
52061
52062
52063
52064
52065
52066
52067
52068
52069
52070
52071
52072
52073
52074
52075
52076
52077
52078
52079
52080
52081
52082
52083
52084
52085
52086
52087
52088
52089
52090
52091
52092
52093
52094
52095
52096
52097
52098
52099
52100
52101
52102
52103
52104
52105
52106
52107
52108
52109
52110
52111
52112
52113
52114
52115
52116
52117
52118
52119
52120
52121
52122
52123
52124
52125
52126
52127
52128
52129
52130
52131
52132
52133
52134
52135
52136
52137
52138
52139
52140
52141
52142
52143
52144
52145
52146
52147
52148
52149
52150
52151
52152
52153
52154
52155
52156
52157
52158
52159
52160
52161
52162
52163
52164
52165
52166
52167
52168
52169
52170
52171
52172
52173
52174
52175
52176
52177
52178
52179
52180
52181
52182
52183
52184
52185
52186
52187
52188
52189
52190
52191
52192
52193
52194
52195
52196
52197
52198
52199
52200
52201
52202
52203
52204
52205
52206
52207
52208
52209
52210
52211
52212
52213
52214
52215
52216
52217
52218
52219
52220
52221
52222
52223
52224
52225
52226
52227
52228
52229
52230
52231
52232
52233
52234
52235
52236
52237
52238
52239
52240
52241
52242
52243
52244
52245
52246
52247
52248
52249
52250
52251
52252
52253
52254
52255
52256
52257
52258
52259
52260
52261
52262
52263
52264
52265
52266
52267
52268
52269
52270
52271
52272
52273
52274
52275
52276
52277
52278
52279
52280
52281
52282
52283
52284
52285
52286
52287
52288
52289
52290
52291
52292
52293
52294
52295
52296
52297
52298
52299
52300
52301
52302
52303
52304
52305
52306
52307
52308
52309
52310
52311
52312
52313
52314
52315
52316
52317
52318
52319
52320
52321
52322
52323
52324
52325
52326
52327
52328
52329
52330
52331
52332
52333
52334
52335
52336
52337
52338
52339
52340
52341
52342
52343
52344
52345
52346
52347
52348
52349
52350
52351
52352
52353
52354
52355
52356
52357
52358
52359
52360
52361
52362
52363
52364
52365
52366
52367
52368
52369
52370
52371
52372
52373
52374
52375
52376
52377
52378
52379
52380
52381
52382
52383
52384
52385
52386
52387
52388
52389
52390
52391
52392
52393
52394
52395
52396
52397
52398
52399
52400
52401
52402
52403
52404
52405
52406
52407
52408
52409
52410
52411
52412
52413
52414
52415
52416
52417
52418
52419
52420
52421
52422
52423
52424
52425
52426
52427
52428
52429
52430
52431
52432
52433
52434
52435
52436
52437
52438
52439
52440
52441
52442
52443
52444
52445
52446
52447
52448
52449
52450
52451
52452
52453
52454
52455
52456
52457
52458
52459
52460
52461
52462
52463
52464
52465
52466
52467
52468
52469
52470
52471
52472
52473
52474
52475
52476
52477
52478
52479
52480
52481
52482
52483
52484
52485
52486
52487
52488
52489
52490
52491
52492
52493
52494
52495
52496
52497
52498
52499
52500
52501
52502
52503
52504
52505
52506
52507
52508
52509
52510
52511
52512
52513
52514
52515
52516
52517
52518
52519
52520
52521
52522
52523
52524
52525
52526
52527
52528
52529
52530
52531
52532
52533
52534
52535
52536
52537
52538
52539
52540
52541
52542
52543
52544
52545
52546
52547
52548
52549
52550
52551
52552
52553
52554
52555
52556
52557
52558
52559
52560
52561
52562
52563
52564
52565
52566
52567
52568
52569
52570
52571
52572
52573
52574
52575
52576
52577
52578
52579
52580
52581
52582
52583
52584
52585
52586
52587
52588
52589
52590
52591
52592
52593
52594
52595
52596
52597
52598
52599
52600
52601
52602
52603
52604
52605
52606
52607
52608
52609
52610
52611
52612
52613
52614
52615
52616
52617
52618
52619
52620
52621
52622
52623
52624
52625
52626
52627
52628
52629
52630
52631
52632
52633
52634
52635
52636
52637
52638
52639
52640
52641
52642
52643
52644
52645
52646
52647
52648
52649
52650
52651
52652
52653
52654
52655
52656
52657
52658
52659
52660
52661
52662
52663
52664
52665
52666
52667
52668
52669
52670
52671
52672
52673
52674
52675
52676
52677
52678
52679
52680
52681
52682
52683
52684
52685
52686
52687
52688
52689
52690
52691
52692
52693
52694
52695
52696
52697
52698
52699
52700
52701
52702
52703
52704
52705
52706
52707
52708
52709
52710
52711
52712
52713
52714
52715
52716
52717
52718
52719
52720
52721
52722
52723
52724
52725
52726
52727
52728
52729
52730
52731
52732
52733
52734
52735
52736
52737
52738
52739
52740
52741
52742
52743
52744
52745
52746
52747
52748
52749
52750
52751
52752
52753
52754
52755
52756
52757
52758
52759
52760
52761
52762
52763
52764
52765
52766
52767
52768
52769
52770
52771
52772
52773
52774
52775
52776
52777
52778
52779
52780
52781
52782
52783
52784
52785
52786
52787
52788
52789
52790
52791
52792
52793
52794
52795
52796
52797
52798
52799
52800
52801
52802
52803
52804
52805
52806
52807
52808
52809
52810
52811
52812
52813
52814
52815
52816
52817
52818
52819
52820
52821
52822
52823
52824
52825
52826
52827
52828
52829
52830
52831
52832
52833
52834
52835
52836
52837
52838
52839
52840
52841
52842
52843
52844
52845
52846
52847
52848
52849
52850
52851
52852
52853
52854
52855
52856
52857
52858
52859
52860
52861
52862
52863
52864
52865
52866
52867
52868
52869
52870
52871
52872
52873
52874
52875
52876
52877
52878
52879
52880
52881
52882
52883
52884
52885
52886
52887
52888
52889
52890
52891
52892
52893
52894
52895
52896
52897
52898
52899
52900
52901
52902
52903
52904
52905
52906
52907
52908
52909
52910
52911
52912
52913
52914
52915
52916
52917
52918
52919
52920
52921
52922
52923
52924
52925
52926
52927
52928
52929
52930
52931
52932
52933
52934
52935
52936
52937
52938
52939
52940
52941
52942
52943
52944
52945
52946
52947
52948
52949
52950
52951
52952
52953
52954
52955
52956
52957
52958
52959
52960
52961
52962
52963
52964
52965
52966
52967
52968
52969
52970
52971
52972
52973
52974
52975
52976
52977
52978
52979
52980
52981
52982
52983
52984
52985
52986
52987
52988
52989
52990
52991
52992
52993
52994
52995
52996
52997
52998
52999
53000
53001
53002
53003
53004
53005
53006
53007
53008
53009
53010
53011
53012
53013
53014
53015
53016
53017
53018
53019
53020
53021
53022
53023
53024
53025
53026
53027
53028
53029
53030
53031
53032
53033
53034
53035
53036
53037
53038
53039
53040
53041
53042
53043
53044
53045
53046
53047
53048
53049
53050
53051
53052
53053
53054
53055
53056
53057
53058
53059
53060
53061
53062
53063
53064
53065
53066
53067
53068
53069
53070
53071
53072
53073
53074
53075
53076
53077
53078
53079
53080
53081
53082
53083
53084
53085
53086
53087
53088
53089
53090
53091
53092
53093
53094
53095
53096
53097
53098
53099
53100
53101
53102
53103
53104
53105
53106
53107
53108
53109
53110
53111
53112
53113
53114
53115
53116
53117
53118
53119
53120
53121
53122
53123
53124
53125
53126
53127
53128
53129
53130
53131
53132
53133
53134
53135
53136
53137
53138
53139
53140
53141
53142
53143
53144
53145
53146
53147
53148
53149
53150
53151
53152
53153
53154
53155
53156
53157
53158
53159
53160
53161
53162
53163
53164
53165
53166
53167
53168
53169
53170
53171
53172
53173
53174
53175
53176
53177
53178
53179
53180
53181
53182
53183
53184
53185
53186
53187
53188
53189
53190
53191
53192
53193
53194
53195
53196
53197
53198
53199
53200
53201
53202
53203
53204
53205
53206
53207
53208
53209
53210
53211
53212
53213
53214
53215
53216
53217
53218
53219
53220
53221
53222
53223
53224
53225
53226
53227
53228
53229
53230
53231
53232
53233
53234
53235
53236
53237
53238
53239
53240
53241
53242
53243
53244
53245
53246
53247
53248
53249
53250
53251
53252
53253
53254
53255
53256
53257
53258
53259
53260
53261
53262
53263
53264
53265
53266
53267
53268
53269
53270
53271
53272
53273
53274
53275
53276
53277
53278
53279
53280
53281
53282
53283
53284
53285
53286
53287
53288
53289
53290
53291
53292
53293
53294
53295
53296
53297
53298
53299
53300
53301
53302
53303
53304
53305
53306
53307
53308
53309
53310
53311
53312
53313
53314
53315
53316
53317
53318
53319
53320
53321
53322
53323
53324
53325
53326
53327
53328
53329
53330
53331
53332
53333
53334
53335
53336
53337
53338
53339
53340
53341
53342
53343
53344
53345
53346
53347
53348
53349
53350
53351
53352
53353
53354
53355
53356
53357
53358
53359
53360
53361
53362
53363
53364
53365
53366
53367
53368
53369
53370
53371
53372
53373
53374
53375
53376
53377
53378
53379
53380
53381
53382
53383
53384
53385
53386
53387
53388
53389
53390
53391
53392
53393
53394
53395
53396
53397
53398
53399
53400
53401
53402
53403
53404
53405
53406
53407
53408
53409
53410
53411
53412
53413
53414
53415
53416
53417
53418
53419
53420
53421
53422
53423
53424
53425
53426
53427
53428
53429
53430
53431
53432
53433
53434
53435
53436
53437
53438
53439
53440
53441
53442
53443
53444
53445
53446
53447
53448
53449
53450
53451
53452
53453
53454
53455
53456
53457
53458
53459
53460
53461
53462
53463
53464
53465
53466
53467
53468
53469
53470
53471
53472
53473
53474
53475
53476
53477
53478
53479
53480
53481
53482
53483
53484
53485
53486
53487
53488
53489
53490
53491
53492
53493
53494
53495
53496
53497
53498
53499
53500
53501
53502
53503
53504
53505
53506
53507
53508
53509
53510
53511
53512
53513
53514
53515
53516
53517
53518
53519
53520
53521
53522
53523
53524
53525
53526
53527
53528
53529
53530
53531
53532
53533
53534
53535
53536
53537
53538
53539
53540
53541
53542
53543
53544
53545
53546
53547
53548
53549
53550
53551
53552
53553
53554
53555
53556
53557
53558
53559
53560
53561
53562
53563
53564
53565
53566
53567
53568
53569
53570
53571
53572
53573
53574
53575
53576
53577
53578
53579
53580
53581
53582
53583
53584
53585
53586
53587
53588
53589
53590
53591
53592
53593
53594
53595
53596
53597
53598
53599
53600
53601
53602
53603
53604
53605
53606
53607
53608
53609
53610
53611
53612
53613
53614
53615
53616
53617
53618
53619
53620
53621
53622
53623
53624
53625
53626
53627
53628
53629
53630
53631
53632
53633
53634
53635
53636
53637
53638
53639
53640
53641
53642
53643
53644
53645
53646
53647
53648
53649
53650
53651
53652
53653
53654
53655
53656
53657
53658
53659
53660
53661
53662
53663
53664
53665
53666
53667
53668
53669
53670
53671
53672
53673
53674
53675
53676
53677
53678
53679
53680
53681
53682
53683
53684
53685
53686
53687
53688
53689
53690
53691
53692
53693
53694
53695
53696
53697
53698
53699
53700
53701
53702
53703
53704
53705
53706
53707
53708
53709
53710
53711
53712
53713
53714
53715
53716
53717
53718
53719
53720
53721
53722
53723
53724
53725
53726
53727
53728
53729
53730
53731
53732
53733
53734
53735
53736
53737
53738
53739
53740
53741
53742
53743
53744
53745
53746
53747
53748
53749
53750
53751
53752
53753
53754
53755
53756
53757
53758
53759
53760
53761
53762
53763
53764
53765
53766
53767
53768
53769
53770
53771
53772
53773
53774
53775
53776
53777
53778
53779
53780
53781
53782
53783
53784
53785
53786
53787
53788
53789
53790
53791
53792
53793
53794
53795
53796
53797
53798
53799
53800
53801
53802
53803
53804
53805
53806
53807
53808
53809
53810
53811
53812
53813
53814
53815
53816
53817
53818
53819
53820
53821
53822
53823
53824
53825
53826
53827
53828
53829
53830
53831
53832
53833
53834
53835
53836
53837
53838
53839
53840
53841
53842
53843
53844
53845
53846
53847
53848
53849
53850
53851
53852
53853
53854
53855
53856
53857
53858
53859
53860
53861
53862
53863
53864
53865
53866
53867
53868
53869
53870
53871
53872
53873
53874
53875
53876
53877
53878
53879
53880
53881
53882
53883
53884
53885
53886
53887
53888
53889
53890
53891
53892
53893
53894
53895
53896
53897
53898
53899
53900
53901
53902
53903
53904
53905
53906
53907
53908
53909
53910
53911
53912
53913
53914
53915
53916
53917
53918
53919
53920
53921
53922
53923
53924
53925
53926
53927
53928
53929
53930
53931
53932
53933
53934
53935
53936
53937
53938
53939
53940
53941
53942
53943
53944
53945
53946
53947
53948
53949
53950
53951
53952
53953
53954
53955
53956
53957
53958
53959
53960
53961
53962
53963
53964
53965
53966
53967
53968
53969
53970
53971
53972
53973
53974
53975
53976
53977
53978
53979
53980
53981
53982
53983
53984
53985
53986
53987
53988
53989
53990
53991
53992
53993
53994
53995
53996
53997
53998
53999
54000
54001
54002
54003
54004
54005
54006
54007
54008
54009
54010
54011
54012
54013
54014
54015
54016
54017
54018
54019
54020
54021
54022
54023
54024
54025
54026
54027
54028
54029
54030
54031
54032
54033
54034
54035
54036
54037
54038
54039
54040
54041
54042
54043
54044
54045
54046
54047
54048
54049
54050
54051
54052
54053
54054
54055
54056
54057
54058
54059
54060
54061
54062
54063
54064
54065
54066
54067
54068
54069
54070
54071
54072
54073
54074
54075
54076
54077
54078
54079
54080
54081
54082
54083
54084
54085
54086
54087
54088
54089
54090
54091
54092
54093
54094
54095
54096
54097
54098
54099
54100
54101
54102
54103
54104
54105
54106
54107
54108
54109
54110
54111
54112
54113
54114
54115
54116
54117
54118
54119
54120
54121
54122
54123
54124
54125
54126
54127
54128
54129
54130
54131
54132
54133
54134
54135
54136
54137
54138
54139
54140
54141
54142
54143
54144
54145
54146
54147
54148
54149
54150
54151
54152
54153
54154
54155
54156
54157
54158
54159
54160
54161
54162
54163
54164
54165
54166
54167
54168
54169
54170
54171
54172
54173
54174
54175
54176
54177
54178
54179
54180
54181
54182
54183
54184
54185
54186
54187
54188
54189
54190
54191
54192
54193
54194
54195
54196
54197
54198
54199
54200
54201
54202
54203
54204
54205
54206
54207
54208
54209
54210
54211
54212
54213
54214
54215
54216
54217
54218
54219
54220
54221
54222
54223
54224
54225
54226
54227
54228
54229
54230
54231
54232
54233
54234
54235
54236
54237
54238
54239
54240
54241
54242
54243
54244
54245
54246
54247
54248
54249
54250
54251
54252
54253
54254
54255
54256
54257
54258
54259
54260
54261
54262
54263
54264
54265
54266
54267
54268
54269
54270
54271
54272
54273
54274
54275
54276
54277
54278
54279
54280
54281
54282
54283
54284
54285
54286
54287
54288
54289
54290
54291
54292
54293
54294
54295
54296
54297
54298
54299
54300
54301
54302
54303
54304
54305
54306
54307
54308
54309
54310
54311
54312
54313
54314
54315
54316
54317
54318
54319
54320
54321
54322
54323
54324
54325
54326
54327
54328
54329
54330
54331
54332
54333
54334
54335
54336
54337
54338
54339
54340
54341
54342
54343
54344
54345
54346
54347
54348
54349
54350
54351
54352
54353
54354
54355
54356
54357
54358
54359
54360
54361
54362
54363
54364
54365
54366
54367
54368
54369
54370
54371
54372
54373
54374
54375
54376
54377
54378
54379
54380
54381
54382
54383
54384
54385
54386
54387
54388
54389
54390
54391
54392
54393
54394
54395
54396
54397
54398
54399
54400
54401
54402
54403
54404
54405
54406
54407
54408
54409
54410
54411
54412
54413
54414
54415
54416
54417
54418
54419
54420
54421
54422
54423
54424
54425
54426
54427
54428
54429
54430
54431
54432
54433
54434
54435
54436
54437
54438
54439
54440
54441
54442
54443
54444
54445
54446
54447
54448
54449
54450
54451
54452
54453
54454
54455
54456
54457
54458
54459
54460
54461
54462
54463
54464
54465
54466
54467
54468
54469
54470
54471
54472
54473
54474
54475
54476
54477
54478
54479
54480
54481
54482
54483
54484
54485
54486
54487
54488
54489
54490
54491
54492
54493
54494
54495
54496
54497
54498
54499
54500
54501
54502
54503
54504
54505
54506
54507
54508
54509
54510
54511
54512
54513
54514
54515
54516
54517
54518
54519
54520
54521
54522
54523
54524
54525
54526
54527
54528
54529
54530
54531
54532
54533
54534
54535
54536
54537
54538
54539
54540
54541
54542
54543
54544
54545
54546
54547
54548
54549
54550
54551
54552
54553
54554
54555
54556
54557
54558
54559
54560
54561
54562
54563
54564
54565
54566
54567
54568
54569
54570
54571
54572
54573
54574
54575
54576
54577
54578
54579
54580
54581
54582
54583
54584
54585
54586
54587
54588
54589
54590
54591
54592
54593
54594
54595
54596
54597
54598
54599
54600
54601
54602
54603
54604
54605
54606
54607
54608
54609
54610
54611
54612
54613
54614
54615
54616
54617
54618
54619
54620
54621
54622
54623
54624
54625
54626
54627
54628
54629
54630
54631
54632
54633
54634
54635
54636
54637
54638
54639
54640
54641
54642
54643
54644
54645
54646
54647
54648
54649
54650
54651
54652
54653
54654
54655
54656
54657
54658
54659
54660
54661
54662
54663
54664
54665
54666
54667
54668
54669
54670
54671
54672
54673
54674
54675
54676
54677
54678
54679
54680
54681
54682
54683
54684
54685
54686
54687
54688
54689
54690
54691
54692
54693
54694
54695
54696
54697
54698
54699
54700
54701
54702
54703
54704
54705
54706
54707
54708
54709
54710
54711
54712
54713
54714
54715
54716
54717
54718
54719
54720
54721
54722
54723
54724
54725
54726
54727
54728
54729
54730
54731
54732
54733
54734
54735
54736
54737
54738
54739
54740
54741
54742
54743
54744
54745
54746
54747
54748
54749
54750
54751
54752
54753
54754
54755
54756
54757
54758
54759
54760
54761
54762
54763
54764
54765
54766
54767
54768
54769
54770
54771
54772
54773
54774
54775
54776
54777
54778
54779
54780
54781
54782
54783
54784
54785
54786
54787
54788
54789
54790
54791
54792
54793
54794
54795
54796
54797
54798
54799
54800
54801
54802
54803
54804
54805
54806
54807
54808
54809
54810
54811
54812
54813
54814
54815
54816
54817
54818
54819
54820
54821
54822
54823
54824
54825
54826
54827
54828
54829
54830
54831
54832
54833
54834
54835
54836
54837
54838
54839
54840
54841
54842
54843
54844
54845
54846
54847
54848
54849
54850
54851
54852
54853
54854
54855
54856
54857
54858
54859
54860
54861
54862
54863
54864
54865
54866
54867
54868
54869
54870
54871
54872
54873
54874
54875
54876
54877
54878
54879
54880
54881
54882
54883
54884
54885
54886
54887
54888
54889
54890
54891
54892
54893
54894
54895
54896
54897
54898
54899
54900
54901
54902
54903
54904
54905
54906
54907
54908
54909
54910
54911
54912
54913
54914
54915
54916
54917
54918
54919
54920
54921
54922
54923
54924
54925
54926
54927
54928
54929
54930
54931
54932
54933
54934
54935
54936
54937
54938
54939
54940
54941
54942
54943
54944
54945
54946
54947
54948
54949
54950
54951
54952
54953
54954
54955
54956
54957
54958
54959
54960
54961
54962
54963
54964
54965
54966
54967
54968
54969
54970
54971
54972
54973
54974
54975
54976
54977
54978
54979
54980
54981
54982
54983
54984
54985
54986
54987
54988
54989
54990
54991
54992
54993
54994
54995
54996
54997
54998
54999
55000
55001
55002
55003
55004
55005
55006
55007
55008
55009
55010
55011
55012
55013
55014
55015
55016
55017
55018
55019
55020
55021
55022
55023
55024
55025
55026
55027
55028
55029
55030
55031
55032
55033
55034
55035
55036
55037
55038
55039
55040
55041
55042
55043
55044
55045
55046
55047
55048
55049
55050
55051
55052
55053
55054
55055
55056
55057
55058
55059
55060
55061
55062
55063
55064
55065
55066
55067
55068
55069
55070
55071
55072
55073
55074
55075
55076
55077
55078
55079
55080
55081
55082
55083
55084
55085
55086
55087
55088
55089
55090
55091
55092
55093
55094
55095
55096
55097
55098
55099
55100
55101
55102
55103
55104
55105
55106
55107
55108
55109
55110
55111
55112
55113
55114
55115
55116
55117
55118
55119
55120
55121
55122
55123
55124
55125
55126
55127
55128
55129
55130
55131
55132
55133
55134
55135
55136
55137
55138
55139
55140
55141
55142
55143
55144
55145
55146
55147
55148
55149
55150
55151
55152
55153
55154
55155
55156
55157
55158
55159
55160
55161
55162
55163
55164
55165
55166
55167
55168
55169
55170
55171
55172
55173
55174
55175
55176
55177
55178
55179
55180
55181
55182
55183
55184
55185
55186
55187
55188
55189
55190
55191
55192
55193
55194
55195
55196
55197
55198
55199
55200
55201
55202
55203
55204
55205
55206
55207
55208
55209
55210
55211
55212
55213
55214
55215
55216
55217
55218
55219
55220
55221
55222
55223
55224
55225
55226
55227
55228
55229
55230
55231
55232
55233
55234
55235
55236
55237
55238
55239
55240
55241
55242
55243
55244
55245
55246
55247
55248
55249
55250
55251
55252
55253
55254
55255
55256
55257
55258
55259
55260
55261
55262
55263
55264
55265
55266
55267
55268
55269
55270
55271
55272
55273
55274
55275
55276
55277
55278
55279
55280
55281
55282
55283
55284
55285
55286
55287
55288
55289
55290
55291
55292
55293
55294
55295
55296
55297
55298
55299
55300
55301
55302
55303
55304
55305
55306
55307
55308
55309
55310
55311
55312
55313
55314
55315
55316
55317
55318
55319
55320
55321
55322
55323
55324
55325
55326
55327
55328
55329
55330
55331
55332
55333
55334
55335
55336
55337
55338
55339
55340
55341
55342
55343
55344
55345
55346
55347
55348
55349
55350
55351
55352
55353
55354
55355
55356
55357
55358
55359
55360
55361
55362
55363
55364
55365
55366
55367
55368
55369
55370
55371
55372
55373
55374
55375
55376
55377
55378
55379
55380
55381
55382
55383
55384
55385
55386
55387
55388
55389
55390
55391
55392
55393
55394
55395
55396
55397
55398
55399
55400
55401
55402
55403
55404
55405
55406
55407
55408
55409
55410
55411
55412
55413
55414
55415
55416
55417
55418
55419
55420
55421
55422
55423
55424
55425
55426
55427
55428
55429
55430
55431
55432
55433
55434
55435
55436
55437
55438
55439
55440
55441
55442
55443
55444
55445
55446
55447
55448
55449
55450
55451
55452
55453
55454
55455
55456
55457
55458
55459
55460
55461
55462
55463
55464
55465
55466
55467
55468
55469
55470
55471
55472
55473
55474
55475
55476
55477
55478
55479
55480
55481
55482
55483
55484
55485
55486
55487
55488
55489
55490
55491
55492
55493
55494
55495
55496
55497
55498
55499
55500
55501
55502
55503
55504
55505
55506
55507
55508
55509
55510
55511
55512
55513
55514
55515
55516
55517
55518
55519
55520
55521
55522
55523
55524
55525
55526
55527
55528
55529
55530
55531
55532
55533
55534
55535
55536
55537
55538
55539
55540
55541
55542
55543
55544
55545
55546
55547
55548
55549
55550
55551
55552
55553
55554
55555
55556
55557
55558
55559
55560
55561
55562
55563
55564
55565
55566
55567
55568
55569
55570
55571
55572
55573
55574
55575
55576
55577
55578
55579
55580
55581
55582
55583
55584
55585
55586
55587
55588
55589
55590
55591
55592
55593
55594
55595
55596
55597
55598
55599
55600
55601
55602
55603
55604
55605
55606
55607
55608
55609
55610
55611
55612
55613
55614
55615
55616
55617
55618
55619
55620
55621
55622
55623
55624
55625
55626
55627
55628
55629
55630
55631
55632
55633
55634
55635
55636
55637
55638
55639
55640
55641
55642
55643
55644
55645
55646
55647
55648
55649
55650
55651
55652
55653
55654
55655
55656
55657
55658
55659
55660
55661
55662
55663
55664
55665
55666
55667
55668
55669
55670
55671
55672
55673
55674
55675
55676
55677
55678
55679
55680
55681
55682
55683
55684
55685
55686
55687
55688
55689
55690
55691
55692
55693
55694
55695
55696
55697
55698
55699
55700
55701
55702
55703
55704
55705
55706
55707
55708
55709
55710
55711
55712
55713
55714
55715
55716
55717
55718
55719
55720
55721
55722
55723
55724
55725
55726
55727
55728
55729
55730
55731
55732
55733
55734
55735
55736
55737
55738
55739
55740
55741
55742
55743
55744
55745
55746
55747
55748
55749
55750
55751
55752
55753
55754
55755
55756
55757
55758
55759
55760
55761
55762
55763
55764
55765
55766
55767
55768
55769
55770
55771
55772
55773
55774
55775
55776
55777
55778
55779
55780
55781
55782
55783
55784
55785
55786
55787
55788
55789
55790
55791
55792
55793
55794
55795
55796
55797
55798
55799
55800
55801
55802
55803
55804
55805
55806
55807
55808
55809
55810
55811
55812
55813
55814
55815
55816
55817
55818
55819
55820
55821
55822
55823
55824
55825
55826
55827
55828
55829
55830
55831
55832
55833
55834
55835
55836
55837
55838
55839
55840
55841
55842
55843
55844
55845
55846
55847
55848
55849
55850
55851
55852
55853
55854
55855
55856
55857
55858
55859
55860
55861
55862
55863
55864
55865
55866
55867
55868
55869
55870
55871
55872
55873
55874
55875
55876
55877
55878
55879
55880
55881
55882
55883
55884
55885
55886
55887
55888
55889
55890
55891
55892
55893
55894
55895
55896
55897
55898
55899
55900
55901
55902
55903
55904
55905
55906
55907
55908
55909
55910
55911
55912
55913
55914
55915
55916
55917
55918
55919
55920
55921
55922
55923
55924
55925
55926
55927
55928
55929
55930
55931
55932
55933
55934
55935
55936
55937
55938
55939
55940
55941
55942
55943
55944
55945
55946
55947
55948
55949
55950
55951
55952
55953
55954
55955
55956
55957
55958
55959
55960
55961
55962
55963
55964
55965
55966
55967
55968
55969
55970
55971
55972
55973
55974
55975
55976
55977
55978
55979
55980
55981
55982
55983
55984
55985
55986
55987
55988
55989
55990
55991
55992
55993
55994
55995
55996
55997
55998
55999
56000
56001
56002
56003
56004
56005
56006
56007
56008
56009
56010
56011
56012
56013
56014
56015
56016
56017
56018
56019
56020
56021
56022
56023
56024
56025
56026
56027
56028
56029
56030
56031
56032
56033
56034
56035
56036
56037
56038
56039
56040
56041
56042
56043
56044
56045
56046
56047
56048
56049
56050
56051
56052
56053
56054
56055
56056
56057
56058
56059
56060
56061
56062
56063
56064
56065
56066
56067
56068
56069
56070
56071
56072
56073
56074
56075
56076
56077
56078
56079
56080
56081
56082
56083
56084
56085
56086
56087
56088
56089
56090
56091
56092
56093
56094
56095
56096
56097
56098
56099
56100
56101
56102
56103
56104
56105
56106
56107
56108
56109
56110
56111
56112
56113
56114
56115
56116
56117
56118
56119
56120
56121
56122
56123
56124
56125
56126
56127
56128
56129
56130
56131
56132
56133
56134
56135
56136
56137
56138
56139
56140
56141
56142
56143
56144
56145
56146
56147
56148
56149
56150
56151
56152
56153
56154
56155
56156
56157
56158
56159
56160
56161
56162
56163
56164
56165
56166
56167
56168
56169
56170
56171
56172
56173
56174
56175
56176
56177
56178
56179
56180
56181
56182
56183
56184
56185
56186
56187
56188
56189
56190
56191
56192
56193
56194
56195
56196
56197
56198
56199
56200
56201
56202
56203
56204
56205
56206
56207
56208
56209
56210
56211
56212
56213
56214
56215
56216
56217
56218
56219
56220
56221
56222
56223
56224
56225
56226
56227
56228
56229
56230
56231
56232
56233
56234
56235
56236
56237
56238
56239
56240
56241
56242
56243
56244
56245
56246
56247
56248
56249
56250
56251
56252
56253
56254
56255
56256
56257
56258
56259
56260
56261
56262
56263
56264
56265
56266
56267
56268
56269
56270
56271
56272
56273
56274
56275
56276
56277
56278
56279
56280
56281
56282
56283
56284
56285
56286
56287
56288
56289
56290
56291
56292
56293
56294
56295
56296
56297
56298
56299
56300
56301
56302
56303
56304
56305
56306
56307
56308
56309
56310
56311
56312
56313
56314
56315
56316
56317
56318
56319
56320
56321
56322
56323
56324
56325
56326
56327
56328
56329
56330
56331
56332
56333
56334
56335
56336
56337
56338
56339
56340
56341
56342
56343
56344
56345
56346
56347
56348
56349
56350
56351
56352
56353
56354
56355
56356
56357
56358
56359
56360
56361
56362
56363
56364
56365
56366
56367
56368
56369
56370
56371
56372
56373
56374
56375
56376
56377
56378
56379
56380
56381
56382
56383
56384
56385
56386
56387
56388
56389
56390
56391
56392
56393
56394
56395
56396
56397
56398
56399
56400
56401
56402
56403
56404
56405
56406
56407
56408
56409
56410
56411
56412
56413
56414
56415
56416
56417
56418
56419
56420
56421
56422
56423
56424
56425
56426
56427
56428
56429
56430
56431
56432
56433
56434
56435
56436
56437
56438
56439
56440
56441
56442
56443
56444
56445
56446
56447
56448
56449
56450
56451
56452
56453
56454
56455
56456
56457
56458
56459
56460
56461
56462
56463
56464
56465
56466
56467
56468
56469
56470
56471
56472
56473
56474
56475
56476
56477
56478
56479
56480
56481
56482
56483
56484
56485
56486
56487
56488
56489
56490
56491
56492
56493
56494
56495
56496
56497
56498
56499
56500
56501
56502
56503
56504
56505
56506
56507
56508
56509
56510
56511
56512
56513
56514
56515
56516
56517
56518
56519
56520
56521
56522
56523
56524
56525
56526
56527
56528
56529
56530
56531
56532
56533
56534
56535
56536
56537
56538
56539
56540
56541
56542
56543
56544
56545
56546
56547
56548
56549
56550
56551
56552
56553
56554
56555
56556
56557
56558
56559
56560
56561
56562
56563
56564
56565
56566
56567
56568
56569
56570
56571
56572
56573
56574
56575
56576
56577
56578
56579
56580
56581
56582
56583
56584
56585
56586
56587
56588
56589
56590
56591
56592
56593
56594
56595
56596
56597
56598
56599
56600
56601
56602
56603
56604
56605
56606
56607
56608
56609
56610
56611
56612
56613
56614
56615
56616
56617
56618
56619
56620
56621
56622
56623
56624
56625
56626
56627
56628
56629
56630
56631
56632
56633
56634
56635
56636
56637
56638
56639
56640
56641
56642
56643
56644
56645
56646
56647
56648
56649
56650
56651
56652
56653
56654
56655
56656
56657
56658
56659
56660
56661
56662
56663
56664
56665
56666
56667
56668
56669
56670
56671
56672
56673
56674
56675
56676
56677
56678
56679
56680
56681
56682
56683
56684
56685
56686
56687
56688
56689
56690
56691
56692
56693
56694
56695
56696
56697
56698
56699
56700
56701
56702
56703
56704
56705
56706
56707
56708
56709
56710
56711
56712
56713
56714
56715
56716
56717
56718
56719
56720
56721
56722
56723
56724
56725
56726
56727
56728
56729
56730
56731
56732
56733
56734
56735
56736
56737
56738
56739
56740
56741
56742
56743
56744
56745
56746
56747
56748
56749
56750
56751
56752
56753
56754
56755
56756
56757
56758
56759
56760
56761
56762
56763
56764
56765
56766
56767
56768
56769
56770
56771
56772
56773
56774
56775
56776
56777
56778
56779
56780
56781
56782
56783
56784
56785
56786
56787
56788
56789
56790
56791
56792
56793
56794
56795
56796
56797
56798
56799
56800
56801
56802
56803
56804
56805
56806
56807
56808
56809
56810
56811
56812
56813
56814
56815
56816
56817
56818
56819
56820
56821
56822
56823
56824
56825
56826
56827
56828
56829
56830
56831
56832
56833
56834
56835
56836
56837
56838
56839
56840
56841
56842
56843
56844
56845
56846
56847
56848
56849
56850
56851
56852
56853
56854
56855
56856
56857
56858
56859
56860
56861
56862
56863
56864
56865
56866
56867
56868
56869
56870
56871
56872
56873
56874
56875
56876
56877
56878
56879
56880
56881
56882
56883
56884
56885
56886
56887
56888
56889
56890
56891
56892
56893
56894
56895
56896
56897
56898
56899
56900
56901
56902
56903
56904
56905
56906
56907
56908
56909
56910
56911
56912
56913
56914
56915
56916
56917
56918
56919
56920
56921
56922
56923
56924
56925
56926
56927
56928
56929
56930
56931
56932
56933
56934
56935
56936
56937
56938
56939
56940
56941
56942
56943
56944
56945
56946
56947
56948
56949
56950
56951
56952
56953
56954
56955
56956
56957
56958
56959
56960
56961
56962
56963
56964
56965
56966
56967
56968
56969
56970
56971
56972
56973
56974
56975
56976
56977
56978
56979
56980
56981
56982
56983
56984
56985
56986
56987
56988
56989
56990
56991
56992
56993
56994
56995
56996
56997
56998
56999
57000
57001
57002
57003
57004
57005
57006
57007
57008
57009
57010
57011
57012
57013
57014
57015
57016
57017
57018
57019
57020
57021
57022
57023
57024
57025
57026
57027
57028
57029
57030
57031
57032
57033
57034
57035
57036
57037
57038
57039
57040
57041
57042
57043
57044
57045
57046
57047
57048
57049
57050
57051
57052
57053
57054
57055
57056
57057
57058
57059
57060
57061
57062
57063
57064
57065
57066
57067
57068
57069
57070
57071
57072
57073
57074
57075
57076
57077
57078
57079
57080
57081
57082
57083
57084
57085
57086
57087
57088
57089
57090
57091
57092
57093
57094
57095
57096
57097
57098
57099
57100
57101
57102
57103
57104
57105
57106
57107
57108
57109
57110
57111
57112
57113
57114
57115
57116
57117
57118
57119
57120
57121
57122
57123
57124
57125
57126
57127
57128
57129
57130
57131
57132
57133
57134
57135
57136
57137
57138
57139
57140
57141
57142
57143
57144
57145
57146
57147
57148
57149
57150
57151
57152
57153
57154
57155
57156
57157
57158
57159
57160
57161
57162
57163
57164
57165
57166
57167
57168
57169
57170
57171
57172
57173
57174
57175
57176
57177
57178
57179
57180
57181
57182
57183
57184
57185
57186
57187
57188
57189
57190
57191
57192
57193
57194
57195
57196
57197
57198
57199
57200
57201
57202
57203
57204
57205
57206
57207
57208
57209
57210
57211
57212
57213
57214
57215
57216
57217
57218
57219
57220
57221
57222
57223
57224
57225
57226
57227
57228
57229
57230
57231
57232
57233
57234
57235
57236
57237
57238
57239
57240
57241
57242
57243
57244
57245
57246
57247
57248
57249
57250
57251
57252
57253
57254
57255
57256
57257
57258
57259
57260
57261
57262
57263
57264
57265
57266
57267
57268
57269
57270
57271
57272
57273
57274
57275
57276
57277
57278
57279
57280
57281
57282
57283
57284
57285
57286
57287
57288
57289
57290
57291
57292
57293
57294
57295
57296
57297
57298
57299
57300
57301
57302
57303
57304
57305
57306
57307
57308
57309
57310
57311
57312
57313
57314
57315
57316
57317
57318
57319
57320
57321
57322
57323
57324
57325
57326
57327
57328
57329
57330
57331
57332
57333
57334
57335
57336
57337
57338
57339
57340
57341
57342
57343
57344
57345
57346
57347
57348
57349
57350
57351
57352
57353
57354
57355
57356
57357
57358
57359
57360
57361
57362
57363
57364
57365
57366
57367
57368
57369
57370
57371
57372
57373
57374
57375
57376
57377
57378
57379
57380
57381
57382
57383
57384
57385
57386
57387
57388
57389
57390
57391
57392
57393
57394
57395
57396
57397
57398
57399
57400
57401
57402
57403
57404
57405
57406
57407
57408
57409
57410
57411
57412
57413
57414
57415
57416
57417
57418
57419
57420
57421
57422
57423
57424
57425
57426
57427
57428
57429
57430
57431
57432
57433
57434
57435
57436
57437
57438
57439
57440
57441
57442
57443
57444
57445
57446
57447
57448
57449
57450
57451
57452
57453
57454
57455
57456
57457
57458
57459
57460
57461
57462
57463
57464
57465
57466
57467
57468
57469
57470
57471
57472
57473
57474
57475
57476
57477
57478
57479
57480
57481
57482
57483
57484
57485
57486
57487
57488
57489
57490
57491
57492
57493
57494
57495
57496
57497
57498
57499
57500
57501
57502
57503
57504
57505
57506
57507
57508
57509
57510
57511
57512
57513
57514
57515
57516
57517
57518
57519
57520
57521
57522
57523
57524
57525
57526
57527
57528
57529
57530
57531
57532
57533
57534
57535
57536
57537
57538
57539
57540
57541
57542
57543
57544
57545
57546
57547
57548
57549
57550
57551
57552
57553
57554
57555
57556
57557
57558
57559
57560
57561
57562
57563
57564
57565
57566
57567
57568
57569
57570
57571
57572
57573
57574
57575
57576
57577
57578
57579
57580
57581
57582
57583
57584
57585
57586
57587
57588
57589
57590
57591
57592
57593
57594
57595
57596
57597
57598
57599
57600
57601
57602
57603
57604
57605
57606
57607
57608
57609
57610
57611
57612
57613
57614
57615
57616
57617
57618
57619
57620
57621
57622
57623
57624
57625
57626
57627
57628
57629
57630
57631
57632
57633
57634
57635
57636
57637
57638
57639
57640
57641
57642
57643
57644
57645
57646
57647
57648
57649
57650
57651
57652
57653
57654
57655
57656
57657
57658
57659
57660
57661
57662
57663
57664
57665
57666
57667
57668
57669
57670
57671
57672
57673
57674
57675
57676
57677
57678
57679
57680
57681
57682
57683
57684
57685
57686
57687
57688
57689
57690
57691
57692
57693
57694
57695
57696
57697
57698
57699
57700
57701
57702
57703
57704
57705
57706
57707
57708
57709
57710
57711
57712
57713
57714
57715
57716
57717
57718
57719
57720
57721
57722
57723
57724
57725
57726
57727
57728
57729
57730
57731
57732
57733
57734
57735
57736
57737
57738
57739
57740
57741
57742
57743
57744
57745
57746
57747
57748
57749
57750
57751
57752
57753
57754
57755
57756
57757
57758
57759
57760
57761
57762
57763
57764
57765
57766
57767
57768
57769
57770
57771
57772
57773
57774
57775
57776
57777
57778
57779
57780
57781
57782
57783
57784
57785
57786
57787
57788
57789
57790
57791
57792
57793
57794
57795
57796
57797
57798
57799
57800
57801
57802
57803
57804
57805
57806
57807
57808
57809
57810
57811
57812
57813
57814
57815
57816
57817
57818
57819
57820
57821
57822
57823
57824
57825
57826
57827
57828
57829
57830
57831
57832
57833
57834
57835
57836
57837
57838
57839
57840
57841
57842
57843
57844
57845
57846
57847
57848
57849
57850
57851
57852
57853
57854
57855
57856
57857
57858
57859
57860
57861
57862
57863
57864
57865
57866
57867
57868
57869
57870
57871
57872
57873
57874
57875
57876
57877
57878
57879
57880
57881
57882
57883
57884
57885
57886
57887
57888
57889
57890
57891
57892
57893
57894
57895
57896
57897
57898
57899
57900
57901
57902
57903
57904
57905
57906
57907
57908
57909
57910
57911
57912
57913
57914
57915
57916
57917
57918
57919
57920
57921
57922
57923
57924
57925
57926
57927
57928
57929
57930
57931
57932
57933
57934
57935
57936
57937
57938
57939
57940
57941
57942
57943
57944
57945
57946
57947
57948
57949
57950
57951
57952
57953
57954
57955
57956
57957
57958
57959
57960
57961
57962
57963
57964
57965
57966
57967
57968
57969
57970
57971
57972
57973
57974
57975
57976
57977
57978
57979
57980
57981
57982
57983
57984
57985
57986
57987
57988
57989
57990
57991
57992
57993
57994
57995
57996
57997
57998
57999
58000
58001
58002
58003
58004
58005
58006
58007
58008
58009
58010
58011
58012
58013
58014
58015
58016
58017
58018
58019
58020
58021
58022
58023
58024
58025
58026
58027
58028
58029
58030
58031
58032
58033
58034
58035
58036
58037
58038
58039
58040
58041
58042
58043
58044
58045
58046
58047
58048
58049
58050
58051
58052
58053
58054
58055
58056
58057
58058
58059
58060
58061
58062
58063
58064
58065
58066
58067
58068
58069
58070
58071
58072
58073
58074
58075
58076
58077
58078
58079
58080
58081
58082
58083
58084
58085
58086
58087
58088
58089
58090
58091
58092
58093
58094
58095
58096
58097
58098
58099
58100
58101
58102
58103
58104
58105
58106
58107
58108
58109
58110
58111
58112
58113
58114
58115
58116
58117
58118
58119
58120
58121
58122
58123
58124
58125
58126
58127
58128
58129
58130
58131
58132
58133
58134
58135
58136
58137
58138
58139
58140
58141
58142
58143
58144
58145
58146
58147
58148
58149
58150
58151
58152
58153
58154
58155
58156
58157
58158
58159
58160
58161
58162
58163
58164
58165
58166
58167
58168
58169
58170
58171
58172
58173
58174
58175
58176
58177
58178
58179
58180
58181
58182
58183
58184
58185
58186
58187
58188
58189
58190
58191
58192
58193
58194
58195
58196
58197
58198
58199
58200
58201
58202
58203
58204
58205
58206
58207
58208
58209
58210
58211
58212
58213
58214
58215
58216
58217
58218
58219
58220
58221
58222
58223
58224
58225
58226
58227
58228
58229
58230
58231
58232
58233
58234
58235
58236
58237
58238
58239
58240
58241
58242
58243
58244
58245
58246
58247
58248
58249
58250
58251
58252
58253
58254
58255
58256
58257
58258
58259
58260
58261
58262
58263
58264
58265
58266
58267
58268
58269
58270
58271
58272
58273
58274
58275
58276
58277
58278
58279
58280
58281
58282
58283
58284
58285
58286
58287
58288
58289
58290
58291
58292
58293
58294
58295
58296
58297
58298
58299
58300
58301
58302
58303
58304
58305
58306
58307
58308
58309
58310
58311
58312
58313
58314
58315
58316
58317
58318
58319
58320
58321
58322
58323
58324
58325
58326
58327
58328
58329
58330
58331
58332
58333
58334
58335
58336
58337
58338
58339
58340
58341
58342
58343
58344
58345
58346
58347
58348
58349
58350
58351
58352
58353
58354
58355
58356
58357
58358
58359
58360
58361
58362
58363
58364
58365
58366
58367
58368
58369
58370
58371
58372
58373
58374
58375
58376
58377
58378
58379
58380
58381
58382
58383
58384
58385
58386
58387
58388
58389
58390
58391
58392
58393
58394
58395
58396
58397
58398
58399
58400
58401
58402
58403
58404
58405
58406
58407
58408
58409
58410
58411
58412
58413
58414
58415
58416
58417
58418
58419
58420
58421
58422
58423
58424
58425
58426
58427
58428
58429
58430
58431
58432
58433
58434
58435
58436
58437
58438
58439
58440
58441
58442
58443
58444
58445
58446
58447
58448
58449
58450
58451
58452
58453
58454
58455
58456
58457
58458
58459
58460
58461
58462
58463
58464
58465
58466
58467
58468
58469
58470
58471
58472
58473
58474
58475
58476
58477
58478
58479
58480
58481
58482
58483
58484
58485
58486
58487
58488
58489
58490
58491
58492
58493
58494
58495
58496
58497
58498
58499
58500
58501
58502
58503
58504
58505
58506
58507
58508
58509
58510
58511
58512
58513
58514
58515
58516
58517
58518
58519
58520
58521
58522
58523
58524
58525
58526
58527
58528
58529
58530
58531
58532
58533
58534
58535
58536
58537
58538
58539
58540
58541
58542
58543
58544
58545
58546
58547
58548
58549
58550
58551
58552
58553
58554
58555
58556
58557
58558
58559
58560
58561
58562
58563
58564
58565
58566
58567
58568
58569
58570
58571
58572
58573
58574
58575
58576
58577
58578
58579
58580
58581
58582
58583
58584
58585
58586
58587
58588
58589
58590
58591
58592
58593
58594
58595
58596
58597
58598
58599
58600
58601
58602
58603
58604
58605
58606
58607
58608
58609
58610
58611
58612
58613
58614
58615
58616
58617
58618
58619
58620
58621
58622
58623
58624
58625
58626
58627
58628
58629
58630
58631
58632
58633
58634
58635
58636
58637
58638
58639
58640
58641
58642
58643
58644
58645
58646
58647
58648
58649
58650
58651
58652
58653
58654
58655
58656
58657
58658
58659
58660
58661
58662
58663
58664
58665
58666
58667
58668
58669
58670
58671
58672
58673
58674
58675
58676
58677
58678
58679
58680
58681
58682
58683
58684
58685
58686
58687
58688
58689
58690
58691
58692
58693
58694
58695
58696
58697
58698
58699
58700
58701
58702
58703
58704
58705
58706
58707
58708
58709
58710
58711
58712
58713
58714
58715
58716
58717
58718
58719
58720
58721
58722
58723
58724
58725
58726
58727
58728
58729
58730
58731
58732
58733
58734
58735
58736
58737
58738
58739
58740
58741
58742
58743
58744
58745
58746
58747
58748
58749
58750
58751
58752
58753
58754
58755
58756
58757
58758
58759
58760
58761
58762
58763
58764
58765
58766
58767
58768
58769
58770
58771
58772
58773
58774
58775
58776
58777
58778
58779
58780
58781
58782
58783
58784
58785
58786
58787
58788
58789
58790
58791
58792
58793
58794
58795
58796
58797
58798
58799
58800
58801
58802
58803
58804
58805
58806
58807
58808
58809
58810
58811
58812
58813
58814
58815
58816
58817
58818
58819
58820
58821
58822
58823
58824
58825
58826
58827
58828
58829
58830
58831
58832
58833
58834
58835
58836
58837
58838
58839
58840
58841
58842
58843
58844
58845
58846
58847
58848
58849
58850
58851
58852
58853
58854
58855
58856
58857
58858
58859
58860
58861
58862
58863
58864
58865
58866
58867
58868
58869
58870
58871
58872
58873
58874
58875
58876
58877
58878
58879
58880
58881
58882
58883
58884
58885
58886
58887
58888
58889
58890
58891
58892
58893
58894
58895
58896
58897
58898
58899
58900
58901
58902
58903
58904
58905
58906
58907
58908
58909
58910
58911
58912
58913
58914
58915
58916
58917
58918
58919
58920
58921
58922
58923
58924
58925
58926
58927
58928
58929
58930
58931
58932
58933
58934
58935
58936
58937
58938
58939
58940
58941
58942
58943
58944
58945
58946
58947
58948
58949
58950
58951
58952
58953
58954
58955
58956
58957
58958
58959
58960
58961
58962
58963
58964
58965
58966
58967
58968
58969
58970
58971
58972
58973
58974
58975
58976
58977
58978
58979
58980
58981
58982
58983
58984
58985
58986
58987
58988
58989
58990
58991
58992
58993
58994
58995
58996
58997
58998
58999
59000
59001
59002
59003
59004
59005
59006
59007
59008
59009
59010
59011
59012
59013
59014
59015
59016
59017
59018
59019
59020
59021
59022
59023
59024
59025
59026
59027
59028
59029
59030
59031
59032
59033
59034
59035
59036
59037
59038
59039
59040
59041
59042
59043
59044
59045
59046
59047
59048
59049
59050
59051
59052
59053
59054
59055
59056
59057
59058
59059
59060
59061
59062
59063
59064
59065
59066
59067
59068
59069
59070
59071
59072
59073
59074
59075
59076
59077
59078
59079
59080
59081
59082
59083
59084
59085
59086
59087
59088
59089
59090
59091
59092
59093
59094
59095
59096
59097
59098
59099
59100
59101
59102
59103
59104
59105
59106
59107
59108
59109
59110
59111
59112
59113
59114
59115
59116
59117
59118
59119
59120
59121
59122
59123
59124
59125
59126
59127
59128
59129
59130
59131
59132
59133
59134
59135
59136
59137
59138
59139
59140
59141
59142
59143
59144
59145
59146
59147
59148
59149
59150
59151
59152
59153
59154
59155
59156
59157
59158
59159
59160
59161
59162
59163
59164
59165
59166
59167
59168
59169
59170
59171
59172
59173
59174
59175
59176
59177
59178
59179
59180
59181
59182
59183
59184
59185
59186
59187
59188
59189
59190
59191
59192
59193
59194
59195
59196
59197
59198
59199
59200
59201
59202
59203
59204
59205
59206
59207
59208
59209
59210
59211
59212
59213
59214
59215
59216
59217
59218
59219
59220
59221
59222
59223
59224
59225
59226
59227
59228
59229
59230
59231
59232
59233
59234
59235
59236
59237
59238
59239
59240
59241
59242
59243
59244
59245
59246
59247
59248
59249
59250
59251
59252
59253
59254
59255
59256
59257
59258
59259
59260
59261
59262
59263
59264
59265
59266
59267
59268
59269
59270
59271
59272
59273
59274
59275
59276
59277
59278
59279
59280
59281
59282
59283
59284
59285
59286
59287
59288
59289
59290
59291
59292
59293
59294
59295
59296
59297
59298
59299
59300
59301
59302
59303
59304
59305
59306
59307
59308
59309
59310
59311
59312
59313
59314
59315
59316
59317
59318
59319
59320
59321
59322
59323
59324
59325
59326
59327
59328
59329
59330
59331
59332
59333
59334
59335
59336
59337
59338
59339
59340
59341
59342
59343
59344
59345
59346
59347
59348
59349
59350
59351
59352
59353
59354
59355
59356
59357
59358
59359
59360
59361
59362
59363
59364
59365
59366
59367
59368
59369
59370
59371
59372
59373
59374
59375
59376
59377
59378
59379
59380
59381
59382
59383
59384
59385
59386
59387
59388
59389
59390
59391
59392
59393
59394
59395
59396
59397
59398
59399
59400
59401
59402
59403
59404
59405
59406
59407
59408
59409
59410
59411
59412
59413
59414
59415
59416
59417
59418
59419
59420
59421
59422
59423
59424
59425
59426
59427
59428
59429
59430
59431
59432
59433
59434
59435
59436
59437
59438
59439
59440
59441
59442
59443
59444
59445
59446
59447
59448
59449
59450
59451
59452
59453
59454
59455
59456
59457
59458
59459
59460
59461
59462
59463
59464
59465
59466
59467
59468
59469
59470
59471
59472
59473
59474
59475
59476
59477
59478
59479
59480
59481
59482
59483
59484
59485
59486
59487
59488
59489
59490
59491
59492
59493
59494
59495
59496
59497
59498
59499
59500
59501
59502
59503
59504
59505
59506
59507
59508
59509
59510
59511
59512
59513
59514
59515
59516
59517
59518
59519
59520
59521
59522
59523
59524
59525
59526
59527
59528
59529
59530
59531
59532
59533
59534
59535
59536
59537
59538
59539
59540
59541
59542
59543
59544
59545
59546
59547
59548
59549
59550
59551
59552
59553
59554
59555
59556
59557
59558
59559
59560
59561
59562
59563
59564
59565
59566
59567
59568
59569
59570
59571
59572
59573
59574
59575
59576
59577
59578
59579
59580
59581
59582
59583
59584
59585
59586
59587
59588
59589
59590
59591
59592
59593
59594
59595
59596
59597
59598
59599
59600
59601
59602
59603
59604
59605
59606
59607
59608
59609
59610
59611
59612
59613
59614
59615
59616
59617
59618
59619
59620
59621
59622
59623
59624
59625
59626
59627
59628
59629
59630
59631
59632
59633
59634
59635
59636
59637
59638
59639
59640
59641
59642
59643
59644
59645
59646
59647
59648
59649
59650
59651
59652
59653
59654
59655
59656
59657
59658
59659
59660
59661
59662
59663
59664
59665
59666
59667
59668
59669
59670
59671
59672
59673
59674
59675
59676
59677
59678
59679
59680
59681
59682
59683
59684
59685
59686
59687
59688
59689
59690
59691
59692
59693
59694
59695
59696
59697
59698
59699
59700
59701
59702
59703
59704
59705
59706
59707
59708
59709
59710
59711
59712
59713
59714
59715
59716
59717
59718
59719
59720
59721
59722
59723
59724
59725
59726
59727
59728
59729
59730
59731
59732
59733
59734
59735
59736
59737
59738
59739
59740
59741
59742
59743
59744
59745
59746
59747
59748
59749
59750
59751
59752
59753
59754
59755
59756
59757
59758
59759
59760
59761
59762
59763
59764
59765
59766
59767
59768
59769
59770
59771
59772
59773
59774
59775
59776
59777
59778
59779
59780
59781
59782
59783
59784
59785
59786
59787
59788
59789
59790
59791
59792
59793
59794
59795
59796
59797
59798
59799
59800
59801
59802
59803
59804
59805
59806
59807
59808
59809
59810
59811
59812
59813
59814
59815
59816
59817
59818
59819
59820
59821
59822
59823
59824
59825
59826
59827
59828
59829
59830
59831
59832
59833
59834
59835
59836
59837
59838
59839
59840
59841
59842
59843
59844
59845
59846
59847
59848
59849
59850
59851
59852
59853
59854
59855
59856
59857
59858
59859
59860
59861
59862
59863
59864
59865
59866
59867
59868
59869
59870
59871
59872
59873
59874
59875
59876
59877
59878
59879
59880
59881
59882
59883
59884
59885
59886
59887
59888
59889
59890
59891
59892
59893
59894
59895
59896
59897
59898
59899
59900
59901
59902
59903
59904
59905
59906
59907
59908
59909
59910
59911
59912
59913
59914
59915
59916
59917
59918
59919
59920
59921
59922
59923
59924
59925
59926
59927
59928
59929
59930
59931
59932
59933
59934
59935
59936
59937
59938
59939
59940
59941
59942
59943
59944
59945
59946
59947
59948
59949
59950
59951
59952
59953
59954
59955
59956
59957
59958
59959
59960
59961
59962
59963
59964
59965
59966
59967
59968
59969
59970
59971
59972
59973
59974
59975
59976
59977
59978
59979
59980
59981
59982
59983
59984
59985
59986
59987
59988
59989
59990
59991
59992
59993
59994
59995
59996
59997
59998
59999
60000
60001
60002
60003
60004
60005
60006
60007
60008
60009
60010
60011
60012
60013
60014
60015
60016
60017
60018
60019
60020
60021
60022
60023
60024
60025
60026
60027
60028
60029
60030
60031
60032
60033
60034
60035
60036
60037
60038
60039
60040
60041
60042
60043
60044
60045
60046
60047
60048
60049
60050
60051
60052
60053
60054
60055
60056
60057
60058
60059
60060
60061
60062
60063
60064
60065
60066
60067
60068
60069
60070
60071
60072
60073
60074
60075
60076
60077
60078
60079
60080
60081
60082
60083
60084
60085
60086
60087
60088
60089
60090
60091
60092
60093
60094
60095
60096
60097
60098
60099
60100
60101
60102
60103
60104
60105
60106
60107
60108
60109
60110
60111
60112
60113
60114
60115
60116
60117
60118
60119
60120
60121
60122
60123
60124
60125
60126
60127
60128
60129
60130
60131
60132
60133
60134
60135
60136
60137
60138
60139
60140
60141
60142
60143
60144
60145
60146
60147
60148
60149
60150
60151
60152
60153
60154
60155
60156
60157
60158
60159
60160
60161
60162
60163
60164
60165
60166
60167
60168
60169
60170
60171
60172
60173
60174
60175
60176
60177
60178
60179
60180
60181
60182
60183
60184
60185
60186
60187
60188
60189
60190
60191
60192
60193
60194
60195
60196
60197
60198
60199
60200
60201
60202
60203
60204
60205
60206
60207
60208
60209
60210
60211
60212
60213
60214
60215
60216
60217
60218
60219
60220
60221
60222
60223
60224
60225
60226
60227
60228
60229
60230
60231
60232
60233
60234
60235
60236
60237
60238
60239
60240
60241
60242
60243
60244
60245
60246
60247
60248
60249
60250
60251
60252
60253
60254
60255
60256
60257
60258
60259
60260
60261
60262
60263
60264
60265
60266
60267
60268
60269
60270
60271
60272
60273
60274
60275
60276
60277
60278
60279
60280
60281
60282
60283
60284
60285
60286
60287
60288
60289
60290
60291
60292
60293
60294
60295
60296
60297
60298
60299
60300
60301
60302
60303
60304
60305
60306
60307
60308
60309
60310
60311
60312
60313
60314
60315
60316
60317
60318
60319
60320
60321
60322
60323
60324
60325
60326
60327
60328
60329
60330
60331
60332
60333
60334
60335
60336
60337
60338
60339
60340
60341
60342
60343
60344
60345
60346
60347
60348
60349
60350
60351
60352
60353
60354
60355
60356
60357
60358
60359
60360
60361
60362
60363
60364
60365
60366
60367
60368
60369
60370
60371
60372
60373
60374
60375
60376
60377
60378
60379
60380
60381
60382
60383
60384
60385
60386
60387
60388
60389
60390
60391
60392
60393
60394
60395
60396
60397
60398
60399
60400
60401
60402
60403
60404
60405
60406
60407
60408
60409
60410
60411
60412
60413
60414
60415
60416
60417
60418
60419
60420
60421
60422
60423
60424
60425
60426
60427
60428
60429
60430
60431
60432
60433
60434
60435
60436
60437
60438
60439
60440
60441
60442
60443
60444
60445
60446
60447
60448
60449
60450
60451
60452
60453
60454
60455
60456
60457
60458
60459
60460
60461
60462
60463
60464
60465
60466
60467
60468
60469
60470
60471
60472
60473
60474
60475
60476
60477
60478
60479
60480
60481
60482
60483
60484
60485
60486
60487
60488
60489
60490
60491
60492
60493
60494
60495
60496
60497
60498
60499
60500
60501
60502
60503
60504
60505
60506
60507
60508
60509
60510
60511
60512
60513
60514
60515
60516
60517
60518
60519
60520
60521
60522
60523
60524
60525
60526
60527
60528
60529
60530
60531
60532
60533
60534
60535
60536
60537
60538
60539
60540
60541
60542
60543
60544
60545
60546
60547
60548
60549
60550
60551
60552
60553
60554
60555
60556
60557
60558
60559
60560
60561
60562
60563
60564
60565
60566
60567
60568
60569
60570
60571
60572
60573
60574
60575
60576
60577
60578
60579
60580
60581
60582
60583
60584
60585
60586
60587
60588
60589
60590
60591
60592
60593
60594
60595
60596
60597
60598
60599
60600
60601
60602
60603
60604
60605
60606
60607
60608
60609
60610
60611
60612
60613
60614
60615
60616
60617
60618
60619
60620
60621
60622
60623
60624
60625
60626
60627
60628
60629
60630
60631
60632
60633
60634
60635
60636
60637
60638
60639
60640
60641
60642
60643
60644
60645
60646
60647
60648
60649
60650
60651
60652
60653
60654
60655
60656
60657
60658
60659
60660
60661
60662
60663
60664
60665
60666
60667
60668
60669
60670
60671
60672
60673
60674
60675
60676
60677
60678
60679
60680
60681
60682
60683
60684
60685
60686
60687
60688
60689
60690
60691
60692
60693
60694
60695
60696
60697
60698
60699
60700
60701
60702
60703
60704
60705
60706
60707
60708
60709
60710
60711
60712
60713
60714
60715
60716
60717
60718
60719
60720
60721
60722
60723
60724
60725
60726
60727
60728
60729
60730
60731
60732
60733
60734
60735
60736
60737
60738
60739
60740
60741
60742
60743
60744
60745
60746
60747
60748
60749
60750
60751
60752
60753
60754
60755
60756
60757
60758
60759
60760
60761
60762
60763
60764
60765
60766
60767
60768
60769
60770
60771
60772
60773
60774
60775
60776
60777
60778
60779
60780
60781
60782
60783
60784
60785
60786
60787
60788
60789
60790
60791
60792
60793
60794
60795
60796
60797
60798
60799
60800
60801
60802
60803
60804
60805
60806
60807
60808
60809
60810
60811
60812
60813
60814
60815
60816
60817
60818
60819
60820
60821
60822
60823
60824
60825
60826
60827
60828
60829
60830
60831
60832
60833
60834
60835
60836
60837
60838
60839
60840
60841
60842
60843
60844
60845
60846
60847
60848
60849
60850
60851
60852
60853
60854
60855
60856
60857
60858
60859
60860
60861
60862
60863
60864
60865
60866
60867
60868
60869
60870
60871
60872
60873
60874
60875
60876
60877
60878
60879
60880
60881
60882
60883
60884
60885
60886
60887
60888
60889
60890
60891
60892
60893
60894
60895
60896
60897
60898
60899
60900
60901
60902
60903
60904
60905
60906
60907
60908
60909
60910
60911
60912
60913
60914
60915
60916
60917
60918
60919
60920
60921
60922
60923
60924
60925
60926
60927
60928
60929
60930
60931
60932
60933
60934
60935
60936
60937
60938
60939
60940
60941
60942
60943
60944
60945
60946
60947
60948
60949
60950
60951
60952
60953
60954
60955
60956
60957
60958
60959
60960
60961
60962
60963
60964
60965
60966
60967
60968
60969
60970
60971
60972
60973
60974
60975
60976
60977
60978
60979
60980
60981
60982
60983
60984
60985
60986
60987
60988
60989
60990
60991
60992
60993
60994
60995
60996
60997
60998
60999
61000
61001
61002
61003
61004
61005
61006
61007
61008
61009
61010
61011
61012
61013
61014
61015
61016
61017
61018
61019
61020
61021
61022
61023
61024
61025
61026
61027
61028
61029
61030
61031
61032
61033
61034
61035
61036
61037
61038
61039
61040
61041
61042
61043
61044
61045
61046
61047
61048
61049
61050
61051
61052
61053
61054
61055
61056
61057
61058
61059
61060
61061
61062
61063
61064
61065
61066
61067
61068
61069
61070
61071
61072
61073
61074
61075
61076
61077
61078
61079
61080
61081
61082
61083
61084
61085
61086
61087
61088
61089
61090
61091
61092
61093
61094
61095
61096
61097
61098
61099
61100
61101
61102
61103
61104
61105
61106
61107
61108
61109
61110
61111
61112
61113
61114
61115
61116
61117
61118
61119
61120
61121
61122
61123
61124
61125
61126
61127
61128
61129
61130
61131
61132
61133
61134
61135
61136
61137
61138
61139
61140
61141
61142
61143
61144
61145
61146
61147
61148
61149
61150
61151
61152
61153
61154
61155
61156
61157
61158
61159
61160
61161
61162
61163
61164
61165
61166
61167
61168
61169
61170
61171
61172
61173
61174
61175
61176
61177
61178
61179
61180
61181
61182
61183
61184
61185
61186
61187
61188
61189
61190
61191
61192
61193
61194
61195
61196
61197
61198
61199
61200
61201
61202
61203
61204
61205
61206
61207
61208
61209
61210
61211
61212
61213
61214
61215
61216
61217
61218
61219
61220
61221
61222
61223
61224
61225
61226
61227
61228
61229
61230
61231
61232
61233
61234
61235
61236
61237
61238
61239
61240
61241
61242
61243
61244
61245
61246
61247
61248
61249
61250
61251
61252
61253
61254
61255
61256
61257
61258
61259
61260
61261
61262
61263
61264
61265
61266
61267
61268
61269
61270
61271
61272
61273
61274
61275
61276
61277
61278
61279
61280
61281
61282
61283
61284
61285
61286
61287
61288
61289
61290
61291
61292
61293
61294
61295
61296
61297
61298
61299
61300
61301
61302
61303
61304
61305
61306
61307
61308
61309
61310
61311
61312
61313
61314
61315
61316
61317
61318
61319
61320
61321
61322
61323
61324
61325
61326
61327
61328
61329
61330
61331
61332
61333
61334
61335
61336
61337
61338
61339
61340
61341
61342
61343
61344
61345
61346
61347
61348
61349
61350
61351
61352
61353
61354
61355
61356
61357
61358
61359
61360
61361
61362
61363
61364
61365
61366
61367
61368
61369
61370
61371
61372
61373
61374
61375
61376
61377
61378
61379
61380
61381
61382
61383
61384
61385
61386
61387
61388
61389
61390
61391
61392
61393
61394
61395
61396
61397
61398
61399
61400
61401
61402
61403
61404
61405
61406
61407
61408
61409
61410
61411
61412
61413
61414
61415
61416
61417
61418
61419
61420
61421
61422
61423
61424
61425
61426
61427
61428
61429
61430
61431
61432
61433
61434
61435
61436
61437
61438
61439
61440
61441
61442
61443
61444
61445
61446
61447
61448
61449
61450
61451
61452
61453
61454
61455
61456
61457
61458
61459
61460
61461
61462
61463
61464
61465
61466
61467
61468
61469
61470
61471
61472
61473
61474
61475
61476
61477
61478
61479
61480
61481
61482
61483
61484
61485
61486
61487
61488
61489
61490
61491
61492
61493
61494
61495
61496
61497
61498
61499
61500
61501
61502
61503
61504
61505
61506
61507
61508
61509
61510
61511
61512
61513
61514
61515
61516
61517
61518
61519
61520
61521
61522
61523
61524
61525
61526
61527
61528
61529
61530
61531
61532
61533
61534
61535
61536
61537
61538
61539
61540
61541
61542
61543
61544
61545
61546
61547
61548
61549
61550
61551
61552
61553
61554
61555
61556
61557
61558
61559
61560
61561
61562
61563
61564
61565
61566
61567
61568
61569
61570
61571
61572
61573
61574
61575
61576
61577
61578
61579
61580
61581
61582
61583
61584
61585
61586
61587
61588
61589
61590
61591
61592
61593
61594
61595
61596
61597
61598
61599
61600
61601
61602
61603
61604
61605
61606
61607
61608
61609
61610
61611
61612
61613
61614
61615
61616
61617
61618
61619
61620
61621
61622
61623
61624
61625
61626
61627
61628
61629
61630
61631
61632
61633
61634
61635
61636
61637
61638
61639
61640
61641
61642
61643
61644
61645
61646
61647
61648
61649
61650
61651
61652
61653
61654
61655
61656
61657
61658
61659
61660
61661
61662
61663
61664
61665
61666
61667
61668
61669
61670
61671
61672
61673
61674
61675
61676
61677
61678
61679
61680
61681
61682
61683
61684
61685
61686
61687
61688
61689
61690
61691
61692
61693
61694
61695
61696
61697
61698
61699
61700
61701
61702
61703
61704
61705
61706
61707
61708
61709
61710
61711
61712
61713
61714
61715
61716
61717
61718
61719
61720
61721
61722
61723
61724
61725
61726
61727
61728
61729
61730
61731
61732
61733
61734
61735
61736
61737
61738
61739
61740
61741
61742
61743
61744
61745
61746
61747
61748
61749
61750
61751
61752
61753
61754
61755
61756
61757
61758
61759
61760
61761
61762
61763
61764
61765
61766
61767
61768
61769
61770
61771
61772
61773
61774
61775
61776
61777
61778
61779
61780
61781
61782
61783
61784
61785
61786
61787
61788
61789
61790
61791
61792
61793
61794
61795
61796
61797
61798
61799
61800
61801
61802
61803
61804
61805
61806
61807
61808
61809
61810
61811
61812
61813
61814
61815
61816
61817
61818
61819
61820
61821
61822
61823
61824
61825
61826
61827
61828
61829
61830
61831
61832
61833
61834
61835
61836
61837
61838
61839
61840
61841
61842
61843
61844
61845
61846
61847
61848
61849
61850
61851
61852
61853
61854
61855
61856
61857
61858
61859
61860
61861
61862
61863
61864
61865
61866
61867
61868
61869
61870
61871
61872
61873
61874
61875
61876
61877
61878
61879
61880
61881
61882
61883
61884
61885
61886
61887
61888
61889
61890
61891
61892
61893
61894
61895
61896
61897
61898
61899
61900
61901
61902
61903
61904
61905
61906
61907
61908
61909
61910
61911
61912
61913
61914
61915
61916
61917
61918
61919
61920
61921
61922
61923
61924
61925
61926
61927
61928
61929
61930
61931
61932
61933
61934
61935
61936
61937
61938
61939
61940
61941
61942
61943
61944
61945
61946
61947
61948
61949
61950
61951
61952
61953
61954
61955
61956
61957
61958
61959
61960
61961
61962
61963
61964
61965
61966
61967
61968
61969
61970
61971
61972
61973
61974
61975
61976
61977
61978
61979
61980
61981
61982
61983
61984
61985
61986
61987
61988
61989
61990
61991
61992
61993
61994
61995
61996
61997
61998
61999
62000
62001
62002
62003
62004
62005
62006
62007
62008
62009
62010
62011
62012
62013
62014
62015
62016
62017
62018
62019
62020
62021
62022
62023
62024
62025
62026
62027
62028
62029
62030
62031
62032
62033
62034
62035
62036
62037
62038
62039
62040
62041
62042
62043
62044
62045
62046
62047
62048
62049
62050
62051
62052
62053
62054
62055
62056
62057
62058
62059
62060
62061
62062
62063
62064
62065
62066
62067
62068
62069
62070
62071
62072
62073
62074
62075
62076
62077
62078
62079
62080
62081
62082
62083
62084
62085
62086
62087
62088
62089
62090
62091
62092
62093
62094
62095
62096
62097
62098
62099
62100
62101
62102
62103
62104
62105
62106
62107
62108
62109
62110
62111
62112
62113
62114
62115
62116
62117
62118
62119
62120
62121
62122
62123
62124
62125
62126
62127
62128
62129
62130
62131
62132
62133
62134
62135
62136
62137
62138
62139
62140
62141
62142
62143
62144
62145
62146
62147
62148
62149
62150
62151
62152
62153
62154
62155
62156
62157
62158
62159
62160
62161
62162
62163
62164
62165
62166
62167
62168
62169
62170
62171
62172
62173
62174
62175
62176
62177
62178
62179
62180
62181
62182
62183
62184
62185
62186
62187
62188
62189
62190
62191
62192
62193
62194
62195
62196
62197
62198
62199
62200
62201
62202
62203
62204
62205
62206
62207
62208
62209
62210
62211
62212
62213
62214
62215
62216
62217
62218
62219
62220
62221
62222
62223
62224
62225
62226
62227
62228
62229
62230
62231
62232
62233
62234
62235
62236
62237
62238
62239
62240
62241
62242
62243
62244
62245
62246
62247
62248
62249
62250
62251
62252
62253
62254
62255
62256
62257
62258
62259
62260
62261
62262
62263
62264
62265
62266
62267
62268
62269
62270
62271
62272
62273
62274
62275
62276
62277
62278
62279
62280
62281
62282
62283
62284
62285
62286
62287
62288
62289
62290
62291
62292
62293
62294
62295
62296
62297
62298
62299
62300
62301
62302
62303
62304
62305
62306
62307
62308
62309
62310
62311
62312
62313
62314
62315
62316
62317
62318
62319
62320
62321
62322
62323
62324
62325
62326
62327
62328
62329
62330
62331
62332
62333
62334
62335
62336
62337
62338
62339
62340
62341
62342
62343
62344
62345
62346
62347
62348
62349
62350
62351
62352
62353
62354
62355
62356
62357
62358
62359
62360
62361
62362
62363
62364
62365
62366
62367
62368
62369
62370
62371
62372
62373
62374
62375
62376
62377
62378
62379
62380
62381
62382
62383
62384
62385
62386
62387
62388
62389
62390
62391
62392
62393
62394
62395
62396
62397
62398
62399
62400
62401
62402
62403
62404
62405
62406
62407
62408
62409
62410
62411
62412
62413
62414
62415
62416
62417
62418
62419
62420
62421
62422
62423
62424
62425
62426
62427
62428
62429
62430
62431
62432
62433
62434
62435
62436
62437
62438
62439
62440
62441
62442
62443
62444
62445
62446
62447
62448
62449
62450
62451
62452
62453
62454
62455
62456
62457
62458
62459
62460
62461
62462
62463
62464
62465
62466
62467
62468
62469
62470
62471
62472
62473
62474
62475
62476
62477
62478
62479
62480
62481
62482
62483
62484
62485
62486
62487
62488
62489
62490
62491
62492
62493
62494
62495
62496
62497
62498
62499
62500
62501
62502
62503
62504
62505
62506
62507
62508
62509
62510
62511
62512
62513
62514
62515
62516
62517
62518
62519
62520
62521
62522
62523
62524
62525
62526
62527
62528
62529
62530
62531
62532
62533
62534
62535
62536
62537
62538
62539
62540
62541
62542
62543
62544
62545
62546
62547
62548
62549
62550
62551
62552
62553
62554
62555
62556
62557
62558
62559
62560
62561
62562
62563
62564
62565
62566
62567
62568
62569
62570
62571
62572
62573
62574
62575
62576
62577
62578
62579
62580
62581
62582
62583
62584
62585
62586
62587
62588
62589
62590
62591
62592
62593
62594
62595
62596
62597
62598
62599
62600
62601
62602
62603
62604
62605
62606
62607
62608
62609
62610
62611
62612
62613
62614
62615
62616
62617
62618
62619
62620
62621
62622
62623
62624
62625
62626
62627
62628
62629
62630
62631
62632
62633
62634
62635
62636
62637
62638
62639
62640
62641
62642
62643
62644
62645
62646
62647
62648
62649
62650
62651
62652
62653
62654
62655
62656
62657
62658
62659
62660
62661
62662
62663
62664
62665
62666
62667
62668
62669
62670
62671
62672
62673
62674
62675
62676
62677
62678
62679
62680
62681
62682
62683
62684
62685
62686
62687
62688
62689
62690
62691
62692
62693
62694
62695
62696
62697
62698
62699
62700
62701
62702
62703
62704
62705
62706
62707
62708
62709
62710
62711
62712
62713
62714
62715
62716
62717
62718
62719
62720
62721
62722
62723
62724
62725
62726
62727
62728
62729
62730
62731
62732
62733
62734
62735
62736
62737
62738
62739
62740
62741
62742
62743
62744
62745
62746
62747
62748
62749
62750
62751
62752
62753
62754
62755
62756
62757
62758
62759
62760
62761
62762
62763
62764
62765
62766
62767
62768
62769
62770
62771
62772
62773
62774
62775
62776
62777
62778
62779
62780
62781
62782
62783
62784
62785
62786
62787
62788
62789
62790
62791
62792
62793
62794
62795
62796
62797
62798
62799
62800
62801
62802
62803
62804
62805
62806
62807
62808
62809
62810
62811
62812
62813
62814
62815
62816
62817
62818
62819
62820
62821
62822
62823
62824
62825
62826
62827
62828
62829
62830
62831
62832
62833
62834
62835
62836
62837
62838
62839
62840
62841
62842
62843
62844
62845
62846
62847
62848
62849
62850
62851
62852
62853
62854
62855
62856
62857
62858
62859
62860
62861
62862
62863
62864
62865
62866
62867
62868
62869
62870
62871
62872
62873
62874
62875
62876
62877
62878
62879
62880
62881
62882
62883
62884
62885
62886
62887
62888
62889
62890
62891
62892
62893
62894
62895
62896
62897
62898
62899
62900
62901
62902
62903
62904
62905
62906
62907
62908
62909
62910
62911
62912
62913
62914
62915
62916
62917
62918
62919
62920
62921
62922
62923
62924
62925
62926
62927
62928
62929
62930
62931
62932
62933
62934
62935
62936
62937
62938
62939
62940
62941
62942
62943
62944
62945
62946
62947
62948
62949
62950
62951
62952
62953
62954
62955
62956
62957
62958
62959
62960
62961
62962
62963
62964
62965
62966
62967
62968
62969
62970
62971
62972
62973
62974
62975
62976
62977
62978
62979
62980
62981
62982
62983
62984
62985
62986
62987
62988
62989
62990
62991
62992
62993
62994
62995
62996
62997
62998
62999
63000
63001
63002
63003
63004
63005
63006
63007
63008
63009
63010
63011
63012
63013
63014
63015
63016
63017
63018
63019
63020
63021
63022
63023
63024
63025
63026
63027
63028
63029
63030
63031
63032
63033
63034
63035
63036
63037
63038
63039
63040
63041
63042
63043
63044
63045
63046
63047
63048
63049
63050
63051
63052
63053
63054
63055
63056
63057
63058
63059
63060
63061
63062
63063
63064
63065
63066
63067
63068
63069
63070
63071
63072
63073
63074
63075
63076
63077
63078
63079
63080
63081
63082
63083
63084
63085
63086
63087
63088
63089
63090
63091
63092
63093
63094
63095
63096
63097
63098
63099
63100
63101
63102
63103
63104
63105
63106
63107
63108
63109
63110
63111
63112
63113
63114
63115
63116
63117
63118
63119
63120
63121
63122
63123
63124
63125
63126
63127
63128
63129
63130
63131
63132
63133
63134
63135
63136
63137
63138
63139
63140
63141
63142
63143
63144
63145
63146
63147
63148
63149
63150
63151
63152
63153
63154
63155
63156
63157
63158
63159
63160
63161
63162
63163
63164
63165
63166
63167
63168
63169
63170
63171
63172
63173
63174
63175
63176
63177
63178
63179
63180
63181
63182
63183
63184
63185
63186
63187
63188
63189
63190
63191
63192
63193
63194
63195
63196
63197
63198
63199
63200
63201
63202
63203
63204
63205
63206
63207
63208
63209
63210
63211
63212
63213
63214
63215
63216
63217
63218
63219
63220
63221
63222
63223
63224
63225
63226
63227
63228
63229
63230
63231
63232
63233
63234
63235
63236
63237
63238
63239
63240
63241
63242
63243
63244
63245
63246
63247
63248
63249
63250
63251
63252
63253
63254
63255
63256
63257
63258
63259
63260
63261
63262
63263
63264
63265
63266
63267
63268
63269
63270
63271
63272
63273
63274
63275
63276
63277
63278
63279
63280
63281
63282
63283
63284
63285
63286
63287
63288
63289
63290
63291
63292
63293
63294
63295
63296
63297
63298
63299
63300
63301
63302
63303
63304
63305
63306
63307
63308
63309
63310
63311
63312
63313
63314
63315
63316
63317
63318
63319
63320
63321
63322
63323
63324
63325
63326
63327
63328
63329
63330
63331
63332
63333
63334
63335
63336
63337
63338
63339
63340
63341
63342
63343
63344
63345
63346
63347
63348
63349
63350
63351
63352
63353
63354
63355
63356
63357
63358
63359
63360
63361
63362
63363
63364
63365
63366
63367
63368
63369
63370
63371
63372
63373
63374
63375
63376
63377
63378
63379
63380
63381
63382
63383
63384
63385
63386
63387
63388
63389
63390
63391
63392
63393
63394
63395
63396
63397
63398
63399
63400
63401
63402
63403
63404
63405
63406
63407
63408
63409
63410
63411
63412
63413
63414
63415
63416
63417
63418
63419
63420
63421
63422
63423
63424
63425
63426
63427
63428
63429
63430
63431
63432
63433
63434
63435
63436
63437
63438
63439
63440
63441
63442
63443
63444
63445
63446
63447
63448
63449
63450
63451
63452
63453
63454
63455
63456
63457
63458
63459
63460
63461
63462
63463
63464
63465
63466
63467
63468
63469
63470
63471
63472
63473
63474
63475
63476
63477
63478
63479
63480
63481
63482
63483
63484
63485
63486
63487
63488
63489
63490
63491
63492
63493
63494
63495
63496
63497
63498
63499
63500
63501
63502
63503
63504
63505
63506
63507
63508
63509
63510
63511
63512
63513
63514
63515
63516
63517
63518
63519
63520
63521
63522
63523
63524
63525
63526
63527
63528
63529
63530
63531
63532
63533
63534
63535
63536
63537
63538
63539
63540
63541
63542
63543
63544
63545
63546
63547
63548
63549
63550
63551
63552
63553
63554
63555
63556
63557
63558
63559
63560
63561
63562
63563
63564
63565
63566
63567
63568
63569
63570
63571
63572
63573
63574
63575
63576
63577
63578
63579
63580
63581
63582
63583
63584
63585
63586
63587
63588
63589
63590
63591
63592
63593
63594
63595
63596
63597
63598
63599
63600
63601
63602
63603
63604
63605
63606
63607
63608
63609
63610
63611
63612
63613
63614
63615
63616
63617
63618
63619
63620
63621
63622
63623
63624
63625
63626
63627
63628
63629
63630
63631
63632
63633
63634
63635
63636
63637
63638
63639
63640
63641
63642
63643
63644
63645
63646
63647
63648
63649
63650
63651
63652
63653
63654
63655
63656
63657
63658
63659
63660
63661
63662
63663
63664
63665
63666
63667
63668
63669
63670
63671
63672
63673
63674
63675
63676
63677
63678
63679
63680
63681
63682
63683
63684
63685
63686
63687
63688
63689
63690
63691
63692
63693
63694
63695
63696
63697
63698
63699
63700
63701
63702
63703
63704
63705
63706
63707
63708
63709
63710
63711
63712
63713
63714
63715
63716
63717
63718
63719
63720
63721
63722
63723
63724
63725
63726
63727
63728
63729
63730
63731
63732
63733
63734
63735
63736
63737
63738
63739
63740
63741
63742
63743
63744
63745
63746
63747
63748
63749
63750
63751
63752
63753
63754
63755
63756
63757
63758
63759
63760
63761
63762
63763
63764
63765
63766
63767
63768
63769
63770
63771
63772
63773
63774
63775
63776
63777
63778
63779
63780
63781
63782
63783
63784
63785
63786
63787
63788
63789
63790
63791
63792
63793
63794
63795
63796
63797
63798
63799
63800
63801
63802
63803
63804
63805
63806
63807
63808
63809
63810
63811
63812
63813
63814
63815
63816
63817
63818
63819
63820
63821
63822
63823
63824
63825
63826
63827
63828
63829
63830
63831
63832
63833
63834
63835
63836
63837
63838
63839
63840
63841
63842
63843
63844
63845
63846
63847
63848
63849
63850
63851
63852
63853
63854
63855
63856
63857
63858
63859
63860
63861
63862
63863
63864
63865
63866
63867
63868
63869
63870
63871
63872
63873
63874
63875
63876
63877
63878
63879
63880
63881
63882
63883
63884
63885
63886
63887
63888
63889
63890
63891
63892
63893
63894
63895
63896
63897
63898
63899
63900
63901
63902
63903
63904
63905
63906
63907
63908
63909
63910
63911
63912
63913
63914
63915
63916
63917
63918
63919
63920
63921
63922
63923
63924
63925
63926
63927
63928
63929
63930
63931
63932
63933
63934
63935
63936
63937
63938
63939
63940
63941
63942
63943
63944
63945
63946
63947
63948
63949
63950
63951
63952
63953
63954
63955
63956
63957
63958
63959
63960
63961
63962
63963
63964
63965
63966
63967
63968
63969
63970
63971
63972
63973
63974
63975
63976
63977
63978
63979
63980
63981
63982
63983
63984
63985
63986
63987
63988
63989
63990
63991
63992
63993
63994
63995
63996
63997
63998
63999
64000
64001
64002
64003
64004
64005
64006
64007
64008
64009
64010
64011
64012
64013
64014
64015
64016
64017
64018
64019
64020
64021
64022
64023
64024
64025
64026
64027
64028
64029
64030
64031
64032
64033
64034
64035
64036
64037
64038
64039
64040
64041
64042
64043
64044
64045
64046
64047
64048
64049
64050
64051
64052
64053
64054
64055
64056
64057
64058
64059
64060
64061
64062
64063
64064
64065
64066
64067
64068
64069
64070
64071
64072
64073
64074
64075
64076
64077
64078
64079
64080
64081
64082
64083
64084
64085
64086
64087
64088
64089
64090
64091
64092
64093
64094
64095
64096
64097
64098
64099
64100
64101
64102
64103
64104
64105
64106
64107
64108
64109
64110
64111
64112
64113
64114
64115
64116
64117
64118
64119
64120
64121
64122
64123
64124
64125
64126
64127
64128
64129
64130
64131
64132
64133
64134
64135
64136
64137
64138
64139
64140
64141
64142
64143
64144
64145
64146
64147
64148
64149
64150
64151
64152
64153
64154
64155
64156
64157
64158
64159
64160
64161
64162
64163
64164
64165
64166
64167
64168
64169
64170
64171
64172
64173
64174
64175
64176
64177
64178
64179
64180
64181
64182
64183
64184
64185
64186
64187
64188
64189
64190
64191
64192
64193
64194
64195
64196
64197
64198
64199
64200
64201
64202
64203
64204
64205
64206
64207
64208
64209
64210
64211
64212
64213
64214
64215
64216
64217
64218
64219
64220
64221
64222
64223
64224
64225
64226
64227
64228
64229
64230
64231
64232
64233
64234
64235
64236
64237
64238
64239
64240
64241
64242
64243
64244
64245
64246
64247
64248
64249
64250
64251
64252
64253
64254
64255
64256
64257
64258
64259
64260
64261
64262
64263
64264
64265
64266
64267
64268
64269
64270
64271
64272
64273
64274
64275
64276
64277
64278
64279
64280
64281
64282
64283
64284
64285
64286
64287
64288
64289
64290
64291
64292
64293
64294
64295
64296
64297
64298
64299
64300
64301
64302
64303
64304
64305
64306
64307
64308
64309
64310
64311
64312
64313
64314
64315
64316
64317
64318
64319
64320
64321
64322
64323
64324
64325
64326
64327
64328
64329
64330
64331
64332
64333
64334
64335
64336
64337
64338
64339
64340
64341
64342
64343
64344
64345
64346
64347
64348
64349
64350
64351
64352
64353
64354
64355
64356
64357
64358
64359
64360
64361
64362
64363
64364
64365
64366
64367
64368
64369
64370
64371
64372
64373
64374
64375
64376
64377
64378
64379
64380
64381
64382
64383
64384
64385
64386
64387
64388
64389
64390
64391
64392
64393
64394
64395
64396
64397
64398
64399
64400
64401
64402
64403
64404
64405
64406
64407
64408
64409
64410
64411
64412
64413
64414
64415
64416
64417
64418
64419
64420
64421
64422
64423
64424
64425
64426
64427
64428
64429
64430
64431
64432
64433
64434
64435
64436
64437
64438
64439
64440
64441
64442
64443
64444
64445
64446
64447
64448
64449
64450
64451
64452
64453
64454
64455
64456
64457
64458
64459
64460
64461
64462
64463
64464
64465
64466
64467
64468
64469
64470
64471
64472
64473
64474
64475
64476
64477
64478
64479
64480
64481
64482
64483
64484
64485
64486
64487
64488
64489
64490
64491
64492
64493
64494
64495
64496
64497
64498
64499
64500
64501
64502
64503
64504
64505
64506
64507
64508
64509
64510
64511
64512
64513
64514
64515
64516
64517
64518
64519
64520
64521
64522
64523
64524
64525
64526
64527
64528
64529
64530
64531
64532
64533
64534
64535
64536
64537
64538
64539
64540
64541
64542
64543
64544
64545
64546
64547
64548
64549
64550
64551
64552
64553
64554
64555
64556
64557
64558
64559
64560
64561
64562
64563
64564
64565
64566
64567
64568
64569
64570
64571
64572
64573
64574
64575
64576
64577
64578
64579
64580
64581
64582
64583
64584
64585
64586
64587
64588
64589
64590
64591
64592
64593
64594
64595
64596
64597
64598
64599
64600
64601
64602
64603
64604
64605
64606
64607
64608
64609
64610
64611
64612
64613
64614
64615
64616
64617
64618
64619
64620
64621
64622
64623
64624
64625
64626
64627
64628
64629
64630
64631
64632
64633
64634
64635
64636
64637
64638
64639
64640
64641
64642
64643
64644
64645
64646
64647
64648
64649
64650
64651
64652
64653
64654
64655
64656
64657
64658
64659
64660
64661
64662
64663
64664
64665
64666
64667
64668
64669
64670
64671
64672
64673
64674
64675
64676
64677
64678
64679
64680
64681
64682
64683
64684
64685
64686
64687
64688
64689
64690
64691
64692
64693
64694
64695
64696
64697
64698
64699
64700
64701
64702
64703
64704
64705
64706
64707
64708
64709
64710
64711
64712
64713
64714
64715
64716
64717
64718
64719
64720
64721
64722
64723
64724
64725
64726
64727
64728
64729
64730
64731
64732
64733
64734
64735
64736
64737
64738
64739
64740
64741
64742
64743
64744
64745
64746
64747
64748
64749
64750
64751
64752
64753
64754
64755
64756
64757
64758
64759
64760
64761
64762
64763
64764
64765
64766
64767
64768
64769
64770
64771
64772
64773
64774
64775
64776
64777
64778
64779
64780
64781
64782
64783
64784
64785
64786
64787
64788
64789
64790
64791
64792
64793
64794
64795
64796
64797
64798
64799
64800
64801
64802
64803
64804
64805
64806
64807
64808
64809
64810
64811
64812
64813
64814
64815
64816
64817
64818
64819
64820
64821
64822
64823
64824
64825
64826
64827
64828
64829
64830
64831
64832
64833
64834
64835
64836
64837
64838
64839
64840
64841
64842
64843
64844
64845
64846
64847
64848
64849
64850
64851
64852
64853
64854
64855
64856
64857
64858
64859
64860
64861
64862
64863
64864
64865
64866
64867
64868
64869
64870
64871
64872
64873
64874
64875
64876
64877
64878
64879
64880
64881
64882
64883
64884
64885
64886
64887
64888
64889
64890
64891
64892
64893
64894
64895
64896
64897
64898
64899
64900
64901
64902
64903
64904
64905
64906
64907
64908
64909
64910
64911
64912
64913
64914
64915
64916
64917
64918
64919
64920
64921
64922
64923
64924
64925
64926
64927
64928
64929
64930
64931
64932
64933
64934
64935
64936
64937
64938
64939
64940
64941
64942
64943
64944
64945
64946
64947
64948
64949
64950
64951
64952
64953
64954
64955
64956
64957
64958
64959
64960
64961
64962
64963
64964
64965
64966
64967
64968
64969
64970
64971
64972
64973
64974
64975
64976
64977
64978
64979
64980
64981
64982
64983
64984
64985
64986
64987
64988
64989
64990
64991
64992
64993
64994
64995
64996
64997
64998
64999
65000
65001
65002
65003
65004
65005
65006
65007
65008
65009
65010
65011
65012
65013
65014
65015
65016
65017
65018
65019
65020
65021
65022
65023
65024
65025
65026
65027
65028
65029
65030
65031
65032
65033
65034
65035
65036
65037
65038
65039
65040
65041
65042
65043
65044
65045
65046
65047
65048
65049
65050
65051
65052
65053
65054
65055
65056
65057
65058
65059
65060
65061
65062
65063
65064
65065
65066
65067
65068
65069
65070
65071
65072
65073
65074
65075
65076
65077
65078
65079
65080
65081
65082
65083
65084
65085
65086
65087
65088
65089
65090
65091
65092
65093
65094
65095
65096
65097
65098
65099
65100
65101
65102
65103
65104
65105
65106
65107
65108
65109
65110
65111
65112
65113
65114
65115
65116
65117
65118
65119
65120
65121
65122
65123
65124
65125
65126
65127
65128
65129
65130
65131
65132
65133
65134
65135
65136
65137
65138
65139
65140
65141
65142
65143
65144
65145
65146
65147
65148
65149
65150
65151
65152
65153
65154
65155
65156
65157
65158
65159
65160
65161
65162
65163
65164
65165
65166
65167
65168
65169
65170
65171
65172
65173
65174
65175
65176
65177
65178
65179
65180
65181
65182
65183
65184
65185
65186
65187
65188
65189
65190
65191
65192
65193
65194
65195
65196
65197
65198
65199
65200
65201
65202
65203
65204
65205
65206
65207
65208
65209
65210
65211
65212
65213
65214
65215
65216
65217
65218
65219
65220
65221
65222
65223
65224
65225
65226
65227
65228
65229
65230
65231
65232
65233
65234
65235
65236
65237
65238
65239
65240
65241
65242
65243
65244
65245
65246
65247
65248
65249
65250
65251
65252
65253
65254
65255
65256
65257
65258
65259
65260
65261
65262
65263
65264
65265
65266
65267
65268
65269
65270
65271
65272
65273
65274
65275
65276
65277
65278
65279
65280
65281
65282
65283
65284
65285
65286
65287
65288
65289
65290
65291
65292
65293
65294
65295
65296
65297
65298
65299
65300
65301
65302
65303
65304
65305
65306
65307
65308
65309
65310
65311
65312
65313
65314
65315
65316
65317
65318
65319
65320
65321
65322
65323
65324
65325
65326
65327
65328
65329
65330
65331
65332
65333
65334
65335
65336
65337
65338
65339
65340
65341
65342
65343
65344
65345
65346
65347
65348
65349
65350
65351
65352
65353
65354
65355
65356
65357
65358
65359
65360
65361
65362
65363
65364
65365
65366
65367
65368
65369
65370
65371
65372
65373
65374
65375
65376
65377
65378
65379
65380
65381
65382
65383
65384
65385
65386
65387
65388
65389
65390
65391
65392
65393
65394
65395
65396
65397
65398
65399
65400
65401
65402
65403
65404
65405
65406
65407
65408
65409
65410
65411
65412
65413
65414
65415
65416
65417
65418
65419
65420
65421
65422
65423
65424
65425
65426
65427
65428
65429
65430
65431
65432
65433
65434
65435
65436
65437
65438
65439
65440
65441
65442
65443
65444
65445
65446
65447
65448
65449
65450
65451
65452
65453
65454
65455
65456
65457
65458
65459
65460
65461
65462
65463
65464
65465
65466
65467
65468
65469
65470
65471
65472
65473
65474
65475
65476
65477
65478
65479
65480
65481
65482
65483
65484
65485
65486
65487
65488
65489
65490
65491
65492
65493
65494
65495
65496
65497
65498
65499
65500
65501
65502
65503
65504
65505
65506
65507
65508
65509
65510
65511
65512
65513
65514
65515
65516
65517
65518
65519
65520
65521
65522
65523
65524
65525
65526
65527
65528
65529
65530
65531
65532
65533
65534
65535
65536
65537
65538
65539
65540
65541
65542
65543
65544
65545
65546
65547
65548
65549
65550
65551
65552
65553
65554
65555
65556
65557
65558
65559
65560
65561
65562
65563
65564
65565
65566
65567
65568
65569
65570
65571
65572
65573
65574
65575
65576
65577
65578
65579
65580
65581
65582
65583
65584
65585
65586
65587
65588
65589
65590
65591
65592
65593
65594
65595
65596
65597
65598
65599
65600
65601
65602
65603
65604
65605
65606
65607
65608
65609
65610
65611
65612
65613
65614
65615
65616
65617
65618
65619
65620
65621
65622
65623
65624
65625
65626
65627
65628
65629
65630
65631
65632
65633
65634
65635
65636
65637
65638
65639
65640
65641
65642
65643
65644
65645
65646
65647
65648
65649
65650
65651
65652
65653
65654
65655
65656
65657
65658
65659
65660
65661
65662
65663
65664
65665
65666
65667
65668
65669
65670
65671
65672
65673
65674
65675
65676
65677
65678
65679
65680
65681
65682
65683
65684
65685
65686
65687
65688
65689
65690
65691
65692
65693
65694
65695
65696
65697
65698
65699
65700
65701
65702
65703
65704
65705
65706
65707
65708
65709
65710
65711
65712
65713
65714
65715
65716
65717
65718
65719
65720
65721
65722
65723
65724
65725
65726
65727
65728
65729
65730
65731
65732
65733
65734
65735
65736
65737
65738
65739
65740
65741
65742
65743
65744
65745
65746
65747
65748
65749
65750
65751
65752
65753
65754
65755
65756
65757
65758
65759
65760
65761
65762
65763
65764
65765
65766
65767
65768
65769
65770
65771
65772
65773
65774
65775
65776
65777
65778
65779
65780
65781
65782
65783
65784
65785
65786
65787
65788
65789
65790
65791
65792
65793
65794
65795
65796
65797
65798
65799
65800
65801
65802
65803
65804
65805
65806
65807
65808
65809
65810
65811
65812
65813
65814
65815
65816
65817
65818
65819
65820
65821
65822
65823
65824
65825
65826
65827
65828
65829
65830
65831
65832
65833
65834
65835
65836
65837
65838
65839
65840
65841
65842
65843
65844
65845
65846
65847
65848
65849
65850
65851
65852
65853
65854
65855
65856
65857
65858
65859
65860
65861
65862
65863
65864
65865
65866
65867
65868
65869
65870
65871
65872
65873
65874
65875
65876
65877
65878
65879
65880
65881
65882
65883
65884
65885
65886
65887
65888
65889
65890
65891
65892
65893
65894
65895
65896
65897
65898
65899
65900
65901
65902
65903
65904
65905
65906
65907
65908
65909
65910
65911
65912
65913
65914
65915
65916
65917
65918
65919
65920
65921
65922
65923
65924
65925
65926
65927
65928
65929
65930
65931
65932
65933
65934
65935
65936
65937
65938
65939
65940
65941
65942
65943
65944
65945
65946
65947
65948
65949
65950
65951
65952
65953
65954
65955
65956
65957
65958
65959
65960
65961
65962
65963
65964
65965
65966
65967
65968
65969
65970
65971
65972
65973
65974
65975
65976
65977
65978
65979
65980
65981
65982
65983
65984
65985
65986
65987
65988
65989
65990
65991
65992
65993
65994
65995
65996
65997
65998
65999
66000
66001
66002
66003
66004
66005
66006
66007
66008
66009
66010
66011
66012
66013
66014
66015
66016
66017
66018
66019
66020
66021
66022
66023
66024
66025
66026
66027
66028
66029
66030
66031
66032
66033
66034
66035
66036
66037
66038
66039
66040
66041
66042
66043
66044
66045
66046
66047
66048
66049
66050
66051
66052
66053
66054
66055
66056
66057
66058
66059
66060
66061
66062
66063
66064
66065
66066
66067
66068
66069
66070
66071
66072
66073
66074
66075
66076
66077
66078
66079
66080
66081
66082
66083
66084
66085
66086
66087
66088
66089
66090
66091
66092
66093
66094
66095
66096
66097
66098
66099
66100
66101
66102
66103
66104
66105
66106
66107
66108
66109
66110
66111
66112
66113
66114
66115
66116
66117
66118
66119
66120
66121
66122
66123
66124
66125
66126
66127
66128
66129
66130
66131
66132
66133
66134
66135
66136
66137
66138
66139
66140
66141
66142
66143
66144
66145
66146
66147
66148
66149
66150
66151
66152
66153
66154
66155
66156
66157
66158
66159
66160
66161
66162
66163
66164
66165
66166
66167
66168
66169
66170
66171
66172
66173
66174
66175
66176
66177
66178
66179
66180
66181
66182
66183
66184
66185
66186
66187
66188
66189
66190
66191
66192
66193
66194
66195
66196
66197
66198
66199
66200
66201
66202
66203
66204
66205
66206
66207
66208
66209
66210
66211
66212
66213
66214
66215
66216
66217
66218
66219
66220
66221
66222
66223
66224
66225
66226
66227
66228
66229
66230
66231
66232
66233
66234
66235
66236
66237
66238
66239
66240
66241
66242
66243
66244
66245
66246
66247
66248
66249
66250
66251
66252
66253
66254
66255
66256
66257
66258
66259
66260
66261
66262
66263
66264
66265
66266
66267
66268
66269
66270
66271
66272
66273
66274
66275
66276
66277
66278
66279
66280
66281
66282
66283
66284
66285
66286
66287
66288
66289
66290
66291
66292
66293
66294
66295
66296
66297
66298
66299
66300
66301
66302
66303
66304
66305
66306
66307
66308
66309
66310
66311
66312
66313
66314
66315
66316
66317
66318
66319
66320
66321
66322
66323
66324
66325
66326
66327
66328
66329
66330
66331
66332
66333
66334
66335
66336
66337
66338
66339
66340
66341
66342
66343
66344
66345
66346
66347
66348
66349
66350
66351
66352
66353
66354
66355
66356
66357
66358
66359
66360
66361
66362
66363
66364
66365
66366
66367
66368
66369
66370
66371
66372
66373
66374
66375
66376
66377
66378
66379
66380
66381
66382
66383
66384
66385
66386
66387
66388
66389
66390
66391
66392
66393
66394
66395
66396
66397
66398
66399
66400
66401
66402
66403
66404
66405
66406
66407
66408
66409
66410
66411
66412
66413
66414
66415
66416
66417
66418
66419
66420
66421
66422
66423
66424
66425
66426
66427
66428
66429
66430
66431
66432
66433
66434
66435
66436
66437
66438
66439
66440
66441
66442
66443
66444
66445
66446
66447
66448
66449
66450
66451
66452
66453
66454
66455
66456
66457
66458
66459
66460
66461
66462
66463
66464
66465
66466
66467
66468
66469
66470
66471
66472
66473
66474
66475
66476
66477
66478
66479
66480
66481
66482
66483
66484
66485
66486
66487
66488
66489
66490
66491
66492
66493
66494
66495
66496
66497
66498
66499
66500
66501
66502
66503
66504
66505
66506
66507
66508
66509
66510
66511
66512
66513
66514
66515
66516
66517
66518
66519
66520
66521
66522
66523
66524
66525
66526
66527
66528
66529
66530
66531
66532
66533
66534
66535
66536
66537
66538
66539
66540
66541
66542
66543
66544
66545
66546
66547
66548
66549
66550
66551
66552
66553
66554
66555
66556
66557
66558
66559
66560
66561
66562
66563
66564
66565
66566
66567
66568
66569
66570
66571
66572
66573
66574
66575
66576
66577
66578
66579
66580
66581
66582
66583
66584
66585
66586
66587
66588
66589
66590
66591
66592
66593
66594
66595
66596
66597
66598
66599
66600
66601
66602
66603
66604
66605
66606
66607
66608
66609
66610
66611
66612
66613
66614
66615
66616
66617
66618
66619
66620
66621
66622
66623
66624
66625
66626
66627
66628
66629
66630
66631
66632
66633
66634
66635
66636
66637
66638
66639
66640
66641
66642
66643
66644
66645
66646
66647
66648
66649
66650
66651
66652
66653
66654
66655
66656
66657
66658
66659
66660
66661
66662
66663
66664
66665
66666
66667
66668
66669
66670
66671
66672
66673
66674
66675
66676
66677
66678
66679
66680
66681
66682
66683
66684
66685
66686
66687
66688
66689
66690
66691
66692
66693
66694
66695
66696
66697
66698
66699
66700
66701
66702
66703
66704
66705
66706
66707
66708
66709
66710
66711
66712
66713
66714
66715
66716
66717
66718
66719
66720
66721
66722
66723
66724
66725
66726
66727
66728
66729
66730
66731
66732
66733
66734
66735
66736
66737
66738
66739
66740
66741
66742
66743
66744
66745
66746
66747
66748
66749
66750
66751
66752
66753
66754
66755
66756
66757
66758
66759
66760
66761
66762
66763
66764
66765
66766
66767
66768
66769
66770
66771
66772
66773
66774
66775
66776
66777
66778
66779
66780
66781
66782
66783
66784
66785
66786
66787
66788
66789
66790
66791
66792
66793
66794
66795
66796
66797
66798
66799
66800
66801
66802
66803
66804
66805
66806
66807
66808
66809
66810
66811
66812
66813
66814
66815
66816
66817
66818
66819
66820
66821
66822
66823
66824
66825
66826
66827
66828
66829
66830
66831
66832
66833
66834
66835
66836
66837
66838
66839
66840
66841
66842
66843
66844
66845
66846
66847
66848
66849
66850
66851
66852
66853
66854
66855
66856
66857
66858
66859
66860
66861
66862
66863
66864
66865
66866
66867
66868
66869
66870
66871
66872
66873
66874
66875
66876
66877
66878
66879
66880
66881
66882
66883
66884
66885
66886
66887
66888
66889
66890
66891
66892
66893
66894
66895
66896
66897
66898
66899
66900
66901
66902
66903
66904
66905
66906
66907
66908
66909
66910
66911
66912
66913
66914
66915
66916
66917
66918
66919
66920
66921
66922
66923
66924
66925
66926
66927
66928
66929
66930
66931
66932
66933
66934
66935
66936
66937
66938
66939
66940
66941
66942
66943
66944
66945
66946
66947
66948
66949
66950
66951
66952
66953
66954
66955
66956
66957
66958
66959
66960
66961
66962
66963
66964
66965
66966
66967
66968
66969
66970
66971
66972
66973
66974
66975
66976
66977
66978
66979
66980
66981
66982
66983
66984
66985
66986
66987
66988
66989
66990
66991
66992
66993
66994
66995
66996
66997
66998
66999
67000
67001
67002
67003
67004
67005
67006
67007
67008
67009
67010
67011
67012
67013
67014
67015
67016
67017
67018
67019
67020
67021
67022
67023
67024
67025
67026
67027
67028
67029
67030
67031
67032
67033
67034
67035
67036
67037
67038
67039
67040
67041
67042
67043
67044
67045
67046
67047
67048
67049
67050
67051
67052
67053
67054
67055
67056
67057
67058
67059
67060
67061
67062
67063
67064
67065
67066
67067
67068
67069
67070
67071
67072
67073
67074
67075
67076
67077
67078
67079
67080
67081
67082
67083
67084
67085
67086
67087
67088
67089
67090
67091
67092
67093
67094
67095
67096
67097
67098
67099
67100
67101
67102
67103
67104
67105
67106
67107
67108
67109
67110
67111
67112
67113
67114
67115
67116
67117
67118
67119
67120
67121
67122
67123
67124
67125
67126
67127
67128
67129
67130
67131
67132
67133
67134
67135
67136
67137
67138
67139
67140
67141
67142
67143
67144
67145
67146
67147
67148
67149
67150
67151
67152
67153
67154
67155
67156
67157
67158
67159
67160
67161
67162
67163
67164
67165
67166
67167
67168
67169
67170
67171
67172
67173
67174
67175
67176
67177
67178
67179
67180
67181
67182
67183
67184
67185
67186
67187
67188
67189
67190
67191
67192
67193
67194
67195
67196
67197
67198
67199
67200
67201
67202
67203
67204
67205
67206
67207
67208
67209
67210
67211
67212
67213
67214
67215
67216
67217
67218
67219
67220
67221
67222
67223
67224
67225
67226
67227
67228
67229
67230
67231
67232
67233
67234
67235
67236
67237
67238
67239
67240
67241
67242
67243
67244
67245
67246
67247
67248
67249
67250
67251
67252
67253
67254
67255
67256
67257
67258
67259
67260
67261
67262
67263
67264
67265
67266
67267
67268
67269
67270
67271
67272
67273
67274
67275
67276
67277
67278
67279
67280
67281
67282
67283
67284
67285
67286
67287
67288
67289
67290
67291
67292
67293
67294
67295
67296
67297
67298
67299
67300
67301
67302
67303
67304
67305
67306
67307
67308
67309
67310
67311
67312
67313
67314
67315
67316
67317
67318
67319
67320
67321
67322
67323
67324
67325
67326
67327
67328
67329
67330
67331
67332
67333
67334
67335
67336
67337
67338
67339
67340
67341
67342
67343
67344
67345
67346
67347
67348
67349
67350
67351
67352
67353
67354
67355
67356
67357
67358
67359
67360
67361
67362
67363
67364
67365
67366
67367
67368
67369
67370
67371
67372
67373
67374
67375
67376
67377
67378
67379
67380
67381
67382
67383
67384
67385
67386
67387
67388
67389
67390
67391
67392
67393
67394
67395
67396
67397
67398
67399
67400
67401
67402
67403
67404
67405
67406
67407
67408
67409
67410
67411
67412
67413
67414
67415
67416
67417
67418
67419
67420
67421
67422
67423
67424
67425
67426
67427
67428
67429
67430
67431
67432
67433
67434
67435
67436
67437
67438
67439
67440
67441
67442
67443
67444
67445
67446
67447
67448
67449
67450
67451
67452
67453
67454
67455
67456
67457
67458
67459
67460
67461
67462
67463
67464
67465
67466
67467
67468
67469
67470
67471
67472
67473
67474
67475
67476
67477
67478
67479
67480
67481
67482
67483
67484
67485
67486
67487
67488
67489
67490
67491
67492
67493
67494
67495
67496
67497
67498
67499
67500
67501
67502
67503
67504
67505
67506
67507
67508
67509
67510
67511
67512
67513
67514
67515
67516
67517
67518
67519
67520
67521
67522
67523
67524
67525
67526
67527
67528
67529
67530
67531
67532
67533
67534
67535
67536
67537
67538
67539
67540
67541
67542
67543
67544
67545
67546
67547
67548
67549
67550
67551
67552
67553
67554
67555
67556
67557
67558
67559
67560
67561
67562
67563
67564
67565
67566
67567
67568
67569
67570
67571
67572
67573
67574
67575
67576
67577
67578
67579
67580
67581
67582
67583
67584
67585
67586
67587
67588
67589
67590
67591
67592
67593
67594
67595
67596
67597
67598
67599
67600
67601
67602
67603
67604
67605
67606
67607
67608
67609
67610
67611
67612
67613
67614
67615
67616
67617
67618
67619
67620
67621
67622
67623
67624
67625
67626
67627
67628
67629
67630
67631
67632
67633
67634
67635
67636
67637
67638
67639
67640
67641
67642
67643
67644
67645
67646
67647
67648
67649
67650
67651
67652
67653
67654
67655
67656
67657
67658
67659
67660
67661
67662
67663
67664
67665
67666
67667
67668
67669
67670
67671
67672
67673
67674
67675
67676
67677
67678
67679
67680
67681
67682
67683
67684
67685
67686
67687
67688
67689
67690
67691
67692
67693
67694
67695
67696
67697
67698
67699
67700
67701
67702
67703
67704
67705
67706
67707
67708
67709
67710
67711
67712
67713
67714
67715
67716
67717
67718
67719
67720
67721
67722
67723
67724
67725
67726
67727
67728
67729
67730
67731
67732
67733
67734
67735
67736
67737
67738
67739
67740
67741
67742
67743
67744
67745
67746
67747
67748
67749
67750
67751
67752
67753
67754
67755
67756
67757
67758
67759
67760
67761
67762
67763
67764
67765
67766
67767
67768
67769
67770
67771
67772
67773
67774
67775
67776
67777
67778
67779
67780
67781
67782
67783
67784
67785
67786
67787
67788
67789
67790
67791
67792
67793
67794
67795
67796
67797
67798
67799
67800
67801
67802
67803
67804
67805
67806
67807
67808
67809
67810
67811
67812
67813
67814
67815
67816
67817
67818
67819
67820
67821
67822
67823
67824
67825
67826
67827
67828
67829
67830
67831
67832
67833
67834
67835
67836
67837
67838
67839
67840
67841
67842
67843
67844
67845
67846
67847
67848
67849
67850
67851
67852
67853
67854
67855
67856
67857
67858
67859
67860
67861
67862
67863
67864
67865
67866
67867
67868
67869
67870
67871
67872
67873
67874
67875
67876
67877
67878
67879
67880
67881
67882
67883
67884
67885
67886
67887
67888
67889
67890
67891
67892
67893
67894
67895
67896
67897
67898
67899
67900
67901
67902
67903
67904
67905
67906
67907
67908
67909
67910
67911
67912
67913
67914
67915
67916
67917
67918
67919
67920
67921
67922
67923
67924
67925
67926
67927
67928
67929
67930
67931
67932
67933
67934
67935
67936
67937
67938
67939
67940
67941
67942
67943
67944
67945
67946
67947
67948
67949
67950
67951
67952
67953
67954
67955
67956
67957
67958
67959
67960
67961
67962
67963
67964
67965
67966
67967
67968
67969
67970
67971
67972
67973
67974
67975
67976
67977
67978
67979
67980
67981
67982
67983
67984
67985
67986
67987
67988
67989
67990
67991
67992
67993
67994
67995
67996
67997
67998
67999
68000
68001
68002
68003
68004
68005
68006
68007
68008
68009
68010
68011
68012
68013
68014
68015
68016
68017
68018
68019
68020
68021
68022
68023
68024
68025
68026
68027
68028
68029
68030
68031
68032
68033
68034
68035
68036
68037
68038
68039
68040
68041
68042
68043
68044
68045
68046
68047
68048
68049
68050
68051
68052
68053
68054
68055
68056
68057
68058
68059
68060
68061
68062
68063
68064
68065
68066
68067
68068
68069
68070
68071
68072
68073
68074
68075
68076
68077
68078
68079
68080
68081
68082
68083
68084
68085
68086
68087
68088
68089
68090
68091
68092
68093
68094
68095
68096
68097
68098
68099
68100
68101
68102
68103
68104
68105
68106
68107
68108
68109
68110
68111
68112
68113
68114
68115
68116
68117
68118
68119
68120
68121
68122
68123
68124
68125
68126
68127
68128
68129
68130
68131
68132
68133
68134
68135
68136
68137
68138
68139
68140
68141
68142
68143
68144
68145
68146
68147
68148
68149
68150
68151
68152
68153
68154
68155
68156
68157
68158
68159
68160
68161
68162
68163
68164
68165
68166
68167
68168
68169
68170
68171
68172
68173
68174
68175
68176
68177
68178
68179
68180
68181
68182
68183
68184
68185
68186
68187
68188
68189
68190
68191
68192
68193
68194
68195
68196
68197
68198
68199
68200
68201
68202
68203
68204
68205
68206
68207
68208
68209
68210
68211
68212
68213
68214
68215
68216
68217
68218
68219
68220
68221
68222
68223
68224
68225
68226
68227
68228
68229
68230
68231
68232
68233
68234
68235
68236
68237
68238
68239
68240
68241
68242
68243
68244
68245
68246
68247
68248
68249
68250
68251
68252
68253
68254
68255
68256
68257
68258
68259
68260
68261
68262
68263
68264
68265
68266
68267
68268
68269
68270
68271
68272
68273
68274
68275
68276
68277
68278
68279
68280
68281
68282
68283
68284
68285
68286
68287
68288
68289
68290
68291
68292
68293
68294
68295
68296
68297
68298
68299
68300
68301
68302
68303
68304
68305
68306
68307
68308
68309
68310
68311
68312
68313
68314
68315
68316
68317
68318
68319
68320
68321
68322
68323
68324
68325
68326
68327
68328
68329
68330
68331
68332
68333
68334
68335
68336
68337
68338
68339
68340
68341
68342
68343
68344
68345
68346
68347
68348
68349
68350
68351
68352
68353
68354
68355
68356
68357
68358
68359
68360
68361
68362
68363
68364
68365
68366
68367
68368
68369
68370
68371
68372
68373
68374
68375
68376
68377
68378
68379
68380
68381
68382
68383
68384
68385
68386
68387
68388
68389
68390
68391
68392
68393
68394
68395
68396
68397
68398
68399
68400
68401
68402
68403
68404
68405
68406
68407
68408
68409
68410
68411
68412
68413
68414
68415
68416
68417
68418
68419
68420
68421
68422
68423
68424
68425
68426
68427
68428
68429
68430
68431
68432
68433
68434
68435
68436
68437
68438
68439
68440
68441
68442
68443
68444
68445
68446
68447
68448
68449
68450
68451
68452
68453
68454
68455
68456
68457
68458
68459
68460
68461
68462
68463
68464
68465
68466
68467
68468
68469
68470
68471
68472
68473
68474
68475
68476
68477
68478
68479
68480
68481
68482
68483
68484
68485
68486
68487
68488
68489
68490
68491
68492
68493
68494
68495
68496
68497
68498
68499
68500
68501
68502
68503
68504
68505
68506
68507
68508
68509
68510
68511
68512
68513
68514
68515
68516
68517
68518
68519
68520
68521
68522
68523
68524
68525
68526
68527
68528
68529
68530
68531
68532
68533
68534
68535
68536
68537
68538
68539
68540
68541
68542
68543
68544
68545
68546
68547
68548
68549
68550
68551
68552
68553
68554
68555
68556
68557
68558
68559
68560
68561
68562
68563
68564
68565
68566
68567
68568
68569
68570
68571
68572
68573
68574
68575
68576
68577
68578
68579
68580
68581
68582
68583
68584
68585
68586
68587
68588
68589
68590
68591
68592
68593
68594
68595
68596
68597
68598
68599
68600
68601
68602
68603
68604
68605
68606
68607
68608
68609
68610
68611
68612
68613
68614
68615
68616
68617
68618
68619
68620
68621
68622
68623
68624
68625
68626
68627
68628
68629
68630
68631
68632
68633
68634
68635
68636
68637
68638
68639
68640
68641
68642
68643
68644
68645
68646
68647
68648
68649
68650
68651
68652
68653
68654
68655
68656
68657
68658
68659
68660
68661
68662
68663
68664
68665
68666
68667
68668
68669
68670
68671
68672
68673
68674
68675
68676
68677
68678
68679
68680
68681
68682
68683
68684
68685
68686
68687
68688
68689
68690
68691
68692
68693
68694
68695
68696
68697
68698
68699
68700
68701
68702
68703
68704
68705
68706
68707
68708
68709
68710
68711
68712
68713
68714
68715
68716
68717
68718
68719
68720
68721
68722
68723
68724
68725
68726
68727
68728
68729
68730
68731
68732
68733
68734
68735
68736
68737
68738
68739
68740
68741
68742
68743
68744
68745
68746
68747
68748
68749
68750
68751
68752
68753
68754
68755
68756
68757
68758
68759
68760
68761
68762
68763
68764
68765
68766
68767
68768
68769
68770
68771
68772
68773
68774
68775
68776
68777
68778
68779
68780
68781
68782
68783
68784
68785
68786
68787
68788
68789
68790
68791
68792
68793
68794
68795
68796
68797
68798
68799
68800
68801
68802
68803
68804
68805
68806
68807
68808
68809
68810
68811
68812
68813
68814
68815
68816
68817
68818
68819
68820
68821
68822
68823
68824
68825
68826
68827
68828
68829
68830
68831
68832
68833
68834
68835
68836
68837
68838
68839
68840
68841
68842
68843
68844
68845
68846
68847
68848
68849
68850
68851
68852
68853
68854
68855
68856
68857
68858
68859
68860
68861
68862
68863
68864
68865
68866
68867
68868
68869
68870
68871
68872
68873
68874
68875
68876
68877
68878
68879
68880
68881
68882
68883
68884
68885
68886
68887
68888
68889
68890
68891
68892
68893
68894
68895
68896
68897
68898
68899
68900
68901
68902
68903
68904
68905
68906
68907
68908
68909
68910
68911
68912
68913
68914
68915
68916
68917
68918
68919
68920
68921
68922
68923
68924
68925
68926
68927
68928
68929
68930
68931
68932
68933
68934
68935
68936
68937
68938
68939
68940
68941
68942
68943
68944
68945
68946
68947
68948
68949
68950
68951
68952
68953
68954
68955
68956
68957
68958
68959
68960
68961
68962
68963
68964
68965
68966
68967
68968
68969
68970
68971
68972
68973
68974
68975
68976
68977
68978
68979
68980
68981
68982
68983
68984
68985
68986
68987
68988
68989
68990
68991
68992
68993
68994
68995
68996
68997
68998
68999
69000
69001
69002
69003
69004
69005
69006
69007
69008
69009
69010
69011
69012
69013
69014
69015
69016
69017
69018
69019
69020
69021
69022
69023
69024
69025
69026
69027
69028
69029
69030
69031
69032
69033
69034
69035
69036
69037
69038
69039
69040
69041
69042
69043
69044
69045
69046
69047
69048
69049
69050
69051
69052
69053
69054
69055
69056
69057
69058
69059
69060
69061
69062
69063
69064
69065
69066
69067
69068
69069
69070
69071
69072
69073
69074
69075
69076
69077
69078
69079
69080
69081
69082
69083
69084
69085
69086
69087
69088
69089
69090
69091
69092
69093
69094
69095
69096
69097
69098
69099
69100
69101
69102
69103
69104
69105
69106
69107
69108
69109
69110
69111
69112
69113
69114
69115
69116
69117
69118
69119
69120
69121
69122
69123
69124
69125
69126
69127
69128
69129
69130
69131
69132
69133
69134
69135
69136
69137
69138
69139
69140
69141
69142
69143
69144
69145
69146
69147
69148
69149
69150
69151
69152
69153
69154
69155
69156
69157
69158
69159
69160
69161
69162
69163
69164
69165
69166
69167
69168
69169
69170
69171
69172
69173
69174
69175
69176
69177
69178
69179
69180
69181
69182
69183
69184
69185
69186
69187
69188
69189
69190
69191
69192
69193
69194
69195
69196
69197
69198
69199
69200
69201
69202
69203
69204
69205
69206
69207
69208
69209
69210
69211
69212
69213
69214
69215
69216
69217
69218
69219
69220
69221
69222
69223
69224
69225
69226
69227
69228
69229
69230
69231
69232
69233
69234
69235
69236
69237
69238
69239
69240
69241
69242
69243
69244
69245
69246
69247
69248
69249
69250
69251
69252
69253
69254
69255
69256
69257
69258
69259
69260
69261
69262
69263
69264
69265
69266
69267
69268
69269
69270
69271
69272
69273
69274
69275
69276
69277
69278
69279
69280
69281
69282
69283
69284
69285
69286
69287
69288
69289
69290
69291
69292
69293
69294
69295
69296
69297
69298
69299
69300
69301
69302
69303
69304
69305
69306
69307
69308
69309
69310
69311
69312
69313
69314
69315
69316
69317
69318
69319
69320
69321
69322
69323
69324
69325
69326
69327
69328
69329
69330
69331
69332
69333
69334
69335
69336
69337
69338
69339
69340
69341
69342
69343
69344
69345
69346
69347
69348
69349
69350
69351
69352
69353
69354
69355
69356
69357
69358
69359
69360
69361
69362
69363
69364
69365
69366
69367
69368
69369
69370
69371
69372
69373
69374
69375
69376
69377
69378
69379
69380
69381
69382
69383
69384
69385
69386
69387
69388
69389
69390
69391
69392
69393
69394
69395
69396
69397
69398
69399
69400
69401
69402
69403
69404
69405
69406
69407
69408
69409
69410
69411
69412
69413
69414
69415
69416
69417
69418
69419
69420
69421
69422
69423
69424
69425
69426
69427
69428
69429
69430
69431
69432
69433
69434
69435
69436
69437
69438
69439
69440
69441
69442
69443
69444
69445
69446
69447
69448
69449
69450
69451
69452
69453
69454
69455
69456
69457
69458
69459
69460
69461
69462
69463
69464
69465
69466
69467
69468
69469
69470
69471
69472
69473
69474
69475
69476
69477
69478
69479
69480
69481
69482
69483
69484
69485
69486
69487
69488
69489
69490
69491
69492
69493
69494
69495
69496
69497
69498
69499
69500
69501
69502
69503
69504
69505
69506
69507
69508
69509
69510
69511
69512
69513
69514
69515
69516
69517
69518
69519
69520
69521
69522
69523
69524
69525
69526
69527
69528
69529
69530
69531
69532
69533
69534
69535
69536
69537
69538
69539
69540
69541
69542
69543
69544
69545
69546
69547
69548
69549
69550
69551
69552
69553
69554
69555
69556
69557
69558
69559
69560
69561
69562
69563
69564
69565
69566
69567
69568
69569
69570
69571
69572
69573
69574
69575
69576
69577
69578
69579
69580
69581
69582
69583
69584
69585
69586
69587
69588
69589
69590
69591
69592
69593
69594
69595
69596
69597
69598
69599
69600
69601
69602
69603
69604
69605
69606
69607
69608
69609
69610
69611
69612
69613
69614
69615
69616
69617
69618
69619
69620
69621
69622
69623
69624
69625
69626
69627
69628
69629
69630
69631
69632
69633
69634
69635
69636
69637
69638
69639
69640
69641
69642
69643
69644
69645
69646
69647
69648
69649
69650
69651
69652
69653
69654
69655
69656
69657
69658
69659
69660
69661
69662
69663
69664
69665
69666
69667
69668
69669
69670
69671
69672
69673
69674
69675
69676
69677
69678
69679
69680
69681
69682
69683
69684
69685
69686
69687
69688
69689
69690
69691
69692
69693
69694
69695
69696
69697
69698
69699
69700
69701
69702
69703
69704
69705
69706
69707
69708
69709
69710
69711
69712
69713
69714
69715
69716
69717
69718
69719
69720
69721
69722
69723
69724
69725
69726
69727
69728
69729
69730
69731
69732
69733
69734
69735
69736
69737
69738
69739
69740
69741
69742
69743
69744
69745
69746
69747
69748
69749
69750
69751
69752
69753
69754
69755
69756
69757
69758
69759
69760
69761
69762
69763
69764
69765
69766
69767
69768
69769
69770
69771
69772
69773
69774
69775
69776
69777
69778
69779
69780
69781
69782
69783
69784
69785
69786
69787
69788
69789
69790
69791
69792
69793
69794
69795
69796
69797
69798
69799
69800
69801
69802
69803
69804
69805
69806
69807
69808
69809
69810
69811
69812
69813
69814
69815
69816
69817
69818
69819
69820
69821
69822
69823
69824
69825
69826
69827
69828
69829
69830
69831
69832
69833
69834
69835
69836
69837
69838
69839
69840
69841
69842
69843
69844
69845
69846
69847
69848
69849
69850
69851
69852
69853
69854
69855
69856
69857
69858
69859
69860
69861
69862
69863
69864
69865
69866
69867
69868
69869
69870
69871
69872
69873
69874
69875
69876
69877
69878
69879
69880
69881
69882
69883
69884
69885
69886
69887
69888
69889
69890
69891
69892
69893
69894
69895
69896
69897
69898
69899
69900
69901
69902
69903
69904
69905
69906
69907
69908
69909
69910
69911
69912
69913
69914
69915
69916
69917
69918
69919
69920
69921
69922
69923
69924
69925
69926
69927
69928
69929
69930
69931
69932
69933
69934
69935
69936
69937
69938
69939
69940
69941
69942
69943
69944
69945
69946
69947
69948
69949
69950
69951
69952
69953
69954
69955
69956
69957
69958
69959
69960
69961
69962
69963
69964
69965
69966
69967
69968
69969
69970
69971
69972
69973
69974
69975
69976
69977
69978
69979
69980
69981
69982
69983
69984
69985
69986
69987
69988
69989
69990
69991
69992
69993
69994
69995
69996
69997
69998
69999
70000
70001
70002
70003
70004
70005
70006
70007
70008
70009
70010
70011
70012
70013
70014
70015
70016
70017
70018
70019
70020
70021
70022
70023
70024
70025
70026
70027
70028
70029
70030
70031
70032
70033
70034
70035
70036
70037
70038
70039
70040
70041
70042
70043
70044
70045
70046
70047
70048
70049
70050
70051
70052
70053
70054
70055
70056
70057
70058
70059
70060
70061
70062
70063
70064
70065
70066
70067
70068
70069
70070
70071
70072
70073
70074
70075
70076
70077
70078
70079
70080
70081
70082
70083
70084
70085
70086
70087
70088
70089
70090
70091
70092
70093
70094
70095
70096
70097
70098
70099
70100
70101
70102
70103
70104
70105
70106
70107
70108
70109
70110
70111
70112
70113
70114
70115
70116
70117
70118
70119
70120
70121
70122
70123
70124
70125
70126
70127
70128
70129
70130
70131
70132
70133
70134
70135
70136
70137
70138
70139
70140
70141
70142
70143
70144
70145
70146
70147
70148
70149
70150
70151
70152
70153
70154
70155
70156
70157
70158
70159
70160
70161
70162
70163
70164
70165
70166
70167
70168
70169
70170
70171
70172
70173
70174
70175
70176
70177
70178
70179
70180
70181
70182
70183
70184
70185
70186
70187
70188
70189
70190
70191
70192
70193
70194
70195
70196
70197
70198
70199
70200
70201
70202
70203
70204
70205
70206
70207
70208
70209
70210
70211
70212
70213
70214
70215
70216
70217
70218
70219
70220
70221
70222
70223
70224
70225
70226
70227
70228
70229
70230
70231
70232
70233
70234
70235
70236
70237
70238
70239
70240
70241
70242
70243
70244
70245
70246
70247
70248
70249
70250
70251
70252
70253
70254
70255
70256
70257
70258
70259
70260
70261
70262
70263
70264
70265
70266
70267
70268
70269
70270
70271
70272
70273
70274
70275
70276
70277
70278
70279
70280
70281
70282
70283
70284
70285
70286
70287
70288
70289
70290
70291
70292
70293
70294
70295
70296
70297
70298
70299
70300
70301
70302
70303
70304
70305
70306
70307
70308
70309
70310
70311
70312
70313
70314
70315
70316
70317
70318
70319
70320
70321
70322
70323
70324
70325
70326
70327
70328
70329
70330
70331
70332
70333
70334
70335
70336
70337
70338
70339
70340
70341
70342
70343
70344
70345
70346
70347
70348
70349
70350
70351
70352
70353
70354
70355
70356
70357
70358
70359
70360
70361
70362
70363
70364
70365
70366
70367
70368
70369
70370
70371
70372
70373
70374
70375
70376
70377
70378
70379
70380
70381
70382
70383
70384
70385
70386
70387
70388
70389
70390
70391
70392
70393
70394
70395
70396
70397
70398
70399
70400
70401
70402
70403
70404
70405
70406
70407
70408
70409
70410
70411
70412
70413
70414
70415
70416
70417
70418
70419
70420
70421
70422
70423
70424
70425
70426
70427
70428
70429
70430
70431
70432
70433
70434
70435
70436
70437
70438
70439
70440
70441
70442
70443
70444
70445
70446
70447
70448
70449
70450
70451
70452
70453
70454
70455
70456
70457
70458
70459
70460
70461
70462
70463
70464
70465
70466
70467
70468
70469
70470
70471
70472
70473
70474
70475
70476
70477
70478
70479
70480
70481
70482
70483
70484
70485
70486
70487
70488
70489
70490
70491
70492
70493
70494
70495
70496
70497
70498
70499
70500
70501
70502
70503
70504
70505
70506
70507
70508
70509
70510
70511
70512
70513
70514
70515
70516
70517
70518
70519
70520
70521
70522
70523
70524
70525
70526
70527
70528
70529
70530
70531
70532
70533
70534
70535
70536
70537
70538
70539
70540
70541
70542
70543
70544
70545
70546
70547
70548
70549
70550
70551
70552
70553
70554
70555
70556
70557
70558
70559
70560
70561
70562
70563
70564
70565
70566
70567
70568
70569
70570
70571
70572
70573
70574
70575
70576
70577
70578
70579
70580
70581
70582
70583
70584
70585
70586
70587
70588
70589
70590
70591
70592
70593
70594
70595
70596
70597
70598
70599
70600
70601
70602
70603
70604
70605
70606
70607
70608
70609
70610
70611
70612
70613
70614
70615
70616
70617
70618
70619
70620
70621
70622
70623
70624
70625
70626
70627
70628
70629
70630
70631
70632
70633
70634
70635
70636
70637
70638
70639
70640
70641
70642
70643
70644
70645
70646
70647
70648
70649
70650
70651
70652
70653
70654
70655
70656
70657
70658
70659
70660
70661
70662
70663
70664
70665
70666
70667
70668
70669
70670
70671
70672
70673
70674
70675
70676
70677
70678
70679
70680
70681
70682
70683
70684
70685
70686
70687
70688
70689
70690
70691
70692
70693
70694
70695
70696
70697
70698
70699
70700
70701
70702
70703
70704
70705
70706
70707
70708
70709
70710
70711
70712
70713
70714
70715
70716
70717
70718
70719
70720
70721
70722
70723
70724
70725
70726
70727
70728
70729
70730
70731
70732
70733
70734
70735
70736
70737
70738
70739
70740
70741
70742
70743
70744
70745
70746
70747
70748
70749
70750
70751
70752
70753
70754
70755
70756
70757
70758
70759
70760
70761
70762
70763
70764
70765
70766
70767
70768
70769
70770
70771
70772
70773
70774
70775
70776
70777
70778
70779
70780
70781
70782
70783
70784
70785
70786
70787
70788
70789
70790
70791
70792
70793
70794
70795
70796
70797
70798
70799
70800
70801
70802
70803
70804
70805
70806
70807
70808
70809
70810
70811
70812
70813
70814
70815
70816
70817
70818
70819
70820
70821
70822
70823
70824
70825
70826
70827
70828
70829
70830
70831
70832
70833
70834
70835
70836
70837
70838
70839
70840
70841
70842
70843
70844
70845
70846
70847
70848
70849
70850
70851
70852
70853
70854
70855
70856
70857
70858
70859
70860
70861
70862
70863
70864
70865
70866
70867
70868
70869
70870
70871
70872
70873
70874
70875
70876
70877
70878
70879
70880
70881
70882
70883
70884
70885
70886
70887
70888
70889
70890
70891
70892
70893
70894
70895
70896
70897
70898
70899
70900
70901
70902
70903
70904
70905
70906
70907
70908
70909
70910
70911
70912
70913
70914
70915
70916
70917
70918
70919
70920
70921
70922
70923
70924
70925
70926
70927
70928
70929
70930
70931
70932
70933
70934
70935
70936
70937
70938
70939
70940
70941
70942
70943
70944
70945
70946
70947
70948
70949
70950
70951
70952
70953
70954
70955
70956
70957
70958
70959
70960
70961
70962
70963
70964
70965
70966
70967
70968
70969
70970
70971
70972
70973
70974
70975
70976
70977
70978
70979
70980
70981
70982
70983
70984
70985
70986
70987
70988
70989
70990
70991
70992
70993
70994
70995
70996
70997
70998
70999
71000
71001
71002
71003
71004
71005
71006
71007
71008
71009
71010
71011
71012
71013
71014
71015
71016
71017
71018
71019
71020
71021
71022
71023
71024
71025
71026
71027
71028
71029
71030
71031
71032
71033
71034
71035
71036
71037
71038
71039
71040
71041
71042
71043
71044
71045
71046
71047
71048
71049
71050
71051
71052
71053
71054
71055
71056
71057
71058
71059
71060
71061
71062
71063
71064
71065
71066
71067
71068
71069
71070
71071
71072
71073
71074
71075
71076
71077
71078
71079
71080
71081
71082
71083
71084
71085
71086
71087
71088
71089
71090
71091
71092
71093
71094
71095
71096
71097
71098
71099
71100
71101
71102
71103
71104
71105
71106
71107
71108
71109
71110
71111
71112
71113
71114
71115
71116
71117
71118
71119
71120
71121
71122
71123
71124
71125
71126
71127
71128
71129
71130
71131
71132
71133
71134
71135
71136
71137
71138
71139
71140
71141
71142
71143
71144
71145
71146
71147
71148
71149
71150
71151
71152
71153
71154
71155
71156
71157
71158
71159
71160
71161
71162
71163
71164
71165
71166
71167
71168
71169
71170
71171
71172
71173
71174
71175
71176
71177
71178
71179
71180
71181
71182
71183
71184
71185
71186
71187
71188
71189
71190
71191
71192
71193
71194
71195
71196
71197
71198
71199
71200
71201
71202
71203
71204
71205
71206
71207
71208
71209
71210
71211
71212
71213
71214
71215
71216
71217
71218
71219
71220
71221
71222
71223
71224
71225
71226
71227
71228
71229
71230
71231
71232
71233
71234
71235
71236
71237
71238
71239
71240
71241
71242
71243
71244
71245
71246
71247
71248
71249
71250
71251
71252
71253
71254
71255
71256
71257
71258
71259
71260
71261
71262
71263
71264
71265
71266
71267
71268
71269
71270
71271
71272
71273
71274
71275
71276
71277
71278
71279
71280
71281
71282
71283
71284
71285
71286
71287
71288
71289
71290
71291
71292
71293
71294
71295
71296
71297
71298
71299
71300
71301
71302
71303
71304
71305
71306
71307
71308
71309
71310
71311
71312
71313
71314
71315
71316
71317
71318
71319
71320
71321
71322
71323
71324
71325
71326
71327
71328
71329
71330
71331
71332
71333
71334
71335
71336
71337
71338
71339
71340
71341
71342
71343
71344
71345
71346
71347
71348
71349
71350
71351
71352
71353
71354
71355
71356
71357
71358
71359
71360
71361
71362
71363
71364
71365
71366
71367
71368
71369
71370
71371
71372
71373
71374
71375
71376
71377
71378
71379
71380
71381
71382
71383
71384
71385
71386
71387
71388
71389
71390
71391
71392
71393
71394
71395
71396
71397
71398
71399
71400
71401
71402
71403
71404
71405
71406
71407
71408
71409
71410
71411
71412
71413
71414
71415
71416
71417
71418
71419
71420
71421
71422
71423
71424
71425
71426
71427
71428
71429
71430
71431
71432
71433
71434
71435
71436
71437
71438
71439
71440
71441
71442
71443
71444
71445
71446
71447
71448
71449
71450
71451
71452
71453
71454
71455
71456
71457
71458
71459
71460
71461
71462
71463
71464
71465
71466
71467
71468
71469
71470
71471
71472
71473
71474
71475
71476
71477
71478
71479
71480
71481
71482
71483
71484
71485
71486
71487
71488
71489
71490
71491
71492
71493
71494
71495
71496
71497
71498
71499
71500
71501
71502
71503
71504
71505
71506
71507
71508
71509
71510
71511
71512
71513
71514
71515
71516
71517
71518
71519
71520
71521
71522
71523
71524
71525
71526
71527
71528
71529
71530
71531
71532
71533
71534
71535
71536
71537
71538
71539
71540
71541
71542
71543
71544
71545
71546
71547
71548
71549
71550
71551
71552
71553
71554
71555
71556
71557
71558
71559
71560
71561
71562
71563
71564
71565
71566
71567
71568
71569
71570
71571
71572
71573
71574
71575
71576
71577
71578
71579
71580
71581
71582
71583
71584
71585
71586
71587
71588
71589
71590
71591
71592
71593
71594
71595
71596
71597
71598
71599
71600
71601
71602
71603
71604
71605
71606
71607
71608
71609
71610
71611
71612
71613
71614
71615
71616
71617
71618
71619
71620
71621
71622
71623
71624
71625
71626
71627
71628
71629
71630
71631
71632
71633
71634
71635
71636
71637
71638
71639
71640
71641
71642
71643
71644
71645
71646
71647
71648
71649
71650
71651
71652
71653
71654
71655
71656
71657
71658
71659
71660
71661
71662
71663
71664
71665
71666
71667
71668
71669
71670
71671
71672
71673
71674
71675
71676
71677
71678
71679
71680
71681
71682
71683
71684
71685
71686
71687
71688
71689
71690
71691
71692
71693
71694
71695
71696
71697
71698
71699
71700
71701
71702
71703
71704
71705
71706
71707
71708
71709
71710
71711
71712
71713
71714
71715
71716
71717
71718
71719
71720
71721
71722
71723
71724
71725
71726
71727
71728
71729
71730
71731
71732
71733
71734
71735
71736
71737
71738
71739
71740
71741
71742
71743
71744
71745
71746
71747
71748
71749
71750
71751
71752
71753
71754
71755
71756
71757
71758
71759
71760
71761
71762
71763
71764
71765
71766
71767
71768
71769
71770
71771
71772
71773
71774
71775
71776
71777
71778
71779
71780
71781
71782
71783
71784
71785
71786
71787
71788
71789
71790
71791
71792
71793
71794
71795
71796
71797
71798
71799
71800
71801
71802
71803
71804
71805
71806
71807
71808
71809
71810
71811
71812
71813
71814
71815
71816
71817
71818
71819
71820
71821
71822
71823
71824
71825
71826
71827
71828
71829
71830
71831
71832
71833
71834
71835
71836
71837
71838
71839
71840
71841
71842
71843
71844
71845
71846
71847
71848
71849
71850
71851
71852
71853
71854
71855
71856
71857
71858
71859
71860
71861
71862
71863
71864
71865
71866
71867
71868
71869
71870
71871
71872
71873
71874
71875
71876
71877
71878
71879
71880
71881
71882
71883
71884
71885
71886
71887
71888
71889
71890
71891
71892
71893
71894
71895
71896
71897
71898
71899
71900
71901
71902
71903
71904
71905
71906
71907
71908
71909
71910
71911
71912
71913
71914
71915
71916
71917
71918
71919
71920
71921
71922
71923
71924
71925
71926
71927
71928
71929
71930
71931
71932
71933
71934
71935
71936
71937
71938
71939
71940
71941
71942
71943
71944
71945
71946
71947
71948
71949
71950
71951
71952
71953
71954
71955
71956
71957
71958
71959
71960
71961
71962
71963
71964
71965
71966
71967
71968
71969
71970
71971
71972
71973
71974
71975
71976
71977
71978
71979
71980
71981
71982
71983
71984
71985
71986
71987
71988
71989
71990
71991
71992
71993
71994
71995
71996
71997
71998
71999
72000
72001
72002
72003
72004
72005
72006
72007
72008
72009
72010
72011
72012
72013
72014
72015
72016
72017
72018
72019
72020
72021
72022
72023
72024
72025
72026
72027
72028
72029
72030
72031
72032
72033
72034
72035
72036
72037
72038
72039
72040
72041
72042
72043
72044
72045
72046
72047
72048
72049
72050
72051
72052
72053
72054
72055
72056
72057
72058
72059
72060
72061
72062
72063
72064
72065
72066
72067
72068
72069
72070
72071
72072
72073
72074
72075
72076
72077
72078
72079
72080
72081
72082
72083
72084
72085
72086
72087
72088
72089
72090
72091
72092
72093
72094
72095
72096
72097
72098
72099
72100
72101
72102
72103
72104
72105
72106
72107
72108
72109
72110
72111
72112
72113
72114
72115
72116
72117
72118
72119
72120
72121
72122
72123
72124
72125
72126
72127
72128
72129
72130
72131
72132
72133
72134
72135
72136
72137
72138
72139
72140
72141
72142
72143
72144
72145
72146
72147
72148
72149
72150
72151
72152
72153
72154
72155
72156
72157
72158
72159
72160
72161
72162
72163
72164
72165
72166
72167
72168
72169
72170
72171
72172
72173
72174
72175
72176
72177
72178
72179
72180
72181
72182
72183
72184
72185
72186
72187
72188
72189
72190
72191
72192
72193
72194
72195
72196
72197
72198
72199
72200
72201
72202
72203
72204
72205
72206
72207
72208
72209
72210
72211
72212
72213
72214
72215
72216
72217
72218
72219
72220
72221
72222
72223
72224
72225
72226
72227
72228
72229
72230
72231
72232
72233
72234
72235
72236
72237
72238
72239
72240
72241
72242
72243
72244
72245
72246
72247
72248
72249
72250
72251
72252
72253
72254
72255
72256
72257
72258
72259
72260
72261
72262
72263
72264
72265
72266
72267
72268
72269
72270
72271
72272
72273
72274
72275
72276
72277
72278
72279
72280
72281
72282
72283
72284
72285
72286
72287
72288
72289
72290
72291
72292
72293
72294
72295
72296
72297
72298
72299
72300
72301
72302
72303
72304
72305
72306
72307
72308
72309
72310
72311
72312
72313
72314
72315
72316
72317
72318
72319
72320
72321
72322
72323
72324
72325
72326
72327
72328
72329
72330
72331
72332
72333
72334
72335
72336
72337
72338
72339
72340
72341
72342
72343
72344
72345
72346
72347
72348
72349
72350
72351
72352
72353
72354
72355
72356
72357
72358
72359
72360
72361
72362
72363
72364
72365
72366
72367
72368
72369
72370
72371
72372
72373
72374
72375
72376
72377
72378
72379
72380
72381
72382
72383
72384
72385
72386
72387
72388
72389
72390
72391
72392
72393
72394
72395
72396
72397
72398
72399
72400
72401
72402
72403
72404
72405
72406
72407
72408
72409
72410
72411
72412
72413
72414
72415
72416
72417
72418
72419
72420
72421
72422
72423
72424
72425
72426
72427
72428
72429
72430
72431
72432
72433
72434
72435
72436
72437
72438
72439
72440
72441
72442
72443
72444
72445
72446
72447
72448
72449
72450
72451
72452
72453
72454
72455
72456
72457
72458
72459
72460
72461
72462
72463
72464
72465
72466
72467
72468
72469
72470
72471
72472
72473
72474
72475
72476
72477
72478
72479
72480
72481
72482
72483
72484
72485
72486
72487
72488
72489
72490
72491
72492
72493
72494
72495
72496
72497
72498
72499
72500
72501
72502
72503
72504
72505
72506
72507
72508
72509
72510
72511
72512
72513
72514
72515
72516
72517
72518
72519
72520
72521
72522
72523
72524
72525
72526
72527
72528
72529
72530
72531
72532
72533
72534
72535
72536
72537
72538
72539
72540
72541
72542
72543
72544
72545
72546
72547
72548
72549
72550
72551
72552
72553
72554
72555
72556
72557
72558
72559
72560
72561
72562
72563
72564
72565
72566
72567
72568
72569
72570
72571
72572
72573
72574
72575
72576
72577
72578
72579
72580
72581
72582
72583
72584
72585
72586
72587
72588
72589
72590
72591
72592
72593
72594
72595
72596
72597
72598
72599
72600
72601
72602
72603
72604
72605
72606
72607
72608
72609
72610
72611
72612
72613
72614
72615
72616
72617
72618
72619
72620
72621
72622
72623
72624
72625
72626
72627
72628
72629
72630
72631
72632
72633
72634
72635
72636
72637
72638
72639
72640
72641
72642
72643
72644
72645
72646
72647
72648
72649
72650
72651
72652
72653
72654
72655
72656
72657
72658
72659
72660
72661
72662
72663
72664
72665
72666
72667
72668
72669
72670
72671
72672
72673
72674
72675
72676
72677
72678
72679
72680
72681
72682
72683
72684
72685
72686
72687
72688
72689
72690
72691
72692
72693
72694
72695
72696
72697
72698
72699
72700
72701
72702
72703
72704
72705
72706
72707
72708
72709
72710
72711
72712
72713
72714
72715
72716
72717
72718
72719
72720
72721
72722
72723
72724
72725
72726
72727
72728
72729
72730
72731
72732
72733
72734
72735
72736
72737
72738
72739
72740
72741
72742
72743
72744
72745
72746
72747
72748
72749
72750
72751
72752
72753
72754
72755
72756
72757
72758
72759
72760
72761
72762
72763
72764
72765
72766
72767
72768
72769
72770
72771
72772
72773
72774
72775
72776
72777
72778
72779
72780
72781
72782
72783
72784
72785
72786
72787
72788
72789
72790
72791
72792
72793
72794
72795
72796
72797
72798
72799
72800
72801
72802
72803
72804
72805
72806
72807
72808
72809
72810
72811
72812
72813
72814
72815
72816
72817
72818
72819
72820
72821
72822
72823
72824
72825
72826
72827
72828
72829
72830
72831
72832
72833
72834
72835
72836
72837
72838
72839
72840
72841
72842
72843
72844
72845
72846
72847
72848
72849
72850
72851
72852
72853
72854
72855
72856
72857
72858
72859
72860
72861
72862
72863
72864
72865
72866
72867
72868
72869
72870
72871
72872
72873
72874
72875
72876
72877
72878
72879
72880
72881
72882
72883
72884
72885
72886
72887
72888
72889
72890
72891
72892
72893
72894
72895
72896
72897
72898
72899
72900
72901
72902
72903
72904
72905
72906
72907
72908
72909
72910
72911
72912
72913
72914
72915
72916
72917
72918
72919
72920
72921
72922
72923
72924
72925
72926
72927
72928
72929
72930
72931
72932
72933
72934
72935
72936
72937
72938
72939
72940
72941
72942
72943
72944
72945
72946
72947
72948
72949
72950
72951
72952
72953
72954
72955
72956
72957
72958
72959
72960
72961
72962
72963
72964
72965
72966
72967
72968
72969
72970
72971
72972
72973
72974
72975
72976
72977
72978
72979
72980
72981
72982
72983
72984
72985
72986
72987
72988
72989
72990
72991
72992
72993
72994
72995
72996
72997
72998
72999
73000
73001
73002
73003
73004
73005
73006
73007
73008
73009
73010
73011
73012
73013
73014
73015
73016
73017
73018
73019
73020
73021
73022
73023
73024
73025
73026
73027
73028
73029
73030
73031
73032
73033
73034
73035
73036
73037
73038
73039
73040
73041
73042
73043
73044
73045
73046
73047
73048
73049
73050
73051
73052
73053
73054
73055
73056
73057
73058
73059
73060
73061
73062
73063
73064
73065
73066
73067
73068
73069
73070
73071
73072
73073
73074
73075
73076
73077
73078
73079
73080
73081
73082
73083
73084
73085
73086
73087
73088
73089
73090
73091
73092
73093
73094
73095
73096
73097
73098
73099
73100
73101
73102
73103
73104
73105
73106
73107
73108
73109
73110
73111
73112
73113
73114
73115
73116
73117
73118
73119
73120
73121
73122
73123
73124
73125
73126
73127
73128
73129
73130
73131
73132
73133
73134
73135
73136
73137
73138
73139
73140
73141
73142
73143
73144
73145
73146
73147
73148
73149
73150
73151
73152
73153
73154
73155
73156
73157
73158
73159
73160
73161
73162
73163
73164
73165
73166
73167
73168
73169
73170
73171
73172
73173
73174
73175
73176
73177
73178
73179
73180
73181
73182
73183
73184
73185
73186
73187
73188
73189
73190
73191
73192
73193
73194
73195
73196
73197
73198
73199
73200
73201
73202
73203
73204
73205
73206
73207
73208
73209
73210
73211
73212
73213
73214
73215
73216
73217
73218
73219
73220
73221
73222
73223
73224
73225
73226
73227
73228
73229
73230
73231
73232
73233
73234
73235
73236
73237
73238
73239
73240
73241
73242
73243
73244
73245
73246
73247
73248
73249
73250
73251
73252
73253
73254
73255
73256
73257
73258
73259
73260
73261
73262
73263
73264
73265
73266
73267
73268
73269
73270
73271
73272
73273
73274
73275
73276
73277
73278
73279
73280
73281
73282
73283
73284
73285
73286
73287
73288
73289
73290
73291
73292
73293
73294
73295
73296
73297
73298
73299
73300
73301
73302
73303
73304
73305
73306
73307
73308
73309
73310
73311
73312
73313
73314
73315
73316
73317
73318
73319
73320
73321
73322
73323
73324
73325
73326
73327
73328
73329
73330
73331
73332
73333
73334
73335
73336
73337
73338
73339
73340
73341
73342
73343
73344
73345
73346
73347
73348
73349
73350
73351
73352
73353
73354
73355
73356
73357
73358
73359
73360
73361
73362
73363
73364
73365
73366
73367
73368
73369
73370
73371
73372
73373
73374
73375
73376
73377
73378
73379
73380
73381
73382
73383
73384
73385
73386
73387
73388
73389
73390
73391
73392
73393
73394
73395
73396
73397
73398
73399
73400
73401
73402
73403
73404
73405
73406
73407
73408
73409
73410
73411
73412
73413
73414
73415
73416
73417
73418
73419
73420
73421
73422
73423
73424
73425
73426
73427
73428
73429
73430
73431
73432
73433
73434
73435
73436
73437
73438
73439
73440
73441
73442
73443
73444
73445
73446
73447
73448
73449
73450
73451
73452
73453
73454
73455
73456
73457
73458
73459
73460
73461
73462
73463
73464
73465
73466
73467
73468
73469
73470
73471
73472
73473
73474
73475
73476
73477
73478
73479
73480
73481
73482
73483
73484
73485
73486
73487
73488
73489
73490
73491
73492
73493
73494
73495
73496
73497
73498
73499
73500
73501
73502
73503
73504
73505
73506
73507
73508
73509
73510
73511
73512
73513
73514
73515
73516
73517
73518
73519
73520
73521
73522
73523
73524
73525
73526
73527
73528
73529
73530
73531
73532
73533
73534
73535
73536
73537
73538
73539
73540
73541
73542
73543
73544
73545
73546
73547
73548
73549
73550
73551
73552
73553
73554
73555
73556
73557
73558
73559
73560
73561
73562
73563
73564
73565
73566
73567
73568
73569
73570
73571
73572
73573
73574
73575
73576
73577
73578
73579
73580
73581
73582
73583
73584
73585
73586
73587
73588
73589
73590
73591
73592
73593
73594
73595
73596
73597
73598
73599
73600
73601
73602
73603
73604
73605
73606
73607
73608
73609
73610
73611
73612
73613
73614
73615
73616
73617
73618
73619
73620
73621
73622
73623
73624
73625
73626
73627
73628
73629
73630
73631
73632
73633
73634
73635
73636
73637
73638
73639
73640
73641
73642
73643
73644
73645
73646
73647
73648
73649
73650
73651
73652
73653
73654
73655
73656
73657
73658
73659
73660
73661
73662
73663
73664
73665
73666
73667
73668
73669
73670
73671
73672
73673
73674
73675
73676
73677
73678
73679
73680
73681
73682
73683
73684
73685
73686
73687
73688
73689
73690
73691
73692
73693
73694
73695
73696
73697
73698
73699
73700
73701
73702
73703
73704
73705
73706
73707
73708
73709
73710
73711
73712
73713
73714
73715
73716
73717
73718
73719
73720
73721
73722
73723
73724
73725
73726
73727
73728
73729
73730
73731
73732
73733
73734
73735
73736
73737
73738
73739
73740
73741
73742
73743
73744
73745
73746
73747
73748
73749
73750
73751
73752
73753
73754
73755
73756
73757
73758
73759
73760
73761
73762
73763
73764
73765
73766
73767
73768
73769
73770
73771
73772
73773
73774
73775
73776
73777
73778
73779
73780
73781
73782
73783
73784
73785
73786
73787
73788
73789
73790
73791
73792
73793
73794
73795
73796
73797
73798
73799
73800
73801
73802
73803
73804
73805
73806
73807
73808
73809
73810
73811
73812
73813
73814
73815
73816
73817
73818
73819
73820
73821
73822
73823
73824
73825
73826
73827
73828
73829
73830
73831
73832
73833
73834
73835
73836
73837
73838
73839
73840
73841
73842
73843
73844
73845
73846
73847
73848
73849
73850
73851
73852
73853
73854
73855
73856
73857
73858
73859
73860
73861
73862
73863
73864
73865
73866
73867
73868
73869
73870
73871
73872
73873
73874
73875
73876
73877
73878
73879
73880
73881
73882
73883
73884
73885
73886
73887
73888
73889
73890
73891
73892
73893
73894
73895
73896
73897
73898
73899
73900
73901
73902
73903
73904
73905
73906
73907
73908
73909
73910
73911
73912
73913
73914
73915
73916
73917
73918
73919
73920
73921
73922
73923
73924
73925
73926
73927
73928
73929
73930
73931
73932
73933
73934
73935
73936
73937
73938
73939
73940
73941
73942
73943
73944
73945
73946
73947
73948
73949
73950
73951
73952
73953
73954
73955
73956
73957
73958
73959
73960
73961
73962
73963
73964
73965
73966
73967
73968
73969
73970
73971
73972
73973
73974
73975
73976
73977
73978
73979
73980
73981
73982
73983
73984
73985
73986
73987
73988
73989
73990
73991
73992
73993
73994
73995
73996
73997
73998
73999
74000
74001
74002
74003
74004
74005
74006
74007
74008
74009
74010
74011
74012
74013
74014
74015
74016
74017
74018
74019
74020
74021
74022
74023
74024
74025
74026
74027
74028
74029
74030
74031
74032
74033
74034
74035
74036
74037
74038
74039
74040
74041
74042
74043
74044
74045
74046
74047
74048
74049
74050
74051
74052
74053
74054
74055
74056
74057
74058
74059
74060
74061
74062
74063
74064
74065
74066
74067
74068
74069
74070
74071
74072
74073
74074
74075
74076
74077
74078
74079
74080
74081
74082
74083
74084
74085
74086
74087
74088
74089
74090
74091
74092
74093
74094
74095
74096
74097
74098
74099
74100
74101
74102
74103
74104
74105
74106
74107
74108
74109
74110
74111
74112
74113
74114
74115
74116
74117
74118
74119
74120
74121
74122
74123
74124
74125
74126
74127
74128
74129
74130
74131
74132
74133
74134
74135
74136
74137
74138
74139
74140
74141
74142
74143
74144
74145
74146
74147
74148
74149
74150
74151
74152
74153
74154
74155
74156
74157
74158
74159
74160
74161
74162
74163
74164
74165
74166
74167
74168
74169
74170
74171
74172
74173
74174
74175
74176
74177
74178
74179
74180
74181
74182
74183
74184
74185
74186
74187
74188
74189
74190
74191
74192
74193
74194
74195
74196
74197
74198
74199
74200
74201
74202
74203
74204
74205
74206
74207
74208
74209
74210
74211
74212
74213
74214
74215
74216
74217
74218
74219
74220
74221
74222
74223
74224
74225
74226
74227
74228
74229
74230
74231
74232
74233
74234
74235
74236
74237
74238
74239
74240
74241
74242
74243
74244
74245
74246
74247
74248
74249
74250
74251
74252
74253
74254
74255
74256
74257
74258
74259
74260
74261
74262
74263
74264
74265
74266
74267
74268
74269
74270
74271
74272
74273
74274
74275
74276
74277
74278
74279
74280
74281
74282
74283
74284
74285
74286
74287
74288
74289
74290
74291
74292
74293
74294
74295
74296
74297
74298
74299
74300
74301
74302
74303
74304
74305
74306
74307
74308
74309
74310
74311
74312
74313
74314
74315
74316
74317
74318
74319
74320
74321
74322
74323
74324
74325
74326
74327
74328
74329
74330
74331
74332
74333
74334
74335
74336
74337
74338
74339
74340
74341
74342
74343
74344
74345
74346
74347
74348
74349
74350
74351
74352
74353
74354
74355
74356
74357
74358
74359
74360
74361
74362
74363
74364
74365
74366
74367
74368
74369
74370
74371
74372
74373
74374
74375
74376
74377
74378
74379
74380
74381
74382
74383
74384
74385
74386
74387
74388
74389
74390
74391
74392
74393
74394
74395
74396
74397
74398
74399
74400
74401
74402
74403
74404
74405
74406
74407
74408
74409
74410
74411
74412
74413
74414
74415
74416
74417
74418
74419
74420
74421
74422
74423
74424
74425
74426
74427
74428
74429
74430
74431
74432
74433
74434
74435
74436
74437
74438
74439
74440
74441
74442
74443
74444
74445
74446
74447
74448
74449
74450
74451
74452
74453
74454
74455
74456
74457
74458
74459
74460
74461
74462
74463
74464
74465
74466
74467
74468
74469
74470
74471
74472
74473
74474
74475
74476
74477
74478
74479
74480
74481
74482
74483
74484
74485
74486
74487
74488
74489
74490
74491
74492
74493
74494
74495
74496
74497
74498
74499
74500
74501
74502
74503
74504
74505
74506
74507
74508
74509
74510
74511
74512
74513
74514
74515
74516
74517
74518
74519
74520
74521
74522
74523
74524
74525
74526
74527
74528
74529
74530
74531
74532
74533
74534
74535
74536
74537
74538
74539
74540
74541
74542
74543
74544
74545
74546
74547
74548
74549
74550
74551
74552
74553
74554
74555
74556
74557
74558
74559
74560
74561
74562
74563
74564
74565
74566
74567
74568
74569
74570
74571
74572
74573
74574
74575
74576
74577
74578
74579
74580
74581
74582
74583
74584
74585
74586
74587
74588
74589
74590
74591
74592
74593
74594
74595
74596
74597
74598
74599
74600
74601
74602
74603
74604
74605
74606
74607
74608
74609
74610
74611
74612
74613
74614
74615
74616
74617
74618
74619
74620
74621
74622
74623
74624
74625
74626
74627
74628
74629
74630
74631
74632
74633
74634
74635
74636
74637
74638
74639
74640
74641
74642
74643
74644
74645
74646
74647
74648
74649
74650
74651
74652
74653
74654
74655
74656
74657
74658
74659
74660
74661
74662
74663
74664
74665
74666
74667
74668
74669
74670
74671
74672
74673
74674
74675
74676
74677
74678
74679
74680
74681
74682
74683
74684
74685
74686
74687
74688
74689
74690
74691
74692
74693
74694
74695
74696
74697
74698
74699
74700
74701
74702
74703
74704
74705
74706
74707
74708
74709
74710
74711
74712
74713
74714
74715
74716
74717
74718
74719
74720
74721
74722
74723
74724
74725
74726
74727
74728
74729
74730
74731
74732
74733
74734
74735
74736
74737
74738
74739
74740
74741
74742
74743
74744
74745
74746
74747
74748
74749
74750
74751
74752
74753
74754
74755
74756
74757
74758
74759
74760
74761
74762
74763
74764
74765
74766
74767
74768
74769
74770
74771
74772
74773
74774
74775
74776
74777
74778
74779
74780
74781
74782
74783
74784
74785
74786
74787
74788
74789
74790
74791
74792
74793
74794
74795
74796
74797
74798
74799
74800
74801
74802
74803
74804
74805
74806
74807
74808
74809
74810
74811
74812
74813
74814
74815
74816
74817
74818
74819
74820
74821
74822
74823
74824
74825
74826
74827
74828
74829
74830
74831
74832
74833
74834
74835
74836
74837
74838
74839
74840
74841
74842
74843
74844
74845
74846
74847
74848
74849
74850
74851
74852
74853
74854
74855
74856
74857
74858
74859
74860
74861
74862
74863
74864
74865
74866
74867
74868
74869
74870
74871
74872
74873
74874
74875
74876
74877
74878
74879
74880
74881
74882
74883
74884
74885
74886
74887
74888
74889
74890
74891
74892
74893
74894
74895
74896
74897
74898
74899
74900
74901
74902
74903
74904
74905
74906
74907
74908
74909
74910
74911
74912
74913
74914
74915
74916
74917
74918
74919
74920
74921
74922
74923
74924
74925
74926
74927
74928
74929
74930
74931
74932
74933
74934
74935
74936
74937
74938
74939
74940
74941
74942
74943
74944
74945
74946
74947
74948
74949
74950
74951
74952
74953
74954
74955
74956
74957
74958
74959
74960
74961
74962
74963
74964
74965
74966
74967
74968
74969
74970
74971
74972
74973
74974
74975
74976
74977
74978
74979
74980
74981
74982
74983
74984
74985
74986
74987
74988
74989
74990
74991
74992
74993
74994
74995
74996
74997
74998
74999
75000
75001
75002
75003
75004
75005
75006
75007
75008
75009
75010
75011
75012
75013
75014
75015
75016
75017
75018
75019
75020
75021
75022
75023
75024
75025
75026
75027
75028
75029
75030
75031
75032
75033
75034
75035
75036
75037
75038
75039
75040
75041
75042
75043
75044
75045
75046
75047
75048
75049
75050
75051
75052
75053
75054
75055
75056
75057
75058
75059
75060
75061
75062
75063
75064
75065
75066
75067
75068
75069
75070
75071
75072
75073
75074
75075
75076
75077
75078
75079
75080
75081
75082
75083
75084
75085
75086
75087
75088
75089
75090
75091
75092
75093
75094
75095
75096
75097
75098
75099
75100
75101
75102
75103
75104
75105
75106
75107
75108
75109
75110
75111
75112
75113
75114
75115
75116
75117
75118
75119
75120
75121
75122
75123
75124
75125
75126
75127
75128
75129
75130
75131
75132
75133
75134
75135
75136
75137
75138
75139
75140
75141
75142
75143
75144
75145
75146
75147
75148
75149
75150
75151
75152
75153
75154
75155
75156
75157
75158
75159
75160
75161
75162
75163
75164
75165
75166
75167
75168
75169
75170
75171
75172
75173
75174
75175
75176
75177
75178
75179
75180
75181
75182
75183
75184
75185
75186
75187
75188
75189
75190
75191
75192
75193
75194
75195
75196
75197
75198
75199
75200
75201
75202
75203
75204
75205
75206
75207
75208
75209
75210
75211
75212
75213
75214
75215
75216
75217
75218
75219
75220
75221
75222
75223
75224
75225
75226
75227
75228
75229
75230
75231
75232
75233
75234
75235
75236
75237
75238
75239
75240
75241
75242
75243
75244
75245
75246
75247
75248
75249
75250
75251
75252
75253
75254
75255
75256
75257
75258
75259
75260
75261
75262
75263
75264
75265
75266
75267
75268
75269
75270
75271
75272
75273
75274
75275
75276
75277
75278
75279
75280
75281
75282
75283
75284
75285
75286
75287
75288
75289
75290
75291
75292
75293
75294
75295
75296
75297
75298
75299
75300
75301
75302
75303
75304
75305
75306
75307
75308
75309
75310
75311
75312
75313
75314
75315
75316
75317
75318
75319
75320
75321
75322
75323
75324
75325
75326
75327
75328
75329
75330
75331
75332
75333
75334
75335
75336
75337
75338
75339
75340
75341
75342
75343
75344
75345
75346
75347
75348
75349
75350
75351
75352
75353
75354
75355
75356
75357
75358
75359
75360
75361
75362
75363
75364
75365
75366
75367
75368
75369
75370
75371
75372
75373
75374
75375
75376
75377
75378
75379
75380
75381
75382
75383
75384
75385
75386
75387
75388
75389
75390
75391
75392
75393
75394
75395
75396
75397
75398
75399
75400
75401
75402
75403
75404
75405
75406
75407
75408
75409
75410
75411
75412
75413
75414
75415
75416
75417
75418
75419
75420
75421
75422
75423
75424
75425
75426
75427
75428
75429
75430
75431
75432
75433
75434
75435
75436
75437
75438
75439
75440
75441
75442
75443
75444
75445
75446
75447
75448
75449
75450
75451
75452
75453
75454
75455
75456
75457
75458
75459
75460
75461
75462
75463
75464
75465
75466
75467
75468
75469
75470
75471
75472
75473
75474
75475
75476
75477
75478
75479
75480
75481
75482
75483
75484
75485
75486
75487
75488
75489
75490
75491
75492
75493
75494
75495
75496
75497
75498
75499
75500
75501
75502
75503
75504
75505
75506
75507
75508
75509
75510
75511
75512
75513
75514
75515
75516
75517
75518
75519
75520
75521
75522
75523
75524
75525
75526
75527
75528
75529
75530
75531
75532
75533
75534
75535
75536
75537
75538
75539
75540
75541
75542
75543
75544
75545
75546
75547
75548
75549
75550
75551
75552
75553
75554
75555
75556
75557
75558
75559
75560
75561
75562
75563
75564
75565
75566
75567
75568
75569
75570
75571
75572
75573
75574
75575
75576
75577
75578
75579
75580
75581
75582
75583
75584
75585
75586
75587
75588
75589
75590
75591
75592
75593
75594
75595
75596
75597
75598
75599
75600
75601
75602
75603
75604
75605
75606
75607
75608
75609
75610
75611
75612
75613
75614
75615
75616
75617
75618
75619
75620
75621
75622
75623
75624
75625
75626
75627
75628
75629
75630
75631
75632
75633
75634
75635
75636
75637
75638
75639
75640
75641
75642
75643
75644
75645
75646
75647
75648
75649
75650
75651
75652
75653
75654
75655
75656
75657
75658
75659
75660
75661
75662
75663
75664
75665
75666
75667
75668
75669
75670
75671
75672
75673
75674
75675
75676
75677
75678
75679
75680
75681
75682
75683
75684
75685
75686
75687
75688
75689
75690
75691
75692
75693
75694
75695
75696
75697
75698
75699
75700
75701
75702
75703
75704
75705
75706
75707
75708
75709
75710
75711
75712
75713
75714
75715
75716
75717
75718
75719
75720
75721
75722
75723
75724
75725
75726
75727
75728
75729
75730
75731
75732
75733
75734
75735
75736
75737
75738
75739
75740
75741
75742
75743
75744
75745
75746
75747
75748
75749
75750
75751
75752
75753
75754
75755
75756
75757
75758
75759
75760
75761
75762
75763
75764
75765
75766
75767
75768
75769
75770
75771
75772
75773
75774
75775
75776
75777
75778
75779
75780
75781
75782
75783
75784
75785
75786
75787
75788
75789
75790
75791
75792
75793
75794
75795
75796
75797
75798
75799
75800
75801
75802
75803
75804
75805
75806
75807
75808
75809
75810
75811
75812
75813
75814
75815
75816
75817
75818
75819
75820
75821
75822
75823
75824
75825
75826
75827
75828
75829
75830
75831
75832
75833
75834
75835
75836
75837
75838
75839
75840
75841
75842
75843
75844
75845
75846
75847
75848
75849
75850
75851
75852
75853
75854
75855
75856
75857
75858
75859
75860
75861
75862
75863
75864
75865
75866
75867
75868
75869
75870
75871
75872
75873
75874
75875
75876
75877
75878
75879
75880
75881
75882
75883
75884
75885
75886
75887
75888
75889
75890
75891
75892
75893
75894
75895
75896
75897
75898
75899
75900
75901
75902
75903
75904
75905
75906
75907
75908
75909
75910
75911
75912
75913
75914
75915
75916
75917
75918
75919
75920
75921
75922
75923
75924
75925
75926
75927
75928
75929
75930
75931
75932
75933
75934
75935
75936
75937
75938
75939
75940
75941
75942
75943
75944
75945
75946
75947
75948
75949
75950
75951
75952
75953
75954
75955
75956
75957
75958
75959
75960
75961
75962
75963
75964
75965
75966
75967
75968
75969
75970
75971
75972
75973
75974
75975
75976
75977
75978
75979
75980
75981
75982
75983
75984
75985
75986
75987
75988
75989
75990
75991
75992
75993
75994
75995
75996
75997
75998
75999
76000
76001
76002
76003
76004
76005
76006
76007
76008
76009
76010
76011
76012
76013
76014
76015
76016
76017
76018
76019
76020
76021
76022
76023
76024
76025
76026
76027
76028
76029
76030
76031
76032
76033
76034
76035
76036
76037
76038
76039
76040
76041
76042
76043
76044
76045
76046
76047
76048
76049
76050
76051
76052
76053
76054
76055
76056
76057
76058
76059
76060
76061
76062
76063
76064
76065
76066
76067
76068
76069
76070
76071
76072
76073
76074
76075
76076
76077
76078
76079
76080
76081
76082
76083
76084
76085
76086
76087
76088
76089
76090
76091
76092
76093
76094
76095
76096
76097
76098
76099
76100
76101
76102
76103
76104
76105
76106
76107
76108
76109
76110
76111
76112
76113
76114
76115
76116
76117
76118
76119
76120
76121
76122
76123
76124
76125
76126
76127
76128
76129
76130
76131
76132
76133
76134
76135
76136
76137
76138
76139
76140
76141
76142
76143
76144
76145
76146
76147
76148
76149
76150
76151
76152
76153
76154
76155
76156
76157
76158
76159
76160
76161
76162
76163
76164
76165
76166
76167
76168
76169
76170
76171
76172
76173
76174
76175
76176
76177
76178
76179
76180
76181
76182
76183
76184
76185
76186
76187
76188
76189
76190
76191
76192
76193
76194
76195
76196
76197
76198
76199
76200
76201
76202
76203
76204
76205
76206
76207
76208
76209
76210
76211
76212
76213
76214
76215
76216
76217
76218
76219
76220
76221
76222
76223
76224
76225
76226
76227
76228
76229
76230
76231
76232
76233
76234
76235
76236
76237
76238
76239
76240
76241
76242
76243
76244
76245
76246
76247
76248
76249
76250
76251
76252
76253
76254
76255
76256
76257
76258
76259
76260
76261
76262
76263
76264
76265
76266
76267
76268
76269
76270
76271
76272
76273
76274
76275
76276
76277
76278
76279
76280
76281
76282
76283
76284
76285
76286
76287
76288
76289
76290
76291
76292
76293
76294
76295
76296
76297
76298
76299
76300
76301
76302
76303
76304
76305
76306
76307
76308
76309
76310
76311
76312
76313
76314
76315
76316
76317
76318
76319
76320
76321
76322
76323
76324
76325
76326
76327
76328
76329
76330
76331
76332
76333
76334
76335
76336
76337
76338
76339
76340
76341
76342
76343
76344
76345
76346
76347
76348
76349
76350
76351
76352
76353
76354
76355
76356
76357
76358
76359
76360
76361
76362
76363
76364
76365
76366
76367
76368
76369
76370
76371
76372
76373
76374
76375
76376
76377
76378
76379
76380
76381
76382
76383
76384
76385
76386
76387
76388
76389
76390
76391
76392
76393
76394
76395
76396
76397
76398
76399
76400
76401
76402
76403
76404
76405
76406
76407
76408
76409
76410
76411
76412
76413
76414
76415
76416
76417
76418
76419
76420
76421
76422
76423
76424
76425
76426
76427
76428
76429
76430
76431
76432
76433
76434
76435
76436
76437
76438
76439
76440
76441
76442
76443
76444
76445
76446
76447
76448
76449
76450
76451
76452
76453
76454
76455
76456
76457
76458
76459
76460
76461
76462
76463
76464
76465
76466
76467
76468
76469
76470
76471
76472
76473
76474
76475
76476
76477
76478
76479
76480
76481
76482
76483
76484
76485
76486
76487
76488
76489
76490
76491
76492
76493
76494
76495
76496
76497
76498
76499
76500
76501
76502
76503
76504
76505
76506
76507
76508
76509
76510
76511
76512
76513
76514
76515
76516
76517
76518
76519
76520
76521
76522
76523
76524
76525
76526
76527
76528
76529
76530
76531
76532
76533
76534
76535
76536
76537
76538
76539
76540
76541
76542
76543
76544
76545
76546
76547
76548
76549
76550
76551
76552
76553
76554
76555
76556
76557
76558
76559
76560
76561
76562
76563
76564
76565
76566
76567
76568
76569
76570
76571
76572
76573
76574
76575
76576
76577
76578
76579
76580
76581
76582
76583
76584
76585
76586
76587
76588
76589
76590
76591
76592
76593
76594
76595
76596
76597
76598
76599
76600
76601
76602
76603
76604
76605
76606
76607
76608
76609
76610
76611
76612
76613
76614
76615
76616
76617
76618
76619
76620
76621
76622
76623
76624
76625
76626
76627
76628
76629
76630
76631
76632
76633
76634
76635
76636
76637
76638
76639
76640
76641
76642
76643
76644
76645
76646
76647
76648
76649
76650
76651
76652
76653
76654
76655
76656
76657
76658
76659
76660
76661
76662
76663
76664
76665
76666
76667
76668
76669
76670
76671
76672
76673
76674
76675
76676
76677
76678
76679
76680
76681
76682
76683
76684
76685
76686
76687
76688
76689
76690
76691
76692
76693
76694
76695
76696
76697
76698
76699
76700
76701
76702
76703
76704
76705
76706
76707
76708
76709
76710
76711
76712
76713
76714
76715
76716
76717
76718
76719
76720
76721
76722
76723
76724
76725
76726
76727
76728
76729
76730
76731
76732
76733
76734
76735
76736
76737
76738
76739
76740
76741
76742
76743
76744
76745
76746
76747
76748
76749
76750
76751
76752
76753
76754
76755
76756
76757
76758
76759
76760
76761
76762
76763
76764
76765
76766
76767
76768
76769
76770
76771
76772
76773
76774
76775
76776
76777
76778
76779
76780
76781
76782
76783
76784
76785
76786
76787
76788
76789
76790
76791
76792
76793
76794
76795
76796
76797
76798
76799
76800
76801
76802
76803
76804
76805
76806
76807
76808
76809
76810
76811
76812
76813
76814
76815
76816
76817
76818
76819
76820
76821
76822
76823
76824
76825
76826
76827
76828
76829
76830
76831
76832
76833
76834
76835
76836
76837
76838
76839
76840
76841
76842
76843
76844
76845
76846
76847
76848
76849
76850
76851
76852
76853
76854
76855
76856
76857
76858
76859
76860
76861
76862
76863
76864
76865
76866
76867
76868
76869
76870
76871
76872
76873
76874
76875
76876
76877
76878
76879
76880
76881
76882
76883
76884
76885
76886
76887
76888
76889
76890
76891
76892
76893
76894
76895
76896
76897
76898
76899
76900
76901
76902
76903
76904
76905
76906
76907
76908
76909
76910
76911
76912
76913
76914
76915
76916
76917
76918
76919
76920
76921
76922
76923
76924
76925
76926
76927
76928
76929
76930
76931
76932
76933
76934
76935
76936
76937
76938
76939
76940
76941
76942
76943
76944
76945
76946
76947
76948
76949
76950
76951
76952
76953
76954
76955
76956
76957
76958
76959
76960
76961
76962
76963
76964
76965
76966
76967
76968
76969
76970
76971
76972
76973
76974
76975
76976
76977
76978
76979
76980
76981
76982
76983
76984
76985
76986
76987
76988
76989
76990
76991
76992
76993
76994
76995
76996
76997
76998
76999
77000
77001
77002
77003
77004
77005
77006
77007
77008
77009
77010
77011
77012
77013
77014
77015
77016
77017
77018
77019
77020
77021
77022
77023
77024
77025
77026
77027
77028
77029
77030
77031
77032
77033
77034
77035
77036
77037
77038
77039
77040
77041
77042
77043
77044
77045
77046
77047
77048
77049
77050
77051
77052
77053
77054
77055
77056
77057
77058
77059
77060
77061
77062
77063
77064
77065
77066
77067
77068
77069
77070
77071
77072
77073
77074
77075
77076
77077
77078
77079
77080
77081
77082
77083
77084
77085
77086
77087
77088
77089
77090
77091
77092
77093
77094
77095
77096
77097
77098
77099
77100
77101
77102
77103
77104
77105
77106
77107
77108
77109
77110
77111
77112
77113
77114
77115
77116
77117
77118
77119
77120
77121
77122
77123
77124
77125
77126
77127
77128
77129
77130
77131
77132
77133
77134
77135
77136
77137
77138
77139
77140
77141
77142
77143
77144
77145
77146
77147
77148
77149
77150
77151
77152
77153
77154
77155
77156
77157
77158
77159
77160
77161
77162
77163
77164
77165
77166
77167
77168
77169
77170
77171
77172
77173
77174
77175
77176
77177
77178
77179
77180
77181
77182
77183
77184
77185
77186
77187
77188
77189
77190
77191
77192
77193
77194
77195
77196
77197
77198
77199
77200
77201
77202
77203
77204
77205
77206
77207
77208
77209
77210
77211
77212
77213
77214
77215
77216
77217
77218
77219
77220
77221
77222
77223
77224
77225
77226
77227
77228
77229
77230
77231
77232
77233
77234
77235
77236
77237
77238
77239
77240
77241
77242
77243
77244
77245
77246
77247
77248
77249
77250
77251
77252
77253
77254
77255
77256
77257
77258
77259
77260
77261
77262
77263
77264
77265
77266
77267
77268
77269
77270
77271
77272
77273
77274
77275
77276
77277
77278
77279
77280
77281
77282
77283
77284
77285
77286
77287
77288
77289
77290
77291
77292
77293
77294
77295
77296
77297
77298
77299
77300
77301
77302
77303
77304
77305
77306
77307
77308
77309
77310
77311
77312
77313
77314
77315
77316
77317
77318
77319
77320
77321
77322
77323
77324
77325
77326
77327
77328
77329
77330
77331
77332
77333
77334
77335
77336
77337
77338
77339
77340
77341
77342
77343
77344
77345
77346
77347
77348
77349
77350
77351
77352
77353
77354
77355
77356
77357
77358
77359
77360
77361
77362
77363
77364
77365
77366
77367
77368
77369
77370
77371
77372
77373
77374
77375
77376
77377
77378
77379
77380
77381
77382
77383
77384
77385
77386
77387
77388
77389
77390
77391
77392
77393
77394
77395
77396
77397
77398
77399
77400
77401
77402
77403
77404
77405
77406
77407
77408
77409
77410
77411
77412
77413
77414
77415
77416
77417
77418
77419
77420
77421
77422
77423
77424
77425
77426
77427
77428
77429
77430
77431
77432
77433
77434
77435
77436
77437
77438
77439
77440
77441
77442
77443
77444
77445
77446
77447
77448
77449
77450
77451
77452
77453
77454
77455
77456
77457
77458
77459
77460
77461
77462
77463
77464
77465
77466
77467
77468
77469
77470
77471
77472
77473
77474
77475
77476
77477
77478
77479
77480
77481
77482
77483
77484
77485
77486
77487
77488
77489
77490
77491
77492
77493
77494
77495
77496
77497
77498
77499
77500
77501
77502
77503
77504
77505
77506
77507
77508
77509
77510
77511
77512
77513
77514
77515
77516
77517
77518
77519
77520
77521
77522
77523
77524
77525
77526
77527
77528
77529
77530
77531
77532
77533
77534
77535
77536
77537
77538
77539
77540
77541
77542
77543
77544
77545
77546
77547
77548
77549
77550
77551
77552
77553
77554
77555
77556
77557
77558
77559
77560
77561
77562
77563
77564
77565
77566
77567
77568
77569
77570
77571
77572
77573
77574
77575
77576
77577
77578
77579
77580
77581
77582
77583
77584
77585
77586
77587
77588
77589
77590
77591
77592
77593
77594
77595
77596
77597
77598
77599
77600
77601
77602
77603
77604
77605
77606
77607
77608
77609
77610
77611
77612
77613
77614
77615
77616
77617
77618
77619
77620
77621
77622
77623
77624
77625
77626
77627
77628
77629
77630
77631
77632
77633
77634
77635
77636
77637
77638
77639
77640
77641
77642
77643
77644
77645
77646
77647
77648
77649
77650
77651
77652
77653
77654
77655
77656
77657
77658
77659
77660
77661
77662
77663
77664
77665
77666
77667
77668
77669
77670
77671
77672
77673
77674
77675
77676
77677
77678
77679
77680
77681
77682
77683
77684
77685
77686
77687
77688
77689
77690
77691
77692
77693
77694
77695
77696
77697
77698
77699
77700
77701
77702
77703
77704
77705
77706
77707
77708
77709
77710
77711
77712
77713
77714
77715
77716
77717
77718
77719
77720
77721
77722
77723
77724
77725
77726
77727
77728
77729
77730
77731
77732
77733
77734
77735
77736
77737
77738
77739
77740
77741
77742
77743
77744
77745
77746
77747
77748
77749
77750
77751
77752
77753
77754
77755
77756
77757
77758
77759
77760
77761
77762
77763
77764
77765
77766
77767
77768
77769
77770
77771
77772
77773
77774
77775
77776
77777
77778
77779
77780
77781
77782
77783
77784
77785
77786
77787
77788
77789
77790
77791
77792
77793
77794
77795
77796
77797
77798
77799
77800
77801
77802
77803
77804
77805
77806
77807
77808
77809
77810
77811
77812
77813
77814
77815
77816
77817
77818
77819
77820
77821
77822
77823
77824
77825
77826
77827
77828
77829
77830
77831
77832
77833
77834
77835
77836
77837
77838
77839
77840
77841
77842
77843
77844
77845
77846
77847
77848
77849
77850
77851
77852
77853
77854
77855
77856
77857
77858
77859
77860
77861
77862
77863
77864
77865
77866
77867
77868
77869
77870
77871
77872
77873
77874
77875
77876
77877
77878
77879
77880
77881
77882
77883
77884
77885
77886
77887
77888
77889
77890
77891
77892
77893
77894
77895
77896
77897
77898
77899
77900
77901
77902
77903
77904
77905
77906
77907
77908
77909
77910
77911
77912
77913
77914
77915
77916
77917
77918
77919
77920
77921
77922
77923
77924
77925
77926
77927
77928
77929
77930
77931
77932
77933
77934
77935
77936
77937
77938
77939
77940
77941
77942
77943
77944
77945
77946
77947
77948
77949
77950
77951
77952
77953
77954
77955
77956
77957
77958
77959
77960
77961
77962
77963
77964
77965
77966
77967
77968
77969
77970
77971
77972
77973
77974
77975
77976
77977
77978
77979
77980
77981
77982
77983
77984
77985
77986
77987
77988
77989
77990
77991
77992
77993
77994
77995
77996
77997
77998
77999
78000
78001
78002
78003
78004
78005
78006
78007
78008
78009
78010
78011
78012
78013
78014
78015
78016
78017
78018
78019
78020
78021
78022
78023
78024
78025
78026
78027
78028
78029
78030
78031
78032
78033
78034
78035
78036
78037
78038
78039
78040
78041
78042
78043
78044
78045
78046
78047
78048
78049
78050
78051
78052
78053
78054
78055
78056
78057
78058
78059
78060
78061
78062
78063
78064
78065
78066
78067
78068
78069
78070
78071
78072
78073
78074
78075
78076
78077
78078
78079
78080
78081
78082
78083
78084
78085
78086
78087
78088
78089
78090
78091
78092
78093
78094
78095
78096
78097
78098
78099
78100
78101
78102
78103
78104
78105
78106
78107
78108
78109
78110
78111
78112
78113
78114
78115
78116
78117
78118
78119
78120
78121
78122
78123
78124
78125
78126
78127
78128
78129
78130
78131
78132
78133
78134
78135
78136
78137
78138
78139
78140
78141
78142
78143
78144
78145
78146
78147
78148
78149
78150
78151
78152
78153
78154
78155
78156
78157
78158
78159
78160
78161
78162
78163
78164
78165
78166
78167
78168
78169
78170
78171
78172
78173
78174
78175
78176
78177
78178
78179
78180
78181
78182
78183
78184
78185
78186
78187
78188
78189
78190
78191
78192
78193
78194
78195
78196
78197
78198
78199
78200
78201
78202
78203
78204
78205
78206
78207
78208
78209
78210
78211
78212
78213
78214
78215
78216
78217
78218
78219
78220
78221
78222
78223
78224
78225
78226
78227
78228
78229
78230
78231
78232
78233
78234
78235
78236
78237
78238
78239
78240
78241
78242
78243
78244
78245
78246
78247
78248
78249
78250
78251
78252
78253
78254
78255
78256
78257
78258
78259
78260
78261
78262
78263
78264
78265
78266
78267
78268
78269
78270
78271
78272
78273
78274
78275
78276
78277
78278
78279
78280
78281
78282
78283
78284
78285
78286
78287
78288
78289
78290
78291
78292
78293
78294
78295
78296
78297
78298
78299
78300
78301
78302
78303
78304
78305
78306
78307
78308
78309
78310
78311
78312
78313
78314
78315
78316
78317
78318
78319
78320
78321
78322
78323
78324
78325
78326
78327
78328
78329
78330
78331
78332
78333
78334
78335
78336
78337
78338
78339
78340
78341
78342
78343
78344
78345
78346
78347
78348
78349
78350
78351
78352
78353
78354
78355
78356
78357
78358
78359
78360
78361
78362
78363
78364
78365
78366
78367
78368
78369
78370
78371
78372
78373
78374
78375
78376
78377
78378
78379
78380
78381
78382
78383
78384
78385
78386
78387
78388
78389
78390
78391
78392
78393
78394
78395
78396
78397
78398
78399
78400
78401
78402
78403
78404
78405
78406
78407
78408
78409
78410
78411
78412
78413
78414
78415
78416
78417
78418
78419
78420
78421
78422
78423
78424
78425
78426
78427
78428
78429
78430
78431
78432
78433
78434
78435
78436
78437
78438
78439
78440
78441
78442
78443
78444
78445
78446
78447
78448
78449
78450
78451
78452
78453
78454
78455
78456
78457
78458
78459
78460
78461
78462
78463
78464
78465
78466
78467
78468
78469
78470
78471
78472
78473
78474
78475
78476
78477
78478
78479
78480
78481
78482
78483
78484
78485
78486
78487
78488
78489
78490
78491
78492
78493
78494
78495
78496
78497
78498
78499
78500
78501
78502
78503
78504
78505
78506
78507
78508
78509
78510
78511
78512
78513
78514
78515
78516
78517
78518
78519
78520
78521
78522
78523
78524
78525
78526
78527
78528
78529
78530
78531
78532
78533
78534
78535
78536
78537
78538
78539
78540
78541
78542
78543
78544
78545
78546
78547
78548
78549
78550
78551
78552
78553
78554
78555
78556
78557
78558
78559
78560
78561
78562
78563
78564
78565
78566
78567
78568
78569
78570
78571
78572
78573
78574
78575
78576
78577
78578
78579
78580
78581
78582
78583
78584
78585
78586
78587
78588
78589
78590
78591
78592
78593
78594
78595
78596
78597
78598
78599
78600
78601
78602
78603
78604
78605
78606
78607
78608
78609
78610
78611
78612
78613
78614
78615
78616
78617
78618
78619
78620
78621
78622
78623
78624
78625
78626
78627
78628
78629
78630
78631
78632
78633
78634
78635
78636
78637
78638
78639
78640
78641
78642
78643
78644
78645
78646
78647
78648
78649
78650
78651
78652
78653
78654
78655
78656
78657
78658
78659
78660
78661
78662
78663
78664
78665
78666
78667
78668
78669
78670
78671
78672
78673
78674
78675
78676
78677
78678
78679
78680
78681
78682
78683
78684
78685
78686
78687
78688
78689
78690
78691
78692
78693
78694
78695
78696
78697
78698
78699
78700
78701
78702
78703
78704
78705
78706
78707
78708
78709
78710
78711
78712
78713
78714
78715
78716
78717
78718
78719
78720
78721
78722
78723
78724
78725
78726
78727
78728
78729
78730
78731
78732
78733
78734
78735
78736
78737
78738
78739
78740
78741
78742
78743
78744
78745
78746
78747
78748
78749
78750
78751
78752
78753
78754
78755
78756
78757
78758
78759
78760
78761
78762
78763
78764
78765
78766
78767
78768
78769
78770
78771
78772
78773
78774
78775
78776
78777
78778
78779
78780
78781
78782
78783
78784
78785
78786
78787
78788
78789
78790
78791
78792
78793
78794
78795
78796
78797
78798
78799
78800
78801
78802
78803
78804
78805
78806
78807
78808
78809
78810
78811
78812
78813
78814
78815
78816
78817
78818
78819
78820
78821
78822
78823
78824
78825
78826
78827
78828
78829
78830
78831
78832
78833
78834
78835
78836
78837
78838
78839
78840
78841
78842
78843
78844
78845
78846
78847
78848
78849
78850
78851
78852
78853
78854
78855
78856
78857
78858
78859
78860
78861
78862
78863
78864
78865
78866
78867
78868
78869
78870
78871
78872
78873
78874
78875
78876
78877
78878
78879
78880
78881
78882
78883
78884
78885
78886
78887
78888
78889
78890
78891
78892
78893
78894
78895
78896
78897
78898
78899
78900
78901
78902
78903
78904
78905
78906
78907
78908
78909
78910
78911
78912
78913
78914
78915
78916
78917
78918
78919
78920
78921
78922
78923
78924
78925
78926
78927
78928
78929
78930
78931
78932
78933
78934
78935
78936
78937
78938
78939
78940
78941
78942
78943
78944
78945
78946
78947
78948
78949
78950
78951
78952
78953
78954
78955
78956
78957
78958
78959
78960
78961
78962
78963
78964
78965
78966
78967
78968
78969
78970
78971
78972
78973
78974
78975
78976
78977
78978
78979
78980
78981
78982
78983
78984
78985
78986
78987
78988
78989
78990
78991
78992
78993
78994
78995
78996
78997
78998
78999
79000
79001
79002
79003
79004
79005
79006
79007
79008
79009
79010
79011
79012
79013
79014
79015
79016
79017
79018
79019
79020
79021
79022
79023
79024
79025
79026
79027
79028
79029
79030
79031
79032
79033
79034
79035
79036
79037
79038
79039
79040
79041
79042
79043
79044
79045
79046
79047
79048
79049
79050
79051
79052
79053
79054
79055
79056
79057
79058
79059
79060
79061
79062
79063
79064
79065
79066
79067
79068
79069
79070
79071
79072
79073
79074
79075
79076
79077
79078
79079
79080
79081
79082
79083
79084
79085
79086
79087
79088
79089
79090
79091
79092
79093
79094
79095
79096
79097
79098
79099
79100
79101
79102
79103
79104
79105
79106
79107
79108
79109
79110
79111
79112
79113
79114
79115
79116
79117
79118
79119
79120
79121
79122
79123
79124
79125
79126
79127
79128
79129
79130
79131
79132
79133
79134
79135
79136
79137
79138
79139
79140
79141
79142
79143
79144
79145
79146
79147
79148
79149
79150
79151
79152
79153
79154
79155
79156
79157
79158
79159
79160
79161
79162
79163
79164
79165
79166
79167
79168
79169
79170
79171
79172
79173
79174
79175
79176
79177
79178
79179
79180
79181
79182
79183
79184
79185
79186
79187
79188
79189
79190
79191
79192
79193
79194
79195
79196
79197
79198
79199
79200
79201
79202
79203
79204
79205
79206
79207
79208
79209
79210
79211
79212
79213
79214
79215
79216
79217
79218
79219
79220
79221
79222
79223
79224
79225
79226
79227
79228
79229
79230
79231
79232
79233
79234
79235
79236
79237
79238
79239
79240
79241
79242
79243
79244
79245
79246
79247
79248
79249
79250
79251
79252
79253
79254
79255
79256
79257
79258
79259
79260
79261
79262
79263
79264
79265
79266
79267
79268
79269
79270
79271
79272
79273
79274
79275
79276
79277
79278
79279
79280
79281
79282
79283
79284
79285
79286
79287
79288
79289
79290
79291
79292
79293
79294
79295
79296
79297
79298
79299
79300
79301
79302
79303
79304
79305
79306
79307
79308
79309
79310
79311
79312
79313
79314
79315
79316
79317
79318
79319
79320
79321
79322
79323
79324
79325
79326
79327
79328
79329
79330
79331
79332
79333
79334
79335
79336
79337
79338
79339
79340
79341
79342
79343
79344
79345
79346
79347
79348
79349
79350
79351
79352
79353
79354
79355
79356
79357
79358
79359
79360
79361
79362
79363
79364
79365
79366
79367
79368
79369
79370
79371
79372
79373
79374
79375
79376
79377
79378
79379
79380
79381
79382
79383
79384
79385
79386
79387
79388
79389
79390
79391
79392
79393
79394
79395
79396
79397
79398
79399
79400
79401
79402
79403
79404
79405
79406
79407
79408
79409
79410
79411
79412
79413
79414
79415
79416
79417
79418
79419
79420
79421
79422
79423
79424
79425
79426
79427
79428
79429
79430
79431
79432
79433
79434
79435
79436
79437
79438
79439
79440
79441
79442
79443
79444
79445
79446
79447
79448
79449
79450
79451
79452
79453
79454
79455
79456
79457
79458
79459
79460
79461
79462
79463
79464
79465
79466
79467
79468
79469
79470
79471
79472
79473
79474
79475
79476
79477
79478
79479
79480
79481
79482
79483
79484
79485
79486
79487
79488
79489
79490
79491
79492
79493
79494
79495
79496
79497
79498
79499
79500
79501
79502
79503
79504
79505
79506
79507
79508
79509
79510
79511
79512
79513
79514
79515
79516
79517
79518
79519
79520
79521
79522
79523
79524
79525
79526
79527
79528
79529
79530
79531
79532
79533
79534
79535
79536
79537
79538
79539
79540
79541
79542
79543
79544
79545
79546
79547
79548
79549
79550
79551
79552
79553
79554
79555
79556
79557
79558
79559
79560
79561
79562
79563
79564
79565
79566
79567
79568
79569
79570
79571
79572
79573
79574
79575
79576
79577
79578
79579
79580
79581
79582
79583
79584
79585
79586
79587
79588
79589
79590
79591
79592
79593
79594
79595
79596
79597
79598
79599
79600
79601
79602
79603
79604
79605
79606
79607
79608
79609
79610
79611
79612
79613
79614
79615
79616
79617
79618
79619
79620
79621
79622
79623
79624
79625
79626
79627
79628
79629
79630
79631
79632
79633
79634
79635
79636
79637
79638
79639
79640
79641
79642
79643
79644
79645
79646
79647
79648
79649
79650
79651
79652
79653
79654
79655
79656
79657
79658
79659
79660
79661
79662
79663
79664
79665
79666
79667
79668
79669
79670
79671
79672
79673
79674
79675
79676
79677
79678
79679
79680
79681
79682
79683
79684
79685
79686
79687
79688
79689
79690
79691
79692
79693
79694
79695
79696
79697
79698
79699
79700
79701
79702
79703
79704
79705
79706
79707
79708
79709
79710
79711
79712
79713
79714
79715
79716
79717
79718
79719
79720
79721
79722
79723
79724
79725
79726
79727
79728
79729
79730
79731
79732
79733
79734
79735
79736
79737
79738
79739
79740
79741
79742
79743
79744
79745
79746
79747
79748
79749
79750
79751
79752
79753
79754
79755
79756
79757
79758
79759
79760
79761
79762
79763
79764
79765
79766
79767
79768
79769
79770
79771
79772
79773
79774
79775
79776
79777
79778
79779
79780
79781
79782
79783
79784
79785
79786
79787
79788
79789
79790
79791
79792
79793
79794
79795
79796
79797
79798
79799
79800
79801
79802
79803
79804
79805
79806
79807
79808
79809
79810
79811
79812
79813
79814
79815
79816
79817
79818
79819
79820
79821
79822
79823
79824
79825
79826
79827
79828
79829
79830
79831
79832
79833
79834
79835
79836
79837
79838
79839
79840
79841
79842
79843
79844
79845
79846
79847
79848
79849
79850
79851
79852
79853
79854
79855
79856
79857
79858
79859
79860
79861
79862
79863
79864
79865
79866
79867
79868
79869
79870
79871
79872
79873
79874
79875
79876
79877
79878
79879
79880
79881
79882
79883
79884
79885
79886
79887
79888
79889
79890
79891
79892
79893
79894
79895
79896
79897
79898
79899
79900
79901
79902
79903
79904
79905
79906
79907
79908
79909
79910
79911
79912
79913
79914
79915
79916
79917
79918
79919
79920
79921
79922
79923
79924
79925
79926
79927
79928
79929
79930
79931
79932
79933
79934
79935
79936
79937
79938
79939
79940
79941
79942
79943
79944
79945
79946
79947
79948
79949
79950
79951
79952
79953
79954
79955
79956
79957
79958
79959
79960
79961
79962
79963
79964
79965
79966
79967
79968
79969
79970
79971
79972
79973
79974
79975
79976
79977
79978
79979
79980
79981
79982
79983
79984
79985
79986
79987
79988
79989
79990
79991
79992
79993
79994
79995
79996
79997
79998
79999
80000
80001
80002
80003
80004
80005
80006
80007
80008
80009
80010
80011
80012
80013
80014
80015
80016
80017
80018
80019
80020
80021
80022
80023
80024
80025
80026
80027
80028
80029
80030
80031
80032
80033
80034
80035
80036
80037
80038
80039
80040
80041
80042
80043
80044
80045
80046
80047
80048
80049
80050
80051
80052
80053
80054
80055
80056
80057
80058
80059
80060
80061
80062
80063
80064
80065
80066
80067
80068
80069
80070
80071
80072
80073
80074
80075
80076
80077
80078
80079
80080
80081
80082
80083
80084
80085
80086
80087
80088
80089
80090
80091
80092
80093
80094
80095
80096
80097
80098
80099
80100
80101
80102
80103
80104
80105
80106
80107
80108
80109
80110
80111
80112
80113
80114
80115
80116
80117
80118
80119
80120
80121
80122
80123
80124
80125
80126
80127
80128
80129
80130
80131
80132
80133
80134
80135
80136
80137
80138
80139
80140
80141
80142
80143
80144
80145
80146
80147
80148
80149
80150
80151
80152
80153
80154
80155
80156
80157
80158
80159
80160
80161
80162
80163
80164
80165
80166
80167
80168
80169
80170
80171
80172
80173
80174
80175
80176
80177
80178
80179
80180
80181
80182
80183
80184
80185
80186
80187
80188
80189
80190
80191
80192
80193
80194
80195
80196
80197
80198
80199
80200
80201
80202
80203
80204
80205
80206
80207
80208
80209
80210
80211
80212
80213
80214
80215
80216
80217
80218
80219
80220
80221
80222
80223
80224
80225
80226
80227
80228
80229
80230
80231
80232
80233
80234
80235
80236
80237
80238
80239
80240
80241
80242
80243
80244
80245
80246
80247
80248
80249
80250
80251
80252
80253
80254
80255
80256
80257
80258
80259
80260
80261
80262
80263
80264
80265
80266
80267
80268
80269
80270
80271
80272
80273
80274
80275
80276
80277
80278
80279
80280
80281
80282
80283
80284
80285
80286
80287
80288
80289
80290
80291
80292
80293
80294
80295
80296
80297
80298
80299
80300
80301
80302
80303
80304
80305
80306
80307
80308
80309
80310
80311
80312
80313
80314
80315
80316
80317
80318
80319
80320
80321
80322
80323
80324
80325
80326
80327
80328
80329
80330
80331
80332
80333
80334
80335
80336
80337
80338
80339
80340
80341
80342
80343
80344
80345
80346
80347
80348
80349
80350
80351
80352
80353
80354
80355
80356
80357
80358
80359
80360
80361
80362
80363
80364
80365
80366
80367
80368
80369
80370
80371
80372
80373
80374
80375
80376
80377
80378
80379
80380
80381
80382
80383
80384
80385
80386
80387
80388
80389
80390
80391
80392
80393
80394
80395
80396
80397
80398
80399
80400
80401
80402
80403
80404
80405
80406
80407
80408
80409
80410
80411
80412
80413
80414
80415
80416
80417
80418
80419
80420
80421
80422
80423
80424
80425
80426
80427
80428
80429
80430
80431
80432
80433
80434
80435
80436
80437
80438
80439
80440
80441
80442
80443
80444
80445
80446
80447
80448
80449
80450
80451
80452
80453
80454
80455
80456
80457
80458
80459
80460
80461
80462
80463
80464
80465
80466
80467
80468
80469
80470
80471
80472
80473
80474
80475
80476
80477
80478
80479
80480
80481
80482
80483
80484
80485
80486
80487
80488
80489
80490
80491
80492
80493
80494
80495
80496
80497
80498
80499
80500
80501
80502
80503
80504
80505
80506
80507
80508
80509
80510
80511
80512
80513
80514
80515
80516
80517
80518
80519
80520
80521
80522
80523
80524
80525
80526
80527
80528
80529
80530
80531
80532
80533
80534
80535
80536
80537
80538
80539
80540
80541
80542
80543
80544
80545
80546
80547
80548
80549
80550
80551
80552
80553
80554
80555
80556
80557
80558
80559
80560
80561
80562
80563
80564
80565
80566
80567
80568
80569
80570
80571
80572
80573
80574
80575
80576
80577
80578
80579
80580
80581
80582
80583
80584
80585
80586
80587
80588
80589
80590
80591
80592
80593
80594
80595
80596
80597
80598
80599
80600
80601
80602
80603
80604
80605
80606
80607
80608
80609
80610
80611
80612
80613
80614
80615
80616
80617
80618
80619
80620
80621
80622
80623
80624
80625
80626
80627
80628
80629
80630
80631
80632
80633
80634
80635
80636
80637
80638
80639
80640
80641
80642
80643
80644
80645
80646
80647
80648
80649
80650
80651
80652
80653
80654
80655
80656
80657
80658
80659
80660
80661
80662
80663
80664
80665
80666
80667
80668
80669
80670
80671
80672
80673
80674
80675
80676
80677
80678
80679
80680
80681
80682
80683
80684
80685
80686
80687
80688
80689
80690
80691
80692
80693
80694
80695
80696
80697
80698
80699
80700
80701
80702
80703
80704
80705
80706
80707
80708
80709
80710
80711
80712
80713
80714
80715
80716
80717
80718
80719
80720
80721
80722
80723
80724
80725
80726
80727
80728
80729
80730
80731
80732
80733
80734
80735
80736
80737
80738
80739
80740
80741
80742
80743
80744
80745
80746
80747
80748
80749
80750
80751
80752
80753
80754
80755
80756
80757
80758
80759
80760
80761
80762
80763
80764
80765
80766
80767
80768
80769
80770
80771
80772
80773
80774
80775
80776
80777
80778
80779
80780
80781
80782
80783
80784
80785
80786
80787
80788
80789
80790
80791
80792
80793
80794
80795
80796
80797
80798
80799
80800
80801
80802
80803
80804
80805
80806
80807
80808
80809
80810
80811
80812
80813
80814
80815
80816
80817
80818
80819
80820
80821
80822
80823
80824
80825
80826
80827
80828
80829
80830
80831
80832
80833
80834
80835
80836
80837
80838
80839
80840
80841
80842
80843
80844
80845
80846
80847
80848
80849
80850
80851
80852
80853
80854
80855
80856
80857
80858
80859
80860
80861
80862
80863
80864
80865
80866
80867
80868
80869
80870
80871
80872
80873
80874
80875
80876
80877
80878
80879
80880
80881
80882
80883
80884
80885
80886
80887
80888
80889
80890
80891
80892
80893
80894
80895
80896
80897
80898
80899
80900
80901
80902
80903
80904
80905
80906
80907
80908
80909
80910
80911
80912
80913
80914
80915
80916
80917
80918
80919
80920
80921
80922
80923
80924
80925
80926
80927
80928
80929
80930
80931
80932
80933
80934
80935
80936
80937
80938
80939
80940
80941
80942
80943
80944
80945
80946
80947
80948
80949
80950
80951
80952
80953
80954
80955
80956
80957
80958
80959
80960
80961
80962
80963
80964
80965
80966
80967
80968
80969
80970
80971
80972
80973
80974
80975
80976
80977
80978
80979
80980
80981
80982
80983
80984
80985
80986
80987
80988
80989
80990
80991
80992
80993
80994
80995
80996
80997
80998
80999
81000
81001
81002
81003
81004
81005
81006
81007
81008
81009
81010
81011
81012
81013
81014
81015
81016
81017
81018
81019
81020
81021
81022
81023
81024
81025
81026
81027
81028
81029
81030
81031
81032
81033
81034
81035
81036
81037
81038
81039
81040
81041
81042
81043
81044
81045
81046
81047
81048
81049
81050
81051
81052
81053
81054
81055
81056
81057
81058
81059
81060
81061
81062
81063
81064
81065
81066
81067
81068
81069
81070
81071
81072
81073
81074
81075
81076
81077
81078
81079
81080
81081
81082
81083
81084
81085
81086
81087
81088
81089
81090
81091
81092
81093
81094
81095
81096
81097
81098
81099
81100
81101
81102
81103
81104
81105
81106
81107
81108
81109
81110
81111
81112
81113
81114
81115
81116
81117
81118
81119
81120
81121
81122
81123
81124
81125
81126
81127
81128
81129
81130
81131
81132
81133
81134
81135
81136
81137
81138
81139
81140
81141
81142
81143
81144
81145
81146
81147
81148
81149
81150
81151
81152
81153
81154
81155
81156
81157
81158
81159
81160
81161
81162
81163
81164
81165
81166
81167
81168
81169
81170
81171
81172
81173
81174
81175
81176
81177
81178
81179
81180
81181
81182
81183
81184
81185
81186
81187
81188
81189
81190
81191
81192
81193
81194
81195
81196
81197
81198
81199
81200
81201
81202
81203
81204
81205
81206
81207
81208
81209
81210
81211
81212
81213
81214
81215
81216
81217
81218
81219
81220
81221
81222
81223
81224
81225
81226
81227
81228
81229
81230
81231
81232
81233
81234
81235
81236
81237
81238
81239
81240
81241
81242
81243
81244
81245
81246
81247
81248
81249
81250
81251
81252
81253
81254
81255
81256
81257
81258
81259
81260
81261
81262
81263
81264
81265
81266
81267
81268
81269
81270
81271
81272
81273
81274
81275
81276
81277
81278
81279
81280
81281
81282
81283
81284
81285
81286
81287
81288
81289
81290
81291
81292
81293
81294
81295
81296
81297
81298
81299
81300
81301
81302
81303
81304
81305
81306
81307
81308
81309
81310
81311
81312
81313
81314
81315
81316
81317
81318
81319
81320
81321
81322
81323
81324
81325
81326
81327
81328
81329
81330
81331
81332
81333
81334
81335
81336
81337
81338
81339
81340
81341
81342
81343
81344
81345
81346
81347
81348
81349
81350
81351
81352
81353
81354
81355
81356
81357
81358
81359
81360
81361
81362
81363
81364
81365
81366
81367
81368
81369
81370
81371
81372
81373
81374
81375
81376
81377
81378
81379
81380
81381
81382
81383
81384
81385
81386
81387
81388
81389
81390
81391
81392
81393
81394
81395
81396
81397
81398
81399
81400
81401
81402
81403
81404
81405
81406
81407
81408
81409
81410
81411
81412
81413
81414
81415
81416
81417
81418
81419
81420
81421
81422
81423
81424
81425
81426
81427
81428
81429
81430
81431
81432
81433
81434
81435
81436
81437
81438
81439
81440
81441
81442
81443
81444
81445
81446
81447
81448
81449
81450
81451
81452
81453
81454
81455
81456
81457
81458
81459
81460
81461
81462
81463
81464
81465
81466
81467
81468
81469
81470
81471
81472
81473
81474
81475
81476
81477
81478
81479
81480
81481
81482
81483
81484
81485
81486
81487
81488
81489
81490
81491
81492
81493
81494
81495
81496
81497
81498
81499
81500
81501
81502
81503
81504
81505
81506
81507
81508
81509
81510
81511
81512
81513
81514
81515
81516
81517
81518
81519
81520
81521
81522
81523
81524
81525
81526
81527
81528
81529
81530
81531
81532
81533
81534
81535
81536
81537
81538
81539
81540
81541
81542
81543
81544
81545
81546
81547
81548
81549
81550
81551
81552
81553
81554
81555
81556
81557
81558
81559
81560
81561
81562
81563
81564
81565
81566
81567
81568
81569
81570
81571
81572
81573
81574
81575
81576
81577
81578
81579
81580
81581
81582
81583
81584
81585
81586
81587
81588
81589
81590
81591
81592
81593
81594
81595
81596
81597
81598
81599
81600
81601
81602
81603
81604
81605
81606
81607
81608
81609
81610
81611
81612
81613
81614
81615
81616
81617
81618
81619
81620
81621
81622
81623
81624
81625
81626
81627
81628
81629
81630
81631
81632
81633
81634
81635
81636
81637
81638
81639
81640
81641
81642
81643
81644
81645
81646
81647
81648
81649
81650
81651
81652
81653
81654
81655
81656
81657
81658
81659
81660
81661
81662
81663
81664
81665
81666
81667
81668
81669
81670
81671
81672
81673
81674
81675
81676
81677
81678
81679
81680
81681
81682
81683
81684
81685
81686
81687
81688
81689
81690
81691
81692
81693
81694
81695
81696
81697
81698
81699
81700
81701
81702
81703
81704
81705
81706
81707
81708
81709
81710
81711
81712
81713
81714
81715
81716
81717
81718
81719
81720
81721
81722
81723
81724
81725
81726
81727
81728
81729
81730
81731
81732
81733
81734
81735
81736
81737
81738
81739
81740
81741
81742
81743
81744
81745
81746
81747
81748
81749
81750
81751
81752
81753
81754
81755
81756
81757
81758
81759
81760
81761
81762
81763
81764
81765
81766
81767
81768
81769
81770
81771
81772
81773
81774
81775
81776
81777
81778
81779
81780
81781
81782
81783
81784
81785
81786
81787
81788
81789
81790
81791
81792
81793
81794
81795
81796
81797
81798
81799
81800
81801
81802
81803
81804
81805
81806
81807
81808
81809
81810
81811
81812
81813
81814
81815
81816
81817
81818
81819
81820
81821
81822
81823
81824
81825
81826
81827
81828
81829
81830
81831
81832
81833
81834
81835
81836
81837
81838
81839
81840
81841
81842
81843
81844
81845
81846
81847
81848
81849
81850
81851
81852
81853
81854
81855
81856
81857
81858
81859
81860
81861
81862
81863
81864
81865
81866
81867
81868
81869
81870
81871
81872
81873
81874
81875
81876
81877
81878
81879
81880
81881
81882
81883
81884
81885
81886
81887
81888
81889
81890
81891
81892
81893
81894
81895
81896
81897
81898
81899
81900
81901
81902
81903
81904
81905
81906
81907
81908
81909
81910
81911
81912
81913
81914
81915
81916
81917
81918
81919
81920
81921
81922
81923
81924
81925
81926
81927
81928
81929
81930
81931
81932
81933
81934
81935
81936
81937
81938
81939
81940
81941
81942
81943
81944
81945
81946
81947
81948
81949
81950
81951
81952
81953
81954
81955
81956
81957
81958
81959
81960
81961
81962
81963
81964
81965
81966
81967
81968
81969
81970
81971
81972
81973
81974
81975
81976
81977
81978
81979
81980
81981
81982
81983
81984
81985
81986
81987
81988
81989
81990
81991
81992
81993
81994
81995
81996
81997
81998
81999
82000
82001
82002
82003
82004
82005
82006
82007
82008
82009
82010
82011
82012
82013
82014
82015
82016
82017
82018
82019
82020
82021
82022
82023
82024
82025
82026
82027
82028
82029
82030
82031
82032
82033
82034
82035
82036
82037
82038
82039
82040
82041
82042
82043
82044
82045
82046
82047
82048
82049
82050
82051
82052
82053
82054
82055
82056
82057
82058
82059
82060
82061
82062
82063
82064
82065
82066
82067
82068
82069
82070
82071
82072
82073
82074
82075
82076
82077
82078
82079
82080
82081
82082
82083
82084
82085
82086
82087
82088
82089
82090
82091
82092
82093
82094
82095
82096
82097
82098
82099
82100
82101
82102
82103
82104
82105
82106
82107
82108
82109
82110
82111
82112
82113
82114
82115
82116
82117
82118
82119
82120
82121
82122
82123
82124
82125
82126
82127
82128
82129
82130
82131
82132
82133
82134
82135
82136
82137
82138
82139
82140
82141
82142
82143
82144
82145
82146
82147
82148
82149
82150
82151
82152
82153
82154
82155
82156
82157
82158
82159
82160
82161
82162
82163
82164
82165
82166
82167
82168
82169
82170
82171
82172
82173
82174
82175
82176
82177
82178
82179
82180
82181
82182
82183
82184
82185
82186
82187
82188
82189
82190
82191
82192
82193
82194
82195
82196
82197
82198
82199
82200
82201
82202
82203
82204
82205
82206
82207
82208
82209
82210
82211
82212
82213
82214
82215
82216
82217
82218
82219
82220
82221
82222
82223
82224
82225
82226
82227
82228
82229
82230
82231
82232
82233
82234
82235
82236
82237
82238
82239
82240
82241
82242
82243
82244
82245
82246
82247
82248
82249
82250
82251
82252
82253
82254
82255
82256
82257
82258
82259
82260
82261
82262
82263
82264
82265
82266
82267
82268
82269
82270
82271
82272
82273
82274
82275
82276
82277
82278
82279
82280
82281
82282
82283
82284
82285
82286
82287
82288
82289
82290
82291
82292
82293
82294
82295
82296
82297
82298
82299
82300
82301
82302
82303
82304
82305
82306
82307
82308
82309
82310
82311
82312
82313
82314
82315
82316
82317
82318
82319
82320
82321
82322
82323
82324
82325
82326
82327
82328
82329
82330
82331
82332
82333
82334
82335
82336
82337
82338
82339
82340
82341
82342
82343
82344
82345
82346
82347
82348
82349
82350
82351
82352
82353
82354
82355
82356
82357
82358
82359
82360
82361
82362
82363
82364
82365
82366
82367
82368
82369
82370
82371
82372
82373
82374
82375
82376
82377
82378
82379
82380
82381
82382
82383
82384
82385
82386
82387
82388
82389
82390
82391
82392
82393
82394
82395
82396
82397
82398
82399
82400
82401
82402
82403
82404
82405
82406
82407
82408
82409
82410
82411
82412
82413
82414
82415
82416
82417
82418
82419
82420
82421
82422
82423
82424
82425
82426
82427
82428
82429
82430
82431
82432
82433
82434
82435
82436
82437
82438
82439
82440
82441
82442
82443
82444
82445
82446
82447
82448
82449
82450
82451
82452
82453
82454
82455
82456
82457
82458
82459
82460
82461
82462
82463
82464
82465
82466
82467
82468
82469
82470
82471
82472
82473
82474
82475
82476
82477
82478
82479
82480
82481
82482
82483
82484
82485
82486
82487
82488
82489
82490
82491
82492
82493
82494
82495
82496
82497
82498
82499
82500
82501
82502
82503
82504
82505
82506
82507
82508
82509
82510
82511
82512
82513
82514
82515
82516
82517
82518
82519
82520
82521
82522
82523
82524
82525
82526
82527
82528
82529
82530
82531
82532
82533
82534
82535
82536
82537
82538
82539
82540
82541
82542
82543
82544
82545
82546
82547
82548
82549
82550
82551
82552
82553
82554
82555
82556
82557
82558
82559
82560
82561
82562
82563
82564
82565
82566
82567
82568
82569
82570
82571
82572
82573
82574
82575
82576
82577
82578
82579
82580
82581
82582
82583
82584
82585
82586
82587
82588
82589
82590
82591
82592
82593
82594
82595
82596
82597
82598
82599
82600
82601
82602
82603
82604
82605
82606
82607
82608
82609
82610
82611
82612
82613
82614
82615
82616
82617
82618
82619
82620
82621
82622
82623
82624
82625
82626
82627
82628
82629
82630
82631
82632
82633
82634
82635
82636
82637
82638
82639
82640
82641
82642
82643
82644
82645
82646
82647
82648
82649
82650
82651
82652
82653
82654
82655
82656
82657
82658
82659
82660
82661
82662
82663
82664
82665
82666
82667
82668
82669
82670
82671
82672
82673
82674
82675
82676
82677
82678
82679
82680
82681
82682
82683
82684
82685
82686
82687
82688
82689
82690
82691
82692
82693
82694
82695
82696
82697
82698
82699
82700
82701
82702
82703
82704
82705
82706
82707
82708
82709
82710
82711
82712
82713
82714
82715
82716
82717
82718
82719
82720
82721
82722
82723
82724
82725
82726
82727
82728
82729
82730
82731
82732
82733
82734
82735
82736
82737
82738
82739
82740
82741
82742
82743
82744
82745
82746
82747
82748
82749
82750
82751
82752
82753
82754
82755
82756
82757
82758
82759
82760
82761
82762
82763
82764
82765
82766
82767
82768
82769
82770
82771
82772
82773
82774
82775
82776
82777
82778
82779
82780
82781
82782
82783
82784
82785
82786
82787
82788
82789
82790
82791
82792
82793
82794
82795
82796
82797
82798
82799
82800
82801
82802
82803
82804
82805
82806
82807
82808
82809
82810
82811
82812
82813
82814
82815
82816
82817
82818
82819
82820
82821
82822
82823
82824
82825
82826
82827
82828
82829
82830
82831
82832
82833
82834
82835
82836
82837
82838
82839
82840
82841
82842
82843
82844
82845
82846
82847
82848
82849
82850
82851
82852
82853
82854
82855
82856
82857
82858
82859
82860
82861
82862
82863
82864
82865
82866
82867
82868
82869
82870
82871
82872
82873
82874
82875
82876
82877
82878
82879
82880
82881
82882
82883
82884
82885
82886
82887
82888
82889
82890
82891
82892
82893
82894
82895
82896
82897
82898
82899
82900
82901
82902
82903
82904
82905
82906
82907
82908
82909
82910
82911
82912
82913
82914
82915
82916
82917
82918
82919
82920
82921
82922
82923
82924
82925
82926
82927
82928
82929
82930
82931
82932
82933
82934
82935
82936
82937
82938
82939
82940
82941
82942
82943
82944
82945
82946
82947
82948
82949
82950
82951
82952
82953
82954
82955
82956
82957
82958
82959
82960
82961
82962
82963
82964
82965
82966
82967
82968
82969
82970
82971
82972
82973
82974
82975
82976
82977
82978
82979
82980
82981
82982
82983
82984
82985
82986
82987
82988
82989
82990
82991
82992
82993
82994
82995
82996
82997
82998
82999
83000
83001
83002
83003
83004
83005
83006
83007
83008
83009
83010
83011
83012
83013
83014
83015
83016
83017
83018
83019
83020
83021
83022
83023
83024
83025
83026
83027
83028
83029
83030
83031
83032
83033
83034
83035
83036
83037
83038
83039
83040
83041
83042
83043
83044
83045
83046
83047
83048
83049
83050
83051
83052
83053
83054
83055
83056
83057
83058
83059
83060
83061
83062
83063
83064
83065
83066
83067
83068
83069
83070
83071
83072
83073
83074
83075
83076
83077
83078
83079
83080
83081
83082
83083
83084
83085
83086
83087
83088
83089
83090
83091
83092
83093
83094
83095
83096
83097
83098
83099
83100
83101
83102
83103
83104
83105
83106
83107
83108
83109
83110
83111
83112
83113
83114
83115
83116
83117
83118
83119
83120
83121
83122
83123
83124
83125
83126
83127
83128
83129
83130
83131
83132
83133
83134
83135
83136
83137
83138
83139
83140
83141
83142
83143
83144
83145
83146
83147
83148
83149
83150
83151
83152
83153
83154
83155
83156
83157
83158
83159
83160
83161
83162
83163
83164
83165
83166
83167
83168
83169
83170
83171
83172
83173
83174
83175
83176
83177
83178
83179
83180
83181
83182
83183
83184
83185
83186
83187
83188
83189
83190
83191
83192
83193
83194
83195
83196
83197
83198
83199
83200
83201
83202
83203
83204
83205
83206
83207
83208
83209
83210
83211
83212
83213
83214
83215
83216
83217
83218
83219
83220
83221
83222
83223
83224
83225
83226
83227
83228
83229
83230
83231
83232
83233
83234
83235
83236
83237
83238
83239
83240
83241
83242
83243
83244
83245
83246
83247
83248
83249
83250
83251
83252
83253
83254
83255
83256
83257
83258
83259
83260
83261
83262
83263
83264
83265
83266
83267
83268
83269
83270
83271
83272
83273
83274
83275
83276
83277
83278
83279
83280
83281
83282
83283
83284
83285
83286
83287
83288
83289
83290
83291
83292
83293
83294
83295
83296
83297
83298
83299
83300
83301
83302
83303
83304
83305
83306
83307
83308
83309
83310
83311
83312
83313
83314
83315
83316
83317
83318
83319
83320
83321
83322
83323
83324
83325
83326
83327
83328
83329
83330
83331
83332
83333
83334
83335
83336
83337
83338
83339
83340
83341
83342
83343
83344
83345
83346
83347
83348
83349
83350
83351
83352
83353
83354
83355
83356
83357
83358
83359
83360
83361
83362
83363
83364
83365
83366
83367
83368
83369
83370
83371
83372
83373
83374
83375
83376
83377
83378
83379
83380
83381
83382
83383
83384
83385
83386
83387
83388
83389
83390
83391
83392
83393
83394
83395
83396
83397
83398
83399
83400
83401
83402
83403
83404
83405
83406
83407
83408
83409
83410
83411
83412
83413
83414
83415
83416
83417
83418
83419
83420
83421
83422
83423
83424
83425
83426
83427
83428
83429
83430
83431
83432
83433
83434
83435
83436
83437
83438
83439
83440
83441
83442
83443
83444
83445
83446
83447
83448
83449
83450
83451
83452
83453
83454
83455
83456
83457
83458
83459
83460
83461
83462
83463
83464
83465
83466
83467
83468
83469
83470
83471
83472
83473
83474
83475
83476
83477
83478
83479
83480
83481
83482
83483
83484
83485
83486
83487
83488
83489
83490
83491
83492
83493
83494
83495
83496
83497
83498
83499
83500
83501
83502
83503
83504
83505
83506
83507
83508
83509
83510
83511
83512
83513
83514
83515
83516
83517
83518
83519
83520
83521
83522
83523
83524
83525
83526
83527
83528
83529
83530
83531
83532
83533
83534
83535
83536
83537
83538
83539
83540
83541
83542
83543
83544
83545
83546
83547
83548
83549
83550
83551
83552
83553
83554
83555
83556
83557
83558
83559
83560
83561
83562
83563
83564
83565
83566
83567
83568
83569
83570
83571
83572
83573
83574
83575
83576
83577
83578
83579
83580
83581
83582
83583
83584
83585
83586
83587
83588
83589
83590
83591
83592
83593
83594
83595
83596
83597
83598
83599
83600
83601
83602
83603
83604
83605
83606
83607
83608
83609
83610
83611
83612
83613
83614
83615
83616
83617
83618
83619
83620
83621
83622
83623
83624
83625
83626
83627
83628
83629
83630
83631
83632
83633
83634
83635
83636
83637
83638
83639
83640
83641
83642
83643
83644
83645
83646
83647
83648
83649
83650
83651
83652
83653
83654
83655
83656
83657
83658
83659
83660
83661
83662
83663
83664
83665
83666
83667
83668
83669
83670
83671
83672
83673
83674
83675
83676
83677
83678
83679
83680
83681
83682
83683
83684
83685
83686
83687
83688
83689
83690
83691
83692
83693
83694
83695
83696
83697
83698
83699
83700
83701
83702
83703
83704
83705
83706
83707
83708
83709
83710
83711
83712
83713
83714
83715
83716
83717
83718
83719
83720
83721
83722
83723
83724
83725
83726
83727
83728
83729
83730
83731
83732
83733
83734
83735
83736
83737
83738
83739
83740
83741
83742
83743
83744
83745
83746
83747
83748
83749
83750
83751
83752
83753
83754
83755
83756
83757
83758
83759
83760
83761
83762
83763
83764
83765
83766
83767
83768
83769
83770
83771
83772
83773
83774
83775
83776
83777
83778
83779
83780
83781
83782
83783
83784
83785
83786
83787
83788
83789
83790
83791
83792
83793
83794
83795
83796
83797
83798
83799
83800
83801
83802
83803
83804
83805
83806
83807
83808
83809
83810
83811
83812
83813
83814
83815
83816
83817
83818
83819
83820
83821
83822
83823
83824
83825
83826
83827
83828
83829
83830
83831
83832
83833
83834
83835
83836
83837
83838
83839
83840
83841
83842
83843
83844
83845
83846
83847
83848
83849
83850
83851
83852
83853
83854
83855
83856
83857
83858
83859
83860
83861
83862
83863
83864
83865
83866
83867
83868
83869
83870
83871
83872
83873
83874
83875
83876
83877
83878
83879
83880
83881
83882
83883
83884
83885
83886
83887
83888
83889
83890
83891
83892
83893
83894
83895
83896
83897
83898
83899
83900
83901
83902
83903
83904
83905
83906
83907
83908
83909
83910
83911
83912
83913
83914
83915
83916
83917
83918
83919
83920
83921
83922
83923
83924
83925
83926
83927
83928
83929
83930
83931
83932
83933
83934
83935
83936
83937
83938
83939
83940
83941
83942
83943
83944
83945
83946
83947
83948
83949
83950
83951
83952
83953
83954
83955
83956
83957
83958
83959
83960
83961
83962
83963
83964
83965
83966
83967
83968
83969
83970
83971
83972
83973
83974
83975
83976
83977
83978
83979
83980
83981
83982
83983
83984
83985
83986
83987
83988
83989
83990
83991
83992
83993
83994
83995
83996
83997
83998
83999
84000
84001
84002
84003
84004
84005
84006
84007
84008
84009
84010
84011
84012
84013
84014
84015
84016
84017
84018
84019
84020
84021
84022
84023
84024
84025
84026
84027
84028
84029
84030
84031
84032
84033
84034
84035
84036
84037
84038
84039
84040
84041
84042
84043
84044
84045
84046
84047
84048
84049
84050
84051
84052
84053
84054
84055
84056
84057
84058
84059
84060
84061
84062
84063
84064
84065
84066
84067
84068
84069
84070
84071
84072
84073
84074
84075
84076
84077
84078
84079
84080
84081
84082
84083
84084
84085
84086
84087
84088
84089
84090
84091
84092
84093
84094
84095
84096
84097
84098
84099
84100
84101
84102
84103
84104
84105
84106
84107
84108
84109
84110
84111
84112
84113
84114
84115
84116
84117
84118
84119
84120
84121
84122
84123
84124
84125
84126
84127
84128
84129
84130
84131
84132
84133
84134
84135
84136
84137
84138
84139
84140
84141
84142
84143
84144
84145
84146
84147
84148
84149
84150
84151
84152
84153
84154
84155
84156
84157
84158
84159
84160
84161
84162
84163
84164
84165
84166
84167
84168
84169
84170
84171
84172
84173
84174
84175
84176
84177
84178
84179
84180
84181
84182
84183
84184
84185
84186
84187
84188
84189
84190
84191
84192
84193
84194
84195
84196
84197
84198
84199
84200
84201
84202
84203
84204
84205
84206
84207
84208
84209
84210
84211
84212
84213
84214
84215
84216
84217
84218
84219
84220
84221
84222
84223
84224
84225
84226
84227
84228
84229
84230
84231
84232
84233
84234
84235
84236
84237
84238
84239
84240
84241
84242
84243
84244
84245
84246
84247
84248
84249
84250
84251
84252
84253
84254
84255
84256
84257
84258
84259
84260
84261
84262
84263
84264
84265
84266
84267
84268
84269
84270
84271
84272
84273
84274
84275
84276
84277
84278
84279
84280
84281
84282
84283
84284
84285
84286
84287
84288
84289
84290
84291
84292
84293
84294
84295
84296
84297
84298
84299
84300
84301
84302
84303
84304
84305
84306
84307
84308
84309
84310
84311
84312
84313
84314
84315
84316
84317
84318
84319
84320
84321
84322
84323
84324
84325
84326
84327
84328
84329
84330
84331
84332
84333
84334
84335
84336
84337
84338
84339
84340
84341
84342
84343
84344
84345
84346
84347
84348
84349
84350
84351
84352
84353
84354
84355
84356
84357
84358
84359
84360
84361
84362
84363
84364
84365
84366
84367
84368
84369
84370
84371
84372
84373
84374
84375
84376
84377
84378
84379
84380
84381
84382
84383
84384
84385
84386
84387
84388
84389
84390
84391
84392
84393
84394
84395
84396
84397
84398
84399
84400
84401
84402
84403
84404
84405
84406
84407
84408
84409
84410
84411
84412
84413
84414
84415
84416
84417
84418
84419
84420
84421
84422
84423
84424
84425
84426
84427
84428
84429
84430
84431
84432
84433
84434
84435
84436
84437
84438
84439
84440
84441
84442
84443
84444
84445
84446
84447
84448
84449
84450
84451
84452
84453
84454
84455
84456
84457
84458
84459
84460
84461
84462
84463
84464
84465
84466
84467
84468
84469
84470
84471
84472
84473
84474
84475
84476
84477
84478
84479
84480
84481
84482
84483
84484
84485
84486
84487
84488
84489
84490
84491
84492
84493
84494
84495
84496
84497
84498
84499
84500
84501
84502
84503
84504
84505
84506
84507
84508
84509
84510
84511
84512
84513
84514
84515
84516
84517
84518
84519
84520
84521
84522
84523
84524
84525
84526
84527
84528
84529
84530
84531
84532
84533
84534
84535
84536
84537
84538
84539
84540
84541
84542
84543
84544
84545
84546
84547
84548
84549
84550
84551
84552
84553
84554
84555
84556
84557
84558
84559
84560
84561
84562
84563
84564
84565
84566
84567
84568
84569
84570
84571
84572
84573
84574
84575
84576
84577
84578
84579
84580
84581
84582
84583
84584
84585
84586
84587
84588
84589
84590
84591
84592
84593
84594
84595
84596
84597
84598
84599
84600
84601
84602
84603
84604
84605
84606
84607
84608
84609
84610
84611
84612
84613
84614
84615
84616
84617
84618
84619
84620
84621
84622
84623
84624
84625
84626
84627
84628
84629
84630
84631
84632
84633
84634
84635
84636
84637
84638
84639
84640
84641
84642
84643
84644
84645
84646
84647
84648
84649
84650
84651
84652
84653
84654
84655
84656
84657
84658
84659
84660
84661
84662
84663
84664
84665
84666
84667
84668
84669
84670
84671
84672
84673
84674
84675
84676
84677
84678
84679
84680
84681
84682
84683
84684
84685
84686
84687
84688
84689
84690
84691
84692
84693
84694
84695
84696
84697
84698
84699
84700
84701
84702
84703
84704
84705
84706
84707
84708
84709
84710
84711
84712
84713
84714
84715
84716
84717
84718
84719
84720
84721
84722
84723
84724
84725
84726
84727
84728
84729
84730
84731
84732
84733
84734
84735
84736
84737
84738
84739
84740
84741
84742
84743
84744
84745
84746
84747
84748
84749
84750
84751
84752
84753
84754
84755
84756
84757
84758
84759
84760
84761
84762
84763
84764
84765
84766
84767
84768
84769
84770
84771
84772
84773
84774
84775
84776
84777
84778
84779
84780
84781
84782
84783
84784
84785
84786
84787
84788
84789
84790
84791
84792
84793
84794
84795
84796
84797
84798
84799
84800
84801
84802
84803
84804
84805
84806
84807
84808
84809
84810
84811
84812
84813
84814
84815
84816
84817
84818
84819
84820
84821
84822
84823
84824
84825
84826
84827
84828
84829
84830
84831
84832
84833
84834
84835
84836
84837
84838
84839
84840
84841
84842
84843
84844
84845
84846
84847
84848
84849
84850
84851
84852
84853
84854
84855
84856
84857
84858
84859
84860
84861
84862
84863
84864
84865
84866
84867
84868
84869
84870
84871
84872
84873
84874
84875
84876
84877
84878
84879
84880
84881
84882
84883
84884
84885
84886
84887
84888
84889
84890
84891
84892
84893
84894
84895
84896
84897
84898
84899
84900
84901
84902
84903
84904
84905
84906
84907
84908
84909
84910
84911
84912
84913
84914
84915
84916
84917
84918
84919
84920
84921
84922
84923
84924
84925
84926
84927
84928
84929
84930
84931
84932
84933
84934
84935
84936
84937
84938
84939
84940
84941
84942
84943
84944
84945
84946
84947
84948
84949
84950
84951
84952
84953
84954
84955
84956
84957
84958
84959
84960
84961
84962
84963
84964
84965
84966
84967
84968
84969
84970
84971
84972
84973
84974
84975
84976
84977
84978
84979
84980
84981
84982
84983
84984
84985
84986
84987
84988
84989
84990
84991
84992
84993
84994
84995
84996
84997
84998
84999
85000
85001
85002
85003
85004
85005
85006
85007
85008
85009
85010
85011
85012
85013
85014
85015
85016
85017
85018
85019
85020
85021
85022
85023
85024
85025
85026
85027
85028
85029
85030
85031
85032
85033
85034
85035
85036
85037
85038
85039
85040
85041
85042
85043
85044
85045
85046
85047
85048
85049
85050
85051
85052
85053
85054
85055
85056
85057
85058
85059
85060
85061
85062
85063
85064
85065
85066
85067
85068
85069
85070
85071
85072
85073
85074
85075
85076
85077
85078
85079
85080
85081
85082
85083
85084
85085
85086
85087
85088
85089
85090
85091
85092
85093
85094
85095
85096
85097
85098
85099
85100
85101
85102
85103
85104
85105
85106
85107
85108
85109
85110
85111
85112
85113
85114
85115
85116
85117
85118
85119
85120
85121
85122
85123
85124
85125
85126
85127
85128
85129
85130
85131
85132
85133
85134
85135
85136
85137
85138
85139
85140
85141
85142
85143
85144
85145
85146
85147
85148
85149
85150
85151
85152
85153
85154
85155
85156
85157
85158
85159
85160
85161
85162
85163
85164
85165
85166
85167
85168
85169
85170
85171
85172
85173
85174
85175
85176
85177
85178
85179
85180
85181
85182
85183
85184
85185
85186
85187
85188
85189
85190
85191
85192
85193
85194
85195
85196
85197
85198
85199
85200
85201
85202
85203
85204
85205
85206
85207
85208
85209
85210
85211
85212
85213
85214
85215
85216
85217
85218
85219
85220
85221
85222
85223
85224
85225
85226
85227
85228
85229
85230
85231
85232
85233
85234
85235
85236
85237
85238
85239
85240
85241
85242
85243
85244
85245
85246
85247
85248
85249
85250
85251
85252
85253
85254
85255
85256
85257
85258
85259
85260
85261
85262
85263
85264
85265
85266
85267
85268
85269
85270
85271
85272
85273
85274
85275
85276
85277
85278
85279
85280
85281
85282
85283
85284
85285
85286
85287
85288
85289
85290
85291
85292
85293
85294
85295
85296
85297
85298
85299
85300
85301
85302
85303
85304
85305
85306
85307
85308
85309
85310
85311
85312
85313
85314
85315
85316
85317
85318
85319
85320
85321
85322
85323
85324
85325
85326
85327
85328
85329
85330
85331
85332
85333
85334
85335
85336
85337
85338
85339
85340
85341
85342
85343
85344
85345
85346
85347
85348
85349
85350
85351
85352
85353
85354
85355
85356
85357
85358
85359
85360
85361
85362
85363
85364
85365
85366
85367
85368
85369
85370
85371
85372
85373
85374
85375
85376
85377
85378
85379
85380
85381
85382
85383
85384
85385
85386
85387
85388
85389
85390
85391
85392
85393
85394
85395
85396
85397
85398
85399
85400
85401
85402
85403
85404
85405
85406
85407
85408
85409
85410
85411
85412
85413
85414
85415
85416
85417
85418
85419
85420
85421
85422
85423
85424
85425
85426
85427
85428
85429
85430
85431
85432
85433
85434
85435
85436
85437
85438
85439
85440
85441
85442
85443
85444
85445
85446
85447
85448
85449
85450
85451
85452
85453
85454
85455
85456
85457
85458
85459
85460
85461
85462
85463
85464
85465
85466
85467
85468
85469
85470
85471
85472
85473
85474
85475
85476
85477
85478
85479
85480
85481
85482
85483
85484
85485
85486
85487
85488
85489
85490
85491
85492
85493
85494
85495
85496
85497
85498
85499
85500
85501
85502
85503
85504
85505
85506
85507
85508
85509
85510
85511
85512
85513
85514
85515
85516
85517
85518
85519
85520
85521
85522
85523
85524
85525
85526
85527
85528
85529
85530
85531
85532
85533
85534
85535
85536
85537
85538
85539
85540
85541
85542
85543
85544
85545
85546
85547
85548
85549
85550
85551
85552
85553
85554
85555
85556
85557
85558
85559
85560
85561
85562
85563
85564
85565
85566
85567
85568
85569
85570
85571
85572
85573
85574
85575
85576
85577
85578
85579
85580
85581
85582
85583
85584
85585
85586
85587
85588
85589
85590
85591
85592
85593
85594
85595
85596
85597
85598
85599
85600
85601
85602
85603
85604
85605
85606
85607
85608
85609
85610
85611
85612
85613
85614
85615
85616
85617
85618
85619
85620
85621
85622
85623
85624
85625
85626
85627
85628
85629
85630
85631
85632
85633
85634
85635
85636
85637
85638
85639
85640
85641
85642
85643
85644
85645
85646
85647
85648
85649
85650
85651
85652
85653
85654
85655
85656
85657
85658
85659
85660
85661
85662
85663
85664
85665
85666
85667
85668
85669
85670
85671
85672
85673
85674
85675
85676
85677
85678
85679
85680
85681
85682
85683
85684
85685
85686
85687
85688
85689
85690
85691
85692
85693
85694
85695
85696
85697
85698
85699
85700
85701
85702
85703
85704
85705
85706
85707
85708
85709
85710
85711
85712
85713
85714
85715
85716
85717
85718
85719
85720
85721
85722
85723
85724
85725
85726
85727
85728
85729
85730
85731
85732
85733
85734
85735
85736
85737
85738
85739
85740
85741
85742
85743
85744
85745
85746
85747
85748
85749
85750
85751
85752
85753
85754
85755
85756
85757
85758
85759
85760
85761
85762
85763
85764
85765
85766
85767
85768
85769
85770
85771
85772
85773
85774
85775
85776
85777
85778
85779
85780
85781
85782
85783
85784
85785
85786
85787
85788
85789
85790
85791
85792
85793
85794
85795
85796
85797
85798
85799
85800
85801
85802
85803
85804
85805
85806
85807
85808
85809
85810
85811
85812
85813
85814
85815
85816
85817
85818
85819
85820
85821
85822
85823
85824
85825
85826
85827
85828
85829
85830
85831
85832
85833
85834
85835
85836
85837
85838
85839
85840
85841
85842
85843
85844
85845
85846
85847
85848
85849
85850
85851
85852
85853
85854
85855
85856
85857
85858
85859
85860
85861
85862
85863
85864
85865
85866
85867
85868
85869
85870
85871
85872
85873
85874
85875
85876
85877
85878
85879
85880
85881
85882
85883
85884
85885
85886
85887
85888
85889
85890
85891
85892
85893
85894
85895
85896
85897
85898
85899
85900
85901
85902
85903
85904
85905
85906
85907
85908
85909
85910
85911
85912
85913
85914
85915
85916
85917
85918
85919
85920
85921
85922
85923
85924
85925
85926
85927
85928
85929
85930
85931
85932
85933
85934
85935
85936
85937
85938
85939
85940
85941
85942
85943
85944
85945
85946
85947
85948
85949
85950
85951
85952
85953
85954
85955
85956
85957
85958
85959
85960
85961
85962
85963
85964
85965
85966
85967
85968
85969
85970
85971
85972
85973
85974
85975
85976
85977
85978
85979
85980
85981
85982
85983
85984
85985
85986
85987
85988
85989
85990
85991
85992
85993
85994
85995
85996
85997
85998
85999
86000
86001
86002
86003
86004
86005
86006
86007
86008
86009
86010
86011
86012
86013
86014
86015
86016
86017
86018
86019
86020
86021
86022
86023
86024
86025
86026
86027
86028
86029
86030
86031
86032
86033
86034
86035
86036
86037
86038
86039
86040
86041
86042
86043
86044
86045
86046
86047
86048
86049
86050
86051
86052
86053
86054
86055
86056
86057
86058
86059
86060
86061
86062
86063
86064
86065
86066
86067
86068
86069
86070
86071
86072
86073
86074
86075
86076
86077
86078
86079
86080
86081
86082
86083
86084
86085
86086
86087
86088
86089
86090
86091
86092
86093
86094
86095
86096
86097
86098
86099
86100
86101
86102
86103
86104
86105
86106
86107
86108
86109
86110
86111
86112
86113
86114
86115
86116
86117
86118
86119
86120
86121
86122
86123
86124
86125
86126
86127
86128
86129
86130
86131
86132
86133
86134
86135
86136
86137
86138
86139
86140
86141
86142
86143
86144
86145
86146
86147
86148
86149
86150
86151
86152
86153
86154
86155
86156
86157
86158
86159
86160
86161
86162
86163
86164
86165
86166
86167
86168
86169
86170
86171
86172
86173
86174
86175
86176
86177
86178
86179
86180
86181
86182
86183
86184
86185
86186
86187
86188
86189
86190
86191
86192
86193
86194
86195
86196
86197
86198
86199
86200
86201
86202
86203
86204
86205
86206
86207
86208
86209
86210
86211
86212
86213
86214
86215
86216
86217
86218
86219
86220
86221
86222
86223
86224
86225
86226
86227
86228
86229
86230
86231
86232
86233
86234
86235
86236
86237
86238
86239
86240
86241
86242
86243
86244
86245
86246
86247
86248
86249
86250
86251
86252
86253
86254
86255
86256
86257
86258
86259
86260
86261
86262
86263
86264
86265
86266
86267
86268
86269
86270
86271
86272
86273
86274
86275
86276
86277
86278
86279
86280
86281
86282
86283
86284
86285
86286
86287
86288
86289
86290
86291
86292
86293
86294
86295
86296
86297
86298
86299
86300
86301
86302
86303
86304
86305
86306
86307
86308
86309
86310
86311
86312
86313
86314
86315
86316
86317
86318
86319
86320
86321
86322
86323
86324
86325
86326
86327
86328
86329
86330
86331
86332
86333
86334
86335
86336
86337
86338
86339
86340
86341
86342
86343
86344
86345
86346
86347
86348
86349
86350
86351
86352
86353
86354
86355
86356
86357
86358
86359
86360
86361
86362
86363
86364
86365
86366
86367
86368
86369
86370
86371
86372
86373
86374
86375
86376
86377
86378
86379
86380
86381
86382
86383
86384
86385
86386
86387
86388
86389
86390
86391
86392
86393
86394
86395
86396
86397
86398
86399
86400
86401
86402
86403
86404
86405
86406
86407
86408
86409
86410
86411
86412
86413
86414
86415
86416
86417
86418
86419
86420
86421
86422
86423
86424
86425
86426
86427
86428
86429
86430
86431
86432
86433
86434
86435
86436
86437
86438
86439
86440
86441
86442
86443
86444
86445
86446
86447
86448
86449
86450
86451
86452
86453
86454
86455
86456
86457
86458
86459
86460
86461
86462
86463
86464
86465
86466
86467
86468
86469
86470
86471
86472
86473
86474
86475
86476
86477
86478
86479
86480
86481
86482
86483
86484
86485
86486
86487
86488
86489
86490
86491
86492
86493
86494
86495
86496
86497
86498
86499
86500
86501
86502
86503
86504
86505
86506
86507
86508
86509
86510
86511
86512
86513
86514
86515
86516
86517
86518
86519
86520
86521
86522
86523
86524
86525
86526
86527
86528
86529
86530
86531
86532
86533
86534
86535
86536
86537
86538
86539
86540
86541
86542
86543
86544
86545
86546
86547
86548
86549
86550
86551
86552
86553
86554
86555
86556
86557
86558
86559
86560
86561
86562
86563
86564
86565
86566
86567
86568
86569
86570
86571
86572
86573
86574
86575
86576
86577
86578
86579
86580
86581
86582
86583
86584
86585
86586
86587
86588
86589
86590
86591
86592
86593
86594
86595
86596
86597
86598
86599
86600
86601
86602
86603
86604
86605
86606
86607
86608
86609
86610
86611
86612
86613
86614
86615
86616
86617
86618
86619
86620
86621
86622
86623
86624
86625
86626
86627
86628
86629
86630
86631
86632
86633
86634
86635
86636
86637
86638
86639
86640
86641
86642
86643
86644
86645
86646
86647
86648
86649
86650
86651
86652
86653
86654
86655
86656
86657
86658
86659
86660
86661
86662
86663
86664
86665
86666
86667
86668
86669
86670
86671
86672
86673
86674
86675
86676
86677
86678
86679
86680
86681
86682
86683
86684
86685
86686
86687
86688
86689
86690
86691
86692
86693
86694
86695
86696
86697
86698
86699
86700
86701
86702
86703
86704
86705
86706
86707
86708
86709
86710
86711
86712
86713
86714
86715
86716
86717
86718
86719
86720
86721
86722
86723
86724
86725
86726
86727
86728
86729
86730
86731
86732
86733
86734
86735
86736
86737
86738
86739
86740
86741
86742
86743
86744
86745
86746
86747
86748
86749
86750
86751
86752
86753
86754
86755
86756
86757
86758
86759
86760
86761
86762
86763
86764
86765
86766
86767
86768
86769
86770
86771
86772
86773
86774
86775
86776
86777
86778
86779
86780
86781
86782
86783
86784
86785
86786
86787
86788
86789
86790
86791
86792
86793
86794
86795
86796
86797
86798
86799
86800
86801
86802
86803
86804
86805
86806
86807
86808
86809
86810
86811
86812
86813
86814
86815
86816
86817
86818
86819
86820
86821
86822
86823
86824
86825
86826
86827
86828
86829
86830
86831
86832
86833
86834
86835
86836
86837
86838
86839
86840
86841
86842
86843
86844
86845
86846
86847
86848
86849
86850
86851
86852
86853
86854
86855
86856
86857
86858
86859
86860
86861
86862
86863
86864
86865
86866
86867
86868
86869
86870
86871
86872
86873
86874
86875
86876
86877
86878
86879
86880
86881
86882
86883
86884
86885
86886
86887
86888
86889
86890
86891
86892
86893
86894
86895
86896
86897
86898
86899
86900
86901
86902
86903
86904
86905
86906
86907
86908
86909
86910
86911
86912
86913
86914
86915
86916
86917
86918
86919
86920
86921
86922
86923
86924
86925
86926
86927
86928
86929
86930
86931
86932
86933
86934
86935
86936
86937
86938
86939
86940
86941
86942
86943
86944
86945
86946
86947
86948
86949
86950
86951
86952
86953
86954
86955
86956
86957
86958
86959
86960
86961
86962
86963
86964
86965
86966
86967
86968
86969
86970
86971
86972
86973
86974
86975
86976
86977
86978
86979
86980
86981
86982
86983
86984
86985
86986
86987
86988
86989
86990
86991
86992
86993
86994
86995
86996
86997
86998
86999
87000
87001
87002
87003
87004
87005
87006
87007
87008
87009
87010
87011
87012
87013
87014
87015
87016
87017
87018
87019
87020
87021
87022
87023
87024
87025
87026
87027
87028
87029
87030
87031
87032
87033
87034
87035
87036
87037
87038
87039
87040
87041
87042
87043
87044
87045
87046
87047
87048
87049
87050
87051
87052
87053
87054
87055
87056
87057
87058
87059
87060
87061
87062
87063
87064
87065
87066
87067
87068
87069
87070
87071
87072
87073
87074
87075
87076
87077
87078
87079
87080
87081
87082
87083
87084
87085
87086
87087
87088
87089
87090
87091
87092
87093
87094
87095
87096
87097
87098
87099
87100
87101
87102
87103
87104
87105
87106
87107
87108
87109
87110
87111
87112
87113
87114
87115
87116
87117
87118
87119
87120
87121
87122
87123
87124
87125
87126
87127
87128
87129
87130
87131
87132
87133
87134
87135
87136
87137
87138
87139
87140
87141
87142
87143
87144
87145
87146
87147
87148
87149
87150
87151
87152
87153
87154
87155
87156
87157
87158
87159
87160
87161
87162
87163
87164
87165
87166
87167
87168
87169
87170
87171
87172
87173
87174
87175
87176
87177
87178
87179
87180
87181
87182
87183
87184
87185
87186
87187
87188
87189
87190
87191
87192
87193
87194
87195
87196
87197
87198
87199
87200
87201
87202
87203
87204
87205
87206
87207
87208
87209
87210
87211
87212
87213
87214
87215
87216
87217
87218
87219
87220
87221
87222
87223
87224
87225
87226
87227
87228
87229
87230
87231
87232
87233
87234
87235
87236
87237
87238
87239
87240
87241
87242
87243
87244
87245
87246
87247
87248
87249
87250
87251
87252
87253
87254
87255
87256
87257
87258
87259
87260
87261
87262
87263
87264
87265
87266
87267
87268
87269
87270
87271
87272
87273
87274
87275
87276
87277
87278
87279
87280
87281
87282
87283
87284
87285
87286
87287
87288
87289
87290
87291
87292
87293
87294
87295
87296
87297
87298
87299
87300
87301
87302
87303
87304
87305
87306
87307
87308
87309
87310
87311
87312
87313
87314
87315
87316
87317
87318
87319
87320
87321
87322
87323
87324
87325
87326
87327
87328
87329
87330
87331
87332
87333
87334
87335
87336
87337
87338
87339
87340
87341
87342
87343
87344
87345
87346
87347
87348
87349
87350
87351
87352
87353
87354
87355
87356
87357
87358
87359
87360
87361
87362
87363
87364
87365
87366
87367
87368
87369
87370
87371
87372
87373
87374
87375
87376
87377
87378
87379
87380
87381
87382
87383
87384
87385
87386
87387
87388
87389
87390
87391
87392
87393
87394
87395
87396
87397
87398
87399
87400
87401
87402
87403
87404
87405
87406
87407
87408
87409
87410
87411
87412
87413
87414
87415
87416
87417
87418
87419
87420
87421
87422
87423
87424
87425
87426
87427
87428
87429
87430
87431
87432
87433
87434
87435
87436
87437
87438
87439
87440
87441
87442
87443
87444
87445
87446
87447
87448
87449
87450
87451
87452
87453
87454
87455
87456
87457
87458
87459
87460
87461
87462
87463
87464
87465
87466
87467
87468
87469
87470
87471
87472
87473
87474
87475
87476
87477
87478
87479
87480
87481
87482
87483
87484
87485
87486
87487
87488
87489
87490
87491
87492
87493
87494
87495
87496
87497
87498
87499
87500
87501
87502
87503
87504
87505
87506
87507
87508
87509
87510
87511
87512
87513
87514
87515
87516
87517
87518
87519
87520
87521
87522
87523
87524
87525
87526
87527
87528
87529
87530
87531
87532
87533
87534
87535
87536
87537
87538
87539
87540
87541
87542
87543
87544
87545
87546
87547
87548
87549
87550
87551
87552
87553
87554
87555
87556
87557
87558
87559
87560
87561
87562
87563
87564
87565
87566
87567
87568
87569
87570
87571
87572
87573
87574
87575
87576
87577
87578
87579
87580
87581
87582
87583
87584
87585
87586
87587
87588
87589
87590
87591
87592
87593
87594
87595
87596
87597
87598
87599
87600
87601
87602
87603
87604
87605
87606
87607
87608
87609
87610
87611
87612
87613
87614
87615
87616
87617
87618
87619
87620
87621
87622
87623
87624
87625
87626
87627
87628
87629
87630
87631
87632
87633
87634
87635
87636
87637
87638
87639
87640
87641
87642
87643
87644
87645
87646
87647
87648
87649
87650
87651
87652
87653
87654
87655
87656
87657
87658
87659
87660
87661
87662
87663
87664
87665
87666
87667
87668
87669
87670
87671
87672
87673
87674
87675
87676
87677
87678
87679
87680
87681
87682
87683
87684
87685
87686
87687
87688
87689
87690
87691
87692
87693
87694
87695
87696
87697
87698
87699
87700
87701
87702
87703
87704
87705
87706
87707
87708
87709
87710
87711
87712
87713
87714
87715
87716
87717
87718
87719
87720
87721
87722
87723
87724
87725
87726
87727
87728
87729
87730
87731
87732
87733
87734
87735
87736
87737
87738
87739
87740
87741
87742
87743
87744
87745
87746
87747
87748
87749
87750
87751
87752
87753
87754
87755
87756
87757
87758
87759
87760
87761
87762
87763
87764
87765
87766
87767
87768
87769
87770
87771
87772
87773
87774
87775
87776
87777
87778
87779
87780
87781
87782
87783
87784
87785
87786
87787
87788
87789
87790
87791
87792
87793
87794
87795
87796
87797
87798
87799
87800
87801
87802
87803
87804
87805
87806
87807
87808
87809
87810
87811
87812
87813
87814
87815
87816
87817
87818
87819
87820
87821
87822
87823
87824
87825
87826
87827
87828
87829
87830
87831
87832
87833
87834
87835
87836
87837
87838
87839
87840
87841
87842
87843
87844
87845
87846
87847
87848
87849
87850
87851
87852
87853
87854
87855
87856
87857
87858
87859
87860
87861
87862
87863
87864
87865
87866
87867
87868
87869
87870
87871
87872
87873
87874
87875
87876
87877
87878
87879
87880
87881
87882
87883
87884
87885
87886
87887
87888
87889
87890
87891
87892
87893
87894
87895
87896
87897
87898
87899
87900
87901
87902
87903
87904
87905
87906
87907
87908
87909
87910
87911
87912
87913
87914
87915
87916
87917
87918
87919
87920
87921
87922
87923
87924
87925
87926
87927
87928
87929
87930
87931
87932
87933
87934
87935
87936
87937
87938
87939
87940
87941
87942
87943
87944
87945
87946
87947
87948
87949
87950
87951
87952
87953
87954
87955
87956
87957
87958
87959
87960
87961
87962
87963
87964
87965
87966
87967
87968
87969
87970
87971
87972
87973
87974
87975
87976
87977
87978
87979
87980
87981
87982
87983
87984
87985
87986
87987
87988
87989
87990
87991
87992
87993
87994
87995
87996
87997
87998
87999
88000
88001
88002
88003
88004
88005
88006
88007
88008
88009
88010
88011
88012
88013
88014
88015
88016
88017
88018
88019
88020
88021
88022
88023
88024
88025
88026
88027
88028
88029
88030
88031
88032
88033
88034
88035
88036
88037
88038
88039
88040
88041
88042
88043
88044
88045
88046
88047
88048
88049
88050
88051
88052
88053
88054
88055
88056
88057
88058
88059
88060
88061
88062
88063
88064
88065
88066
88067
88068
88069
88070
88071
88072
88073
88074
88075
88076
88077
88078
88079
88080
88081
88082
88083
88084
88085
88086
88087
88088
88089
88090
88091
88092
88093
88094
88095
88096
88097
88098
88099
88100
88101
88102
88103
88104
88105
88106
88107
88108
88109
88110
88111
88112
88113
88114
88115
88116
88117
88118
88119
88120
88121
88122
88123
88124
88125
88126
88127
88128
88129
88130
88131
88132
88133
88134
88135
88136
88137
88138
88139
88140
88141
88142
88143
88144
88145
88146
88147
88148
88149
88150
88151
88152
88153
88154
88155
88156
88157
88158
88159
88160
88161
88162
88163
88164
88165
88166
88167
88168
88169
88170
88171
88172
88173
88174
88175
88176
88177
88178
88179
88180
88181
88182
88183
88184
88185
88186
88187
88188
88189
88190
88191
88192
88193
88194
88195
88196
88197
88198
88199
88200
88201
88202
88203
88204
88205
88206
88207
88208
88209
88210
88211
88212
88213
88214
88215
88216
88217
88218
88219
88220
88221
88222
88223
88224
88225
88226
88227
88228
88229
88230
88231
88232
88233
88234
88235
88236
88237
88238
88239
88240
88241
88242
88243
88244
88245
88246
88247
88248
88249
88250
88251
88252
88253
88254
88255
88256
88257
88258
88259
88260
88261
88262
88263
88264
88265
88266
88267
88268
88269
88270
88271
88272
88273
88274
88275
88276
88277
88278
88279
88280
88281
88282
88283
88284
88285
88286
88287
88288
88289
88290
88291
88292
88293
88294
88295
88296
88297
88298
88299
88300
88301
88302
88303
88304
88305
88306
88307
88308
88309
88310
88311
88312
88313
88314
88315
88316
88317
88318
88319
88320
88321
88322
88323
88324
88325
88326
88327
88328
88329
88330
88331
88332
88333
88334
88335
88336
88337
88338
88339
88340
88341
88342
88343
88344
88345
88346
88347
88348
88349
88350
88351
88352
88353
88354
88355
88356
88357
88358
88359
88360
88361
88362
88363
88364
88365
88366
88367
88368
88369
88370
88371
88372
88373
88374
88375
88376
88377
88378
88379
88380
88381
88382
88383
88384
88385
88386
88387
88388
88389
88390
88391
88392
88393
88394
88395
88396
88397
88398
88399
88400
88401
88402
88403
88404
88405
88406
88407
88408
88409
88410
88411
88412
88413
88414
88415
88416
88417
88418
88419
88420
88421
88422
88423
88424
88425
88426
88427
88428
88429
88430
88431
88432
88433
88434
88435
88436
88437
88438
88439
88440
88441
88442
88443
88444
88445
88446
88447
88448
88449
88450
88451
88452
88453
88454
88455
88456
88457
88458
88459
88460
88461
88462
88463
88464
88465
88466
88467
88468
88469
88470
88471
88472
88473
88474
88475
88476
88477
88478
88479
88480
88481
88482
88483
88484
88485
88486
88487
88488
88489
88490
88491
88492
88493
88494
88495
88496
88497
88498
88499
88500
88501
88502
88503
88504
88505
88506
88507
88508
88509
88510
88511
88512
88513
88514
88515
88516
88517
88518
88519
88520
88521
88522
88523
88524
88525
88526
88527
88528
88529
88530
88531
88532
88533
88534
88535
88536
88537
88538
88539
88540
88541
88542
88543
88544
88545
88546
88547
88548
88549
88550
88551
88552
88553
88554
88555
88556
88557
88558
88559
88560
88561
88562
88563
88564
88565
88566
88567
88568
88569
88570
88571
88572
88573
88574
88575
88576
88577
88578
88579
88580
88581
88582
88583
88584
88585
88586
88587
88588
88589
88590
88591
88592
88593
88594
88595
88596
88597
88598
88599
88600
88601
88602
88603
88604
88605
88606
88607
88608
88609
88610
88611
88612
88613
88614
88615
88616
88617
88618
88619
88620
88621
88622
88623
88624
88625
88626
88627
88628
88629
88630
88631
88632
88633
88634
88635
88636
88637
88638
88639
88640
88641
88642
88643
88644
88645
88646
88647
88648
88649
88650
88651
88652
88653
88654
88655
88656
88657
88658
88659
88660
88661
88662
88663
88664
88665
88666
88667
88668
88669
88670
88671
88672
88673
88674
88675
88676
88677
88678
88679
88680
88681
88682
88683
88684
88685
88686
88687
88688
88689
88690
88691
88692
88693
88694
88695
88696
88697
88698
88699
88700
88701
88702
88703
88704
88705
88706
88707
88708
88709
88710
88711
88712
88713
88714
88715
88716
88717
88718
88719
88720
88721
88722
88723
88724
88725
88726
88727
88728
88729
88730
88731
88732
88733
88734
88735
88736
88737
88738
88739
88740
88741
88742
88743
88744
88745
88746
88747
88748
88749
88750
88751
88752
88753
88754
88755
88756
88757
88758
88759
88760
88761
88762
88763
88764
88765
88766
88767
88768
88769
88770
88771
88772
88773
88774
88775
88776
88777
88778
88779
88780
88781
88782
88783
88784
88785
88786
88787
88788
88789
88790
88791
88792
88793
88794
88795
88796
88797
88798
88799
88800
88801
88802
88803
88804
88805
88806
88807
88808
88809
88810
88811
88812
88813
88814
88815
88816
88817
88818
88819
88820
88821
88822
88823
88824
88825
88826
88827
88828
88829
88830
88831
88832
88833
88834
88835
88836
88837
88838
88839
88840
88841
88842
88843
88844
88845
88846
88847
88848
88849
88850
88851
88852
88853
88854
88855
88856
88857
88858
88859
88860
88861
88862
88863
88864
88865
88866
88867
88868
88869
88870
88871
88872
88873
88874
88875
88876
88877
88878
88879
88880
88881
88882
88883
88884
88885
88886
88887
88888
88889
88890
88891
88892
88893
88894
88895
88896
88897
88898
88899
88900
88901
88902
88903
88904
88905
88906
88907
88908
88909
88910
88911
88912
88913
88914
88915
88916
88917
88918
88919
88920
88921
88922
88923
88924
88925
88926
88927
88928
88929
88930
88931
88932
88933
88934
88935
88936
88937
88938
88939
88940
88941
88942
88943
88944
88945
88946
88947
88948
88949
88950
88951
88952
88953
88954
88955
88956
88957
88958
88959
88960
88961
88962
88963
88964
88965
88966
88967
88968
88969
88970
88971
88972
88973
88974
88975
88976
88977
88978
88979
88980
88981
88982
88983
88984
88985
88986
88987
88988
88989
88990
88991
88992
88993
88994
88995
88996
88997
88998
88999
89000
89001
89002
89003
89004
89005
89006
89007
89008
89009
89010
89011
89012
89013
89014
89015
89016
89017
89018
89019
89020
89021
89022
89023
89024
89025
89026
89027
89028
89029
89030
89031
89032
89033
89034
89035
89036
89037
89038
89039
89040
89041
89042
89043
89044
89045
89046
89047
89048
89049
89050
89051
89052
89053
89054
89055
89056
89057
89058
89059
89060
89061
89062
89063
89064
89065
89066
89067
89068
89069
89070
89071
89072
89073
89074
89075
89076
89077
89078
89079
89080
89081
89082
89083
89084
89085
89086
89087
89088
89089
89090
89091
89092
89093
89094
89095
89096
89097
89098
89099
89100
89101
89102
89103
89104
89105
89106
89107
89108
89109
89110
89111
89112
89113
89114
89115
89116
89117
89118
89119
89120
89121
89122
89123
89124
89125
89126
89127
89128
89129
89130
89131
89132
89133
89134
89135
89136
89137
89138
89139
89140
89141
89142
89143
89144
89145
89146
89147
89148
89149
89150
89151
89152
89153
89154
89155
89156
89157
89158
89159
89160
89161
89162
89163
89164
89165
89166
89167
89168
89169
89170
89171
89172
89173
89174
89175
89176
89177
89178
89179
89180
89181
89182
89183
89184
89185
89186
89187
89188
89189
89190
89191
89192
89193
89194
89195
89196
89197
89198
89199
89200
89201
89202
89203
89204
89205
89206
89207
89208
89209
89210
89211
89212
89213
89214
89215
89216
89217
89218
89219
89220
89221
89222
89223
89224
89225
89226
89227
89228
89229
89230
89231
89232
89233
89234
89235
89236
89237
89238
89239
89240
89241
89242
89243
89244
89245
89246
89247
89248
89249
89250
89251
89252
89253
89254
89255
89256
89257
89258
89259
89260
89261
89262
89263
89264
89265
89266
89267
89268
89269
89270
89271
89272
89273
89274
89275
89276
89277
89278
89279
89280
89281
89282
89283
89284
89285
89286
89287
89288
89289
89290
89291
89292
89293
89294
89295
89296
89297
89298
89299
89300
89301
89302
89303
89304
89305
89306
89307
89308
89309
89310
89311
89312
89313
89314
89315
89316
89317
89318
89319
89320
89321
89322
89323
89324
89325
89326
89327
89328
89329
89330
89331
89332
89333
89334
89335
89336
89337
89338
89339
89340
89341
89342
89343
89344
89345
89346
89347
89348
89349
89350
89351
89352
89353
89354
89355
89356
89357
89358
89359
89360
89361
89362
89363
89364
89365
89366
89367
89368
89369
89370
89371
89372
89373
89374
89375
89376
89377
89378
89379
89380
89381
89382
89383
89384
89385
89386
89387
89388
89389
89390
89391
89392
89393
89394
89395
89396
89397
89398
89399
89400
89401
89402
89403
89404
89405
89406
89407
89408
89409
89410
89411
89412
89413
89414
89415
89416
89417
89418
89419
89420
89421
89422
89423
89424
89425
89426
89427
89428
89429
89430
89431
89432
89433
89434
89435
89436
89437
89438
89439
89440
89441
89442
89443
89444
89445
89446
89447
89448
89449
89450
89451
89452
89453
89454
89455
89456
89457
89458
89459
89460
89461
89462
89463
89464
89465
89466
89467
89468
89469
89470
89471
89472
89473
89474
89475
89476
89477
89478
89479
89480
89481
89482
89483
89484
89485
89486
89487
89488
89489
89490
89491
89492
89493
89494
89495
89496
89497
89498
89499
89500
89501
89502
89503
89504
89505
89506
89507
89508
89509
89510
89511
89512
89513
89514
89515
89516
89517
89518
89519
89520
89521
89522
89523
89524
89525
89526
89527
89528
89529
89530
89531
89532
89533
89534
89535
89536
89537
89538
89539
89540
89541
89542
89543
89544
89545
89546
89547
89548
89549
89550
89551
89552
89553
89554
89555
89556
89557
89558
89559
89560
89561
89562
89563
89564
89565
89566
89567
89568
89569
89570
89571
89572
89573
89574
89575
89576
89577
89578
89579
89580
89581
89582
89583
89584
89585
89586
89587
89588
89589
89590
89591
89592
89593
89594
89595
89596
89597
89598
89599
89600
89601
89602
89603
89604
89605
89606
89607
89608
89609
89610
89611
89612
89613
89614
89615
89616
89617
89618
89619
89620
89621
89622
89623
89624
89625
89626
89627
89628
89629
89630
89631
89632
89633
89634
89635
89636
89637
89638
89639
89640
89641
89642
89643
89644
89645
89646
89647
89648
89649
89650
89651
89652
89653
89654
89655
89656
89657
89658
89659
89660
89661
89662
89663
89664
89665
89666
89667
89668
89669
89670
89671
89672
89673
89674
89675
89676
89677
89678
89679
89680
89681
89682
89683
89684
89685
89686
89687
89688
89689
89690
89691
89692
89693
89694
89695
89696
89697
89698
89699
89700
89701
89702
89703
89704
89705
89706
89707
89708
89709
89710
89711
89712
89713
89714
89715
89716
89717
89718
89719
89720
89721
89722
89723
89724
89725
89726
89727
89728
89729
89730
89731
89732
89733
89734
89735
89736
89737
89738
89739
89740
89741
89742
89743
89744
89745
89746
89747
89748
89749
89750
89751
89752
89753
89754
89755
89756
89757
89758
89759
89760
89761
89762
89763
89764
89765
89766
89767
89768
89769
89770
89771
89772
89773
89774
89775
89776
89777
89778
89779
89780
89781
89782
89783
89784
89785
89786
89787
89788
89789
89790
89791
89792
89793
89794
89795
89796
89797
89798
89799
89800
89801
89802
89803
89804
89805
89806
89807
89808
89809
89810
89811
89812
89813
89814
89815
89816
89817
89818
89819
89820
89821
89822
89823
89824
89825
89826
89827
89828
89829
89830
89831
89832
89833
89834
89835
89836
89837
89838
89839
89840
89841
89842
89843
89844
89845
89846
89847
89848
89849
89850
89851
89852
89853
89854
89855
89856
89857
89858
89859
89860
89861
89862
89863
89864
89865
89866
89867
89868
89869
89870
89871
89872
89873
89874
89875
89876
89877
89878
89879
89880
89881
89882
89883
89884
89885
89886
89887
89888
89889
89890
89891
89892
89893
89894
89895
89896
89897
89898
89899
89900
89901
89902
89903
89904
89905
89906
89907
89908
89909
89910
89911
89912
89913
89914
89915
89916
89917
89918
89919
89920
89921
89922
89923
89924
89925
89926
89927
89928
89929
89930
89931
89932
89933
89934
89935
89936
89937
89938
89939
89940
89941
89942
89943
89944
89945
89946
89947
89948
89949
89950
89951
89952
89953
89954
89955
89956
89957
89958
89959
89960
89961
89962
89963
89964
89965
89966
89967
89968
89969
89970
89971
89972
89973
89974
89975
89976
89977
89978
89979
89980
89981
89982
89983
89984
89985
89986
89987
89988
89989
89990
89991
89992
89993
89994
89995
89996
89997
89998
89999
90000
90001
90002
90003
90004
90005
90006
90007
90008
90009
90010
90011
90012
90013
90014
90015
90016
90017
90018
90019
90020
90021
90022
90023
90024
90025
90026
90027
90028
90029
90030
90031
90032
90033
90034
90035
90036
90037
90038
90039
90040
90041
90042
90043
90044
90045
90046
90047
90048
90049
90050
90051
90052
90053
90054
90055
90056
90057
90058
90059
90060
90061
90062
90063
90064
90065
90066
90067
90068
90069
90070
90071
90072
90073
90074
90075
90076
90077
90078
90079
90080
90081
90082
90083
90084
90085
90086
90087
90088
90089
90090
90091
90092
90093
90094
90095
90096
90097
90098
90099
90100
90101
90102
90103
90104
90105
90106
90107
90108
90109
90110
90111
90112
90113
90114
90115
90116
90117
90118
90119
90120
90121
90122
90123
90124
90125
90126
90127
90128
90129
90130
90131
90132
90133
90134
90135
90136
90137
90138
90139
90140
90141
90142
90143
90144
90145
90146
90147
90148
90149
90150
90151
90152
90153
90154
90155
90156
90157
90158
90159
90160
90161
90162
90163
90164
90165
90166
90167
90168
90169
90170
90171
90172
90173
90174
90175
90176
90177
90178
90179
90180
90181
90182
90183
90184
90185
90186
90187
90188
90189
90190
90191
90192
90193
90194
90195
90196
90197
90198
90199
90200
90201
90202
90203
90204
90205
90206
90207
90208
90209
90210
90211
90212
90213
90214
90215
90216
90217
90218
90219
90220
90221
90222
90223
90224
90225
90226
90227
90228
90229
90230
90231
90232
90233
90234
90235
90236
90237
90238
90239
90240
90241
90242
90243
90244
90245
90246
90247
90248
90249
90250
90251
90252
90253
90254
90255
90256
90257
90258
90259
90260
90261
90262
90263
90264
90265
90266
90267
90268
90269
90270
90271
90272
90273
90274
90275
90276
90277
90278
90279
90280
90281
90282
90283
90284
90285
90286
90287
90288
90289
90290
90291
90292
90293
90294
90295
90296
90297
90298
90299
90300
90301
90302
90303
90304
90305
90306
90307
90308
90309
90310
90311
90312
90313
90314
90315
90316
90317
90318
90319
90320
90321
90322
90323
90324
90325
90326
90327
90328
90329
90330
90331
90332
90333
90334
90335
90336
90337
90338
90339
90340
90341
90342
90343
90344
90345
90346
90347
90348
90349
90350
90351
90352
90353
90354
90355
90356
90357
90358
90359
90360
90361
90362
90363
90364
90365
90366
90367
90368
90369
90370
90371
90372
90373
90374
90375
90376
90377
90378
90379
90380
90381
90382
90383
90384
90385
90386
90387
90388
90389
90390
90391
90392
90393
90394
90395
90396
90397
90398
90399
90400
90401
90402
90403
90404
90405
90406
90407
90408
90409
90410
90411
90412
90413
90414
90415
90416
90417
90418
90419
90420
90421
90422
90423
90424
90425
90426
90427
90428
90429
90430
90431
90432
90433
90434
90435
90436
90437
90438
90439
90440
90441
90442
90443
90444
90445
90446
90447
90448
90449
90450
90451
90452
90453
90454
90455
90456
90457
90458
90459
90460
90461
90462
90463
90464
90465
90466
90467
90468
90469
90470
90471
90472
90473
90474
90475
90476
90477
90478
90479
90480
90481
90482
90483
90484
90485
90486
90487
90488
90489
90490
90491
90492
90493
90494
90495
90496
90497
90498
90499
90500
90501
90502
90503
90504
90505
90506
90507
90508
90509
90510
90511
90512
90513
90514
90515
90516
90517
90518
90519
90520
90521
90522
90523
90524
90525
90526
90527
90528
90529
90530
90531
90532
90533
90534
90535
90536
90537
90538
90539
90540
90541
90542
90543
90544
90545
90546
90547
90548
90549
90550
90551
90552
90553
90554
90555
90556
90557
90558
90559
90560
90561
90562
90563
90564
90565
90566
90567
90568
90569
90570
90571
90572
90573
90574
90575
90576
90577
90578
90579
90580
90581
90582
90583
90584
90585
90586
90587
90588
90589
90590
90591
90592
90593
90594
90595
90596
90597
90598
90599
90600
90601
90602
90603
90604
90605
90606
90607
90608
90609
90610
90611
90612
90613
90614
90615
90616
90617
90618
90619
90620
90621
90622
90623
90624
90625
90626
90627
90628
90629
90630
90631
90632
90633
90634
90635
90636
90637
90638
90639
90640
90641
90642
90643
90644
90645
90646
90647
90648
90649
90650
90651
90652
90653
90654
90655
90656
90657
90658
90659
90660
90661
90662
90663
90664
90665
90666
90667
90668
90669
90670
90671
90672
90673
90674
90675
90676
90677
90678
90679
90680
90681
90682
90683
90684
90685
90686
90687
90688
90689
90690
90691
90692
90693
90694
90695
90696
90697
90698
90699
90700
90701
90702
90703
90704
90705
90706
90707
90708
90709
90710
90711
90712
90713
90714
90715
90716
90717
90718
90719
90720
90721
90722
90723
90724
90725
90726
90727
90728
90729
90730
90731
90732
90733
90734
90735
90736
90737
90738
90739
90740
90741
90742
90743
90744
90745
90746
90747
90748
90749
90750
90751
90752
90753
90754
90755
90756
90757
90758
90759
90760
90761
90762
90763
90764
90765
90766
90767
90768
90769
90770
90771
90772
90773
90774
90775
90776
90777
90778
90779
90780
90781
90782
90783
90784
90785
90786
90787
90788
90789
90790
90791
90792
90793
90794
90795
90796
90797
90798
90799
90800
90801
90802
90803
90804
90805
90806
90807
90808
90809
90810
90811
90812
90813
90814
90815
90816
90817
90818
90819
90820
90821
90822
90823
90824
90825
90826
90827
90828
90829
90830
90831
90832
90833
90834
90835
90836
90837
90838
90839
90840
90841
90842
90843
90844
90845
90846
90847
90848
90849
90850
90851
90852
90853
90854
90855
90856
90857
90858
90859
90860
90861
90862
90863
90864
90865
90866
90867
90868
90869
90870
90871
90872
90873
90874
90875
90876
90877
90878
90879
90880
90881
90882
90883
90884
90885
90886
90887
90888
90889
90890
90891
90892
90893
90894
90895
90896
90897
90898
90899
90900
90901
90902
90903
90904
90905
90906
90907
90908
90909
90910
90911
90912
90913
90914
90915
90916
90917
90918
90919
90920
90921
90922
90923
90924
90925
90926
90927
90928
90929
90930
90931
90932
90933
90934
90935
90936
90937
90938
90939
90940
90941
90942
90943
90944
90945
90946
90947
90948
90949
90950
90951
90952
90953
90954
90955
90956
90957
90958
90959
90960
90961
90962
90963
90964
90965
90966
90967
90968
90969
90970
90971
90972
90973
90974
90975
90976
90977
90978
90979
90980
90981
90982
90983
90984
90985
90986
90987
90988
90989
90990
90991
90992
90993
90994
90995
90996
90997
90998
90999
91000
91001
91002
91003
91004
91005
91006
91007
91008
91009
91010
91011
91012
91013
91014
91015
91016
91017
91018
91019
91020
91021
91022
91023
91024
91025
91026
91027
91028
91029
91030
91031
91032
91033
91034
91035
91036
91037
91038
91039
91040
91041
91042
91043
91044
91045
91046
91047
91048
91049
91050
91051
91052
91053
91054
91055
91056
91057
91058
91059
91060
91061
91062
91063
91064
91065
91066
91067
91068
91069
91070
91071
91072
91073
91074
91075
91076
91077
91078
91079
91080
91081
91082
91083
91084
91085
91086
91087
91088
91089
91090
91091
91092
91093
91094
91095
91096
91097
91098
91099
91100
91101
91102
91103
91104
91105
91106
91107
91108
91109
91110
91111
91112
91113
91114
91115
91116
91117
91118
91119
91120
91121
91122
91123
91124
91125
91126
91127
91128
91129
91130
91131
91132
91133
91134
91135
91136
91137
91138
91139
91140
91141
91142
91143
91144
91145
91146
91147
91148
91149
91150
91151
91152
91153
91154
91155
91156
91157
91158
91159
91160
91161
91162
91163
91164
91165
91166
91167
91168
91169
91170
91171
91172
91173
91174
91175
91176
91177
91178
91179
91180
91181
91182
91183
91184
91185
91186
91187
91188
91189
91190
91191
91192
91193
91194
91195
91196
91197
91198
91199
91200
91201
91202
91203
91204
91205
91206
91207
91208
91209
91210
91211
91212
91213
91214
91215
91216
91217
91218
91219
91220
91221
91222
91223
91224
91225
91226
91227
91228
91229
91230
91231
91232
91233
91234
91235
91236
91237
91238
91239
91240
91241
91242
91243
91244
91245
91246
91247
91248
91249
91250
91251
91252
91253
91254
91255
91256
91257
91258
91259
91260
91261
91262
91263
91264
91265
91266
91267
91268
91269
91270
91271
91272
91273
91274
91275
91276
91277
91278
91279
91280
91281
91282
91283
91284
91285
91286
91287
91288
91289
91290
91291
91292
91293
91294
91295
91296
91297
91298
91299
91300
91301
91302
91303
91304
91305
91306
91307
91308
91309
91310
91311
91312
91313
91314
91315
91316
91317
91318
91319
91320
91321
91322
91323
91324
91325
91326
91327
91328
91329
91330
91331
91332
91333
91334
91335
91336
91337
91338
91339
91340
91341
91342
91343
91344
91345
91346
91347
91348
91349
91350
91351
91352
91353
91354
91355
91356
91357
91358
91359
91360
91361
91362
91363
91364
91365
91366
91367
91368
91369
91370
91371
91372
91373
91374
91375
91376
91377
91378
91379
91380
91381
91382
91383
91384
91385
91386
91387
91388
91389
91390
91391
91392
91393
91394
91395
91396
91397
91398
91399
91400
91401
91402
91403
91404
91405
91406
91407
91408
91409
91410
91411
91412
91413
91414
91415
91416
91417
91418
91419
91420
91421
91422
91423
91424
91425
91426
91427
91428
91429
91430
91431
91432
91433
91434
91435
91436
91437
91438
91439
91440
91441
91442
91443
91444
91445
91446
91447
91448
91449
91450
91451
91452
91453
91454
91455
91456
91457
91458
91459
91460
91461
91462
91463
91464
91465
91466
91467
91468
91469
91470
91471
91472
91473
91474
91475
91476
91477
91478
91479
91480
91481
91482
91483
91484
91485
91486
91487
91488
91489
91490
91491
91492
91493
91494
91495
91496
91497
91498
91499
91500
91501
91502
91503
91504
91505
91506
91507
91508
91509
91510
91511
91512
91513
91514
91515
91516
91517
91518
91519
91520
91521
91522
91523
91524
91525
91526
91527
91528
91529
91530
91531
91532
91533
91534
91535
91536
91537
91538
91539
91540
91541
91542
91543
91544
91545
91546
91547
91548
91549
91550
91551
91552
91553
91554
91555
91556
91557
91558
91559
91560
91561
91562
91563
91564
91565
91566
91567
91568
91569
91570
91571
91572
91573
91574
91575
91576
91577
91578
91579
91580
91581
91582
91583
91584
91585
91586
91587
91588
91589
91590
91591
91592
91593
91594
91595
91596
91597
91598
91599
91600
91601
91602
91603
91604
91605
91606
91607
91608
91609
91610
91611
91612
91613
91614
91615
91616
91617
91618
91619
91620
91621
91622
91623
91624
91625
91626
91627
91628
91629
91630
91631
91632
91633
91634
91635
91636
91637
91638
91639
91640
91641
91642
91643
91644
91645
91646
91647
91648
91649
91650
91651
91652
91653
91654
91655
91656
91657
91658
91659
91660
91661
91662
91663
91664
91665
91666
91667
91668
91669
91670
91671
91672
91673
91674
91675
91676
91677
91678
91679
91680
91681
91682
91683
91684
91685
91686
91687
91688
91689
91690
91691
91692
91693
91694
91695
91696
91697
91698
91699
91700
91701
91702
91703
91704
91705
91706
91707
91708
91709
91710
91711
91712
91713
91714
91715
91716
91717
91718
91719
91720
91721
91722
91723
91724
91725
91726
91727
91728
91729
91730
91731
91732
91733
91734
91735
91736
91737
91738
91739
91740
91741
91742
91743
91744
91745
91746
91747
91748
91749
91750
91751
91752
91753
91754
91755
91756
91757
91758
91759
91760
91761
91762
91763
91764
91765
91766
91767
91768
91769
91770
91771
91772
91773
91774
91775
91776
91777
91778
91779
91780
91781
91782
91783
91784
91785
91786
91787
91788
91789
91790
91791
91792
91793
91794
91795
91796
91797
91798
91799
91800
91801
91802
91803
91804
91805
91806
91807
91808
91809
91810
91811
91812
91813
91814
91815
91816
91817
91818
91819
91820
91821
91822
91823
91824
91825
91826
91827
91828
91829
91830
91831
91832
91833
91834
91835
91836
91837
91838
91839
91840
91841
91842
91843
91844
91845
91846
91847
91848
91849
91850
91851
91852
91853
91854
91855
91856
91857
91858
91859
91860
91861
91862
91863
91864
91865
91866
91867
91868
91869
91870
91871
91872
91873
91874
91875
91876
91877
91878
91879
91880
91881
91882
91883
91884
91885
91886
91887
91888
91889
91890
91891
91892
91893
91894
91895
91896
91897
91898
91899
91900
91901
91902
91903
91904
91905
91906
91907
91908
91909
91910
91911
91912
91913
91914
91915
91916
91917
91918
91919
91920
91921
91922
91923
91924
91925
91926
91927
91928
91929
91930
91931
91932
91933
91934
91935
91936
91937
91938
91939
91940
91941
91942
91943
91944
91945
91946
91947
91948
91949
91950
91951
91952
91953
91954
91955
91956
91957
91958
91959
91960
91961
91962
91963
91964
91965
91966
91967
91968
91969
91970
91971
91972
91973
91974
91975
91976
91977
91978
91979
91980
91981
91982
91983
91984
91985
91986
91987
91988
91989
91990
91991
91992
91993
91994
91995
91996
91997
91998
91999
92000
92001
92002
92003
92004
92005
92006
92007
92008
92009
92010
92011
92012
92013
92014
92015
92016
92017
92018
92019
92020
92021
92022
92023
92024
92025
92026
92027
92028
92029
92030
92031
92032
92033
92034
92035
92036
92037
92038
92039
92040
92041
92042
92043
92044
92045
92046
92047
92048
92049
92050
92051
92052
92053
92054
92055
92056
92057
92058
92059
92060
92061
92062
92063
92064
92065
92066
92067
92068
92069
92070
92071
92072
92073
92074
92075
92076
92077
92078
92079
92080
92081
92082
92083
92084
92085
92086
92087
92088
92089
92090
92091
92092
92093
92094
92095
92096
92097
92098
92099
92100
92101
92102
92103
92104
92105
92106
92107
92108
92109
92110
92111
92112
92113
92114
92115
92116
92117
92118
92119
92120
92121
92122
92123
92124
92125
92126
92127
92128
92129
92130
92131
92132
92133
92134
92135
92136
92137
92138
92139
92140
92141
92142
92143
92144
92145
92146
92147
92148
92149
92150
92151
92152
92153
92154
92155
92156
92157
92158
92159
92160
92161
92162
92163
92164
92165
92166
92167
92168
92169
92170
92171
92172
92173
92174
92175
92176
92177
92178
92179
92180
92181
92182
92183
92184
92185
92186
92187
92188
92189
92190
92191
92192
92193
92194
92195
92196
92197
92198
92199
92200
92201
92202
92203
92204
92205
92206
92207
92208
92209
92210
92211
92212
92213
92214
92215
92216
92217
92218
92219
92220
92221
92222
92223
92224
92225
92226
92227
92228
92229
92230
92231
92232
92233
92234
92235
92236
92237
92238
92239
92240
92241
92242
92243
92244
92245
92246
92247
92248
92249
92250
92251
92252
92253
92254
92255
92256
92257
92258
92259
92260
92261
92262
92263
92264
92265
92266
92267
92268
92269
92270
92271
92272
92273
92274
92275
92276
92277
92278
92279
92280
92281
92282
92283
92284
92285
92286
92287
92288
92289
92290
92291
92292
92293
92294
92295
92296
92297
92298
92299
92300
92301
92302
92303
92304
92305
92306
92307
92308
92309
92310
92311
92312
92313
92314
92315
92316
92317
92318
92319
92320
92321
92322
92323
92324
92325
92326
92327
92328
92329
92330
92331
92332
92333
92334
92335
92336
92337
92338
92339
92340
92341
92342
92343
92344
92345
92346
92347
92348
92349
92350
92351
92352
92353
92354
92355
92356
92357
92358
92359
92360
92361
92362
92363
92364
92365
92366
92367
92368
92369
92370
92371
92372
92373
92374
92375
92376
92377
92378
92379
92380
92381
92382
92383
92384
92385
92386
92387
92388
92389
92390
92391
92392
92393
92394
92395
92396
92397
92398
92399
92400
92401
92402
92403
92404
92405
92406
92407
92408
92409
92410
92411
92412
92413
92414
92415
92416
92417
92418
92419
92420
92421
92422
92423
92424
92425
92426
92427
92428
92429
92430
92431
92432
92433
92434
92435
92436
92437
92438
92439
92440
92441
92442
92443
92444
92445
92446
92447
92448
92449
92450
92451
92452
92453
92454
92455
92456
92457
92458
92459
92460
92461
92462
92463
92464
92465
92466
92467
92468
92469
92470
92471
92472
92473
92474
92475
92476
92477
92478
92479
92480
92481
92482
92483
92484
92485
92486
92487
92488
92489
92490
92491
92492
92493
92494
92495
92496
92497
92498
92499
92500
92501
92502
92503
92504
92505
92506
92507
92508
92509
92510
92511
92512
92513
92514
92515
92516
92517
92518
92519
92520
92521
92522
92523
92524
92525
92526
92527
92528
92529
92530
92531
92532
92533
92534
92535
92536
92537
92538
92539
92540
92541
92542
92543
92544
92545
92546
92547
92548
92549
92550
92551
92552
92553
92554
92555
92556
92557
92558
92559
92560
92561
92562
92563
92564
92565
92566
92567
92568
92569
92570
92571
92572
92573
92574
92575
92576
92577
92578
92579
92580
92581
92582
92583
92584
92585
92586
92587
92588
92589
92590
92591
92592
92593
92594
92595
92596
92597
92598
92599
92600
92601
92602
92603
92604
92605
92606
92607
92608
92609
92610
92611
92612
92613
92614
92615
92616
92617
92618
92619
92620
92621
92622
92623
92624
92625
92626
92627
92628
92629
92630
92631
92632
92633
92634
92635
92636
92637
92638
92639
92640
92641
92642
92643
92644
92645
92646
92647
92648
92649
92650
92651
92652
92653
92654
92655
92656
92657
92658
92659
92660
92661
92662
92663
92664
92665
92666
92667
92668
92669
92670
92671
92672
92673
92674
92675
92676
92677
92678
92679
92680
92681
92682
92683
92684
92685
92686
92687
92688
92689
92690
92691
92692
92693
92694
92695
92696
92697
92698
92699
92700
92701
92702
92703
92704
92705
92706
92707
92708
92709
92710
92711
92712
92713
92714
92715
92716
92717
92718
92719
92720
92721
92722
92723
92724
92725
92726
92727
92728
92729
92730
92731
92732
92733
92734
92735
92736
92737
92738
92739
92740
92741
92742
92743
92744
92745
92746
92747
92748
92749
92750
92751
92752
92753
92754
92755
92756
92757
92758
92759
92760
92761
92762
92763
92764
92765
92766
92767
92768
92769
92770
92771
92772
92773
92774
92775
92776
92777
92778
92779
92780
92781
92782
92783
92784
92785
92786
92787
92788
92789
92790
92791
92792
92793
92794
92795
92796
92797
92798
92799
92800
92801
92802
92803
92804
92805
92806
92807
92808
92809
92810
92811
92812
92813
92814
92815
92816
92817
92818
92819
92820
92821
92822
92823
92824
92825
92826
92827
92828
92829
92830
92831
92832
92833
92834
92835
92836
92837
92838
92839
92840
92841
92842
92843
92844
92845
92846
92847
92848
92849
92850
92851
92852
92853
92854
92855
92856
92857
92858
92859
92860
92861
92862
92863
92864
92865
92866
92867
92868
92869
92870
92871
92872
92873
92874
92875
92876
92877
92878
92879
92880
92881
92882
92883
92884
92885
92886
92887
92888
92889
92890
92891
92892
92893
92894
92895
92896
92897
92898
92899
92900
92901
92902
92903
92904
92905
92906
92907
92908
92909
92910
92911
92912
92913
92914
92915
92916
92917
92918
92919
92920
92921
92922
92923
92924
92925
92926
92927
92928
92929
92930
92931
92932
92933
92934
92935
92936
92937
92938
92939
92940
92941
92942
92943
92944
92945
92946
92947
92948
92949
92950
92951
92952
92953
92954
92955
92956
92957
92958
92959
92960
92961
92962
92963
92964
92965
92966
92967
92968
92969
92970
92971
92972
92973
92974
92975
92976
92977
92978
92979
92980
92981
92982
92983
92984
92985
92986
92987
92988
92989
92990
92991
92992
92993
92994
92995
92996
92997
92998
92999
93000
93001
93002
93003
93004
93005
93006
93007
93008
93009
93010
93011
93012
93013
93014
93015
93016
93017
93018
93019
93020
93021
93022
93023
93024
93025
93026
93027
93028
93029
93030
93031
93032
93033
93034
93035
93036
93037
93038
93039
93040
93041
93042
93043
93044
93045
93046
93047
93048
93049
93050
93051
93052
93053
93054
93055
93056
93057
93058
93059
93060
93061
93062
93063
93064
93065
93066
93067
93068
93069
93070
93071
93072
93073
93074
93075
93076
93077
93078
93079
93080
93081
93082
93083
93084
93085
93086
93087
93088
93089
93090
93091
93092
93093
93094
93095
93096
93097
93098
93099
93100
93101
93102
93103
93104
93105
93106
93107
93108
93109
93110
93111
93112
93113
93114
93115
93116
93117
93118
93119
93120
93121
93122
93123
93124
93125
93126
93127
93128
93129
93130
93131
93132
93133
93134
93135
93136
93137
93138
93139
93140
93141
93142
93143
93144
93145
93146
93147
93148
93149
93150
93151
93152
93153
93154
93155
93156
93157
93158
93159
93160
93161
93162
93163
93164
93165
93166
93167
93168
93169
93170
93171
93172
93173
93174
93175
93176
93177
93178
93179
93180
93181
93182
93183
93184
93185
93186
93187
93188
93189
93190
93191
93192
93193
93194
93195
93196
93197
93198
93199
93200
93201
93202
93203
93204
93205
93206
93207
93208
93209
93210
93211
93212
93213
93214
93215
93216
93217
93218
93219
93220
93221
93222
93223
93224
93225
93226
93227
93228
93229
93230
93231
93232
93233
93234
93235
93236
93237
93238
93239
93240
93241
93242
93243
93244
93245
93246
93247
93248
93249
93250
93251
93252
93253
93254
93255
93256
93257
93258
93259
93260
93261
93262
93263
93264
93265
93266
93267
93268
93269
93270
93271
93272
93273
93274
93275
93276
93277
93278
93279
93280
93281
93282
93283
93284
93285
93286
93287
93288
93289
93290
93291
93292
93293
93294
93295
93296
93297
93298
93299
93300
93301
93302
93303
93304
93305
93306
93307
93308
93309
93310
93311
93312
93313
93314
93315
93316
93317
93318
93319
93320
93321
93322
93323
93324
93325
93326
93327
93328
93329
93330
93331
93332
93333
93334
93335
93336
93337
93338
93339
93340
93341
93342
93343
93344
93345
93346
93347
93348
93349
93350
93351
93352
93353
93354
93355
93356
93357
93358
93359
93360
93361
93362
93363
93364
93365
93366
93367
93368
93369
93370
93371
93372
93373
93374
93375
93376
93377
93378
93379
93380
93381
93382
93383
93384
93385
93386
93387
93388
93389
93390
93391
93392
93393
93394
93395
93396
93397
93398
93399
93400
93401
93402
93403
93404
93405
93406
93407
93408
93409
93410
93411
93412
93413
93414
93415
93416
93417
93418
93419
93420
93421
93422
93423
93424
93425
93426
93427
93428
93429
93430
93431
93432
93433
93434
93435
93436
93437
93438
93439
93440
93441
93442
93443
93444
93445
93446
93447
93448
93449
93450
93451
93452
93453
93454
93455
93456
93457
93458
93459
93460
93461
93462
93463
93464
93465
93466
93467
93468
93469
93470
93471
93472
93473
93474
93475
93476
93477
93478
93479
93480
93481
93482
93483
93484
93485
93486
93487
93488
93489
93490
93491
93492
93493
93494
93495
93496
93497
93498
93499
93500
93501
93502
93503
93504
93505
93506
93507
93508
93509
93510
93511
93512
93513
93514
93515
93516
93517
93518
93519
93520
93521
93522
93523
93524
93525
93526
93527
93528
93529
93530
93531
93532
93533
93534
93535
93536
93537
93538
93539
93540
93541
93542
93543
93544
93545
93546
93547
93548
93549
93550
93551
93552
93553
93554
93555
93556
93557
93558
93559
93560
93561
93562
93563
93564
93565
93566
93567
93568
93569
93570
93571
93572
93573
93574
93575
93576
93577
93578
93579
93580
93581
93582
93583
93584
93585
93586
93587
93588
93589
93590
93591
93592
93593
93594
93595
93596
93597
93598
93599
93600
93601
93602
93603
93604
93605
93606
93607
93608
93609
93610
93611
93612
93613
93614
93615
93616
93617
93618
93619
93620
93621
93622
93623
93624
93625
93626
93627
93628
93629
93630
93631
93632
93633
93634
93635
93636
93637
93638
93639
93640
93641
93642
93643
93644
93645
93646
93647
93648
93649
93650
93651
93652
93653
93654
93655
93656
93657
93658
93659
93660
93661
93662
93663
93664
93665
93666
93667
93668
93669
93670
93671
93672
93673
93674
93675
93676
93677
93678
93679
93680
93681
93682
93683
93684
93685
93686
93687
93688
93689
93690
93691
93692
93693
93694
93695
93696
93697
93698
93699
93700
93701
93702
93703
93704
93705
93706
93707
93708
93709
93710
93711
93712
93713
93714
93715
93716
93717
93718
93719
93720
93721
93722
93723
93724
93725
93726
93727
93728
93729
93730
93731
93732
93733
93734
93735
93736
93737
93738
93739
93740
93741
93742
93743
93744
93745
93746
93747
93748
93749
93750
93751
93752
93753
93754
93755
93756
93757
93758
93759
93760
93761
93762
93763
93764
93765
93766
93767
93768
93769
93770
93771
93772
93773
93774
93775
93776
93777
93778
93779
93780
93781
93782
93783
93784
93785
93786
93787
93788
93789
93790
93791
93792
93793
93794
93795
93796
93797
93798
93799
93800
93801
93802
93803
93804
93805
93806
93807
93808
93809
93810
93811
93812
93813
93814
93815
93816
93817
93818
93819
93820
93821
93822
93823
93824
93825
93826
93827
93828
93829
93830
93831
93832
93833
93834
93835
93836
93837
93838
93839
93840
93841
93842
93843
93844
93845
93846
93847
93848
93849
93850
93851
93852
93853
93854
93855
93856
93857
93858
93859
93860
93861
93862
93863
93864
93865
93866
93867
93868
93869
93870
93871
93872
93873
93874
93875
93876
93877
93878
93879
93880
93881
93882
93883
93884
93885
93886
93887
93888
93889
93890
93891
93892
93893
93894
93895
93896
93897
93898
93899
93900
93901
93902
93903
93904
93905
93906
93907
93908
93909
93910
93911
93912
93913
93914
93915
93916
93917
93918
93919
93920
93921
93922
93923
93924
93925
93926
93927
93928
93929
93930
93931
93932
93933
93934
93935
93936
93937
93938
93939
93940
93941
93942
93943
93944
93945
93946
93947
93948
93949
93950
93951
93952
93953
93954
93955
93956
93957
93958
93959
93960
93961
93962
93963
93964
93965
93966
93967
93968
93969
93970
93971
93972
93973
93974
93975
93976
93977
93978
93979
93980
93981
93982
93983
93984
93985
93986
93987
93988
93989
93990
93991
93992
93993
93994
93995
93996
93997
93998
93999
94000
94001
94002
94003
94004
94005
94006
94007
94008
94009
94010
94011
94012
94013
94014
94015
94016
94017
94018
94019
94020
94021
94022
94023
94024
94025
94026
94027
94028
94029
94030
94031
94032
94033
94034
94035
94036
94037
94038
94039
94040
94041
94042
94043
94044
94045
94046
94047
94048
94049
94050
94051
94052
94053
94054
94055
94056
94057
94058
94059
94060
94061
94062
94063
94064
94065
94066
94067
94068
94069
94070
94071
94072
94073
94074
94075
94076
94077
94078
94079
94080
94081
94082
94083
94084
94085
94086
94087
94088
94089
94090
94091
94092
94093
94094
94095
94096
94097
94098
94099
94100
94101
94102
94103
94104
94105
94106
94107
94108
94109
94110
94111
94112
94113
94114
94115
94116
94117
94118
94119
94120
94121
94122
94123
94124
94125
94126
94127
94128
94129
94130
94131
94132
94133
94134
94135
94136
94137
94138
94139
94140
94141
94142
94143
94144
94145
94146
94147
94148
94149
94150
94151
94152
94153
94154
94155
94156
94157
94158
94159
94160
94161
94162
94163
94164
94165
94166
94167
94168
94169
94170
94171
94172
94173
94174
94175
94176
94177
94178
94179
94180
94181
94182
94183
94184
94185
94186
94187
94188
94189
94190
94191
94192
94193
94194
94195
94196
94197
94198
94199
94200
94201
94202
94203
94204
94205
94206
94207
94208
94209
94210
94211
94212
94213
94214
94215
94216
94217
94218
94219
94220
94221
94222
94223
94224
94225
94226
94227
94228
94229
94230
94231
94232
94233
94234
94235
94236
94237
94238
94239
94240
94241
94242
94243
94244
94245
94246
94247
94248
94249
94250
94251
94252
94253
94254
94255
94256
94257
94258
94259
94260
94261
94262
94263
94264
94265
94266
94267
94268
94269
94270
94271
94272
94273
94274
94275
94276
94277
94278
94279
94280
94281
94282
94283
94284
94285
94286
94287
94288
94289
94290
94291
94292
94293
94294
94295
94296
94297
94298
94299
94300
94301
94302
94303
94304
94305
94306
94307
94308
94309
94310
94311
94312
94313
94314
94315
94316
94317
94318
94319
94320
94321
94322
94323
94324
94325
94326
94327
94328
94329
94330
94331
94332
94333
94334
94335
94336
94337
94338
94339
94340
94341
94342
94343
94344
94345
94346
94347
94348
94349
94350
94351
94352
94353
94354
94355
94356
94357
94358
94359
94360
94361
94362
94363
94364
94365
94366
94367
94368
94369
94370
94371
94372
94373
94374
94375
94376
94377
94378
94379
94380
94381
94382
94383
94384
94385
94386
94387
94388
94389
94390
94391
94392
94393
94394
94395
94396
94397
94398
94399
94400
94401
94402
94403
94404
94405
94406
94407
94408
94409
94410
94411
94412
94413
94414
94415
94416
94417
94418
94419
94420
94421
94422
94423
94424
94425
94426
94427
94428
94429
94430
94431
94432
94433
94434
94435
94436
94437
94438
94439
94440
94441
94442
94443
94444
94445
94446
94447
94448
94449
94450
94451
94452
94453
94454
94455
94456
94457
94458
94459
94460
94461
94462
94463
94464
94465
94466
94467
94468
94469
94470
94471
94472
94473
94474
94475
94476
94477
94478
94479
94480
94481
94482
94483
94484
94485
94486
94487
94488
94489
94490
94491
94492
94493
94494
94495
94496
94497
94498
94499
94500
94501
94502
94503
94504
94505
94506
94507
94508
94509
94510
94511
94512
94513
94514
94515
94516
94517
94518
94519
94520
94521
94522
94523
94524
94525
94526
94527
94528
94529
94530
94531
94532
94533
94534
94535
94536
94537
94538
94539
94540
94541
94542
94543
94544
94545
94546
94547
94548
94549
94550
94551
94552
94553
94554
94555
94556
94557
94558
94559
94560
94561
94562
94563
94564
94565
94566
94567
94568
94569
94570
94571
94572
94573
94574
94575
94576
94577
94578
94579
94580
94581
94582
94583
94584
94585
94586
94587
94588
94589
94590
94591
94592
94593
94594
94595
94596
94597
94598
94599
94600
94601
94602
94603
94604
94605
94606
94607
94608
94609
94610
94611
94612
94613
94614
94615
94616
94617
94618
94619
94620
94621
94622
94623
94624
94625
94626
94627
94628
94629
94630
94631
94632
94633
94634
94635
94636
94637
94638
94639
94640
94641
94642
94643
94644
94645
94646
94647
94648
94649
94650
94651
94652
94653
94654
94655
94656
94657
94658
94659
94660
94661
94662
94663
94664
94665
94666
94667
94668
94669
94670
94671
94672
94673
94674
94675
94676
94677
94678
94679
94680
94681
94682
94683
94684
94685
94686
94687
94688
94689
94690
94691
94692
94693
94694
94695
94696
94697
94698
94699
94700
94701
94702
94703
94704
94705
94706
94707
94708
94709
94710
94711
94712
94713
94714
94715
94716
94717
94718
94719
94720
94721
94722
94723
94724
94725
94726
94727
94728
94729
94730
94731
94732
94733
94734
94735
94736
94737
94738
94739
94740
94741
94742
94743
94744
94745
94746
94747
94748
94749
94750
94751
94752
94753
94754
94755
94756
94757
94758
94759
94760
94761
94762
94763
94764
94765
94766
94767
94768
94769
94770
94771
94772
94773
94774
94775
94776
94777
94778
94779
94780
94781
94782
94783
94784
94785
94786
94787
94788
94789
94790
94791
94792
94793
94794
94795
94796
94797
94798
94799
94800
94801
94802
94803
94804
94805
94806
94807
94808
94809
94810
94811
94812
94813
94814
94815
94816
94817
94818
94819
94820
94821
94822
94823
94824
94825
94826
94827
94828
94829
94830
94831
94832
94833
94834
94835
94836
94837
94838
94839
94840
94841
94842
94843
94844
94845
94846
94847
94848
94849
94850
94851
94852
94853
94854
94855
94856
94857
94858
94859
94860
94861
94862
94863
94864
94865
94866
94867
94868
94869
94870
94871
94872
94873
94874
94875
94876
94877
94878
94879
94880
94881
94882
94883
94884
94885
94886
94887
94888
94889
94890
94891
94892
94893
94894
94895
94896
94897
94898
94899
94900
94901
94902
94903
94904
94905
94906
94907
94908
94909
94910
94911
94912
94913
94914
94915
94916
94917
94918
94919
94920
94921
94922
94923
94924
94925
94926
94927
94928
94929
94930
94931
94932
94933
94934
94935
94936
94937
94938
94939
94940
94941
94942
94943
94944
94945
94946
94947
94948
94949
94950
94951
94952
94953
94954
94955
94956
94957
94958
94959
94960
94961
94962
94963
94964
94965
94966
94967
94968
94969
94970
94971
94972
94973
94974
94975
94976
94977
94978
94979
94980
94981
94982
94983
94984
94985
94986
94987
94988
94989
94990
94991
94992
94993
94994
94995
94996
94997
94998
94999
95000
95001
95002
95003
95004
95005
95006
95007
95008
95009
95010
95011
95012
95013
95014
95015
95016
95017
95018
95019
95020
95021
95022
95023
95024
95025
95026
95027
95028
95029
95030
95031
95032
95033
95034
95035
95036
95037
95038
95039
95040
95041
95042
95043
95044
95045
95046
95047
95048
95049
95050
95051
95052
95053
95054
95055
95056
95057
95058
95059
95060
95061
95062
95063
95064
95065
95066
95067
95068
95069
95070
95071
95072
95073
95074
95075
95076
95077
95078
95079
95080
95081
95082
95083
95084
95085
95086
95087
95088
95089
95090
95091
95092
95093
95094
95095
95096
95097
95098
95099
95100
95101
95102
95103
95104
95105
95106
95107
95108
95109
95110
95111
95112
95113
95114
95115
95116
95117
95118
95119
95120
95121
95122
95123
95124
95125
95126
95127
95128
95129
95130
95131
95132
95133
95134
95135
95136
95137
95138
95139
95140
95141
95142
95143
95144
95145
95146
95147
95148
95149
95150
95151
95152
95153
95154
95155
95156
95157
95158
95159
95160
95161
95162
95163
95164
95165
95166
95167
95168
95169
95170
95171
95172
95173
95174
95175
95176
95177
95178
95179
95180
95181
95182
95183
95184
95185
95186
95187
95188
95189
95190
95191
95192
95193
95194
95195
95196
95197
95198
95199
95200
95201
95202
95203
95204
95205
95206
95207
95208
95209
95210
95211
95212
95213
95214
95215
95216
95217
95218
95219
95220
95221
95222
95223
95224
95225
95226
95227
95228
95229
95230
95231
95232
95233
95234
95235
95236
95237
95238
95239
95240
95241
95242
95243
95244
95245
95246
95247
95248
95249
95250
95251
95252
95253
95254
95255
95256
95257
95258
95259
95260
95261
95262
95263
95264
95265
95266
95267
95268
95269
95270
95271
95272
95273
95274
95275
95276
95277
95278
95279
95280
95281
95282
95283
95284
95285
95286
95287
95288
95289
95290
95291
95292
95293
95294
95295
95296
95297
95298
95299
95300
95301
95302
95303
95304
95305
95306
95307
95308
95309
95310
95311
95312
95313
95314
95315
95316
95317
95318
95319
95320
95321
95322
95323
95324
95325
95326
95327
95328
95329
95330
95331
95332
95333
95334
95335
95336
95337
95338
95339
95340
95341
95342
95343
95344
95345
95346
95347
95348
95349
95350
95351
95352
95353
95354
95355
95356
95357
95358
95359
95360
95361
95362
95363
95364
95365
95366
95367
95368
95369
95370
95371
95372
95373
95374
95375
95376
95377
95378
95379
95380
95381
95382
95383
95384
95385
95386
95387
95388
95389
95390
95391
95392
95393
95394
95395
95396
95397
95398
95399
95400
95401
95402
95403
95404
95405
95406
95407
95408
95409
95410
95411
95412
95413
95414
95415
95416
95417
95418
95419
95420
95421
95422
95423
95424
95425
95426
95427
95428
95429
95430
95431
95432
95433
95434
95435
95436
95437
95438
95439
95440
95441
95442
95443
95444
95445
95446
95447
95448
95449
95450
95451
95452
95453
95454
95455
95456
95457
95458
95459
95460
95461
95462
95463
95464
95465
95466
95467
95468
95469
95470
95471
95472
95473
95474
95475
95476
95477
95478
95479
95480
95481
95482
95483
95484
95485
95486
95487
95488
95489
95490
95491
95492
95493
95494
95495
95496
95497
95498
95499
95500
95501
95502
95503
95504
95505
95506
95507
95508
95509
95510
95511
95512
95513
95514
95515
95516
95517
95518
95519
95520
95521
95522
95523
95524
95525
95526
95527
95528
95529
95530
95531
95532
95533
95534
95535
95536
95537
95538
95539
95540
95541
95542
95543
95544
95545
95546
95547
95548
95549
95550
95551
95552
95553
95554
95555
95556
95557
95558
95559
95560
95561
95562
95563
95564
95565
95566
95567
95568
95569
95570
95571
95572
95573
95574
95575
95576
95577
95578
95579
95580
95581
95582
95583
95584
95585
95586
95587
95588
95589
95590
95591
95592
95593
95594
95595
95596
95597
95598
95599
95600
95601
95602
95603
95604
95605
95606
95607
95608
95609
95610
95611
95612
95613
95614
95615
95616
95617
95618
95619
95620
95621
95622
95623
95624
95625
95626
95627
95628
95629
95630
95631
95632
95633
95634
95635
95636
95637
95638
95639
95640
95641
95642
95643
95644
95645
95646
95647
95648
95649
95650
95651
95652
95653
95654
95655
95656
95657
95658
95659
95660
95661
95662
95663
95664
95665
95666
95667
95668
95669
95670
95671
95672
95673
95674
95675
95676
95677
95678
95679
95680
95681
95682
95683
95684
95685
95686
95687
95688
95689
95690
95691
95692
95693
95694
95695
95696
95697
95698
95699
95700
95701
95702
95703
95704
95705
95706
95707
95708
95709
95710
95711
95712
95713
95714
95715
95716
95717
95718
95719
95720
95721
95722
95723
95724
95725
95726
95727
95728
95729
95730
95731
95732
95733
95734
95735
95736
95737
95738
95739
95740
95741
95742
95743
95744
95745
95746
95747
95748
95749
95750
95751
95752
95753
95754
95755
95756
95757
95758
95759
95760
95761
95762
95763
95764
95765
95766
95767
95768
95769
95770
95771
95772
95773
95774
95775
95776
95777
95778
95779
95780
95781
95782
95783
95784
95785
95786
95787
95788
95789
95790
95791
95792
95793
95794
95795
95796
95797
95798
95799
95800
95801
95802
95803
95804
95805
95806
95807
95808
95809
95810
95811
95812
95813
95814
95815
95816
95817
95818
95819
95820
95821
95822
95823
95824
95825
95826
95827
95828
95829
95830
95831
95832
95833
95834
95835
95836
95837
95838
95839
95840
95841
95842
95843
95844
95845
95846
95847
95848
95849
95850
95851
95852
95853
95854
95855
95856
95857
95858
95859
95860
95861
95862
95863
95864
95865
95866
95867
95868
95869
95870
95871
95872
95873
95874
95875
95876
95877
95878
95879
95880
95881
95882
95883
95884
95885
95886
95887
95888
95889
95890
95891
95892
95893
95894
95895
95896
95897
95898
95899
95900
95901
95902
95903
95904
95905
95906
95907
95908
95909
95910
95911
95912
95913
95914
95915
95916
95917
95918
95919
95920
95921
95922
95923
95924
95925
95926
95927
95928
95929
95930
95931
95932
95933
95934
95935
95936
95937
95938
95939
95940
95941
95942
95943
95944
95945
95946
95947
95948
95949
95950
95951
95952
95953
95954
95955
95956
95957
95958
95959
95960
95961
95962
95963
95964
95965
95966
95967
95968
95969
95970
95971
95972
95973
95974
95975
95976
95977
95978
95979
95980
95981
95982
95983
95984
95985
95986
95987
95988
95989
95990
95991
95992
95993
95994
95995
95996
95997
95998
95999
96000
96001
96002
96003
96004
96005
96006
96007
96008
96009
96010
96011
96012
96013
96014
96015
96016
96017
96018
96019
96020
96021
96022
96023
96024
96025
96026
96027
96028
96029
96030
96031
96032
96033
96034
96035
96036
96037
96038
96039
96040
96041
96042
96043
96044
96045
96046
96047
96048
96049
96050
96051
96052
96053
96054
96055
96056
96057
96058
96059
96060
96061
96062
96063
96064
96065
96066
96067
96068
96069
96070
96071
96072
96073
96074
96075
96076
96077
96078
96079
96080
96081
96082
96083
96084
96085
96086
96087
96088
96089
96090
96091
96092
96093
96094
96095
96096
96097
96098
96099
96100
96101
96102
96103
96104
96105
96106
96107
96108
96109
96110
96111
96112
96113
96114
96115
96116
96117
96118
96119
96120
96121
96122
96123
96124
96125
96126
96127
96128
96129
96130
96131
96132
96133
96134
96135
96136
96137
96138
96139
96140
96141
96142
96143
96144
96145
96146
96147
96148
96149
96150
96151
96152
96153
96154
96155
96156
96157
96158
96159
96160
96161
96162
96163
96164
96165
96166
96167
96168
96169
96170
96171
96172
96173
96174
96175
96176
96177
96178
96179
96180
96181
96182
96183
96184
96185
96186
96187
96188
96189
96190
96191
96192
96193
96194
96195
96196
96197
96198
96199
96200
96201
96202
96203
96204
96205
96206
96207
96208
96209
96210
96211
96212
96213
96214
96215
96216
96217
96218
96219
96220
96221
96222
96223
96224
96225
96226
96227
96228
96229
96230
96231
96232
96233
96234
96235
96236
96237
96238
96239
96240
96241
96242
96243
96244
96245
96246
96247
96248
96249
96250
96251
96252
96253
96254
96255
96256
96257
96258
96259
96260
96261
96262
96263
96264
96265
96266
96267
96268
96269
96270
96271
96272
96273
96274
96275
96276
96277
96278
96279
96280
96281
96282
96283
96284
96285
96286
96287
96288
96289
96290
96291
96292
96293
96294
96295
96296
96297
96298
96299
96300
96301
96302
96303
96304
96305
96306
96307
96308
96309
96310
96311
96312
96313
96314
96315
96316
96317
96318
96319
96320
96321
96322
96323
96324
96325
96326
96327
96328
96329
96330
96331
96332
96333
96334
96335
96336
96337
96338
96339
96340
96341
96342
96343
96344
96345
96346
96347
96348
96349
96350
96351
96352
96353
96354
96355
96356
96357
96358
96359
96360
96361
96362
96363
96364
96365
96366
96367
96368
96369
96370
96371
96372
96373
96374
96375
96376
96377
96378
96379
96380
96381
96382
96383
96384
96385
96386
96387
96388
96389
96390
96391
96392
96393
96394
96395
96396
96397
96398
96399
96400
96401
96402
96403
96404
96405
96406
96407
96408
96409
96410
96411
96412
96413
96414
96415
96416
96417
96418
96419
96420
96421
96422
96423
96424
96425
96426
96427
96428
96429
96430
96431
96432
96433
96434
96435
96436
96437
96438
96439
96440
96441
96442
96443
96444
96445
96446
96447
96448
96449
96450
96451
96452
96453
96454
96455
96456
96457
96458
96459
96460
96461
96462
96463
96464
96465
96466
96467
96468
96469
96470
96471
96472
96473
96474
96475
96476
96477
96478
96479
96480
96481
96482
96483
96484
96485
96486
96487
96488
96489
96490
96491
96492
96493
96494
96495
96496
96497
96498
96499
96500
96501
96502
96503
96504
96505
96506
96507
96508
96509
96510
96511
96512
96513
96514
96515
96516
96517
96518
96519
96520
96521
96522
96523
96524
96525
96526
96527
96528
96529
96530
96531
96532
96533
96534
96535
96536
96537
96538
96539
96540
96541
96542
96543
96544
96545
96546
96547
96548
96549
96550
96551
96552
96553
96554
96555
96556
96557
96558
96559
96560
96561
96562
96563
96564
96565
96566
96567
96568
96569
96570
96571
96572
96573
96574
96575
96576
96577
96578
96579
96580
96581
96582
96583
96584
96585
96586
96587
96588
96589
96590
96591
96592
96593
96594
96595
96596
96597
96598
96599
96600
96601
96602
96603
96604
96605
96606
96607
96608
96609
96610
96611
96612
96613
96614
96615
96616
96617
96618
96619
96620
96621
96622
96623
96624
96625
96626
96627
96628
96629
96630
96631
96632
96633
96634
96635
96636
96637
96638
96639
96640
96641
96642
96643
96644
96645
96646
96647
96648
96649
96650
96651
96652
96653
96654
96655
96656
96657
96658
96659
96660
96661
96662
96663
96664
96665
96666
96667
96668
96669
96670
96671
96672
96673
96674
96675
96676
96677
96678
96679
96680
96681
96682
96683
96684
96685
96686
96687
96688
96689
96690
96691
96692
96693
96694
96695
96696
96697
96698
96699
96700
96701
96702
96703
96704
96705
96706
96707
96708
96709
96710
96711
96712
96713
96714
96715
96716
96717
96718
96719
96720
96721
96722
96723
96724
96725
96726
96727
96728
96729
96730
96731
96732
96733
96734
96735
96736
96737
96738
96739
96740
96741
96742
96743
96744
96745
96746
96747
96748
96749
96750
96751
96752
96753
96754
96755
96756
96757
96758
96759
96760
96761
96762
96763
96764
96765
96766
96767
96768
96769
96770
96771
96772
96773
96774
96775
96776
96777
96778
96779
96780
96781
96782
96783
96784
96785
96786
96787
96788
96789
96790
96791
96792
96793
96794
96795
96796
96797
96798
96799
96800
96801
96802
96803
96804
96805
96806
96807
96808
96809
96810
96811
96812
96813
96814
96815
96816
96817
96818
96819
96820
96821
96822
96823
96824
96825
96826
96827
96828
96829
96830
96831
96832
96833
96834
96835
96836
96837
96838
96839
96840
96841
96842
96843
96844
96845
96846
96847
96848
96849
96850
96851
96852
96853
96854
96855
96856
96857
96858
96859
96860
96861
96862
96863
96864
96865
96866
96867
96868
96869
96870
96871
96872
96873
96874
96875
96876
96877
96878
96879
96880
96881
96882
96883
96884
96885
96886
96887
96888
96889
96890
96891
96892
96893
96894
96895
96896
96897
96898
96899
96900
96901
96902
96903
96904
96905
96906
96907
96908
96909
96910
96911
96912
96913
96914
96915
96916
96917
96918
96919
96920
96921
96922
96923
96924
96925
96926
96927
96928
96929
96930
96931
96932
96933
96934
96935
96936
96937
96938
96939
96940
96941
96942
96943
96944
96945
96946
96947
96948
96949
96950
96951
96952
96953
96954
96955
96956
96957
96958
96959
96960
96961
96962
96963
96964
96965
96966
96967
96968
96969
96970
96971
96972
96973
96974
96975
96976
96977
96978
96979
96980
96981
96982
96983
96984
96985
96986
96987
96988
96989
96990
96991
96992
96993
96994
96995
96996
96997
96998
96999
97000
97001
97002
97003
97004
97005
97006
97007
97008
97009
97010
97011
97012
97013
97014
97015
97016
97017
97018
97019
97020
97021
97022
97023
97024
97025
97026
97027
97028
97029
97030
97031
97032
97033
97034
97035
97036
97037
97038
97039
97040
97041
97042
97043
97044
97045
97046
97047
97048
97049
97050
97051
97052
97053
97054
97055
97056
97057
97058
97059
97060
97061
97062
97063
97064
97065
97066
97067
97068
97069
97070
97071
97072
97073
97074
97075
97076
97077
97078
97079
97080
97081
97082
97083
97084
97085
97086
97087
97088
97089
97090
97091
97092
97093
97094
97095
97096
97097
97098
97099
97100
97101
97102
97103
97104
97105
97106
97107
97108
97109
97110
97111
97112
97113
97114
97115
97116
97117
97118
97119
97120
97121
97122
97123
97124
97125
97126
97127
97128
97129
97130
97131
97132
97133
97134
97135
97136
97137
97138
97139
97140
97141
97142
97143
97144
97145
97146
97147
97148
97149
97150
97151
97152
97153
97154
97155
97156
97157
97158
97159
97160
97161
97162
97163
97164
97165
97166
97167
97168
97169
97170
97171
97172
97173
97174
97175
97176
97177
97178
97179
97180
97181
97182
97183
97184
97185
97186
97187
97188
97189
97190
97191
97192
97193
97194
97195
97196
97197
97198
97199
97200
97201
97202
97203
97204
97205
97206
97207
97208
97209
97210
97211
97212
97213
97214
97215
97216
97217
97218
97219
97220
97221
97222
97223
97224
97225
97226
97227
97228
97229
97230
97231
97232
97233
97234
97235
97236
97237
97238
97239
97240
97241
97242
97243
97244
97245
97246
97247
97248
97249
97250
97251
97252
97253
97254
97255
97256
97257
97258
97259
97260
97261
97262
97263
97264
97265
97266
97267
97268
97269
97270
97271
97272
97273
97274
97275
97276
97277
97278
97279
97280
97281
97282
97283
97284
97285
97286
97287
97288
97289
97290
97291
97292
97293
97294
97295
97296
97297
97298
97299
97300
97301
97302
97303
97304
97305
97306
97307
97308
97309
97310
97311
97312
97313
97314
97315
97316
97317
97318
97319
97320
97321
97322
97323
97324
97325
97326
97327
97328
97329
97330
97331
97332
97333
97334
97335
97336
97337
97338
97339
97340
97341
97342
97343
97344
97345
97346
97347
97348
97349
97350
97351
97352
97353
97354
97355
97356
97357
97358
97359
97360
97361
97362
97363
97364
97365
97366
97367
97368
97369
97370
97371
97372
97373
97374
97375
97376
97377
97378
97379
97380
97381
97382
97383
97384
97385
97386
97387
97388
97389
97390
97391
97392
97393
97394
97395
97396
97397
97398
97399
97400
97401
97402
97403
97404
97405
97406
97407
97408
97409
97410
97411
97412
97413
97414
97415
97416
97417
97418
97419
97420
97421
97422
97423
97424
97425
97426
97427
97428
97429
97430
97431
97432
97433
97434
97435
97436
97437
97438
97439
97440
97441
97442
97443
97444
97445
97446
97447
97448
97449
97450
97451
97452
97453
97454
97455
97456
97457
97458
97459
97460
97461
97462
97463
97464
97465
97466
97467
97468
97469
97470
97471
97472
97473
97474
97475
97476
97477
97478
97479
97480
97481
97482
97483
97484
97485
97486
97487
97488
97489
97490
97491
97492
97493
97494
97495
97496
97497
97498
97499
97500
97501
97502
97503
97504
97505
97506
97507
97508
97509
97510
97511
97512
97513
97514
97515
97516
97517
97518
97519
97520
97521
97522
97523
97524
97525
97526
97527
97528
97529
97530
97531
97532
97533
97534
97535
97536
97537
97538
97539
97540
97541
97542
97543
97544
97545
97546
97547
97548
97549
97550
97551
97552
97553
97554
97555
97556
97557
97558
97559
97560
97561
97562
97563
97564
97565
97566
97567
97568
97569
97570
97571
97572
97573
97574
97575
97576
97577
97578
97579
97580
97581
97582
97583
97584
97585
97586
97587
97588
97589
97590
97591
97592
97593
97594
97595
97596
97597
97598
97599
97600
97601
97602
97603
97604
97605
97606
97607
97608
97609
97610
97611
97612
97613
97614
97615
97616
97617
97618
97619
97620
97621
97622
97623
97624
97625
97626
97627
97628
97629
97630
97631
97632
97633
97634
97635
97636
97637
97638
97639
97640
97641
97642
97643
97644
97645
97646
97647
97648
97649
97650
97651
97652
97653
97654
97655
97656
97657
97658
97659
97660
97661
97662
97663
97664
97665
97666
97667
97668
97669
97670
97671
97672
97673
97674
97675
97676
97677
97678
97679
97680
97681
97682
97683
97684
97685
97686
97687
97688
97689
97690
97691
97692
97693
97694
97695
97696
97697
97698
97699
97700
97701
97702
97703
97704
97705
97706
97707
97708
97709
97710
97711
97712
97713
97714
97715
97716
97717
97718
97719
97720
97721
97722
97723
97724
97725
97726
97727
97728
97729
97730
97731
97732
97733
97734
97735
97736
97737
97738
97739
97740
97741
97742
97743
97744
97745
97746
97747
97748
97749
97750
97751
97752
97753
97754
97755
97756
97757
97758
97759
97760
97761
97762
97763
97764
97765
97766
97767
97768
97769
97770
97771
97772
97773
97774
97775
97776
97777
97778
97779
97780
97781
97782
97783
97784
97785
97786
97787
97788
97789
97790
97791
97792
97793
97794
97795
97796
97797
97798
97799
97800
97801
97802
97803
97804
97805
97806
97807
97808
97809
97810
97811
97812
97813
97814
97815
97816
97817
97818
97819
97820
97821
97822
97823
97824
97825
97826
97827
97828
97829
97830
97831
97832
97833
97834
97835
97836
97837
97838
97839
97840
97841
97842
97843
97844
97845
97846
97847
97848
97849
97850
97851
97852
97853
97854
97855
97856
97857
97858
97859
97860
97861
97862
97863
97864
97865
97866
97867
97868
97869
97870
97871
97872
97873
97874
97875
97876
97877
97878
97879
97880
97881
97882
97883
97884
97885
97886
97887
97888
97889
97890
97891
97892
97893
97894
97895
97896
97897
97898
97899
97900
97901
97902
97903
97904
97905
97906
97907
97908
97909
97910
97911
97912
97913
97914
97915
97916
97917
97918
97919
97920
97921
97922
97923
97924
97925
97926
97927
97928
97929
97930
97931
97932
97933
97934
97935
97936
97937
97938
97939
97940
97941
97942
97943
97944
97945
97946
97947
97948
97949
97950
97951
97952
97953
97954
97955
97956
97957
97958
97959
97960
97961
97962
97963
97964
97965
97966
97967
97968
97969
97970
97971
97972
97973
97974
97975
97976
97977
97978
97979
97980
97981
97982
97983
97984
97985
97986
97987
97988
97989
97990
97991
97992
97993
97994
97995
97996
97997
97998
97999
98000
98001
98002
98003
98004
98005
98006
98007
98008
98009
98010
98011
98012
98013
98014
98015
98016
98017
98018
98019
98020
98021
98022
98023
98024
98025
98026
98027
98028
98029
98030
98031
98032
98033
98034
98035
98036
98037
98038
98039
98040
98041
98042
98043
98044
98045
98046
98047
98048
98049
98050
98051
98052
98053
98054
98055
98056
98057
98058
98059
98060
98061
98062
98063
98064
98065
98066
98067
98068
98069
98070
98071
98072
98073
98074
98075
98076
98077
98078
98079
98080
98081
98082
98083
98084
98085
98086
98087
98088
98089
98090
98091
98092
98093
98094
98095
98096
98097
98098
98099
98100
98101
98102
98103
98104
98105
98106
98107
98108
98109
98110
98111
98112
98113
98114
98115
98116
98117
98118
98119
98120
98121
98122
98123
98124
98125
98126
98127
98128
98129
98130
98131
98132
98133
98134
98135
98136
98137
98138
98139
98140
98141
98142
98143
98144
98145
98146
98147
98148
98149
98150
98151
98152
98153
98154
98155
98156
98157
98158
98159
98160
98161
98162
98163
98164
98165
98166
98167
98168
98169
98170
98171
98172
98173
98174
98175
98176
98177
98178
98179
98180
98181
98182
98183
98184
98185
98186
98187
98188
98189
98190
98191
98192
98193
98194
98195
98196
98197
98198
98199
98200
98201
98202
98203
98204
98205
98206
98207
98208
98209
98210
98211
98212
98213
98214
98215
98216
98217
98218
98219
98220
98221
98222
98223
98224
98225
98226
98227
98228
98229
98230
98231
98232
98233
98234
98235
98236
98237
98238
98239
98240
98241
98242
98243
98244
98245
98246
98247
98248
98249
98250
98251
98252
98253
98254
98255
98256
98257
98258
98259
98260
98261
98262
98263
98264
98265
98266
98267
98268
98269
98270
98271
98272
98273
98274
98275
98276
98277
98278
98279
98280
98281
98282
98283
98284
98285
98286
98287
98288
98289
98290
98291
98292
98293
98294
98295
98296
98297
98298
98299
98300
98301
98302
98303
98304
98305
98306
98307
98308
98309
98310
98311
98312
98313
98314
98315
98316
98317
98318
98319
98320
98321
98322
98323
98324
98325
98326
98327
98328
98329
98330
98331
98332
98333
98334
98335
98336
98337
98338
98339
98340
98341
98342
98343
98344
98345
98346
98347
98348
98349
98350
98351
98352
98353
98354
98355
98356
98357
98358
98359
98360
98361
98362
98363
98364
98365
98366
98367
98368
98369
98370
98371
98372
98373
98374
98375
98376
98377
98378
98379
98380
98381
98382
98383
98384
98385
98386
98387
98388
98389
98390
98391
98392
98393
98394
98395
98396
98397
98398
98399
98400
98401
98402
98403
98404
98405
98406
98407
98408
98409
98410
98411
98412
98413
98414
98415
98416
98417
98418
98419
98420
98421
98422
98423
98424
98425
98426
98427
98428
98429
98430
98431
98432
98433
98434
98435
98436
98437
98438
98439
98440
98441
98442
98443
98444
98445
98446
98447
98448
98449
98450
98451
98452
98453
98454
98455
98456
98457
98458
98459
98460
98461
98462
98463
98464
98465
98466
98467
98468
98469
98470
98471
98472
98473
98474
98475
98476
98477
98478
98479
98480
98481
98482
98483
98484
98485
98486
98487
98488
98489
98490
98491
98492
98493
98494
98495
98496
98497
98498
98499
98500
98501
98502
98503
98504
98505
98506
98507
98508
98509
98510
98511
98512
98513
98514
98515
98516
98517
98518
98519
98520
98521
98522
98523
98524
98525
98526
98527
98528
98529
98530
98531
98532
98533
98534
98535
98536
98537
98538
98539
98540
98541
98542
98543
98544
98545
98546
98547
98548
98549
98550
98551
98552
98553
98554
98555
98556
98557
98558
98559
98560
98561
98562
98563
98564
98565
98566
98567
98568
98569
98570
98571
98572
98573
98574
98575
98576
98577
98578
98579
98580
98581
98582
98583
98584
98585
98586
98587
98588
98589
98590
98591
98592
98593
98594
98595
98596
98597
98598
98599
98600
98601
98602
98603
98604
98605
98606
98607
98608
98609
98610
98611
98612
98613
98614
98615
98616
98617
98618
98619
98620
98621
98622
98623
98624
98625
98626
98627
98628
98629
98630
98631
98632
98633
98634
98635
98636
98637
98638
98639
98640
98641
98642
98643
98644
98645
98646
98647
98648
98649
98650
98651
98652
98653
98654
98655
98656
98657
98658
98659
98660
98661
98662
98663
98664
98665
98666
98667
98668
98669
98670
98671
98672
98673
98674
98675
98676
98677
98678
98679
98680
98681
98682
98683
98684
98685
98686
98687
98688
98689
98690
98691
98692
98693
98694
98695
98696
98697
98698
98699
98700
98701
98702
98703
98704
98705
98706
98707
98708
98709
98710
98711
98712
98713
98714
98715
98716
98717
98718
98719
98720
98721
98722
98723
98724
98725
98726
98727
98728
98729
98730
98731
98732
98733
98734
98735
98736
98737
98738
98739
98740
98741
98742
98743
98744
98745
98746
98747
98748
98749
98750
98751
98752
98753
98754
98755
98756
98757
98758
98759
98760
98761
98762
98763
98764
98765
98766
98767
98768
98769
98770
98771
98772
98773
98774
98775
98776
98777
98778
98779
98780
98781
98782
98783
98784
98785
98786
98787
98788
98789
98790
98791
98792
98793
98794
98795
98796
98797
98798
98799
98800
98801
98802
98803
98804
98805
98806
98807
98808
98809
98810
98811
98812
98813
98814
98815
98816
98817
98818
98819
98820
98821
98822
98823
98824
98825
98826
98827
98828
98829
98830
98831
98832
98833
98834
98835
98836
98837
98838
98839
98840
98841
98842
98843
98844
98845
98846
98847
98848
98849
98850
98851
98852
98853
98854
98855
98856
98857
98858
98859
98860
98861
98862
98863
98864
98865
98866
98867
98868
98869
98870
98871
98872
98873
98874
98875
98876
98877
98878
98879
98880
98881
98882
98883
98884
98885
98886
98887
98888
98889
98890
98891
98892
98893
98894
98895
98896
98897
98898
98899
98900
98901
98902
98903
98904
98905
98906
98907
98908
98909
98910
98911
98912
98913
98914
98915
98916
98917
98918
98919
98920
98921
98922
98923
98924
98925
98926
98927
98928
98929
98930
98931
98932
98933
98934
98935
98936
98937
98938
98939
98940
98941
98942
98943
98944
98945
98946
98947
98948
98949
98950
98951
98952
98953
98954
98955
98956
98957
98958
98959
98960
98961
98962
98963
98964
98965
98966
98967
98968
98969
98970
98971
98972
98973
98974
98975
98976
98977
98978
98979
98980
98981
98982
98983
98984
98985
98986
98987
98988
98989
98990
98991
98992
98993
98994
98995
98996
98997
98998
98999
99000
99001
99002
99003
99004
99005
99006
99007
99008
99009
99010
99011
99012
99013
99014
99015
99016
99017
99018
99019
99020
99021
99022
99023
99024
99025
99026
99027
99028
99029
99030
99031
99032
99033
99034
99035
99036
99037
99038
99039
99040
99041
99042
99043
99044
99045
99046
99047
99048
99049
99050
99051
99052
99053
99054
99055
99056
99057
99058
99059
99060
99061
99062
99063
99064
99065
99066
99067
99068
99069
99070
99071
99072
99073
99074
99075
99076
99077
99078
99079
99080
99081
99082
99083
99084
99085
99086
99087
99088
99089
99090
99091
99092
99093
99094
99095
99096
99097
99098
99099
99100
99101
99102
99103
99104
99105
99106
99107
99108
99109
99110
99111
99112
99113
99114
99115
99116
99117
99118
99119
99120
99121
99122
99123
99124
99125
99126
99127
99128
99129
99130
99131
99132
99133
99134
99135
99136
99137
99138
99139
99140
99141
99142
99143
99144
99145
99146
99147
99148
99149
99150
99151
99152
99153
99154
99155
99156
99157
99158
99159
99160
99161
99162
99163
99164
99165
99166
99167
99168
99169
99170
99171
99172
99173
99174
99175
99176
99177
99178
99179
99180
99181
99182
99183
99184
99185
99186
99187
99188
99189
99190
99191
99192
99193
99194
99195
99196
99197
99198
99199
99200
99201
99202
99203
99204
99205
99206
99207
99208
99209
99210
99211
99212
99213
99214
99215
99216
99217
99218
99219
99220
99221
99222
99223
99224
99225
99226
99227
99228
99229
99230
99231
99232
99233
99234
99235
99236
99237
99238
99239
99240
99241
99242
99243
99244
99245
99246
99247
99248
99249
99250
99251
99252
99253
99254
99255
99256
99257
99258
99259
99260
99261
99262
99263
99264
99265
99266
99267
99268
99269
99270
99271
99272
99273
99274
99275
99276
99277
99278
99279
99280
99281
99282
99283
99284
99285
99286
99287
99288
99289
99290
99291
99292
99293
99294
99295
99296
99297
99298
99299
99300
99301
99302
99303
99304
99305
99306
99307
99308
99309
99310
99311
99312
99313
99314
99315
99316
99317
99318
99319
99320
99321
99322
99323
99324
99325
99326
99327
99328
99329
99330
99331
99332
99333
99334
99335
99336
99337
99338
99339
99340
99341
99342
99343
99344
99345
99346
99347
99348
99349
99350
99351
99352
99353
99354
99355
99356
99357
99358
99359
99360
99361
99362
99363
99364
99365
99366
99367
99368
99369
99370
99371
99372
99373
99374
99375
99376
99377
99378
99379
99380
99381
99382
99383
99384
99385
99386
99387
99388
99389
99390
99391
99392
99393
99394
99395
99396
99397
99398
99399
99400
99401
99402
99403
99404
99405
99406
99407
99408
99409
99410
99411
99412
99413
99414
99415
99416
99417
99418
99419
99420
99421
99422
99423
99424
99425
99426
99427
99428
99429
99430
99431
99432
99433
99434
99435
99436
99437
99438
99439
99440
99441
99442
99443
99444
99445
99446
99447
99448
99449
99450
99451
99452
99453
99454
99455
99456
99457
99458
99459
99460
99461
99462
99463
99464
99465
99466
99467
99468
99469
99470
99471
99472
99473
99474
99475
99476
99477
99478
99479
99480
99481
99482
99483
99484
99485
99486
99487
99488
99489
99490
99491
99492
99493
99494
99495
99496
99497
99498
99499
99500
99501
99502
99503
99504
99505
99506
99507
99508
99509
99510
99511
99512
99513
99514
99515
99516
99517
99518
99519
99520
99521
99522
99523
99524
99525
99526
99527
99528
99529
99530
99531
99532
99533
99534
99535
99536
99537
99538
99539
99540
99541
99542
99543
99544
99545
99546
99547
99548
99549
99550
99551
99552
99553
99554
99555
99556
99557
99558
99559
99560
99561
99562
99563
99564
99565
99566
99567
99568
99569
99570
99571
99572
99573
99574
99575
99576
99577
99578
99579
99580
99581
99582
99583
99584
99585
99586
99587
99588
99589
99590
99591
99592
99593
99594
99595
99596
99597
99598
99599
99600
99601
99602
99603
99604
99605
99606
99607
99608
99609
99610
99611
99612
99613
99614
99615
99616
99617
99618
99619
99620
99621
99622
99623
99624
99625
99626
99627
99628
99629
99630
99631
99632
99633
99634
99635
99636
99637
99638
99639
99640
99641
99642
99643
99644
99645
99646
99647
99648
99649
99650
99651
99652
99653
99654
99655
99656
99657
99658
99659
99660
99661
99662
99663
99664
99665
99666
99667
99668
99669
99670
99671
99672
99673
99674
99675
99676
99677
99678
99679
99680
99681
99682
99683
99684
99685
99686
99687
99688
99689
99690
99691
99692
99693
99694
99695
99696
99697
99698
99699
99700
99701
99702
99703
99704
99705
99706
99707
99708
99709
99710
99711
99712
99713
99714
99715
99716
99717
99718
99719
99720
99721
99722
99723
99724
99725
99726
99727
99728
99729
99730
99731
99732
99733
99734
99735
99736
99737
99738
99739
99740
99741
99742
99743
99744
99745
99746
99747
99748
99749
99750
99751
99752
99753
99754
99755
99756
99757
99758
99759
99760
99761
99762
99763
99764
99765
99766
99767
99768
99769
99770
99771
99772
99773
99774
99775
99776
99777
99778
99779
99780
99781
99782
99783
99784
99785
99786
99787
99788
99789
99790
99791
99792
99793
99794
99795
99796
99797
99798
99799
99800
99801
99802
99803
99804
99805
99806
99807
99808
99809
99810
99811
99812
99813
99814
99815
99816
99817
99818
99819
99820
99821
99822
99823
99824
99825
99826
99827
99828
99829
99830
99831
99832
99833
99834
99835
99836
99837
99838
99839
99840
99841
99842
99843
99844
99845
99846
99847
99848
99849
99850
99851
99852
99853
99854
99855
99856
99857
99858
99859
99860
99861
99862
99863
99864
99865
99866
99867
99868
99869
99870
99871
99872
99873
99874
99875
99876
99877
99878
99879
99880
99881
99882
99883
99884
99885
99886
99887
99888
99889
99890
99891
99892
99893
99894
99895
99896
99897
99898
99899
99900
99901
99902
99903
99904
99905
99906
99907
99908
99909
99910
99911
99912
99913
99914
99915
99916
99917
99918
99919
99920
99921
99922
99923
99924
99925
99926
99927
99928
99929
99930
99931
99932
99933
99934
99935
99936
99937
99938
99939
99940
99941
99942
99943
99944
99945
99946
99947
99948
99949
99950
99951
99952
99953
99954
99955
99956
99957
99958
99959
99960
99961
99962
99963
99964
99965
99966
99967
99968
99969
99970
99971
99972
99973
99974
99975
99976
99977
99978
99979
99980
99981
99982
99983
99984
99985
99986
99987
99988
99989
99990
99991
99992
99993
99994
99995
99996
99997
99998
99999
100000
100001
100002
100003
100004
100005
100006
100007
100008
100009
100010
100011
100012
100013
100014
100015
100016
100017
100018
100019
100020
100021
100022
100023
100024
100025
100026
100027
100028
100029
100030
100031
100032
100033
100034
100035
100036
100037
100038
100039
100040
100041
100042
100043
100044
100045
100046
100047
100048
100049
100050
100051
100052
100053
100054
100055
100056
100057
100058
100059
100060
100061
100062
100063
100064
100065
100066
100067
100068
100069
100070
100071
100072
100073
100074
100075
100076
100077
100078
100079
100080
100081
100082
100083
100084
100085
100086
100087
100088
100089
100090
100091
100092
100093
100094
100095
100096
100097
100098
100099
100100
100101
100102
100103
100104
100105
100106
100107
100108
100109
100110
100111
100112
100113
100114
100115
100116
100117
100118
100119
100120
100121
100122
100123
100124
100125
100126
100127
100128
100129
100130
100131
100132
100133
100134
100135
100136
100137
100138
100139
100140
100141
100142
100143
100144
100145
100146
100147
100148
100149
100150
100151
100152
100153
100154
100155
100156
100157
100158
100159
100160
100161
100162
100163
100164
100165
100166
100167
100168
100169
100170
100171
100172
100173
100174
100175
100176
100177
100178
100179
100180
100181
100182
100183
100184
100185
100186
100187
100188
100189
100190
100191
100192
100193
100194
100195
100196
100197
100198
100199
100200
100201
100202
100203
100204
100205
100206
100207
100208
100209
100210
100211
100212
100213
100214
100215
100216
100217
100218
100219
100220
100221
100222
100223
100224
100225
100226
100227
100228
100229
100230
100231
100232
100233
100234
100235
100236
100237
100238
100239
100240
100241
100242
100243
100244
100245
100246
100247
100248
100249
100250
100251
100252
100253
100254
100255
100256
100257
100258
100259
100260
100261
100262
100263
100264
100265
100266
100267
100268
100269
100270
100271
100272
100273
100274
100275
100276
100277
100278
100279
100280
100281
100282
100283
100284
100285
100286
100287
100288
100289
100290
100291
100292
100293
100294
100295
100296
100297
100298
100299
100300
100301
100302
100303
100304
100305
100306
100307
100308
100309
100310
100311
100312
100313
100314
100315
100316
100317
100318
100319
100320
100321
100322
100323
100324
100325
100326
100327
100328
100329
100330
100331
100332
100333
100334
100335
100336
100337
100338
100339
100340
100341
100342
100343
100344
100345
100346
100347
100348
100349
100350
100351
100352
100353
100354
100355
100356
100357
100358
100359
100360
100361
100362
100363
100364
100365
100366
100367
100368
100369
100370
100371
100372
100373
100374
100375
100376
100377
100378
100379
100380
100381
100382
100383
100384
100385
100386
100387
100388
100389
100390
100391
100392
100393
100394
100395
100396
100397
100398
100399
100400
100401
100402
100403
100404
100405
100406
100407
100408
100409
100410
100411
100412
100413
100414
100415
100416
100417
100418
100419
100420
100421
100422
100423
100424
100425
100426
100427
100428
100429
100430
100431
100432
100433
100434
100435
100436
100437
100438
100439
100440
100441
100442
100443
100444
100445
100446
100447
100448
100449
100450
100451
100452
100453
100454
100455
100456
100457
100458
100459
100460
100461
100462
100463
100464
100465
100466
100467
100468
100469
100470
100471
100472
100473
100474
100475
100476
100477
100478
100479
100480
100481
100482
100483
100484
100485
100486
100487
100488
100489
100490
100491
100492
100493
100494
100495
100496
100497
100498
100499
100500
100501
100502
100503
100504
100505
100506
100507
100508
100509
100510
100511
100512
100513
100514
100515
100516
100517
100518
100519
100520
100521
100522
100523
100524
100525
100526
100527
100528
100529
100530
100531
100532
100533
100534
100535
100536
100537
100538
100539
100540
100541
100542
100543
100544
100545
100546
100547
100548
100549
100550
100551
100552
100553
100554
100555
100556
100557
100558
100559
100560
100561
100562
100563
100564
100565
100566
100567
100568
100569
100570
100571
100572
100573
100574
100575
100576
100577
100578
100579
100580
100581
100582
100583
100584
100585
100586
100587
100588
100589
100590
100591
100592
100593
100594
100595
100596
100597
100598
100599
100600
100601
100602
100603
100604
100605
100606
100607
100608
100609
100610
100611
100612
100613
100614
100615
100616
100617
100618
100619
100620
100621
100622
100623
100624
100625
100626
100627
100628
100629
100630
100631
100632
100633
100634
100635
100636
100637
100638
100639
100640
100641
100642
100643
100644
100645
100646
100647
100648
100649
100650
100651
100652
100653
100654
100655
100656
100657
100658
100659
100660
100661
100662
100663
100664
100665
100666
100667
100668
100669
100670
100671
100672
100673
100674
100675
100676
100677
100678
100679
100680
100681
100682
100683
100684
100685
100686
100687
100688
100689
100690
100691
100692
100693
100694
100695
100696
100697
100698
100699
100700
100701
100702
100703
100704
100705
100706
100707
100708
100709
100710
100711
100712
100713
100714
100715
100716
100717
100718
100719
100720
100721
100722
100723
100724
100725
100726
100727
100728
100729
100730
100731
100732
100733
100734
100735
100736
100737
100738
100739
100740
100741
100742
100743
100744
100745
100746
100747
100748
100749
100750
100751
100752
100753
100754
100755
100756
100757
100758
100759
100760
100761
100762
100763
100764
100765
100766
100767
100768
100769
100770
100771
100772
100773
100774
100775
100776
100777
100778
100779
100780
100781
100782
100783
100784
100785
100786
100787
100788
100789
100790
100791
100792
100793
100794
100795
100796
100797
100798
100799
100800
100801
100802
100803
100804
100805
100806
100807
100808
100809
100810
100811
100812
100813
100814
100815
100816
100817
100818
100819
100820
100821
100822
100823
100824
100825
100826
100827
100828
100829
100830
100831
100832
100833
100834
100835
100836
100837
100838
100839
100840
100841
100842
100843
100844
100845
100846
100847
100848
100849
100850
100851
100852
100853
100854
100855
100856
100857
100858
100859
100860
100861
100862
100863
100864
100865
100866
100867
100868
100869
100870
100871
100872
100873
100874
100875
100876
100877
100878
100879
100880
100881
100882
100883
100884
100885
100886
100887
100888
100889
100890
100891
100892
100893
100894
100895
100896
100897
100898
100899
100900
100901
100902
100903
100904
100905
100906
100907
100908
100909
100910
100911
100912
100913
100914
100915
100916
100917
100918
100919
100920
100921
100922
100923
100924
100925
100926
100927
100928
100929
100930
100931
100932
100933
100934
100935
100936
100937
100938
100939
100940
100941
100942
100943
100944
100945
100946
100947
100948
100949
100950
100951
100952
100953
100954
100955
100956
100957
100958
100959
100960
100961
100962
100963
100964
100965
100966
100967
100968
100969
100970
100971
100972
100973
100974
100975
100976
100977
100978
100979
100980
100981
100982
100983
100984
100985
100986
100987
100988
100989
100990
100991
100992
100993
100994
100995
100996
100997
100998
100999
101000
101001
101002
101003
101004
101005
101006
101007
101008
101009
101010
101011
101012
101013
101014
101015
101016
101017
101018
101019
101020
101021
101022
101023
101024
101025
101026
101027
101028
101029
101030
101031
101032
101033
101034
101035
101036
101037
101038
101039
101040
101041
101042
101043
101044
101045
101046
101047
101048
101049
101050
101051
101052
101053
101054
101055
101056
101057
101058
101059
101060
101061
101062
101063
101064
101065
101066
101067
101068
101069
101070
101071
101072
101073
101074
101075
101076
101077
101078
101079
101080
101081
101082
101083
101084
101085
101086
101087
101088
101089
101090
101091
101092
101093
101094
101095
101096
101097
101098
101099
101100
101101
101102
101103
101104
101105
101106
101107
101108
101109
101110
101111
101112
101113
101114
101115
101116
101117
101118
101119
101120
101121
101122
101123
101124
101125
101126
101127
101128
101129
101130
101131
101132
101133
101134
101135
101136
101137
101138
101139
101140
101141
101142
101143
101144
101145
101146
101147
101148
101149
101150
101151
101152
101153
101154
101155
101156
101157
101158
101159
101160
101161
101162
101163
101164
101165
101166
101167
101168
101169
101170
101171
101172
101173
101174
101175
101176
101177
101178
101179
101180
101181
101182
101183
101184
101185
101186
101187
101188
101189
101190
101191
101192
101193
101194
101195
101196
101197
101198
101199
101200
101201
101202
101203
101204
101205
101206
101207
101208
101209
101210
101211
101212
101213
101214
101215
101216
101217
101218
101219
101220
101221
101222
101223
101224
101225
101226
101227
101228
101229
101230
101231
101232
101233
101234
101235
101236
101237
101238
101239
101240
101241
101242
101243
101244
101245
101246
101247
101248
101249
101250
101251
101252
101253
101254
101255
101256
101257
101258
101259
101260
101261
101262
101263
101264
101265
101266
101267
101268
101269
101270
101271
101272
101273
101274
101275
101276
101277
101278
101279
101280
101281
101282
101283
101284
101285
101286
101287
101288
101289
101290
101291
101292
101293
101294
101295
101296
101297
101298
101299
101300
101301
101302
101303
101304
101305
101306
101307
101308
101309
101310
101311
101312
101313
101314
101315
101316
101317
101318
101319
101320
101321
101322
101323
101324
101325
101326
101327
101328
101329
101330
101331
101332
101333
101334
101335
101336
101337
101338
101339
101340
101341
101342
101343
101344
101345
101346
101347
101348
101349
101350
101351
101352
101353
101354
101355
101356
101357
101358
101359
101360
101361
101362
101363
101364
101365
101366
101367
101368
101369
101370
101371
101372
101373
101374
101375
101376
101377
101378
101379
101380
101381
101382
101383
101384
101385
101386
101387
101388
101389
101390
101391
101392
101393
101394
101395
101396
101397
101398
101399
101400
101401
101402
101403
101404
101405
101406
101407
101408
101409
101410
101411
101412
101413
101414
101415
101416
101417
101418
101419
101420
101421
101422
101423
101424
101425
101426
101427
101428
101429
101430
101431
101432
101433
101434
101435
101436
101437
101438
101439
101440
101441
101442
101443
101444
101445
101446
101447
101448
101449
101450
101451
101452
101453
101454
101455
101456
101457
101458
101459
101460
101461
101462
101463
101464
101465
101466
101467
101468
101469
101470
101471
101472
101473
101474
101475
101476
101477
101478
101479
101480
101481
101482
101483
101484
101485
101486
101487
101488
101489
101490
101491
101492
101493
101494
101495
101496
101497
101498
101499
101500
101501
101502
101503
101504
101505
101506
101507
101508
101509
101510
101511
101512
101513
101514
101515
101516
101517
101518
101519
101520
101521
101522
101523
101524
101525
101526
101527
101528
101529
101530
101531
101532
101533
101534
101535
101536
101537
101538
101539
101540
101541
101542
101543
101544
101545
101546
101547
101548
101549
101550
101551
101552
101553
101554
101555
101556
101557
101558
101559
101560
101561
101562
101563
101564
101565
101566
101567
101568
101569
101570
101571
101572
101573
101574
101575
101576
101577
101578
101579
101580
101581
101582
101583
101584
101585
101586
101587
101588
101589
101590
101591
101592
101593
101594
101595
101596
101597
101598
101599
101600
101601
101602
101603
101604
101605
101606
101607
101608
101609
101610
101611
101612
101613
101614
101615
101616
101617
101618
101619
101620
101621
101622
101623
101624
101625
101626
101627
101628
101629
101630
101631
101632
101633
101634
101635
101636
101637
101638
101639
101640
101641
101642
101643
101644
101645
101646
101647
101648
101649
101650
101651
101652
101653
101654
101655
101656
101657
101658
101659
101660
101661
101662
101663
101664
101665
101666
101667
101668
101669
101670
101671
101672
101673
101674
101675
101676
101677
101678
101679
101680
101681
101682
101683
101684
101685
101686
101687
101688
101689
101690
101691
101692
101693
101694
101695
101696
101697
101698
101699
101700
101701
101702
101703
101704
101705
101706
101707
101708
101709
101710
101711
101712
101713
101714
101715
101716
101717
101718
101719
101720
101721
101722
101723
101724
101725
101726
101727
101728
101729
101730
101731
101732
101733
101734
101735
101736
101737
101738
101739
101740
101741
101742
101743
101744
101745
101746
101747
101748
101749
101750
101751
101752
101753
101754
101755
101756
101757
101758
101759
101760
101761
101762
101763
101764
101765
101766
101767
101768
101769
101770
101771
101772
101773
101774
101775
101776
101777
101778
101779
101780
101781
101782
101783
101784
101785
101786
101787
101788
101789
101790
101791
101792
101793
101794
101795
101796
101797
101798
101799
101800
101801
101802
101803
101804
101805
101806
101807
101808
101809
101810
101811
101812
101813
101814
101815
101816
101817
101818
101819
101820
101821
101822
101823
101824
101825
101826
101827
101828
101829
101830
101831
101832
101833
101834
101835
101836
101837
101838
101839
101840
101841
101842
101843
101844
101845
101846
101847
101848
101849
101850
101851
101852
101853
101854
101855
101856
101857
101858
101859
101860
101861
101862
101863
101864
101865
101866
101867
101868
101869
101870
101871
101872
101873
101874
101875
101876
101877
101878
101879
101880
101881
101882
101883
101884
101885
101886
101887
101888
101889
101890
101891
101892
101893
101894
101895
101896
101897
101898
101899
101900
101901
101902
101903
101904
101905
101906
101907
101908
101909
101910
101911
101912
101913
101914
101915
101916
101917
101918
101919
101920
101921
101922
101923
101924
101925
101926
101927
101928
101929
101930
101931
101932
101933
101934
101935
101936
101937
101938
101939
101940
101941
101942
101943
101944
101945
101946
101947
101948
101949
101950
101951
101952
101953
101954
101955
101956
101957
101958
101959
101960
101961
101962
101963
101964
101965
101966
101967
101968
101969
101970
101971
101972
101973
101974
101975
101976
101977
101978
101979
101980
101981
101982
101983
101984
101985
101986
101987
101988
101989
101990
101991
101992
101993
101994
101995
101996
101997
101998
101999
102000
102001
102002
102003
102004
102005
102006
102007
102008
102009
102010
102011
102012
102013
102014
102015
102016
102017
102018
102019
102020
102021
102022
102023
102024
102025
102026
102027
102028
102029
102030
102031
102032
102033
102034
102035
102036
102037
102038
102039
102040
102041
102042
102043
102044
102045
102046
102047
102048
102049
102050
102051
102052
102053
102054
102055
102056
102057
102058
102059
102060
102061
102062
102063
102064
102065
102066
102067
102068
102069
102070
102071
102072
102073
102074
102075
102076
102077
102078
102079
102080
102081
102082
102083
102084
102085
102086
102087
102088
102089
102090
102091
102092
102093
102094
102095
102096
102097
102098
102099
102100
102101
102102
102103
102104
102105
102106
102107
102108
102109
102110
102111
102112
102113
102114
102115
102116
102117
102118
102119
102120
102121
102122
102123
102124
102125
102126
102127
102128
102129
102130
102131
102132
102133
102134
102135
102136
102137
102138
102139
102140
102141
102142
102143
102144
102145
102146
102147
102148
102149
102150
102151
102152
102153
102154
102155
102156
102157
102158
102159
102160
102161
102162
102163
102164
102165
102166
102167
102168
102169
102170
102171
102172
102173
102174
102175
102176
102177
102178
102179
102180
102181
102182
102183
102184
102185
102186
102187
102188
102189
102190
102191
102192
102193
102194
102195
102196
102197
102198
102199
102200
102201
102202
102203
102204
102205
102206
102207
102208
102209
102210
102211
102212
102213
102214
102215
102216
102217
102218
102219
102220
102221
102222
102223
102224
102225
102226
102227
102228
102229
102230
102231
102232
102233
102234
102235
102236
102237
102238
102239
102240
102241
102242
102243
102244
102245
102246
102247
102248
102249
102250
102251
102252
102253
102254
102255
102256
102257
102258
102259
102260
102261
102262
102263
102264
102265
102266
102267
102268
102269
102270
102271
102272
102273
102274
102275
102276
102277
102278
102279
102280
102281
102282
102283
102284
102285
102286
102287
102288
102289
102290
102291
102292
102293
102294
102295
102296
102297
102298
102299
102300
102301
102302
102303
102304
102305
102306
102307
102308
102309
102310
102311
102312
102313
102314
102315
102316
102317
102318
102319
102320
102321
102322
102323
102324
102325
102326
102327
102328
102329
102330
102331
102332
102333
102334
102335
102336
102337
102338
102339
102340
102341
102342
102343
102344
102345
102346
102347
102348
102349
102350
102351
102352
102353
102354
102355
102356
102357
102358
102359
102360
102361
102362
102363
102364
102365
102366
102367
102368
102369
102370
102371
102372
102373
102374
102375
102376
102377
102378
102379
102380
102381
102382
102383
102384
102385
102386
102387
102388
102389
102390
102391
102392
102393
102394
102395
102396
102397
102398
102399
102400
102401
102402
102403
102404
102405
102406
102407
102408
102409
102410
102411
102412
102413
102414
102415
102416
102417
102418
102419
102420
102421
102422
102423
102424
102425
102426
102427
102428
102429
102430
102431
102432
102433
102434
102435
102436
102437
102438
102439
102440
102441
102442
102443
102444
102445
102446
102447
102448
102449
102450
102451
102452
102453
102454
102455
102456
102457
102458
102459
102460
102461
102462
102463
102464
102465
102466
102467
102468
102469
102470
102471
102472
102473
102474
102475
102476
102477
102478
102479
102480
102481
102482
102483
102484
102485
102486
102487
102488
102489
102490
102491
102492
102493
102494
102495
102496
102497
102498
102499
102500
102501
102502
102503
102504
102505
102506
102507
102508
102509
102510
102511
102512
102513
102514
102515
102516
102517
102518
102519
102520
102521
102522
102523
102524
102525
102526
102527
102528
102529
102530
102531
102532
102533
102534
102535
102536
102537
102538
102539
102540
102541
102542
102543
102544
102545
102546
102547
102548
102549
102550
102551
102552
102553
102554
102555
102556
102557
102558
102559
102560
102561
102562
102563
102564
102565
102566
102567
102568
102569
102570
102571
102572
102573
102574
102575
102576
102577
102578
102579
102580
102581
102582
102583
102584
102585
102586
102587
102588
102589
102590
102591
102592
102593
102594
102595
102596
102597
102598
102599
102600
102601
102602
102603
102604
102605
102606
102607
102608
102609
102610
102611
102612
102613
102614
102615
102616
102617
102618
102619
102620
102621
102622
102623
102624
102625
102626
102627
102628
102629
102630
102631
102632
102633
102634
102635
102636
102637
102638
102639
102640
102641
102642
102643
102644
102645
102646
102647
102648
102649
102650
102651
102652
102653
102654
102655
102656
102657
102658
102659
102660
102661
102662
102663
102664
102665
102666
102667
102668
102669
102670
102671
102672
102673
102674
102675
102676
102677
102678
102679
102680
102681
102682
102683
102684
102685
102686
102687
102688
102689
102690
102691
102692
102693
102694
102695
102696
102697
102698
102699
102700
102701
102702
102703
102704
102705
102706
102707
102708
102709
102710
102711
102712
102713
102714
102715
102716
102717
102718
102719
102720
102721
102722
102723
102724
102725
102726
102727
102728
102729
102730
102731
102732
102733
102734
102735
102736
102737
102738
102739
102740
102741
102742
102743
102744
102745
102746
102747
102748
102749
102750
102751
102752
102753
102754
102755
102756
102757
102758
102759
102760
102761
102762
102763
102764
102765
102766
102767
102768
102769
102770
102771
102772
102773
102774
102775
102776
102777
102778
102779
102780
102781
102782
102783
102784
102785
102786
102787
102788
102789
102790
102791
102792
102793
102794
102795
102796
102797
102798
102799
102800
102801
102802
102803
102804
102805
102806
102807
102808
102809
102810
102811
102812
102813
102814
102815
102816
102817
102818
102819
102820
102821
102822
102823
102824
102825
102826
102827
102828
102829
102830
102831
102832
102833
102834
102835
102836
102837
102838
102839
102840
102841
102842
102843
102844
102845
102846
102847
102848
102849
102850
102851
102852
102853
102854
102855
102856
102857
102858
102859
102860
102861
102862
102863
102864
102865
102866
102867
102868
102869
102870
102871
102872
102873
102874
102875
102876
102877
102878
102879
102880
102881
102882
102883
102884
102885
102886
102887
102888
102889
102890
102891
102892
102893
102894
102895
102896
102897
102898
102899
102900
102901
102902
102903
102904
102905
102906
102907
102908
102909
102910
102911
102912
102913
102914
102915
102916
102917
102918
102919
102920
102921
102922
102923
102924
102925
102926
102927
102928
102929
102930
102931
102932
102933
102934
102935
102936
102937
102938
102939
102940
102941
102942
102943
102944
102945
102946
102947
102948
102949
102950
102951
102952
102953
102954
102955
102956
102957
102958
102959
102960
102961
102962
102963
102964
102965
102966
102967
102968
102969
102970
102971
102972
102973
102974
102975
102976
102977
102978
102979
102980
102981
102982
102983
102984
102985
102986
102987
102988
102989
102990
102991
102992
102993
102994
102995
102996
102997
102998
102999
103000
103001
103002
103003
103004
103005
103006
103007
103008
103009
103010
103011
103012
103013
103014
103015
103016
103017
103018
103019
103020
103021
103022
103023
103024
103025
103026
103027
103028
103029
103030
103031
103032
103033
103034
103035
103036
103037
103038
103039
103040
103041
103042
103043
103044
103045
103046
103047
103048
103049
103050
103051
103052
103053
103054
103055
103056
103057
103058
103059
103060
103061
103062
103063
103064
103065
103066
103067
103068
103069
103070
103071
103072
103073
103074
103075
103076
103077
103078
103079
103080
103081
103082
103083
103084
103085
103086
103087
103088
103089
103090
103091
103092
103093
103094
103095
103096
103097
103098
103099
103100
103101
103102
103103
103104
103105
103106
103107
103108
103109
103110
103111
103112
103113
103114
103115
103116
103117
103118
103119
103120
103121
103122
103123
103124
103125
103126
103127
103128
103129
103130
103131
103132
103133
103134
103135
103136
103137
103138
103139
103140
103141
103142
103143
103144
103145
103146
103147
103148
103149
103150
103151
103152
103153
103154
103155
103156
103157
103158
103159
103160
103161
103162
103163
103164
103165
103166
103167
103168
103169
103170
103171
103172
103173
103174
103175
103176
103177
103178
103179
103180
103181
103182
103183
103184
103185
103186
103187
103188
103189
103190
103191
103192
103193
103194
103195
103196
103197
103198
103199
103200
103201
103202
103203
103204
103205
103206
103207
103208
103209
103210
103211
103212
103213
103214
103215
103216
103217
103218
103219
103220
103221
103222
103223
103224
103225
103226
103227
103228
103229
103230
103231
103232
103233
103234
103235
103236
103237
103238
103239
103240
103241
103242
103243
103244
103245
103246
103247
103248
103249
103250
103251
103252
103253
103254
103255
103256
103257
103258
103259
103260
103261
103262
103263
103264
103265
103266
103267
103268
103269
103270
103271
103272
103273
103274
103275
103276
103277
103278
103279
103280
103281
103282
103283
103284
103285
103286
103287
103288
103289
103290
103291
103292
103293
103294
103295
103296
103297
103298
103299
103300
103301
103302
103303
103304
103305
103306
103307
103308
103309
103310
103311
103312
103313
103314
103315
103316
103317
103318
103319
103320
103321
103322
103323
103324
103325
103326
103327
103328
103329
103330
103331
103332
103333
103334
103335
103336
103337
103338
103339
103340
103341
103342
103343
103344
103345
103346
103347
103348
103349
103350
103351
103352
103353
103354
103355
103356
103357
103358
103359
103360
103361
103362
103363
103364
103365
103366
103367
103368
103369
103370
103371
103372
103373
103374
103375
103376
103377
103378
103379
103380
103381
103382
103383
103384
103385
103386
103387
103388
103389
103390
103391
103392
103393
103394
103395
103396
103397
103398
103399
103400
103401
103402
103403
103404
103405
103406
103407
103408
103409
103410
103411
103412
103413
103414
103415
103416
103417
103418
103419
103420
103421
103422
103423
103424
103425
103426
103427
103428
103429
103430
103431
103432
103433
103434
103435
103436
103437
103438
103439
103440
103441
103442
103443
103444
103445
103446
103447
103448
103449
103450
103451
103452
103453
103454
103455
103456
103457
103458
103459
103460
103461
103462
103463
103464
103465
103466
103467
103468
103469
103470
103471
103472
103473
103474
103475
103476
103477
103478
103479
103480
103481
103482
103483
103484
103485
103486
103487
103488
103489
103490
103491
103492
103493
103494
103495
103496
103497
103498
103499
103500
103501
103502
103503
103504
103505
103506
103507
103508
103509
103510
103511
103512
103513
103514
103515
103516
103517
103518
103519
103520
103521
103522
103523
103524
103525
103526
103527
103528
103529
103530
103531
103532
103533
103534
103535
103536
103537
103538
103539
103540
103541
103542
103543
103544
103545
103546
103547
103548
103549
103550
103551
103552
103553
103554
103555
103556
103557
103558
103559
103560
103561
103562
103563
103564
103565
103566
103567
103568
103569
103570
103571
103572
103573
103574
103575
103576
103577
103578
103579
103580
103581
103582
103583
103584
103585
103586
103587
103588
103589
103590
103591
103592
103593
103594
103595
103596
103597
103598
103599
103600
103601
103602
103603
103604
103605
103606
103607
103608
103609
103610
103611
103612
103613
103614
103615
103616
103617
103618
103619
103620
103621
103622
103623
103624
103625
103626
103627
103628
103629
103630
103631
103632
103633
103634
103635
103636
103637
103638
103639
103640
103641
103642
103643
103644
103645
103646
103647
103648
103649
103650
103651
103652
103653
103654
103655
103656
103657
103658
103659
103660
103661
103662
103663
103664
103665
103666
103667
103668
103669
103670
103671
103672
103673
103674
103675
103676
103677
103678
103679
103680
103681
103682
103683
103684
103685
103686
103687
103688
103689
103690
103691
103692
103693
103694
103695
103696
103697
103698
103699
103700
103701
103702
103703
103704
103705
103706
103707
103708
103709
103710
103711
103712
103713
103714
103715
103716
103717
103718
103719
103720
103721
103722
103723
103724
103725
103726
103727
103728
103729
103730
103731
103732
103733
103734
103735
103736
103737
103738
103739
103740
103741
103742
103743
103744
103745
103746
103747
103748
103749
103750
103751
103752
103753
103754
103755
103756
103757
103758
103759
103760
103761
103762
103763
103764
103765
103766
103767
103768
103769
103770
103771
103772
103773
103774
103775
103776
103777
103778
103779
103780
103781
103782
103783
103784
103785
103786
103787
103788
103789
103790
103791
103792
103793
103794
103795
103796
103797
103798
103799
103800
103801
103802
103803
103804
103805
103806
103807
103808
103809
103810
103811
103812
103813
103814
103815
103816
103817
103818
103819
103820
103821
103822
103823
103824
103825
103826
103827
103828
103829
103830
103831
103832
103833
103834
103835
103836
103837
103838
103839
103840
103841
103842
103843
103844
103845
103846
103847
103848
103849
103850
103851
103852
103853
103854
103855
103856
103857
103858
103859
103860
103861
103862
103863
103864
103865
103866
103867
103868
103869
103870
103871
103872
103873
103874
103875
103876
103877
103878
103879
103880
103881
103882
103883
103884
103885
103886
103887
103888
103889
103890
103891
103892
103893
103894
103895
103896
103897
103898
103899
103900
103901
103902
103903
103904
103905
103906
103907
103908
103909
103910
103911
103912
103913
103914
103915
103916
103917
103918
103919
103920
103921
103922
103923
103924
103925
103926
103927
103928
103929
103930
103931
103932
103933
103934
103935
103936
103937
103938
103939
103940
103941
103942
103943
103944
103945
103946
103947
103948
103949
103950
103951
103952
103953
103954
103955
103956
103957
103958
103959
103960
103961
103962
103963
103964
103965
103966
103967
103968
103969
103970
103971
103972
103973
103974
103975
103976
103977
103978
103979
103980
103981
103982
103983
103984
103985
103986
103987
103988
103989
103990
103991
103992
103993
103994
103995
103996
103997
103998
103999
104000
104001
104002
104003
104004
104005
104006
104007
104008
104009
104010
104011
104012
104013
104014
104015
104016
104017
104018
104019
104020
104021
104022
104023
104024
104025
104026
104027
104028
104029
104030
104031
104032
104033
104034
104035
104036
104037
104038
104039
104040
104041
104042
104043
104044
104045
104046
104047
104048
104049
104050
104051
104052
104053
104054
104055
104056
104057
104058
104059
104060
104061
104062
104063
104064
104065
104066
104067
104068
104069
104070
104071
104072
104073
104074
104075
104076
104077
104078
104079
104080
104081
104082
104083
104084
104085
104086
104087
104088
104089
104090
104091
104092
104093
104094
104095
104096
104097
104098
104099
104100
104101
104102
104103
104104
104105
104106
104107
104108
104109
104110
104111
104112
104113
104114
104115
104116
104117
104118
104119
104120
104121
104122
104123
104124
104125
104126
104127
104128
104129
104130
104131
104132
104133
104134
104135
104136
104137
104138
104139
104140
104141
104142
104143
104144
104145
104146
104147
104148
104149
104150
104151
104152
104153
104154
104155
104156
104157
104158
104159
104160
104161
104162
104163
104164
104165
104166
104167
104168
104169
104170
104171
104172
104173
104174
104175
104176
104177
104178
104179
104180
104181
104182
104183
104184
104185
104186
104187
104188
104189
104190
104191
104192
104193
104194
104195
104196
104197
104198
104199
104200
104201
104202
104203
104204
104205
104206
104207
104208
104209
104210
104211
104212
104213
104214
104215
104216
104217
104218
104219
104220
104221
104222
104223
104224
104225
104226
104227
104228
104229
104230
104231
104232
104233
104234
104235
104236
104237
104238
104239
104240
104241
104242
104243
104244
104245
104246
104247
104248
104249
104250
104251
104252
104253
104254
104255
104256
104257
104258
104259
104260
104261
104262
104263
104264
104265
104266
104267
104268
104269
104270
104271
104272
104273
104274
104275
104276
104277
104278
104279
104280
104281
104282
104283
104284
104285
104286
104287
104288
104289
104290
104291
104292
104293
104294
104295
104296
104297
104298
104299
104300
104301
104302
104303
104304
104305
104306
104307
104308
104309
104310
104311
104312
104313
104314
104315
104316
104317
104318
104319
104320
104321
104322
104323
104324
104325
104326
104327
104328
104329
104330
104331
104332
104333
104334
104335
104336
104337
104338
104339
104340
104341
104342
104343
104344
104345
104346
104347
104348
104349
104350
104351
104352
104353
104354
104355
104356
104357
104358
104359
104360
104361
104362
104363
104364
104365
104366
104367
104368
104369
104370
104371
104372
104373
104374
104375
104376
104377
104378
104379
104380
104381
104382
104383
104384
104385
104386
104387
104388
104389
104390
104391
104392
104393
104394
104395
104396
104397
104398
104399
104400
104401
104402
104403
104404
104405
104406
104407
104408
104409
104410
104411
104412
104413
104414
104415
104416
104417
104418
104419
104420
104421
104422
104423
104424
104425
104426
104427
104428
104429
104430
104431
104432
104433
104434
104435
104436
104437
104438
104439
104440
104441
104442
104443
104444
104445
104446
104447
104448
104449
104450
104451
104452
104453
104454
104455
104456
104457
104458
104459
104460
104461
104462
104463
104464
104465
104466
104467
104468
104469
104470
104471
104472
104473
104474
104475
104476
104477
104478
104479
104480
104481
104482
104483
104484
104485
104486
104487
104488
104489
104490
104491
104492
104493
104494
104495
104496
104497
104498
104499
104500
104501
104502
104503
104504
104505
104506
104507
104508
104509
104510
104511
104512
104513
104514
104515
104516
104517
104518
104519
104520
104521
104522
104523
104524
104525
104526
104527
104528
104529
104530
104531
104532
104533
104534
104535
104536
104537
104538
104539
104540
104541
104542
104543
104544
104545
104546
104547
104548
104549
104550
104551
104552
104553
104554
104555
104556
104557
104558
104559
104560
104561
104562
104563
104564
104565
104566
104567
104568
104569
104570
104571
104572
104573
104574
104575
104576
104577
104578
104579
104580
104581
104582
104583
104584
104585
104586
104587
104588
104589
104590
104591
104592
104593
104594
104595
104596
104597
104598
104599
104600
104601
104602
104603
104604
104605
104606
104607
104608
104609
104610
104611
104612
104613
104614
104615
104616
104617
104618
104619
104620
104621
104622
104623
104624
104625
104626
104627
104628
104629
104630
104631
104632
104633
104634
104635
104636
104637
104638
104639
104640
104641
104642
104643
104644
104645
104646
104647
104648
104649
104650
104651
104652
104653
104654
104655
104656
104657
104658
104659
104660
104661
104662
104663
104664
104665
104666
104667
104668
104669
104670
104671
104672
104673
104674
104675
104676
104677
104678
104679
104680
104681
104682
104683
104684
104685
104686
104687
104688
104689
104690
104691
104692
104693
104694
104695
104696
104697
104698
104699
104700
104701
104702
104703
104704
104705
104706
104707
104708
104709
104710
104711
104712
104713
104714
104715
104716
104717
104718
104719
104720
104721
104722
104723
104724
104725
104726
104727
104728
104729
104730
104731
104732
104733
104734
104735
104736
104737
104738
104739
104740
104741
104742
104743
104744
104745
104746
104747
104748
104749
104750
104751
104752
104753
104754
104755
104756
104757
104758
104759
104760
104761
104762
104763
104764
104765
104766
104767
104768
104769
104770
104771
104772
104773
104774
104775
104776
104777
104778
104779
104780
104781
104782
104783
104784
104785
104786
104787
104788
104789
104790
104791
104792
104793
104794
104795
104796
104797
104798
104799
104800
104801
104802
104803
104804
104805
104806
104807
104808
104809
104810
104811
104812
104813
104814
104815
104816
104817
104818
104819
104820
104821
104822
104823
104824
104825
104826
104827
104828
104829
104830
104831
104832
104833
104834
104835
104836
104837
104838
104839
104840
104841
104842
104843
104844
104845
104846
104847
104848
104849
104850
104851
104852
104853
104854
104855
104856
104857
104858
104859
104860
104861
104862
104863
104864
104865
104866
104867
104868
104869
104870
104871
104872
104873
104874
104875
104876
104877
104878
104879
104880
104881
104882
104883
104884
104885
104886
104887
104888
104889
104890
104891
104892
104893
104894
104895
104896
104897
104898
104899
104900
104901
104902
104903
104904
104905
104906
104907
104908
104909
104910
104911
104912
104913
104914
104915
104916
104917
104918
104919
104920
104921
104922
104923
104924
104925
104926
104927
104928
104929
104930
104931
104932
104933
104934
104935
104936
104937
104938
104939
104940
104941
104942
104943
104944
104945
104946
104947
104948
104949
104950
104951
104952
104953
104954
104955
104956
104957
104958
104959
104960
104961
104962
104963
104964
104965
104966
104967
104968
104969
104970
104971
104972
104973
104974
104975
104976
104977
104978
104979
104980
104981
104982
104983
104984
104985
104986
104987
104988
104989
104990
104991
104992
104993
104994
104995
104996
104997
104998
104999
105000
105001
105002
105003
105004
105005
105006
105007
105008
105009
105010
105011
105012
105013
105014
105015
105016
105017
105018
105019
105020
105021
105022
105023
105024
105025
105026
105027
105028
105029
105030
105031
105032
105033
105034
105035
105036
105037
105038
105039
105040
105041
105042
105043
105044
105045
105046
105047
105048
105049
105050
105051
105052
105053
105054
105055
105056
105057
105058
105059
105060
105061
105062
105063
105064
105065
105066
105067
105068
105069
105070
105071
105072
105073
105074
105075
105076
105077
105078
105079
105080
105081
105082
105083
105084
105085
105086
105087
105088
105089
105090
105091
105092
105093
105094
105095
105096
105097
105098
105099
105100
105101
105102
105103
105104
105105
105106
105107
105108
105109
105110
105111
105112
105113
105114
105115
105116
105117
105118
105119
105120
105121
105122
105123
105124
105125
105126
105127
105128
105129
105130
105131
105132
105133
105134
105135
105136
105137
105138
105139
105140
105141
105142
105143
105144
105145
105146
105147
105148
105149
105150
105151
105152
105153
105154
105155
105156
105157
105158
105159
105160
105161
105162
105163
105164
105165
105166
105167
105168
105169
105170
105171
105172
105173
105174
105175
105176
105177
105178
105179
105180
105181
105182
105183
105184
105185
105186
105187
105188
105189
105190
105191
105192
105193
105194
105195
105196
105197
105198
105199
105200
105201
105202
105203
105204
105205
105206
105207
105208
105209
105210
105211
105212
105213
105214
105215
105216
105217
105218
105219
105220
105221
105222
105223
105224
105225
105226
105227
105228
105229
105230
105231
105232
105233
105234
105235
105236
105237
105238
105239
105240
105241
105242
105243
105244
105245
105246
105247
105248
105249
105250
105251
105252
105253
105254
105255
105256
105257
105258
105259
105260
105261
105262
105263
105264
105265
105266
105267
105268
105269
105270
105271
105272
105273
105274
105275
105276
105277
105278
105279
105280
105281
105282
105283
105284
105285
105286
105287
105288
105289
105290
105291
105292
105293
105294
105295
105296
105297
105298
105299
105300
105301
105302
105303
105304
105305
105306
105307
105308
105309
105310
105311
105312
105313
105314
105315
105316
105317
105318
105319
105320
105321
105322
105323
105324
105325
105326
105327
105328
105329
105330
105331
105332
105333
105334
105335
105336
105337
105338
105339
105340
105341
105342
105343
105344
105345
105346
105347
105348
105349
105350
105351
105352
105353
105354
105355
105356
105357
105358
105359
105360
105361
105362
105363
105364
105365
105366
105367
105368
105369
105370
105371
105372
105373
105374
105375
105376
105377
105378
105379
105380
105381
105382
105383
105384
105385
105386
105387
105388
105389
105390
105391
105392
105393
105394
105395
105396
105397
105398
105399
105400
105401
105402
105403
105404
105405
105406
105407
105408
105409
105410
105411
105412
105413
105414
105415
105416
105417
105418
105419
105420
105421
105422
105423
105424
105425
105426
105427
105428
105429
105430
105431
105432
105433
105434
105435
105436
105437
105438
105439
105440
105441
105442
105443
105444
105445
105446
105447
105448
105449
105450
105451
105452
105453
105454
105455
105456
105457
105458
105459
105460
105461
105462
105463
105464
105465
105466
105467
105468
105469
105470
105471
105472
105473
105474
105475
105476
105477
105478
105479
105480
105481
105482
105483
105484
105485
105486
105487
105488
105489
105490
105491
105492
105493
105494
105495
105496
105497
105498
105499
105500
105501
105502
105503
105504
105505
105506
105507
105508
105509
105510
105511
105512
105513
105514
105515
105516
105517
105518
105519
105520
105521
105522
105523
105524
105525
105526
105527
105528
105529
105530
105531
105532
105533
105534
105535
105536
105537
105538
105539
105540
105541
105542
105543
105544
105545
105546
105547
105548
105549
105550
105551
105552
105553
105554
105555
105556
105557
105558
105559
105560
105561
105562
105563
105564
105565
105566
105567
105568
105569
105570
105571
105572
105573
105574
105575
105576
105577
105578
105579
105580
105581
105582
105583
105584
105585
105586
105587
105588
105589
105590
105591
105592
105593
105594
105595
105596
105597
105598
105599
105600
105601
105602
105603
105604
105605
105606
105607
105608
105609
105610
105611
105612
105613
105614
105615
105616
105617
105618
105619
105620
105621
105622
105623
105624
105625
105626
105627
105628
105629
105630
105631
105632
105633
105634
105635
105636
105637
105638
105639
105640
105641
105642
105643
105644
105645
105646
105647
105648
105649
105650
105651
105652
105653
105654
105655
105656
105657
105658
105659
105660
105661
105662
105663
105664
105665
105666
105667
105668
105669
105670
105671
105672
105673
105674
105675
105676
105677
105678
105679
105680
105681
105682
105683
105684
105685
105686
105687
105688
105689
105690
105691
105692
105693
105694
105695
105696
105697
105698
105699
105700
105701
105702
105703
105704
105705
105706
105707
105708
105709
105710
105711
105712
105713
105714
105715
105716
105717
105718
105719
105720
105721
105722
105723
105724
105725
105726
105727
105728
105729
105730
105731
105732
105733
105734
105735
105736
105737
105738
105739
105740
105741
105742
105743
105744
105745
105746
105747
105748
105749
105750
105751
105752
105753
105754
105755
105756
105757
105758
105759
105760
105761
105762
105763
105764
105765
105766
105767
105768
105769
105770
105771
105772
105773
105774
105775
105776
105777
105778
105779
105780
105781
105782
105783
105784
105785
105786
105787
105788
105789
105790
105791
105792
105793
105794
105795
105796
105797
105798
105799
105800
105801
105802
105803
105804
105805
105806
105807
105808
105809
105810
105811
105812
105813
105814
105815
105816
105817
105818
105819
105820
105821
105822
105823
105824
105825
105826
105827
105828
105829
105830
105831
105832
105833
105834
105835
105836
105837
105838
105839
105840
105841
105842
105843
105844
105845
105846
105847
105848
105849
105850
105851
105852
105853
105854
105855
105856
105857
105858
105859
105860
105861
105862
105863
105864
105865
105866
105867
105868
105869
105870
105871
105872
105873
105874
105875
105876
105877
105878
105879
105880
105881
105882
105883
105884
105885
105886
105887
105888
105889
105890
105891
105892
105893
105894
105895
105896
105897
105898
105899
105900
105901
105902
105903
105904
105905
105906
105907
105908
105909
105910
105911
105912
105913
105914
105915
105916
105917
105918
105919
105920
105921
105922
105923
105924
105925
105926
105927
105928
105929
105930
105931
105932
105933
105934
105935
105936
105937
105938
105939
105940
105941
105942
105943
105944
105945
105946
105947
105948
105949
105950
105951
105952
105953
105954
105955
105956
105957
105958
105959
105960
105961
105962
105963
105964
105965
105966
105967
105968
105969
105970
105971
105972
105973
105974
105975
105976
105977
105978
105979
105980
105981
105982
105983
105984
105985
105986
105987
105988
105989
105990
105991
105992
105993
105994
105995
105996
105997
105998
105999
106000
106001
106002
106003
106004
106005
106006
106007
106008
106009
106010
106011
106012
106013
106014
106015
106016
106017
106018
106019
106020
106021
106022
106023
106024
106025
106026
106027
106028
106029
106030
106031
106032
106033
106034
106035
106036
106037
106038
106039
106040
106041
106042
106043
106044
106045
106046
106047
106048
106049
106050
106051
106052
106053
106054
106055
106056
106057
106058
106059
106060
106061
106062
106063
106064
106065
106066
106067
106068
106069
106070
106071
106072
106073
106074
106075
106076
106077
106078
106079
106080
106081
106082
106083
106084
106085
106086
106087
106088
106089
106090
106091
106092
106093
106094
106095
106096
106097
106098
106099
106100
106101
106102
106103
106104
106105
106106
106107
106108
106109
106110
106111
106112
106113
106114
106115
106116
106117
106118
106119
106120
106121
106122
106123
106124
106125
106126
106127
106128
106129
106130
106131
106132
106133
106134
106135
106136
106137
106138
106139
106140
106141
106142
106143
106144
106145
106146
106147
106148
106149
106150
106151
106152
106153
106154
106155
106156
106157
106158
106159
106160
106161
106162
106163
106164
106165
106166
106167
106168
106169
106170
106171
106172
106173
106174
106175
106176
106177
106178
106179
106180
106181
106182
106183
106184
106185
106186
106187
106188
106189
106190
106191
106192
106193
106194
106195
106196
106197
106198
106199
106200
106201
106202
106203
106204
106205
106206
106207
106208
106209
106210
106211
106212
106213
106214
106215
106216
106217
106218
106219
106220
106221
106222
106223
106224
106225
106226
106227
106228
106229
106230
106231
106232
106233
106234
106235
106236
106237
106238
106239
106240
106241
106242
106243
106244
106245
106246
106247
106248
106249
106250
106251
106252
106253
106254
106255
106256
106257
106258
106259
106260
106261
106262
106263
106264
106265
106266
106267
106268
106269
106270
106271
106272
106273
106274
106275
106276
106277
106278
106279
106280
106281
106282
106283
106284
106285
106286
106287
106288
106289
106290
106291
106292
106293
106294
106295
106296
106297
106298
106299
106300
106301
106302
106303
106304
106305
106306
106307
106308
106309
106310
106311
106312
106313
106314
106315
106316
106317
106318
106319
106320
106321
106322
106323
106324
106325
106326
106327
106328
106329
106330
106331
106332
106333
106334
106335
106336
106337
106338
106339
106340
106341
106342
106343
106344
106345
106346
106347
106348
106349
106350
106351
106352
106353
106354
106355
106356
106357
106358
106359
106360
106361
106362
106363
106364
106365
106366
106367
106368
106369
106370
106371
106372
106373
106374
106375
106376
106377
106378
106379
106380
106381
106382
106383
106384
106385
106386
106387
106388
106389
106390
106391
106392
106393
106394
106395
106396
106397
106398
106399
106400
106401
106402
106403
106404
106405
106406
106407
106408
106409
106410
106411
106412
106413
106414
106415
106416
106417
106418
106419
106420
106421
106422
106423
106424
106425
106426
106427
106428
106429
106430
106431
106432
106433
106434
106435
106436
106437
106438
106439
106440
106441
106442
106443
106444
106445
106446
106447
106448
106449
106450
106451
106452
106453
106454
106455
106456
106457
106458
106459
106460
106461
106462
106463
106464
106465
106466
106467
106468
106469
106470
106471
106472
106473
106474
106475
106476
106477
106478
106479
106480
106481
106482
106483
106484
106485
106486
106487
106488
106489
106490
106491
106492
106493
106494
106495
106496
106497
106498
106499
106500
106501
106502
106503
106504
106505
106506
106507
106508
106509
106510
106511
106512
106513
106514
106515
106516
106517
106518
106519
106520
106521
106522
106523
106524
106525
106526
106527
106528
106529
106530
106531
106532
106533
106534
106535
106536
106537
106538
106539
106540
106541
106542
106543
106544
106545
106546
106547
106548
106549
106550
106551
106552
106553
106554
106555
106556
106557
106558
106559
106560
106561
106562
106563
106564
106565
106566
106567
106568
106569
106570
106571
106572
106573
106574
106575
106576
106577
106578
106579
106580
106581
106582
106583
106584
106585
106586
106587
106588
106589
106590
106591
106592
106593
106594
106595
106596
106597
106598
106599
106600
106601
106602
106603
106604
106605
106606
106607
106608
106609
106610
106611
106612
106613
106614
106615
106616
106617
106618
106619
106620
106621
106622
106623
106624
106625
106626
106627
106628
106629
106630
106631
106632
106633
106634
106635
106636
106637
106638
106639
106640
106641
106642
106643
106644
106645
106646
106647
106648
106649
106650
106651
106652
106653
106654
106655
106656
106657
106658
106659
106660
106661
106662
106663
106664
106665
106666
106667
106668
106669
106670
106671
106672
106673
106674
106675
106676
106677
106678
106679
106680
106681
106682
106683
106684
106685
106686
106687
106688
106689
106690
106691
106692
106693
106694
106695
106696
106697
106698
106699
106700
106701
106702
106703
106704
106705
106706
106707
106708
106709
106710
106711
106712
106713
106714
106715
106716
106717
106718
106719
106720
106721
106722
106723
106724
106725
106726
106727
106728
106729
106730
106731
106732
106733
106734
106735
106736
106737
106738
106739
106740
106741
106742
106743
106744
106745
106746
106747
106748
106749
106750
106751
106752
106753
106754
106755
106756
106757
106758
106759
106760
106761
106762
106763
106764
106765
106766
106767
106768
106769
106770
106771
106772
106773
106774
106775
106776
106777
106778
106779
106780
106781
106782
106783
106784
106785
106786
106787
106788
106789
106790
106791
106792
106793
106794
106795
106796
106797
106798
106799
106800
106801
106802
106803
106804
106805
106806
106807
106808
106809
106810
106811
106812
106813
106814
106815
106816
106817
106818
106819
106820
106821
106822
106823
106824
106825
106826
106827
106828
106829
106830
106831
106832
106833
106834
106835
106836
106837
106838
106839
106840
106841
106842
106843
106844
106845
106846
106847
106848
106849
106850
106851
106852
106853
106854
106855
106856
106857
106858
106859
106860
106861
106862
106863
106864
106865
106866
106867
106868
106869
106870
106871
106872
106873
106874
106875
106876
106877
106878
106879
106880
106881
106882
106883
106884
106885
106886
106887
106888
106889
106890
106891
106892
106893
106894
106895
106896
106897
106898
106899
106900
106901
106902
106903
106904
106905
106906
106907
106908
106909
106910
106911
106912
106913
106914
106915
106916
106917
106918
106919
106920
106921
106922
106923
106924
106925
106926
106927
106928
106929
106930
106931
106932
106933
106934
106935
106936
106937
106938
106939
106940
106941
106942
106943
106944
106945
106946
106947
106948
106949
106950
106951
106952
106953
106954
106955
106956
106957
106958
106959
106960
106961
106962
106963
106964
106965
106966
106967
106968
106969
106970
106971
106972
106973
106974
106975
106976
106977
106978
106979
106980
106981
106982
106983
106984
106985
106986
106987
106988
106989
106990
106991
106992
106993
106994
106995
106996
106997
106998
106999
107000
107001
107002
107003
107004
107005
107006
107007
107008
107009
107010
107011
107012
107013
107014
107015
107016
107017
107018
107019
107020
107021
107022
107023
107024
107025
107026
107027
107028
107029
107030
107031
107032
107033
107034
107035
107036
107037
107038
107039
107040
107041
107042
107043
107044
107045
107046
107047
107048
107049
107050
107051
107052
107053
107054
107055
107056
107057
107058
107059
107060
107061
107062
107063
107064
107065
107066
107067
107068
107069
107070
107071
107072
107073
107074
107075
107076
107077
107078
107079
107080
107081
107082
107083
107084
107085
107086
107087
107088
107089
107090
107091
107092
107093
107094
107095
107096
107097
107098
107099
107100
107101
107102
107103
107104
107105
107106
107107
107108
107109
107110
107111
107112
107113
107114
107115
107116
107117
107118
107119
107120
107121
107122
107123
107124
107125
107126
107127
107128
107129
107130
107131
107132
107133
107134
107135
107136
107137
107138
107139
107140
107141
107142
107143
107144
107145
107146
107147
107148
107149
107150
107151
107152
107153
107154
107155
107156
107157
107158
107159
107160
107161
107162
107163
107164
107165
107166
107167
107168
107169
107170
107171
107172
107173
107174
107175
107176
107177
107178
107179
107180
107181
107182
107183
107184
107185
107186
107187
107188
107189
107190
107191
107192
107193
107194
107195
107196
107197
107198
107199
107200
107201
107202
107203
107204
107205
107206
107207
107208
107209
107210
107211
107212
107213
107214
107215
107216
107217
107218
107219
107220
107221
107222
107223
107224
107225
107226
107227
107228
107229
107230
107231
107232
107233
107234
107235
107236
107237
107238
107239
107240
107241
107242
107243
107244
107245
107246
107247
107248
107249
107250
107251
107252
107253
107254
107255
107256
107257
107258
107259
107260
107261
107262
107263
107264
107265
107266
107267
107268
107269
107270
107271
107272
107273
107274
107275
107276
107277
107278
107279
107280
107281
107282
107283
107284
107285
107286
107287
107288
107289
107290
107291
107292
107293
107294
107295
107296
107297
107298
107299
107300
107301
107302
107303
107304
107305
107306
107307
107308
107309
107310
107311
107312
107313
107314
107315
107316
107317
107318
107319
107320
107321
107322
107323
107324
107325
107326
107327
107328
107329
107330
107331
107332
107333
107334
107335
107336
107337
107338
107339
107340
107341
107342
107343
107344
107345
107346
107347
107348
107349
107350
107351
107352
107353
107354
107355
107356
107357
107358
107359
107360
107361
107362
107363
107364
107365
107366
107367
107368
107369
107370
107371
107372
107373
107374
107375
107376
107377
107378
107379
107380
107381
107382
107383
107384
107385
107386
107387
107388
107389
107390
107391
107392
107393
107394
107395
107396
107397
107398
107399
107400
107401
107402
107403
107404
107405
107406
107407
107408
107409
107410
107411
107412
107413
107414
107415
107416
107417
107418
107419
107420
107421
107422
107423
107424
107425
107426
107427
107428
107429
107430
107431
107432
107433
107434
107435
107436
107437
107438
107439
107440
107441
107442
107443
107444
107445
107446
107447
107448
107449
107450
107451
107452
107453
107454
107455
107456
107457
107458
107459
107460
107461
107462
107463
107464
107465
107466
107467
107468
107469
107470
107471
107472
107473
107474
107475
107476
107477
107478
107479
107480
107481
107482
107483
107484
107485
107486
107487
107488
107489
107490
107491
107492
107493
107494
107495
107496
107497
107498
107499
107500
107501
107502
107503
107504
107505
107506
107507
107508
107509
107510
107511
107512
107513
107514
107515
107516
107517
107518
107519
107520
107521
107522
107523
107524
107525
107526
107527
107528
107529
107530
107531
107532
107533
107534
107535
107536
107537
107538
107539
107540
107541
107542
107543
107544
107545
107546
107547
107548
107549
107550
107551
107552
107553
107554
107555
107556
107557
107558
107559
107560
107561
107562
107563
107564
107565
107566
107567
107568
107569
107570
107571
107572
107573
107574
107575
107576
107577
107578
107579
107580
107581
107582
107583
107584
107585
107586
107587
107588
107589
107590
107591
107592
107593
107594
107595
107596
107597
107598
107599
107600
107601
107602
107603
107604
107605
107606
107607
107608
107609
107610
107611
107612
107613
107614
107615
107616
107617
107618
107619
107620
107621
107622
107623
107624
107625
107626
107627
107628
107629
107630
107631
107632
107633
107634
107635
107636
107637
107638
107639
107640
107641
107642
107643
107644
107645
107646
107647
107648
107649
107650
107651
107652
107653
107654
107655
107656
107657
107658
107659
107660
107661
107662
107663
107664
107665
107666
107667
107668
107669
107670
107671
107672
107673
107674
107675
107676
107677
107678
107679
107680
107681
107682
107683
107684
107685
107686
107687
107688
107689
107690
107691
107692
107693
107694
107695
107696
107697
107698
107699
107700
107701
107702
107703
107704
107705
107706
107707
107708
107709
107710
107711
107712
107713
107714
107715
107716
107717
107718
107719
107720
107721
107722
107723
107724
107725
107726
107727
107728
107729
107730
107731
107732
107733
107734
107735
107736
107737
107738
107739
107740
107741
107742
107743
107744
107745
107746
107747
107748
107749
107750
107751
107752
107753
107754
107755
107756
107757
107758
107759
107760
107761
107762
107763
107764
107765
107766
107767
107768
107769
107770
107771
107772
107773
107774
107775
107776
107777
107778
107779
107780
107781
107782
107783
107784
107785
107786
107787
107788
107789
107790
107791
107792
107793
107794
107795
107796
107797
107798
107799
107800
107801
107802
107803
107804
107805
107806
107807
107808
107809
107810
107811
107812
107813
107814
107815
107816
107817
107818
107819
107820
107821
107822
107823
107824
107825
107826
107827
107828
107829
107830
107831
107832
107833
107834
107835
107836
107837
107838
107839
107840
107841
107842
107843
107844
107845
107846
107847
107848
107849
107850
107851
107852
107853
107854
107855
107856
107857
107858
107859
107860
107861
107862
107863
107864
107865
107866
107867
107868
107869
107870
107871
107872
107873
107874
107875
107876
107877
107878
107879
107880
107881
107882
107883
107884
107885
107886
107887
107888
107889
107890
107891
107892
107893
107894
107895
107896
107897
107898
107899
107900
107901
107902
107903
107904
107905
107906
107907
107908
107909
107910
107911
107912
107913
107914
107915
107916
107917
107918
107919
107920
107921
107922
107923
107924
107925
107926
107927
107928
107929
107930
107931
107932
107933
107934
107935
107936
107937
107938
107939
107940
107941
107942
107943
107944
107945
107946
107947
107948
107949
107950
107951
107952
107953
107954
107955
107956
107957
107958
107959
107960
107961
107962
107963
107964
107965
107966
107967
107968
107969
107970
107971
107972
107973
107974
107975
107976
107977
107978
107979
107980
107981
107982
107983
107984
107985
107986
107987
107988
107989
107990
107991
107992
107993
107994
107995
107996
107997
107998
107999
108000
108001
108002
108003
108004
108005
108006
108007
108008
108009
108010
108011
108012
108013
108014
108015
108016
108017
108018
108019
108020
108021
108022
108023
108024
108025
108026
108027
108028
108029
108030
108031
108032
108033
108034
108035
108036
108037
108038
108039
108040
108041
108042
108043
108044
108045
108046
108047
108048
108049
108050
108051
108052
108053
108054
108055
108056
108057
108058
108059
108060
108061
108062
108063
108064
108065
108066
108067
108068
108069
108070
108071
108072
108073
108074
108075
108076
108077
108078
108079
108080
108081
108082
108083
108084
108085
108086
108087
108088
108089
108090
108091
108092
108093
108094
108095
108096
108097
108098
108099
108100
108101
108102
108103
108104
108105
108106
108107
108108
108109
108110
108111
108112
108113
108114
108115
108116
108117
108118
108119
108120
108121
108122
108123
108124
108125
108126
108127
108128
108129
108130
108131
108132
108133
108134
108135
108136
108137
108138
108139
108140
108141
108142
108143
108144
108145
108146
108147
108148
108149
108150
108151
108152
108153
108154
108155
108156
108157
108158
108159
108160
108161
108162
108163
108164
108165
108166
108167
108168
108169
108170
108171
108172
108173
108174
108175
108176
108177
108178
108179
108180
108181
108182
108183
108184
108185
108186
108187
108188
108189
108190
108191
108192
108193
108194
108195
108196
108197
108198
108199
108200
108201
108202
108203
108204
108205
108206
108207
108208
108209
108210
108211
108212
108213
108214
108215
108216
108217
108218
108219
108220
108221
108222
108223
108224
108225
108226
108227
108228
108229
108230
108231
108232
108233
108234
108235
108236
108237
108238
108239
108240
108241
108242
108243
108244
108245
108246
108247
108248
108249
108250
108251
108252
108253
108254
108255
108256
108257
108258
108259
108260
108261
108262
108263
108264
108265
108266
108267
108268
108269
108270
108271
108272
108273
108274
108275
108276
108277
108278
108279
108280
108281
108282
108283
108284
108285
108286
108287
108288
108289
108290
108291
108292
108293
108294
108295
108296
108297
108298
108299
108300
108301
108302
108303
108304
108305
108306
108307
108308
108309
108310
108311
108312
108313
108314
108315
108316
108317
108318
108319
108320
108321
108322
108323
108324
108325
108326
108327
108328
108329
108330
108331
108332
108333
108334
108335
108336
108337
108338
108339
108340
108341
108342
108343
108344
108345
108346
108347
108348
108349
108350
108351
108352
108353
108354
108355
108356
108357
108358
108359
108360
108361
108362
108363
108364
108365
108366
108367
108368
108369
108370
108371
108372
108373
108374
108375
108376
108377
108378
108379
108380
108381
108382
108383
108384
108385
108386
108387
108388
108389
108390
108391
108392
108393
108394
108395
108396
108397
108398
108399
108400
108401
108402
108403
108404
108405
108406
108407
108408
108409
108410
108411
108412
108413
108414
108415
108416
108417
108418
108419
108420
108421
108422
108423
108424
108425
108426
108427
108428
108429
108430
108431
108432
108433
108434
108435
108436
108437
108438
108439
108440
108441
108442
108443
108444
108445
108446
108447
108448
108449
108450
108451
108452
108453
108454
108455
108456
108457
108458
108459
108460
108461
108462
108463
108464
108465
108466
108467
108468
108469
108470
108471
108472
108473
108474
108475
108476
108477
108478
108479
108480
108481
108482
108483
108484
108485
108486
108487
108488
108489
108490
108491
108492
108493
108494
108495
108496
108497
108498
108499
108500
108501
108502
108503
108504
108505
108506
108507
108508
108509
108510
108511
108512
108513
108514
108515
108516
108517
108518
108519
108520
108521
108522
108523
108524
108525
108526
108527
108528
108529
108530
108531
108532
108533
108534
108535
108536
108537
108538
108539
108540
108541
108542
108543
108544
108545
108546
108547
108548
108549
108550
108551
108552
108553
108554
108555
108556
108557
108558
108559
108560
108561
108562
108563
108564
108565
108566
108567
108568
108569
108570
108571
108572
108573
108574
108575
108576
108577
108578
108579
108580
108581
108582
108583
108584
108585
108586
108587
108588
108589
108590
108591
108592
108593
108594
108595
108596
108597
108598
108599
108600
108601
108602
108603
108604
108605
108606
108607
108608
108609
108610
108611
108612
108613
108614
108615
108616
108617
108618
108619
108620
108621
108622
108623
108624
108625
108626
108627
108628
108629
108630
108631
108632
108633
108634
108635
108636
108637
108638
108639
108640
108641
108642
108643
108644
108645
108646
108647
108648
108649
108650
108651
108652
108653
108654
108655
108656
108657
108658
108659
108660
108661
108662
108663
108664
108665
108666
108667
108668
108669
108670
108671
108672
108673
108674
108675
108676
108677
108678
108679
108680
108681
108682
108683
108684
108685
108686
108687
108688
108689
108690
108691
108692
108693
108694
108695
108696
108697
108698
108699
108700
108701
108702
108703
108704
108705
108706
108707
108708
108709
108710
108711
108712
108713
108714
108715
108716
108717
108718
108719
108720
108721
108722
108723
108724
108725
108726
108727
108728
108729
108730
108731
108732
108733
108734
108735
108736
108737
108738
108739
108740
108741
108742
108743
108744
108745
108746
108747
108748
108749
108750
108751
108752
108753
108754
108755
108756
108757
108758
108759
108760
108761
108762
108763
108764
108765
108766
108767
108768
108769
108770
108771
108772
108773
108774
108775
108776
108777
108778
108779
108780
108781
108782
108783
108784
108785
108786
108787
108788
108789
108790
108791
108792
108793
108794
108795
108796
108797
108798
108799
108800
108801
108802
108803
108804
108805
108806
108807
108808
108809
108810
108811
108812
108813
108814
108815
108816
108817
108818
108819
108820
108821
108822
108823
108824
108825
108826
108827
108828
108829
108830
108831
108832
108833
108834
108835
108836
108837
108838
108839
108840
108841
108842
108843
108844
108845
108846
108847
108848
108849
108850
108851
108852
108853
108854
108855
108856
108857
108858
108859
108860
108861
108862
108863
108864
108865
108866
108867
108868
108869
108870
108871
108872
108873
108874
108875
108876
108877
108878
108879
108880
108881
108882
108883
108884
108885
108886
108887
108888
108889
108890
108891
108892
108893
108894
108895
108896
108897
108898
108899
108900
108901
108902
108903
108904
108905
108906
108907
108908
108909
108910
108911
108912
108913
108914
108915
108916
108917
108918
108919
108920
108921
108922
108923
108924
108925
108926
108927
108928
108929
108930
108931
108932
108933
108934
108935
108936
108937
108938
108939
108940
108941
108942
108943
108944
108945
108946
108947
108948
108949
108950
108951
108952
108953
108954
108955
108956
108957
108958
108959
108960
108961
108962
108963
108964
108965
108966
108967
108968
108969
108970
108971
108972
108973
108974
108975
108976
108977
108978
108979
108980
108981
108982
108983
108984
108985
108986
108987
108988
108989
108990
108991
108992
108993
108994
108995
108996
108997
108998
108999
109000
109001
109002
109003
109004
109005
109006
109007
109008
109009
109010
109011
109012
109013
109014
109015
109016
109017
109018
109019
109020
109021
109022
109023
109024
109025
109026
109027
109028
109029
109030
109031
109032
109033
109034
109035
109036
109037
109038
109039
109040
109041
109042
109043
109044
109045
109046
109047
109048
109049
109050
109051
109052
109053
109054
109055
109056
109057
109058
109059
109060
109061
109062
109063
109064
109065
109066
109067
109068
109069
109070
109071
109072
109073
109074
109075
109076
109077
109078
109079
109080
109081
109082
109083
109084
109085
109086
109087
109088
109089
109090
109091
109092
109093
109094
109095
109096
109097
109098
109099
109100
109101
109102
109103
109104
109105
109106
109107
109108
109109
109110
109111
109112
109113
109114
109115
109116
109117
109118
109119
109120
109121
109122
109123
109124
109125
109126
109127
109128
109129
109130
109131
109132
109133
109134
109135
109136
109137
109138
109139
109140
109141
109142
109143
109144
109145
109146
109147
109148
109149
109150
109151
109152
109153
109154
109155
109156
109157
109158
109159
109160
109161
109162
109163
109164
109165
109166
109167
109168
109169
109170
109171
109172
109173
109174
109175
109176
109177
109178
109179
109180
109181
109182
109183
109184
109185
109186
109187
109188
109189
109190
109191
109192
109193
109194
109195
109196
109197
109198
109199
109200
109201
109202
109203
109204
109205
109206
109207
109208
109209
109210
109211
109212
109213
109214
109215
109216
109217
109218
109219
109220
109221
109222
109223
109224
109225
109226
109227
109228
109229
109230
109231
109232
109233
109234
109235
109236
109237
109238
109239
109240
109241
109242
109243
109244
109245
109246
109247
109248
109249
109250
109251
109252
109253
109254
109255
109256
109257
109258
109259
109260
109261
109262
109263
109264
109265
109266
109267
109268
109269
109270
109271
109272
109273
109274
109275
109276
109277
109278
109279
109280
109281
109282
109283
109284
109285
109286
109287
109288
109289
109290
109291
109292
109293
109294
109295
109296
109297
109298
109299
109300
109301
109302
109303
109304
109305
109306
109307
109308
109309
109310
109311
109312
109313
109314
109315
109316
109317
109318
109319
109320
109321
109322
109323
109324
109325
109326
109327
109328
109329
109330
109331
109332
109333
109334
109335
109336
109337
109338
109339
109340
109341
109342
109343
109344
109345
109346
109347
109348
109349
109350
109351
109352
109353
109354
109355
109356
109357
109358
109359
109360
109361
109362
109363
109364
109365
109366
109367
109368
109369
109370
109371
109372
109373
109374
109375
109376
109377
109378
109379
109380
109381
109382
109383
109384
109385
109386
109387
109388
109389
109390
109391
109392
109393
109394
109395
109396
109397
109398
109399
109400
109401
109402
109403
109404
109405
109406
109407
109408
109409
109410
109411
109412
109413
109414
109415
109416
109417
109418
109419
109420
109421
109422
109423
109424
109425
109426
109427
109428
109429
109430
109431
109432
109433
109434
109435
109436
109437
109438
109439
109440
109441
109442
109443
109444
109445
109446
109447
109448
109449
109450
109451
109452
109453
109454
109455
109456
109457
109458
109459
109460
109461
109462
109463
109464
109465
109466
109467
109468
109469
109470
109471
109472
109473
109474
109475
109476
109477
109478
109479
109480
109481
109482
109483
109484
109485
109486
109487
109488
109489
109490
109491
109492
109493
109494
109495
109496
109497
109498
109499
109500
109501
109502
109503
109504
109505
109506
109507
109508
109509
109510
109511
109512
109513
109514
109515
109516
109517
109518
109519
109520
109521
109522
109523
109524
109525
109526
109527
109528
109529
109530
109531
109532
109533
109534
109535
109536
109537
109538
109539
109540
109541
109542
109543
109544
109545
109546
109547
109548
109549
109550
109551
109552
109553
109554
109555
109556
109557
109558
109559
109560
109561
109562
109563
109564
109565
109566
109567
109568
109569
109570
109571
109572
109573
109574
109575
109576
109577
109578
109579
109580
109581
109582
109583
109584
109585
109586
109587
109588
109589
109590
109591
109592
109593
109594
109595
109596
109597
109598
109599
109600
109601
109602
109603
109604
109605
109606
109607
109608
109609
109610
109611
109612
109613
109614
109615
109616
109617
109618
109619
109620
109621
109622
109623
109624
109625
109626
109627
109628
109629
109630
109631
109632
109633
109634
109635
109636
109637
109638
109639
109640
109641
109642
109643
109644
109645
109646
109647
109648
109649
109650
109651
109652
109653
109654
109655
109656
109657
109658
109659
109660
109661
109662
109663
109664
109665
109666
109667
109668
109669
109670
109671
109672
109673
109674
109675
109676
109677
109678
109679
109680
109681
109682
109683
109684
109685
109686
109687
109688
109689
109690
109691
109692
109693
109694
109695
109696
109697
109698
109699
109700
109701
109702
109703
109704
109705
109706
109707
109708
109709
109710
109711
109712
109713
109714
109715
109716
109717
109718
109719
109720
109721
109722
109723
109724
109725
109726
109727
109728
109729
109730
109731
109732
109733
109734
109735
109736
109737
109738
109739
109740
109741
109742
109743
109744
109745
109746
109747
109748
109749
109750
109751
109752
109753
109754
109755
109756
109757
109758
109759
109760
109761
109762
109763
109764
109765
109766
109767
109768
109769
109770
109771
109772
109773
109774
109775
109776
109777
109778
109779
109780
109781
109782
109783
109784
109785
109786
109787
109788
109789
109790
109791
109792
109793
109794
109795
109796
109797
109798
109799
109800
109801
109802
109803
109804
109805
109806
109807
109808
109809
109810
109811
109812
109813
109814
109815
109816
109817
109818
109819
109820
109821
109822
109823
109824
109825
109826
109827
109828
109829
109830
109831
109832
109833
109834
109835
109836
109837
109838
109839
109840
109841
109842
109843
109844
109845
109846
109847
109848
109849
109850
109851
109852
109853
109854
109855
109856
109857
109858
109859
109860
109861
109862
109863
109864
109865
109866
109867
109868
109869
109870
109871
109872
109873
109874
109875
109876
109877
109878
109879
109880
109881
109882
109883
109884
109885
109886
109887
109888
109889
109890
109891
109892
109893
109894
109895
109896
109897
109898
109899
109900
109901
109902
109903
109904
109905
109906
109907
109908
109909
109910
109911
109912
109913
109914
109915
109916
109917
109918
109919
109920
109921
109922
109923
109924
109925
109926
109927
109928
109929
109930
109931
109932
109933
109934
109935
109936
109937
109938
109939
109940
109941
109942
109943
109944
109945
109946
109947
109948
109949
109950
109951
109952
109953
109954
109955
109956
109957
109958
109959
109960
109961
109962
109963
109964
109965
109966
109967
109968
109969
109970
109971
109972
109973
109974
109975
109976
109977
109978
109979
109980
109981
109982
109983
109984
109985
109986
109987
109988
109989
109990
109991
109992
109993
109994
109995
109996
109997
109998
109999
110000
110001
110002
110003
110004
110005
110006
110007
110008
110009
110010
110011
110012
110013
110014
110015
110016
110017
110018
110019
110020
110021
110022
110023
110024
110025
110026
110027
110028
110029
110030
110031
110032
110033
110034
110035
110036
110037
110038
110039
110040
110041
110042
110043
110044
110045
110046
110047
110048
110049
110050
110051
110052
110053
110054
110055
110056
110057
110058
110059
110060
110061
110062
110063
110064
110065
110066
110067
110068
110069
110070
110071
110072
110073
110074
110075
110076
110077
110078
110079
110080
110081
110082
110083
110084
110085
110086
110087
110088
110089
110090
110091
110092
110093
110094
110095
110096
110097
110098
110099
110100
110101
110102
110103
110104
110105
110106
110107
110108
110109
110110
110111
110112
110113
110114
110115
110116
110117
110118
110119
110120
110121
110122
110123
110124
110125
110126
110127
110128
110129
110130
110131
110132
110133
110134
110135
110136
110137
110138
110139
110140
110141
110142
110143
110144
110145
110146
110147
110148
110149
110150
110151
110152
110153
110154
110155
110156
110157
110158
110159
110160
110161
110162
110163
110164
110165
110166
110167
110168
110169
110170
110171
110172
110173
110174
110175
110176
110177
110178
110179
110180
110181
110182
110183
110184
110185
110186
110187
110188
110189
110190
110191
110192
110193
110194
110195
110196
110197
110198
110199
110200
110201
110202
110203
110204
110205
110206
110207
110208
110209
110210
110211
110212
110213
110214
110215
110216
110217
110218
110219
110220
110221
110222
110223
110224
110225
110226
110227
110228
110229
110230
110231
110232
110233
110234
110235
110236
110237
110238
110239
110240
110241
110242
110243
110244
110245
110246
110247
110248
110249
110250
110251
110252
110253
110254
110255
110256
110257
110258
110259
110260
110261
110262
110263
110264
110265
110266
110267
110268
110269
110270
110271
110272
110273
110274
110275
110276
110277
110278
110279
110280
110281
110282
110283
110284
110285
110286
110287
110288
110289
110290
110291
110292
110293
110294
110295
110296
110297
110298
110299
110300
110301
110302
110303
110304
110305
110306
110307
110308
110309
110310
110311
110312
110313
110314
110315
110316
110317
110318
110319
110320
110321
110322
110323
110324
110325
110326
110327
110328
110329
110330
110331
110332
110333
110334
110335
110336
110337
110338
110339
110340
110341
110342
110343
110344
110345
110346
110347
110348
110349
110350
110351
110352
110353
110354
110355
110356
110357
110358
110359
110360
110361
110362
110363
110364
110365
110366
110367
110368
110369
110370
110371
110372
110373
110374
110375
110376
110377
110378
110379
110380
110381
110382
110383
110384
110385
110386
110387
110388
110389
110390
110391
110392
110393
110394
110395
110396
110397
110398
110399
110400
110401
110402
110403
110404
110405
110406
110407
110408
110409
110410
110411
110412
110413
110414
110415
110416
110417
110418
110419
110420
110421
110422
110423
110424
110425
110426
110427
110428
110429
110430
110431
110432
110433
110434
110435
110436
110437
110438
110439
110440
110441
110442
110443
110444
110445
110446
110447
110448
110449
110450
110451
110452
110453
110454
110455
110456
110457
110458
110459
110460
110461
110462
110463
110464
110465
110466
110467
110468
110469
110470
110471
110472
110473
110474
110475
110476
110477
110478
110479
110480
110481
110482
110483
110484
110485
110486
110487
110488
110489
110490
110491
110492
110493
110494
110495
110496
110497
110498
110499
110500
110501
110502
110503
110504
110505
110506
110507
110508
110509
110510
110511
110512
110513
110514
110515
110516
110517
110518
110519
110520
110521
110522
110523
110524
110525
110526
110527
110528
110529
110530
110531
110532
110533
110534
110535
110536
110537
110538
110539
110540
110541
110542
110543
110544
110545
110546
110547
110548
110549
110550
110551
110552
110553
110554
110555
110556
110557
110558
110559
110560
110561
110562
110563
110564
110565
110566
110567
110568
110569
110570
110571
110572
110573
110574
110575
110576
110577
110578
110579
110580
110581
110582
110583
110584
110585
110586
110587
110588
110589
110590
110591
110592
110593
110594
110595
110596
110597
110598
110599
110600
110601
110602
110603
110604
110605
110606
110607
110608
110609
110610
110611
110612
110613
110614
110615
110616
110617
110618
110619
110620
110621
110622
110623
110624
110625
110626
110627
110628
110629
110630
110631
110632
110633
110634
110635
110636
110637
110638
110639
110640
110641
110642
110643
110644
110645
110646
110647
110648
110649
110650
110651
110652
110653
110654
110655
110656
110657
110658
110659
110660
110661
110662
110663
110664
110665
110666
110667
110668
110669
110670
110671
110672
110673
110674
110675
110676
110677
110678
110679
110680
110681
110682
110683
110684
110685
110686
110687
110688
110689
110690
110691
110692
110693
110694
110695
110696
110697
110698
110699
110700
110701
110702
110703
110704
110705
110706
110707
110708
110709
110710
110711
110712
110713
110714
110715
110716
110717
110718
110719
110720
110721
110722
110723
110724
110725
110726
110727
110728
110729
110730
110731
110732
110733
110734
110735
110736
110737
110738
110739
110740
110741
110742
110743
110744
110745
110746
110747
110748
110749
110750
110751
110752
110753
110754
110755
110756
110757
110758
110759
110760
110761
110762
110763
110764
110765
110766
110767
110768
110769
110770
110771
110772
110773
110774
110775
110776
110777
110778
110779
110780
110781
110782
110783
110784
110785
110786
110787
110788
110789
110790
110791
110792
110793
110794
110795
110796
110797
110798
110799
110800
110801
110802
110803
110804
110805
110806
110807
110808
110809
110810
110811
110812
110813
110814
110815
110816
110817
110818
110819
110820
110821
110822
110823
110824
110825
110826
110827
110828
110829
110830
110831
110832
110833
110834
110835
110836
110837
110838
110839
110840
110841
110842
110843
110844
110845
110846
110847
110848
110849
110850
110851
110852
110853
110854
110855
110856
110857
110858
110859
110860
110861
110862
110863
110864
110865
110866
110867
110868
110869
110870
110871
110872
110873
110874
110875
110876
110877
110878
110879
110880
110881
110882
110883
110884
110885
110886
110887
110888
110889
110890
110891
110892
110893
110894
110895
110896
110897
110898
110899
110900
110901
110902
110903
110904
110905
110906
110907
110908
110909
110910
110911
110912
110913
110914
110915
110916
110917
110918
110919
110920
110921
110922
110923
110924
110925
110926
110927
110928
110929
110930
110931
110932
110933
110934
110935
110936
110937
110938
110939
110940
110941
110942
110943
110944
110945
110946
110947
110948
110949
110950
110951
110952
110953
110954
110955
110956
110957
110958
110959
110960
110961
110962
110963
110964
110965
110966
110967
110968
110969
110970
110971
110972
110973
110974
110975
110976
110977
110978
110979
110980
110981
110982
110983
110984
110985
110986
110987
110988
110989
110990
110991
110992
110993
110994
110995
110996
110997
110998
110999
111000
111001
111002
111003
111004
111005
111006
111007
111008
111009
111010
111011
111012
111013
111014
111015
111016
111017
111018
111019
111020
111021
111022
111023
111024
111025
111026
111027
111028
111029
111030
111031
111032
111033
111034
111035
111036
111037
111038
111039
111040
111041
111042
111043
111044
111045
111046
111047
111048
111049
111050
111051
111052
111053
111054
111055
111056
111057
111058
111059
111060
111061
111062
111063
111064
111065
111066
111067
111068
111069
111070
111071
111072
111073
111074
111075
111076
111077
111078
111079
111080
111081
111082
111083
111084
111085
111086
111087
111088
111089
111090
111091
111092
111093
111094
111095
111096
111097
111098
111099
111100
111101
111102
111103
111104
111105
111106
111107
111108
111109
111110
111111
111112
111113
111114
111115
111116
111117
111118
111119
111120
111121
111122
111123
111124
111125
111126
111127
111128
111129
111130
111131
111132
111133
111134
111135
111136
111137
111138
111139
111140
111141
111142
111143
111144
111145
111146
111147
111148
111149
111150
111151
111152
111153
111154
111155
111156
111157
111158
111159
111160
111161
111162
111163
111164
111165
111166
111167
111168
111169
111170
111171
111172
111173
111174
111175
111176
111177
111178
111179
111180
111181
111182
111183
111184
111185
111186
111187
111188
111189
111190
111191
111192
111193
111194
111195
111196
111197
111198
111199
111200
111201
111202
111203
111204
111205
111206
111207
111208
111209
111210
111211
111212
111213
111214
111215
111216
111217
111218
111219
111220
111221
111222
111223
111224
111225
111226
111227
111228
111229
111230
111231
111232
111233
111234
111235
111236
111237
111238
111239
111240
111241
111242
111243
111244
111245
111246
111247
111248
111249
111250
111251
111252
111253
111254
111255
111256
111257
111258
111259
111260
111261
111262
111263
111264
111265
111266
111267
111268
111269
111270
111271
111272
111273
111274
111275
111276
111277
111278
111279
111280
111281
111282
111283
111284
111285
111286
111287
111288
111289
111290
111291
111292
111293
111294
111295
111296
111297
111298
111299
111300
111301
111302
111303
111304
111305
111306
111307
111308
111309
111310
111311
111312
111313
111314
111315
111316
111317
111318
111319
111320
111321
111322
111323
111324
111325
111326
111327
111328
111329
111330
111331
111332
111333
111334
111335
111336
111337
111338
111339
111340
111341
111342
111343
111344
111345
111346
111347
111348
111349
111350
111351
111352
111353
111354
111355
111356
111357
111358
111359
111360
111361
111362
111363
111364
111365
111366
111367
111368
111369
111370
111371
111372
111373
111374
111375
111376
111377
111378
111379
111380
111381
111382
111383
111384
111385
111386
111387
111388
111389
111390
111391
111392
111393
111394
111395
111396
111397
111398
111399
111400
111401
111402
111403
111404
111405
111406
111407
111408
111409
111410
111411
111412
111413
111414
111415
111416
111417
111418
111419
111420
111421
111422
111423
111424
111425
111426
111427
111428
111429
111430
111431
111432
111433
111434
111435
111436
111437
111438
111439
111440
111441
111442
111443
111444
111445
111446
111447
111448
111449
111450
111451
111452
111453
111454
111455
111456
111457
111458
111459
111460
111461
111462
111463
111464
111465
111466
111467
111468
111469
111470
111471
111472
111473
111474
111475
111476
111477
111478
111479
111480
111481
111482
111483
111484
111485
111486
111487
111488
111489
111490
111491
111492
111493
111494
111495
111496
111497
111498
111499
111500
111501
111502
111503
111504
111505
111506
111507
111508
111509
111510
111511
111512
111513
111514
111515
111516
111517
111518
111519
111520
111521
111522
111523
111524
111525
111526
111527
111528
111529
111530
111531
111532
111533
111534
111535
111536
111537
111538
111539
111540
111541
111542
111543
111544
111545
111546
111547
111548
111549
111550
111551
111552
111553
111554
111555
111556
111557
111558
111559
111560
111561
111562
111563
111564
111565
111566
111567
111568
111569
111570
111571
111572
111573
111574
111575
111576
111577
111578
111579
111580
111581
111582
111583
111584
111585
111586
111587
111588
111589
111590
111591
111592
111593
111594
111595
111596
111597
111598
111599
111600
111601
111602
111603
111604
111605
111606
111607
111608
111609
111610
111611
111612
111613
111614
111615
111616
111617
111618
111619
111620
111621
111622
111623
111624
111625
111626
111627
111628
111629
111630
111631
111632
111633
111634
111635
111636
111637
111638
111639
111640
111641
111642
111643
111644
111645
111646
111647
111648
111649
111650
111651
111652
111653
111654
111655
111656
111657
111658
111659
111660
111661
111662
111663
111664
111665
111666
111667
111668
111669
111670
111671
111672
111673
111674
111675
111676
111677
111678
111679
111680
111681
111682
111683
111684
111685
111686
111687
111688
111689
111690
111691
111692
111693
111694
111695
111696
111697
111698
111699
111700
111701
111702
111703
111704
111705
111706
111707
111708
111709
111710
111711
111712
111713
111714
111715
111716
111717
111718
111719
111720
111721
111722
111723
111724
111725
111726
111727
111728
111729
111730
111731
111732
111733
111734
111735
111736
111737
111738
111739
111740
111741
111742
111743
111744
111745
111746
111747
111748
111749
111750
111751
111752
111753
111754
111755
111756
111757
111758
111759
111760
111761
111762
111763
111764
111765
111766
111767
111768
111769
111770
111771
111772
111773
111774
111775
111776
111777
111778
111779
111780
111781
111782
111783
111784
111785
111786
111787
111788
111789
111790
111791
111792
111793
111794
111795
111796
111797
111798
111799
111800
111801
111802
111803
111804
111805
111806
111807
111808
111809
111810
111811
111812
111813
111814
111815
111816
111817
111818
111819
111820
111821
111822
111823
111824
111825
111826
111827
111828
111829
111830
111831
111832
111833
111834
111835
111836
111837
111838
111839
111840
111841
111842
111843
111844
111845
111846
111847
111848
111849
111850
111851
111852
111853
111854
111855
111856
111857
111858
111859
111860
111861
111862
111863
111864
111865
111866
111867
111868
111869
111870
111871
111872
111873
111874
111875
111876
111877
111878
111879
111880
111881
111882
111883
111884
111885
111886
111887
111888
111889
111890
111891
111892
111893
111894
111895
111896
111897
111898
111899
111900
111901
111902
111903
111904
111905
111906
111907
111908
111909
111910
111911
111912
111913
111914
111915
111916
111917
111918
111919
111920
111921
111922
111923
111924
111925
111926
111927
111928
111929
111930
111931
111932
111933
111934
111935
111936
111937
111938
111939
111940
111941
111942
111943
111944
111945
111946
111947
111948
111949
111950
111951
111952
111953
111954
111955
111956
111957
111958
111959
111960
111961
111962
111963
111964
111965
111966
111967
111968
111969
111970
111971
111972
111973
111974
111975
111976
111977
111978
111979
111980
111981
111982
111983
111984
111985
111986
111987
111988
111989
111990
111991
111992
111993
111994
111995
111996
111997
111998
111999
112000
112001
112002
112003
112004
112005
112006
112007
112008
112009
112010
112011
112012
112013
112014
112015
112016
112017
112018
112019
112020
112021
112022
112023
112024
112025
112026
112027
112028
112029
112030
112031
112032
112033
112034
112035
112036
112037
112038
112039
112040
112041
112042
112043
112044
112045
112046
112047
112048
112049
112050
112051
112052
112053
112054
112055
112056
112057
112058
112059
112060
112061
112062
112063
112064
112065
112066
112067
112068
112069
112070
112071
112072
112073
112074
112075
112076
112077
112078
112079
112080
112081
112082
112083
112084
112085
112086
112087
112088
112089
112090
112091
112092
112093
112094
112095
112096
112097
112098
112099
112100
112101
112102
112103
112104
112105
112106
112107
112108
112109
112110
112111
112112
112113
112114
112115
112116
112117
112118
112119
112120
112121
112122
112123
112124
112125
112126
112127
112128
112129
112130
112131
112132
112133
112134
112135
112136
112137
112138
112139
112140
112141
112142
112143
112144
112145
112146
112147
112148
112149
112150
112151
112152
112153
112154
112155
112156
112157
112158
112159
112160
112161
112162
112163
112164
112165
112166
112167
112168
112169
112170
112171
112172
112173
112174
112175
112176
112177
112178
112179
112180
112181
112182
112183
112184
112185
112186
112187
112188
112189
112190
112191
112192
112193
112194
112195
112196
112197
112198
112199
112200
112201
112202
112203
112204
112205
112206
112207
112208
112209
112210
112211
112212
112213
112214
112215
112216
112217
112218
112219
112220
112221
112222
112223
112224
112225
112226
112227
112228
112229
112230
112231
112232
112233
112234
112235
112236
112237
112238
112239
112240
112241
112242
112243
112244
112245
112246
112247
112248
112249
112250
112251
112252
112253
112254
112255
112256
112257
112258
112259
112260
112261
112262
112263
112264
112265
112266
112267
112268
112269
112270
112271
112272
112273
112274
112275
112276
112277
112278
112279
112280
112281
112282
112283
112284
112285
112286
112287
112288
112289
112290
112291
112292
112293
112294
112295
112296
112297
112298
112299
112300
112301
112302
112303
112304
112305
112306
112307
112308
112309
112310
112311
112312
112313
112314
112315
112316
112317
112318
112319
112320
112321
112322
112323
112324
112325
112326
112327
112328
112329
112330
112331
112332
112333
112334
112335
112336
112337
112338
112339
112340
112341
112342
112343
112344
112345
112346
112347
112348
112349
112350
112351
112352
112353
112354
112355
112356
112357
112358
112359
112360
112361
112362
112363
112364
112365
112366
112367
112368
112369
112370
112371
112372
112373
112374
112375
112376
112377
112378
112379
112380
112381
112382
112383
112384
112385
112386
112387
112388
112389
112390
112391
112392
112393
112394
112395
112396
112397
112398
112399
112400
112401
112402
112403
112404
112405
112406
112407
112408
112409
112410
112411
112412
112413
112414
112415
112416
112417
112418
112419
112420
112421
112422
112423
112424
112425
112426
112427
112428
112429
112430
112431
112432
112433
112434
112435
112436
112437
112438
112439
112440
112441
112442
112443
112444
112445
112446
112447
112448
112449
112450
112451
112452
112453
112454
112455
112456
112457
112458
112459
112460
112461
112462
112463
112464
112465
112466
112467
112468
112469
112470
112471
112472
112473
112474
112475
112476
112477
112478
112479
112480
112481
112482
112483
112484
112485
112486
112487
112488
112489
112490
112491
112492
112493
112494
112495
112496
112497
112498
112499
112500
112501
112502
112503
112504
112505
112506
112507
112508
112509
112510
112511
112512
112513
112514
112515
112516
112517
112518
112519
112520
112521
112522
112523
112524
112525
112526
112527
112528
112529
112530
112531
112532
112533
112534
112535
112536
112537
112538
112539
112540
112541
112542
112543
112544
112545
112546
112547
112548
112549
112550
112551
112552
112553
112554
112555
112556
112557
112558
112559
112560
112561
112562
112563
112564
112565
112566
112567
112568
112569
112570
112571
112572
112573
112574
112575
112576
112577
112578
112579
112580
112581
112582
112583
112584
112585
112586
112587
112588
112589
112590
112591
112592
112593
112594
112595
112596
112597
112598
112599
112600
112601
112602
112603
112604
112605
112606
112607
112608
112609
112610
112611
112612
112613
112614
112615
112616
112617
112618
112619
112620
112621
112622
112623
112624
112625
112626
112627
112628
112629
112630
112631
112632
112633
112634
112635
112636
112637
112638
112639
112640
112641
112642
112643
112644
112645
112646
112647
112648
112649
112650
112651
112652
112653
112654
112655
112656
112657
112658
112659
112660
112661
112662
112663
112664
112665
112666
112667
112668
112669
112670
112671
112672
112673
112674
112675
112676
112677
112678
112679
112680
112681
112682
112683
112684
112685
112686
112687
112688
112689
112690
112691
112692
112693
112694
112695
112696
112697
112698
112699
112700
112701
112702
112703
112704
112705
112706
112707
112708
112709
112710
112711
112712
112713
112714
112715
112716
112717
112718
112719
112720
112721
112722
112723
112724
112725
112726
112727
112728
112729
112730
112731
112732
112733
112734
112735
112736
112737
112738
112739
112740
112741
112742
112743
112744
112745
112746
112747
112748
112749
112750
112751
112752
112753
112754
112755
112756
112757
112758
112759
112760
112761
112762
112763
112764
112765
112766
112767
112768
112769
112770
112771
112772
112773
112774
112775
112776
112777
112778
112779
112780
112781
112782
112783
112784
112785
112786
112787
112788
112789
112790
112791
112792
112793
112794
112795
112796
112797
112798
112799
112800
112801
112802
112803
112804
112805
112806
112807
112808
112809
112810
112811
112812
112813
112814
112815
112816
112817
112818
112819
112820
112821
112822
112823
112824
112825
112826
112827
112828
112829
112830
112831
112832
112833
112834
112835
112836
112837
112838
112839
112840
112841
112842
112843
112844
112845
112846
112847
112848
112849
112850
112851
112852
112853
112854
112855
112856
112857
112858
112859
112860
112861
112862
112863
112864
112865
112866
112867
112868
112869
112870
112871
112872
112873
112874
112875
112876
112877
112878
112879
112880
112881
112882
112883
112884
112885
112886
112887
112888
112889
112890
112891
112892
112893
112894
112895
112896
112897
112898
112899
112900
112901
112902
112903
112904
112905
112906
112907
112908
112909
112910
112911
112912
112913
112914
112915
112916
112917
112918
112919
112920
112921
112922
112923
112924
112925
112926
112927
112928
112929
112930
112931
112932
112933
112934
112935
112936
112937
112938
112939
112940
112941
112942
112943
112944
112945
112946
112947
112948
112949
112950
112951
112952
112953
112954
112955
112956
112957
112958
112959
112960
112961
112962
112963
112964
112965
112966
112967
112968
112969
112970
112971
112972
112973
112974
112975
112976
112977
112978
112979
112980
112981
112982
112983
112984
112985
112986
112987
112988
112989
112990
112991
112992
112993
112994
112995
112996
112997
112998
112999
113000
113001
113002
113003
113004
113005
113006
113007
113008
113009
113010
113011
113012
113013
113014
113015
113016
113017
113018
113019
113020
113021
113022
113023
113024
113025
113026
113027
113028
113029
113030
113031
113032
113033
113034
113035
113036
113037
113038
113039
113040
113041
113042
113043
113044
113045
113046
113047
113048
113049
113050
113051
113052
113053
113054
113055
113056
113057
113058
113059
113060
113061
113062
113063
113064
113065
113066
113067
113068
113069
113070
113071
113072
113073
113074
113075
113076
113077
113078
113079
113080
113081
113082
113083
113084
113085
113086
113087
113088
113089
113090
113091
113092
113093
113094
113095
113096
113097
113098
113099
113100
113101
113102
113103
113104
113105
113106
113107
113108
113109
113110
113111
113112
113113
113114
113115
113116
113117
113118
113119
113120
113121
113122
113123
113124
113125
113126
113127
113128
113129
113130
113131
113132
113133
113134
113135
113136
113137
113138
113139
113140
113141
113142
113143
113144
113145
113146
113147
113148
113149
113150
113151
113152
113153
113154
113155
113156
113157
113158
113159
113160
113161
113162
113163
113164
113165
113166
113167
113168
113169
113170
113171
113172
113173
113174
113175
113176
113177
113178
113179
113180
113181
113182
113183
113184
113185
113186
113187
113188
113189
113190
113191
113192
113193
113194
113195
113196
113197
113198
113199
113200
113201
113202
113203
113204
113205
113206
113207
113208
113209
113210
113211
113212
113213
113214
113215
113216
113217
113218
113219
113220
113221
113222
113223
113224
113225
113226
113227
113228
113229
113230
113231
113232
113233
113234
113235
113236
113237
113238
113239
113240
113241
113242
113243
113244
113245
113246
113247
113248
113249
113250
113251
113252
113253
113254
113255
113256
113257
113258
113259
113260
113261
113262
113263
113264
113265
113266
113267
113268
113269
113270
113271
113272
113273
113274
113275
113276
113277
113278
113279
113280
113281
113282
113283
113284
113285
113286
113287
113288
113289
113290
113291
113292
113293
113294
113295
113296
113297
113298
113299
113300
113301
113302
113303
113304
113305
113306
113307
113308
113309
113310
113311
113312
113313
113314
113315
113316
113317
113318
113319
113320
113321
113322
113323
113324
113325
113326
113327
113328
113329
113330
113331
113332
113333
113334
113335
113336
113337
113338
113339
113340
113341
113342
113343
113344
113345
113346
113347
113348
113349
113350
113351
113352
113353
113354
113355
113356
113357
113358
113359
113360
113361
113362
113363
113364
113365
113366
113367
113368
113369
113370
113371
113372
113373
113374
113375
113376
113377
113378
113379
113380
113381
113382
113383
113384
113385
113386
113387
113388
113389
113390
113391
113392
113393
113394
113395
113396
113397
113398
113399
113400
113401
113402
113403
113404
113405
113406
113407
113408
113409
113410
113411
113412
113413
113414
113415
113416
113417
113418
113419
113420
113421
113422
113423
113424
113425
113426
113427
113428
113429
113430
113431
113432
113433
113434
113435
113436
113437
113438
113439
113440
113441
113442
113443
113444
113445
113446
113447
113448
113449
113450
113451
113452
113453
113454
113455
113456
113457
113458
113459
113460
113461
113462
113463
113464
113465
113466
113467
113468
113469
113470
113471
113472
113473
113474
113475
113476
113477
113478
113479
113480
113481
113482
113483
113484
113485
113486
113487
113488
113489
113490
113491
113492
113493
113494
113495
113496
113497
113498
113499
113500
113501
113502
113503
113504
113505
113506
113507
113508
113509
113510
113511
113512
113513
113514
113515
113516
113517
113518
113519
113520
113521
113522
113523
113524
113525
113526
113527
113528
113529
113530
113531
113532
113533
113534
113535
113536
113537
113538
113539
113540
113541
113542
113543
113544
113545
113546
113547
113548
113549
113550
113551
113552
113553
113554
113555
113556
113557
113558
113559
113560
113561
113562
113563
113564
113565
113566
113567
113568
113569
113570
113571
113572
113573
113574
113575
113576
113577
113578
113579
113580
113581
113582
113583
113584
113585
113586
113587
113588
113589
113590
113591
113592
113593
113594
113595
113596
113597
113598
113599
113600
113601
113602
113603
113604
113605
113606
113607
113608
113609
113610
113611
113612
113613
113614
113615
113616
113617
113618
113619
113620
113621
113622
113623
113624
113625
113626
113627
113628
113629
113630
113631
113632
113633
113634
113635
113636
113637
113638
113639
113640
113641
113642
113643
113644
113645
113646
113647
113648
113649
113650
113651
113652
113653
113654
113655
113656
113657
113658
113659
113660
113661
113662
113663
113664
113665
113666
113667
113668
113669
113670
113671
113672
113673
113674
113675
113676
113677
113678
113679
113680
113681
113682
113683
113684
113685
113686
113687
113688
113689
113690
113691
113692
113693
113694
113695
113696
113697
113698
113699
113700
113701
113702
113703
113704
113705
113706
113707
113708
113709
113710
113711
113712
113713
113714
113715
113716
113717
113718
113719
113720
113721
113722
113723
113724
113725
113726
113727
113728
113729
113730
113731
113732
113733
113734
113735
113736
113737
113738
113739
113740
113741
113742
113743
113744
113745
113746
113747
113748
113749
113750
113751
113752
113753
113754
113755
113756
113757
113758
113759
113760
113761
113762
113763
113764
113765
113766
113767
113768
113769
113770
113771
113772
113773
113774
113775
113776
113777
113778
113779
113780
113781
113782
113783
113784
113785
113786
113787
113788
113789
113790
113791
113792
113793
113794
113795
113796
113797
113798
113799
113800
113801
113802
113803
113804
113805
113806
113807
113808
113809
113810
113811
113812
113813
113814
113815
113816
113817
113818
113819
113820
113821
113822
113823
113824
113825
113826
113827
113828
113829
113830
113831
113832
113833
113834
113835
113836
113837
113838
113839
113840
113841
113842
113843
113844
113845
113846
113847
113848
113849
113850
113851
113852
113853
113854
113855
113856
113857
113858
113859
113860
113861
113862
113863
113864
113865
113866
113867
113868
113869
113870
113871
113872
113873
113874
113875
113876
113877
113878
113879
113880
113881
113882
113883
113884
113885
113886
113887
113888
113889
113890
113891
113892
113893
113894
113895
113896
113897
113898
113899
113900
113901
113902
113903
113904
113905
113906
113907
113908
113909
113910
113911
113912
113913
113914
113915
113916
113917
113918
113919
113920
113921
113922
113923
113924
113925
113926
113927
113928
113929
113930
113931
113932
113933
113934
113935
113936
113937
113938
113939
113940
113941
113942
113943
113944
113945
113946
113947
113948
113949
113950
113951
113952
113953
113954
113955
113956
113957
113958
113959
113960
113961
113962
113963
113964
113965
113966
113967
113968
113969
113970
113971
113972
113973
113974
113975
113976
113977
113978
113979
113980
113981
113982
113983
113984
113985
113986
113987
113988
113989
113990
113991
113992
113993
113994
113995
113996
113997
113998
113999
114000
114001
114002
114003
114004
114005
114006
114007
114008
114009
114010
114011
114012
114013
114014
114015
114016
114017
114018
114019
114020
114021
114022
114023
114024
114025
114026
114027
114028
114029
114030
114031
114032
114033
114034
114035
114036
114037
114038
114039
114040
114041
114042
114043
114044
114045
114046
114047
114048
114049
114050
114051
114052
114053
114054
114055
114056
114057
114058
114059
114060
114061
114062
114063
114064
114065
114066
114067
114068
114069
114070
114071
114072
114073
114074
114075
114076
114077
114078
114079
114080
114081
114082
114083
114084
114085
114086
114087
114088
114089
114090
114091
114092
114093
114094
114095
114096
114097
114098
114099
114100
114101
114102
114103
114104
114105
114106
114107
114108
114109
114110
114111
114112
114113
114114
114115
114116
114117
114118
114119
114120
114121
114122
114123
114124
114125
114126
114127
114128
114129
114130
114131
114132
114133
114134
114135
114136
114137
114138
114139
114140
114141
114142
114143
114144
114145
114146
114147
114148
114149
114150
114151
114152
114153
114154
114155
114156
114157
114158
114159
114160
114161
114162
114163
114164
114165
114166
114167
114168
114169
114170
114171
114172
114173
114174
114175
114176
114177
114178
114179
114180
114181
114182
114183
114184
114185
114186
114187
114188
114189
114190
114191
114192
114193
114194
114195
114196
114197
114198
114199
114200
114201
114202
114203
114204
114205
114206
114207
114208
114209
114210
114211
114212
114213
114214
114215
114216
114217
114218
114219
114220
114221
114222
114223
114224
114225
114226
114227
114228
114229
114230
114231
114232
114233
114234
114235
114236
114237
114238
114239
114240
114241
114242
114243
114244
114245
114246
114247
114248
114249
114250
114251
114252
114253
114254
114255
114256
114257
114258
114259
114260
114261
114262
114263
114264
114265
114266
114267
114268
114269
114270
114271
114272
114273
114274
114275
114276
114277
114278
114279
114280
114281
114282
114283
114284
114285
114286
114287
114288
114289
114290
114291
114292
114293
114294
114295
114296
114297
114298
114299
114300
114301
114302
114303
114304
114305
114306
114307
114308
114309
114310
114311
114312
114313
114314
114315
114316
114317
114318
114319
114320
114321
114322
114323
114324
114325
114326
114327
114328
114329
114330
114331
114332
114333
114334
114335
114336
114337
114338
114339
114340
114341
114342
114343
114344
114345
114346
114347
114348
114349
114350
114351
114352
114353
114354
114355
114356
114357
114358
114359
114360
114361
114362
114363
114364
114365
114366
114367
114368
114369
114370
114371
114372
114373
114374
114375
114376
114377
114378
114379
114380
114381
114382
114383
114384
114385
114386
114387
114388
114389
114390
114391
114392
114393
114394
114395
114396
114397
114398
114399
114400
114401
114402
114403
114404
114405
114406
114407
114408
114409
114410
114411
114412
114413
114414
114415
114416
114417
114418
114419
114420
114421
114422
114423
114424
114425
114426
114427
114428
114429
114430
114431
114432
114433
114434
114435
114436
114437
114438
114439
114440
114441
114442
114443
114444
114445
114446
114447
114448
114449
114450
114451
114452
114453
114454
114455
114456
114457
114458
114459
114460
114461
114462
114463
114464
114465
114466
114467
114468
114469
114470
114471
114472
114473
114474
114475
114476
114477
114478
114479
114480
114481
114482
114483
114484
114485
114486
114487
114488
114489
114490
114491
114492
114493
114494
114495
114496
114497
114498
114499
114500
114501
114502
114503
114504
114505
114506
114507
114508
114509
114510
114511
114512
114513
114514
114515
114516
114517
114518
114519
114520
114521
114522
114523
114524
114525
114526
114527
114528
114529
114530
114531
114532
114533
114534
114535
114536
114537
114538
114539
114540
114541
114542
114543
114544
114545
114546
114547
114548
114549
114550
114551
114552
114553
114554
114555
114556
114557
114558
114559
114560
114561
114562
114563
114564
114565
114566
114567
114568
114569
114570
114571
114572
114573
114574
114575
114576
114577
114578
114579
114580
114581
114582
114583
114584
114585
114586
114587
114588
114589
114590
114591
114592
114593
114594
114595
114596
114597
114598
114599
114600
114601
114602
114603
114604
114605
114606
114607
114608
114609
114610
114611
114612
114613
114614
114615
114616
114617
114618
114619
114620
114621
114622
114623
114624
114625
114626
114627
114628
114629
114630
114631
114632
114633
114634
114635
114636
114637
114638
114639
114640
114641
114642
114643
114644
114645
114646
114647
114648
114649
114650
114651
114652
114653
114654
114655
114656
114657
114658
114659
114660
114661
114662
114663
114664
114665
114666
114667
114668
114669
114670
114671
114672
114673
114674
114675
114676
114677
114678
114679
114680
114681
114682
114683
114684
114685
114686
114687
114688
114689
114690
114691
114692
114693
114694
114695
114696
114697
114698
114699
114700
114701
114702
114703
114704
114705
114706
114707
114708
114709
114710
114711
114712
114713
114714
114715
114716
114717
114718
114719
114720
114721
114722
114723
114724
114725
114726
114727
114728
114729
114730
114731
114732
114733
114734
114735
114736
114737
114738
114739
114740
114741
114742
114743
114744
114745
114746
114747
114748
114749
114750
114751
114752
114753
114754
114755
114756
114757
114758
114759
114760
114761
114762
114763
114764
114765
114766
114767
114768
114769
114770
114771
114772
114773
114774
114775
114776
114777
114778
114779
114780
114781
114782
114783
114784
114785
114786
114787
114788
114789
114790
114791
114792
114793
114794
114795
114796
114797
114798
114799
114800
114801
114802
114803
114804
114805
114806
114807
114808
114809
114810
114811
114812
114813
114814
114815
114816
114817
114818
114819
114820
114821
114822
114823
114824
114825
114826
114827
114828
114829
114830
114831
114832
114833
114834
114835
114836
114837
114838
114839
114840
114841
114842
114843
114844
114845
114846
114847
114848
114849
114850
114851
114852
114853
114854
114855
114856
114857
114858
114859
114860
114861
114862
114863
114864
114865
114866
114867
114868
114869
114870
114871
114872
114873
114874
114875
114876
114877
114878
114879
114880
114881
114882
114883
114884
114885
114886
114887
114888
114889
114890
114891
114892
114893
114894
114895
114896
114897
114898
114899
114900
114901
114902
114903
114904
114905
114906
114907
114908
114909
114910
114911
114912
114913
114914
114915
114916
114917
114918
114919
114920
114921
114922
114923
114924
114925
114926
114927
114928
114929
114930
114931
114932
114933
114934
114935
114936
114937
114938
114939
114940
114941
114942
114943
114944
114945
114946
114947
114948
114949
114950
114951
114952
114953
114954
114955
114956
114957
114958
114959
114960
114961
114962
114963
114964
114965
114966
114967
114968
114969
114970
114971
114972
114973
114974
114975
114976
114977
114978
114979
114980
114981
114982
114983
114984
114985
114986
114987
114988
114989
114990
114991
114992
114993
114994
114995
114996
114997
114998
114999
115000
115001
115002
115003
115004
115005
115006
115007
115008
115009
115010
115011
115012
115013
115014
115015
115016
115017
115018
115019
115020
115021
115022
115023
115024
115025
115026
115027
115028
115029
115030
115031
115032
115033
115034
115035
115036
115037
115038
115039
115040
115041
115042
115043
115044
115045
115046
115047
115048
115049
115050
115051
115052
115053
115054
115055
115056
115057
115058
115059
115060
115061
115062
115063
115064
115065
115066
115067
115068
115069
115070
115071
115072
115073
115074
115075
115076
115077
115078
115079
115080
115081
115082
115083
115084
115085
115086
115087
115088
115089
115090
115091
115092
115093
115094
115095
115096
115097
115098
115099
115100
115101
115102
115103
115104
115105
115106
115107
115108
115109
115110
115111
115112
115113
115114
115115
115116
115117
115118
115119
115120
115121
115122
115123
115124
115125
115126
115127
115128
115129
115130
115131
115132
115133
115134
115135
115136
115137
115138
115139
115140
115141
115142
115143
115144
115145
115146
115147
115148
115149
115150
115151
115152
115153
115154
115155
115156
115157
115158
115159
115160
115161
115162
115163
115164
115165
115166
115167
115168
115169
115170
115171
115172
115173
115174
115175
115176
115177
115178
115179
115180
115181
115182
115183
115184
115185
115186
115187
115188
115189
115190
115191
115192
115193
115194
115195
115196
115197
115198
115199
115200
115201
115202
115203
115204
115205
115206
115207
115208
115209
115210
115211
115212
115213
115214
115215
115216
115217
115218
115219
115220
115221
115222
115223
115224
115225
115226
115227
115228
115229
115230
115231
115232
115233
115234
115235
115236
115237
115238
115239
115240
115241
115242
115243
115244
115245
115246
115247
115248
115249
115250
115251
115252
115253
115254
115255
115256
115257
115258
115259
115260
115261
115262
115263
115264
115265
115266
115267
115268
115269
115270
115271
115272
115273
115274
115275
115276
115277
115278
115279
115280
115281
115282
115283
115284
115285
115286
115287
115288
115289
115290
115291
115292
115293
115294
115295
115296
115297
115298
115299
115300
115301
115302
115303
115304
115305
115306
115307
115308
115309
115310
115311
115312
115313
115314
115315
115316
115317
115318
115319
115320
115321
115322
115323
115324
115325
115326
115327
115328
115329
115330
115331
115332
115333
115334
115335
115336
115337
115338
115339
115340
115341
115342
115343
115344
115345
115346
115347
115348
115349
115350
115351
115352
115353
115354
115355
115356
115357
115358
115359
115360
115361
115362
115363
115364
115365
115366
115367
115368
115369
115370
115371
115372
115373
115374
115375
115376
115377
115378
115379
115380
115381
115382
115383
115384
115385
115386
115387
115388
115389
115390
115391
115392
115393
115394
115395
115396
115397
115398
115399
115400
115401
115402
115403
115404
115405
115406
115407
115408
115409
115410
115411
115412
115413
115414
115415
115416
115417
115418
115419
115420
115421
115422
115423
115424
115425
115426
115427
115428
115429
115430
115431
115432
115433
115434
115435
115436
115437
115438
115439
115440
115441
115442
115443
115444
115445
115446
115447
115448
115449
115450
115451
115452
115453
115454
115455
115456
115457
115458
115459
115460
115461
115462
115463
115464
115465
115466
115467
115468
115469
115470
115471
115472
115473
115474
115475
115476
115477
115478
115479
115480
115481
115482
115483
115484
115485
115486
115487
115488
115489
115490
115491
115492
115493
115494
115495
115496
115497
115498
115499
115500
115501
115502
115503
115504
115505
115506
115507
115508
115509
115510
115511
115512
115513
115514
115515
115516
115517
115518
115519
115520
115521
115522
115523
115524
115525
115526
115527
115528
115529
115530
115531
115532
115533
115534
115535
115536
115537
115538
115539
115540
115541
115542
115543
115544
115545
115546
115547
115548
115549
115550
115551
115552
115553
115554
115555
115556
115557
115558
115559
115560
115561
115562
115563
115564
115565
115566
115567
115568
115569
115570
115571
115572
115573
115574
115575
115576
115577
115578
115579
115580
115581
115582
115583
115584
115585
115586
115587
115588
115589
115590
115591
115592
115593
115594
115595
115596
115597
115598
115599
115600
115601
115602
115603
115604
115605
115606
115607
115608
115609
115610
115611
115612
115613
115614
115615
115616
115617
115618
115619
115620
115621
115622
115623
115624
115625
115626
115627
115628
115629
115630
115631
115632
115633
115634
115635
115636
115637
115638
115639
115640
115641
115642
115643
115644
115645
115646
115647
115648
115649
115650
115651
115652
115653
115654
115655
115656
115657
115658
115659
115660
115661
115662
115663
115664
115665
115666
115667
115668
115669
115670
115671
115672
115673
115674
115675
115676
115677
115678
115679
115680
115681
115682
115683
115684
115685
115686
115687
115688
115689
115690
115691
115692
115693
115694
115695
115696
115697
115698
115699
115700
115701
115702
115703
115704
115705
115706
115707
115708
115709
115710
115711
115712
115713
115714
115715
115716
115717
115718
115719
115720
115721
115722
115723
115724
115725
115726
115727
115728
115729
115730
115731
115732
115733
115734
115735
115736
115737
115738
115739
115740
115741
115742
115743
115744
115745
115746
115747
115748
115749
115750
115751
115752
115753
115754
115755
115756
115757
115758
115759
115760
115761
115762
115763
115764
115765
115766
115767
115768
115769
115770
115771
115772
115773
115774
115775
115776
115777
115778
115779
115780
115781
115782
115783
115784
115785
115786
115787
115788
115789
115790
115791
115792
115793
115794
115795
115796
115797
115798
115799
115800
115801
115802
115803
115804
115805
115806
115807
115808
115809
115810
115811
115812
115813
115814
115815
115816
115817
115818
115819
115820
115821
115822
115823
115824
115825
115826
115827
115828
115829
115830
115831
115832
115833
115834
115835
115836
115837
115838
115839
115840
115841
115842
115843
115844
115845
115846
115847
115848
115849
115850
115851
115852
115853
115854
115855
115856
115857
115858
115859
115860
115861
115862
115863
115864
115865
115866
115867
115868
115869
115870
115871
115872
115873
115874
115875
115876
115877
115878
115879
115880
115881
115882
115883
115884
115885
115886
115887
115888
115889
115890
115891
115892
115893
115894
115895
115896
115897
115898
115899
115900
115901
115902
115903
115904
115905
115906
115907
115908
115909
115910
115911
115912
115913
115914
115915
115916
115917
115918
115919
115920
115921
115922
115923
115924
115925
115926
115927
115928
115929
115930
115931
115932
115933
115934
115935
115936
115937
115938
115939
115940
115941
115942
115943
115944
115945
115946
115947
115948
115949
115950
115951
115952
115953
115954
115955
115956
115957
115958
115959
115960
115961
115962
115963
115964
115965
115966
115967
115968
115969
115970
115971
115972
115973
115974
115975
115976
115977
115978
115979
115980
115981
115982
115983
115984
115985
115986
115987
115988
115989
115990
115991
115992
115993
115994
115995
115996
115997
115998
115999
116000
116001
116002
116003
116004
116005
116006
116007
116008
116009
116010
116011
116012
116013
116014
116015
116016
116017
116018
116019
116020
116021
116022
116023
116024
116025
116026
116027
116028
116029
116030
116031
116032
116033
116034
116035
116036
116037
116038
116039
116040
116041
116042
116043
116044
116045
116046
116047
116048
116049
116050
116051
116052
116053
116054
116055
116056
116057
116058
116059
116060
116061
116062
116063
116064
116065
116066
116067
116068
116069
116070
116071
116072
116073
116074
116075
116076
116077
116078
116079
116080
116081
116082
116083
116084
116085
116086
116087
116088
116089
116090
116091
116092
116093
116094
116095
116096
116097
116098
116099
116100
116101
116102
116103
116104
116105
116106
116107
116108
116109
116110
116111
116112
116113
116114
116115
116116
116117
116118
116119
116120
116121
116122
116123
116124
116125
116126
116127
116128
116129
116130
116131
116132
116133
116134
116135
116136
116137
116138
116139
116140
116141
116142
116143
116144
116145
116146
116147
116148
116149
116150
116151
116152
116153
116154
116155
116156
116157
116158
116159
116160
116161
116162
116163
116164
116165
116166
116167
116168
116169
116170
116171
116172
116173
116174
116175
116176
116177
116178
116179
116180
116181
116182
116183
116184
116185
116186
116187
116188
116189
116190
116191
116192
116193
116194
116195
116196
116197
116198
116199
116200
116201
116202
116203
116204
116205
116206
116207
116208
116209
116210
116211
116212
116213
116214
116215
116216
116217
116218
116219
116220
116221
116222
116223
116224
116225
116226
116227
116228
116229
116230
116231
116232
116233
116234
116235
116236
116237
116238
116239
116240
116241
116242
116243
116244
116245
116246
116247
116248
116249
116250
116251
116252
116253
116254
116255
116256
116257
116258
116259
116260
116261
116262
116263
116264
116265
116266
116267
116268
116269
116270
116271
116272
116273
116274
116275
116276
116277
116278
116279
116280
116281
116282
116283
116284
116285
116286
116287
116288
116289
116290
116291
116292
116293
116294
116295
116296
116297
116298
116299
116300
116301
116302
116303
116304
116305
116306
116307
116308
116309
116310
116311
116312
116313
116314
116315
116316
116317
116318
116319
116320
116321
116322
116323
116324
116325
116326
116327
116328
116329
116330
116331
116332
116333
116334
116335
116336
116337
116338
116339
116340
116341
116342
116343
116344
116345
116346
116347
116348
116349
116350
116351
116352
116353
116354
116355
116356
116357
116358
116359
116360
116361
116362
116363
116364
116365
116366
116367
116368
116369
116370
116371
116372
116373
116374
116375
116376
116377
116378
116379
116380
116381
116382
116383
116384
116385
116386
116387
116388
116389
116390
116391
116392
116393
116394
116395
116396
116397
116398
116399
116400
116401
116402
116403
116404
116405
116406
116407
116408
116409
116410
116411
116412
116413
116414
116415
116416
116417
116418
116419
116420
116421
116422
116423
116424
116425
116426
116427
116428
116429
116430
116431
116432
116433
116434
116435
116436
116437
116438
116439
116440
116441
116442
116443
116444
116445
116446
116447
116448
116449
116450
116451
116452
116453
116454
116455
116456
116457
116458
116459
116460
116461
116462
116463
116464
116465
116466
116467
116468
116469
116470
116471
116472
116473
116474
116475
116476
116477
116478
116479
116480
116481
116482
116483
116484
116485
116486
116487
116488
116489
116490
116491
116492
116493
116494
116495
116496
116497
116498
116499
116500
116501
116502
116503
116504
116505
116506
116507
116508
116509
116510
116511
116512
116513
116514
116515
116516
116517
116518
116519
116520
116521
116522
116523
116524
116525
116526
116527
116528
116529
116530
116531
116532
116533
116534
116535
116536
116537
116538
116539
116540
116541
116542
116543
116544
116545
116546
116547
116548
116549
116550
116551
116552
116553
116554
116555
116556
116557
116558
116559
116560
116561
116562
116563
116564
116565
116566
116567
116568
116569
116570
116571
116572
116573
116574
116575
116576
116577
116578
116579
116580
116581
116582
116583
116584
116585
116586
116587
116588
116589
116590
116591
116592
116593
116594
116595
116596
116597
116598
116599
116600
116601
116602
116603
116604
116605
116606
116607
116608
116609
116610
116611
116612
116613
116614
116615
116616
116617
116618
116619
116620
116621
116622
116623
116624
116625
116626
116627
116628
116629
116630
116631
116632
116633
116634
116635
116636
116637
116638
116639
116640
116641
116642
116643
116644
116645
116646
116647
116648
116649
116650
116651
116652
116653
116654
116655
116656
116657
116658
116659
116660
116661
116662
116663
116664
116665
116666
116667
116668
116669
116670
116671
116672
116673
116674
116675
116676
116677
116678
116679
116680
116681
116682
116683
116684
116685
116686
116687
116688
116689
116690
116691
116692
116693
116694
116695
116696
116697
116698
116699
116700
116701
116702
116703
116704
116705
116706
116707
116708
116709
116710
116711
116712
116713
116714
116715
116716
116717
116718
116719
116720
116721
116722
116723
116724
116725
116726
116727
116728
116729
116730
116731
116732
116733
116734
116735
116736
116737
116738
116739
116740
116741
116742
116743
116744
116745
116746
116747
116748
116749
116750
116751
116752
116753
116754
116755
116756
116757
116758
116759
116760
116761
116762
116763
116764
116765
116766
116767
116768
116769
116770
116771
116772
116773
116774
116775
116776
116777
116778
116779
116780
116781
116782
116783
116784
116785
116786
116787
116788
116789
116790
116791
116792
116793
116794
116795
116796
116797
116798
116799
116800
116801
116802
116803
116804
116805
116806
116807
116808
116809
116810
116811
116812
116813
116814
116815
116816
116817
116818
116819
116820
116821
116822
116823
116824
116825
116826
116827
116828
116829
116830
116831
116832
116833
116834
116835
116836
116837
116838
116839
116840
116841
116842
116843
116844
116845
116846
116847
116848
116849
116850
116851
116852
116853
116854
116855
116856
116857
116858
116859
116860
116861
116862
116863
116864
116865
116866
116867
116868
116869
116870
116871
116872
116873
116874
116875
116876
116877
116878
116879
116880
116881
116882
116883
116884
116885
116886
116887
116888
116889
116890
116891
116892
116893
116894
116895
116896
116897
116898
116899
116900
116901
116902
116903
116904
116905
116906
116907
116908
116909
116910
116911
116912
116913
116914
116915
116916
116917
116918
116919
116920
116921
116922
116923
116924
116925
116926
116927
116928
116929
116930
116931
116932
116933
116934
116935
116936
116937
116938
116939
116940
116941
116942
116943
116944
116945
116946
116947
116948
116949
116950
116951
116952
116953
116954
116955
116956
116957
116958
116959
116960
116961
116962
116963
116964
116965
116966
116967
116968
116969
116970
116971
116972
116973
116974
116975
116976
116977
116978
116979
116980
116981
116982
116983
116984
116985
116986
116987
116988
116989
116990
116991
116992
116993
116994
116995
116996
116997
116998
116999
117000
117001
117002
117003
117004
117005
117006
117007
117008
117009
117010
117011
117012
117013
117014
117015
117016
117017
117018
117019
117020
117021
117022
117023
117024
117025
117026
117027
117028
117029
117030
117031
117032
117033
117034
117035
117036
117037
117038
117039
117040
117041
117042
117043
117044
117045
117046
117047
117048
117049
117050
117051
117052
117053
117054
117055
117056
117057
117058
117059
117060
117061
117062
117063
117064
117065
117066
117067
117068
117069
117070
117071
117072
117073
117074
117075
117076
117077
117078
117079
117080
117081
117082
117083
117084
117085
117086
117087
117088
117089
117090
117091
117092
117093
117094
117095
117096
117097
117098
117099
117100
117101
117102
117103
117104
117105
117106
117107
117108
117109
117110
117111
117112
117113
117114
117115
117116
117117
117118
117119
117120
117121
117122
117123
117124
117125
117126
117127
117128
117129
117130
117131
117132
117133
117134
117135
117136
117137
117138
117139
117140
117141
117142
117143
117144
117145
117146
117147
117148
117149
117150
117151
117152
117153
117154
117155
117156
117157
117158
117159
117160
117161
117162
117163
117164
117165
117166
117167
117168
117169
117170
117171
117172
117173
117174
117175
117176
117177
117178
117179
117180
117181
117182
117183
117184
117185
117186
117187
117188
117189
117190
117191
117192
117193
117194
117195
117196
117197
117198
117199
117200
117201
117202
117203
117204
117205
117206
117207
117208
117209
117210
117211
117212
117213
117214
117215
117216
117217
117218
117219
117220
117221
117222
117223
117224
117225
117226
117227
117228
117229
117230
117231
117232
117233
117234
117235
117236
117237
117238
117239
117240
117241
117242
117243
117244
117245
117246
117247
117248
117249
117250
117251
117252
117253
117254
117255
117256
117257
117258
117259
117260
117261
117262
117263
117264
117265
117266
117267
117268
117269
117270
117271
117272
117273
117274
117275
117276
117277
117278
117279
117280
117281
117282
117283
117284
117285
117286
117287
117288
117289
117290
117291
117292
117293
117294
117295
117296
117297
117298
117299
117300
117301
117302
117303
117304
117305
117306
117307
117308
117309
117310
117311
117312
117313
117314
117315
117316
117317
117318
117319
117320
117321
117322
117323
117324
117325
117326
117327
117328
117329
117330
117331
117332
117333
117334
117335
117336
117337
117338
117339
117340
117341
117342
117343
117344
117345
117346
117347
117348
117349
117350
117351
117352
117353
117354
117355
117356
117357
117358
117359
117360
117361
117362
117363
117364
117365
117366
117367
117368
117369
117370
117371
117372
117373
117374
117375
117376
117377
117378
117379
117380
117381
117382
117383
117384
117385
117386
117387
117388
117389
117390
117391
117392
117393
117394
117395
117396
117397
117398
117399
117400
117401
117402
117403
117404
117405
117406
117407
117408
117409
117410
117411
117412
117413
117414
117415
117416
117417
117418
117419
117420
117421
117422
117423
117424
117425
117426
117427
117428
117429
117430
117431
117432
117433
117434
117435
117436
117437
117438
117439
117440
117441
117442
117443
117444
117445
117446
117447
117448
117449
117450
117451
117452
117453
117454
117455
117456
117457
117458
117459
117460
117461
117462
117463
117464
117465
117466
117467
117468
117469
117470
117471
117472
117473
117474
117475
117476
117477
117478
117479
117480
117481
117482
117483
117484
117485
117486
117487
117488
117489
117490
117491
117492
117493
117494
117495
117496
117497
117498
117499
117500
117501
117502
117503
117504
117505
117506
117507
117508
117509
117510
117511
117512
117513
117514
117515
117516
117517
117518
117519
117520
117521
117522
117523
117524
117525
117526
117527
117528
117529
117530
117531
117532
117533
117534
117535
117536
117537
117538
117539
117540
117541
117542
117543
117544
117545
117546
117547
117548
117549
117550
117551
117552
117553
117554
117555
117556
117557
117558
117559
117560
117561
117562
117563
117564
117565
117566
117567
117568
117569
117570
117571
117572
117573
117574
117575
117576
117577
117578
117579
117580
117581
117582
117583
117584
117585
117586
117587
117588
117589
117590
117591
117592
117593
117594
117595
117596
117597
117598
117599
117600
117601
117602
117603
117604
117605
117606
117607
117608
117609
117610
117611
117612
117613
117614
117615
117616
117617
117618
117619
117620
117621
117622
117623
117624
117625
117626
117627
117628
117629
117630
117631
117632
117633
117634
117635
117636
117637
117638
117639
117640
117641
117642
117643
117644
117645
117646
117647
117648
117649
117650
117651
117652
117653
117654
117655
117656
117657
117658
117659
117660
117661
117662
117663
117664
117665
117666
117667
117668
117669
117670
117671
117672
117673
117674
117675
117676
117677
117678
117679
117680
117681
117682
117683
117684
117685
117686
117687
117688
117689
117690
117691
117692
117693
117694
117695
117696
117697
117698
117699
117700
117701
117702
117703
117704
117705
117706
117707
117708
117709
117710
117711
117712
117713
117714
117715
117716
117717
117718
117719
117720
117721
117722
117723
117724
117725
117726
117727
117728
117729
117730
117731
117732
117733
117734
117735
117736
117737
117738
117739
117740
117741
117742
117743
117744
117745
117746
117747
117748
117749
117750
117751
117752
117753
117754
117755
117756
117757
117758
117759
117760
117761
117762
117763
117764
117765
117766
117767
117768
117769
117770
117771
117772
117773
117774
117775
117776
117777
117778
117779
117780
117781
117782
117783
117784
117785
117786
117787
117788
117789
117790
117791
117792
117793
117794
117795
117796
117797
117798
117799
117800
117801
117802
117803
117804
117805
117806
117807
117808
117809
117810
117811
117812
117813
117814
117815
117816
117817
117818
117819
117820
117821
117822
117823
117824
117825
117826
117827
117828
117829
117830
117831
117832
117833
117834
117835
117836
117837
117838
117839
117840
117841
117842
117843
117844
117845
117846
117847
117848
117849
117850
117851
117852
117853
117854
117855
117856
117857
117858
117859
117860
117861
117862
117863
117864
117865
117866
117867
117868
117869
117870
117871
117872
117873
117874
117875
117876
117877
117878
117879
117880
117881
117882
117883
117884
117885
117886
117887
117888
117889
117890
117891
117892
117893
117894
117895
117896
117897
117898
117899
117900
117901
117902
117903
117904
117905
117906
117907
117908
117909
117910
117911
117912
117913
117914
117915
117916
117917
117918
117919
117920
117921
117922
117923
117924
117925
117926
117927
117928
117929
117930
117931
117932
117933
117934
117935
117936
117937
117938
117939
117940
117941
117942
117943
117944
117945
117946
117947
117948
117949
117950
117951
117952
117953
117954
117955
117956
117957
117958
117959
117960
117961
117962
117963
117964
117965
117966
117967
117968
117969
117970
117971
117972
117973
117974
117975
117976
117977
117978
117979
117980
117981
117982
117983
117984
117985
117986
117987
117988
117989
117990
117991
117992
117993
117994
117995
117996
117997
117998
117999
118000
118001
118002
118003
118004
118005
118006
118007
118008
118009
118010
118011
118012
118013
118014
118015
118016
118017
118018
118019
118020
118021
118022
118023
118024
118025
118026
118027
118028
118029
118030
118031
118032
118033
118034
118035
118036
118037
118038
118039
118040
118041
118042
118043
118044
118045
118046
118047
118048
118049
118050
118051
118052
118053
118054
118055
118056
118057
118058
118059
118060
118061
118062
118063
118064
118065
118066
118067
118068
118069
118070
118071
118072
118073
118074
118075
118076
118077
118078
118079
118080
118081
118082
118083
118084
118085
118086
118087
118088
118089
118090
118091
118092
118093
118094
118095
118096
118097
118098
118099
118100
118101
118102
118103
118104
118105
118106
118107
118108
118109
118110
118111
118112
118113
118114
118115
118116
118117
118118
118119
118120
118121
118122
118123
118124
118125
118126
118127
118128
118129
118130
118131
118132
118133
118134
118135
118136
118137
118138
118139
118140
118141
118142
118143
118144
118145
118146
118147
118148
118149
118150
118151
118152
118153
118154
118155
118156
118157
118158
118159
118160
118161
118162
118163
118164
118165
118166
118167
118168
118169
118170
118171
118172
118173
118174
118175
118176
118177
118178
118179
118180
118181
118182
118183
118184
118185
118186
118187
118188
118189
118190
118191
118192
118193
118194
118195
118196
118197
118198
118199
118200
118201
118202
118203
118204
118205
118206
118207
118208
118209
118210
118211
118212
118213
118214
118215
118216
118217
118218
118219
118220
118221
118222
118223
118224
118225
118226
118227
118228
118229
118230
118231
118232
118233
118234
118235
118236
118237
118238
118239
118240
118241
118242
118243
118244
118245
118246
118247
118248
118249
118250
118251
118252
118253
118254
118255
118256
118257
118258
118259
118260
118261
118262
118263
118264
118265
118266
118267
118268
118269
118270
118271
118272
118273
118274
118275
118276
118277
118278
118279
118280
118281
118282
118283
118284
118285
118286
118287
118288
118289
118290
118291
118292
118293
118294
118295
118296
118297
118298
118299
118300
118301
118302
118303
118304
118305
118306
118307
118308
118309
118310
118311
118312
118313
118314
118315
118316
118317
118318
118319
118320
118321
118322
118323
118324
118325
118326
118327
118328
118329
118330
118331
118332
118333
118334
118335
118336
118337
118338
118339
118340
118341
118342
118343
118344
118345
118346
118347
118348
118349
118350
118351
118352
118353
118354
118355
118356
118357
118358
118359
118360
118361
118362
118363
118364
118365
118366
118367
118368
118369
118370
118371
118372
118373
118374
118375
118376
118377
118378
118379
118380
118381
118382
118383
118384
118385
118386
118387
118388
118389
118390
118391
118392
118393
118394
118395
118396
118397
118398
118399
118400
118401
118402
118403
118404
118405
118406
118407
118408
118409
118410
118411
118412
118413
118414
118415
118416
118417
118418
118419
118420
118421
118422
118423
118424
118425
118426
118427
118428
118429
118430
118431
118432
118433
118434
118435
118436
118437
118438
118439
118440
118441
118442
118443
118444
118445
118446
118447
118448
118449
118450
118451
118452
118453
118454
118455
118456
118457
118458
118459
118460
118461
118462
118463
118464
118465
118466
118467
118468
118469
118470
118471
118472
118473
118474
118475
118476
118477
118478
118479
118480
118481
118482
118483
118484
118485
118486
118487
118488
118489
118490
118491
118492
118493
118494
118495
118496
118497
118498
118499
118500
118501
118502
118503
118504
118505
118506
118507
118508
118509
118510
118511
118512
118513
118514
118515
118516
118517
118518
118519
118520
118521
118522
118523
118524
118525
118526
118527
118528
118529
118530
118531
118532
118533
118534
118535
118536
118537
118538
118539
118540
118541
118542
118543
118544
118545
118546
118547
118548
118549
118550
118551
118552
118553
118554
118555
118556
118557
118558
118559
118560
118561
118562
118563
118564
118565
118566
118567
118568
118569
118570
118571
118572
118573
118574
118575
118576
118577
118578
118579
118580
118581
118582
118583
118584
118585
118586
118587
118588
118589
118590
118591
118592
118593
118594
118595
118596
118597
118598
118599
118600
118601
118602
118603
118604
118605
118606
118607
118608
118609
118610
118611
118612
118613
118614
118615
118616
118617
118618
118619
118620
118621
118622
118623
118624
118625
118626
118627
118628
118629
118630
118631
118632
118633
118634
118635
118636
118637
118638
118639
118640
118641
118642
118643
118644
118645
118646
118647
118648
118649
118650
118651
118652
118653
118654
118655
118656
118657
118658
118659
118660
118661
118662
118663
118664
118665
118666
118667
118668
118669
118670
118671
118672
118673
118674
118675
118676
118677
118678
118679
118680
118681
118682
118683
118684
118685
118686
118687
118688
118689
118690
118691
118692
118693
118694
118695
118696
118697
118698
118699
118700
118701
118702
118703
118704
118705
118706
118707
118708
118709
118710
118711
118712
118713
118714
118715
118716
118717
118718
118719
118720
118721
118722
118723
118724
118725
118726
118727
118728
118729
118730
118731
118732
118733
118734
118735
118736
118737
118738
118739
118740
118741
118742
118743
118744
118745
118746
118747
118748
118749
118750
118751
118752
118753
118754
118755
118756
118757
118758
118759
118760
118761
118762
118763
118764
118765
118766
118767
118768
118769
118770
118771
118772
118773
118774
118775
118776
118777
118778
118779
118780
118781
118782
118783
118784
118785
118786
118787
118788
118789
118790
118791
118792
118793
118794
118795
118796
118797
118798
118799
118800
118801
118802
118803
118804
118805
118806
118807
118808
118809
118810
118811
118812
118813
118814
118815
118816
118817
118818
118819
118820
118821
118822
118823
118824
118825
118826
118827
118828
118829
118830
118831
118832
118833
118834
118835
118836
118837
118838
118839
118840
118841
118842
118843
118844
118845
118846
118847
118848
118849
118850
118851
118852
118853
118854
118855
118856
118857
118858
118859
118860
118861
118862
118863
118864
118865
118866
118867
118868
118869
118870
118871
118872
118873
118874
118875
118876
118877
118878
118879
118880
118881
118882
118883
118884
118885
118886
118887
118888
118889
118890
118891
118892
118893
118894
118895
118896
118897
118898
118899
118900
118901
118902
118903
118904
118905
118906
118907
118908
118909
118910
118911
118912
118913
118914
118915
118916
118917
118918
118919
118920
118921
118922
118923
118924
118925
118926
118927
118928
118929
118930
118931
118932
118933
118934
118935
118936
118937
118938
118939
118940
118941
118942
118943
118944
118945
118946
118947
118948
118949
118950
118951
118952
118953
118954
118955
118956
118957
118958
118959
118960
118961
118962
118963
118964
118965
118966
118967
118968
118969
118970
118971
118972
118973
118974
118975
118976
118977
118978
118979
118980
118981
118982
118983
118984
118985
118986
118987
118988
118989
118990
118991
118992
118993
118994
118995
118996
118997
118998
118999
119000
119001
119002
119003
119004
119005
119006
119007
119008
119009
119010
119011
119012
119013
119014
119015
119016
119017
119018
119019
119020
119021
119022
119023
119024
119025
119026
119027
119028
119029
119030
119031
119032
119033
119034
119035
119036
119037
119038
119039
119040
119041
119042
119043
119044
119045
119046
119047
119048
119049
119050
119051
119052
119053
119054
119055
119056
119057
119058
119059
119060
119061
119062
119063
119064
119065
119066
119067
119068
119069
119070
119071
119072
119073
119074
119075
119076
119077
119078
119079
119080
119081
119082
119083
119084
119085
119086
119087
119088
119089
119090
119091
119092
119093
119094
119095
119096
119097
119098
119099
119100
119101
119102
119103
119104
119105
119106
119107
119108
119109
119110
119111
119112
119113
119114
119115
119116
119117
119118
119119
119120
119121
119122
119123
119124
119125
119126
119127
119128
119129
119130
119131
119132
119133
119134
119135
119136
119137
119138
119139
119140
119141
119142
119143
119144
119145
119146
119147
119148
119149
119150
119151
119152
119153
119154
119155
119156
119157
119158
119159
119160
119161
119162
119163
119164
119165
119166
119167
119168
119169
119170
119171
119172
119173
119174
119175
119176
119177
119178
119179
119180
119181
119182
119183
119184
119185
119186
119187
119188
119189
119190
119191
119192
119193
119194
119195
119196
119197
119198
119199
119200
119201
119202
119203
119204
119205
119206
119207
119208
119209
119210
119211
119212
119213
119214
119215
119216
119217
119218
119219
119220
119221
119222
119223
119224
119225
119226
119227
119228
119229
119230
119231
119232
119233
119234
119235
119236
119237
119238
119239
119240
119241
119242
119243
119244
119245
119246
119247
119248
119249
119250
119251
119252
119253
119254
119255
119256
119257
119258
119259
119260
119261
119262
119263
119264
119265
119266
119267
119268
119269
119270
119271
119272
119273
119274
119275
119276
119277
119278
119279
119280
119281
119282
119283
119284
119285
119286
119287
119288
119289
119290
119291
119292
119293
119294
119295
119296
119297
119298
119299
119300
119301
119302
119303
119304
119305
119306
119307
119308
119309
119310
119311
119312
119313
119314
119315
119316
119317
119318
119319
119320
119321
119322
119323
119324
119325
119326
119327
119328
119329
119330
119331
119332
119333
119334
119335
119336
119337
119338
119339
119340
119341
119342
119343
119344
119345
119346
119347
119348
119349
119350
119351
119352
119353
119354
119355
119356
119357
119358
119359
119360
119361
119362
119363
119364
119365
119366
119367
119368
119369
119370
119371
119372
119373
119374
119375
119376
119377
119378
119379
119380
119381
119382
119383
119384
119385
119386
119387
119388
119389
119390
119391
119392
119393
119394
119395
119396
119397
119398
119399
119400
119401
119402
119403
119404
119405
119406
119407
119408
119409
119410
119411
119412
119413
119414
119415
119416
119417
119418
119419
119420
119421
119422
119423
119424
119425
119426
119427
119428
119429
119430
119431
119432
119433
119434
119435
119436
119437
119438
119439
119440
119441
119442
119443
119444
119445
119446
119447
119448
119449
119450
119451
119452
119453
119454
119455
119456
119457
119458
119459
119460
119461
119462
119463
119464
119465
119466
119467
119468
119469
119470
119471
119472
119473
119474
119475
119476
119477
119478
119479
119480
119481
119482
119483
119484
119485
119486
119487
119488
119489
119490
119491
119492
119493
119494
119495
119496
119497
119498
119499
119500
119501
119502
119503
119504
119505
119506
119507
119508
119509
119510
119511
119512
119513
119514
119515
119516
119517
119518
119519
119520
119521
119522
119523
119524
119525
119526
119527
119528
119529
119530
119531
119532
119533
119534
119535
119536
119537
119538
119539
119540
119541
119542
119543
119544
119545
119546
119547
119548
119549
119550
119551
119552
119553
119554
119555
119556
119557
119558
119559
119560
119561
119562
119563
119564
119565
119566
119567
119568
119569
119570
119571
119572
119573
119574
119575
119576
119577
119578
119579
119580
119581
119582
119583
119584
119585
119586
119587
119588
119589
119590
119591
119592
119593
119594
119595
119596
119597
119598
119599
119600
119601
119602
119603
119604
119605
119606
119607
119608
119609
119610
119611
119612
119613
119614
119615
119616
119617
119618
119619
119620
119621
119622
119623
119624
119625
119626
119627
119628
119629
119630
119631
119632
119633
119634
119635
119636
119637
119638
119639
119640
119641
119642
119643
119644
119645
119646
119647
119648
119649
119650
119651
119652
119653
119654
119655
119656
119657
119658
119659
119660
119661
119662
119663
119664
119665
119666
119667
119668
119669
119670
119671
119672
119673
119674
119675
119676
119677
119678
119679
119680
119681
119682
119683
119684
119685
119686
119687
119688
119689
119690
119691
119692
119693
119694
119695
119696
119697
119698
119699
119700
119701
119702
119703
119704
119705
119706
119707
119708
119709
119710
119711
119712
119713
119714
119715
119716
119717
119718
119719
119720
119721
119722
119723
119724
119725
119726
119727
119728
119729
119730
119731
119732
119733
119734
119735
119736
119737
119738
119739
119740
119741
119742
119743
119744
119745
119746
119747
119748
119749
119750
119751
119752
119753
119754
119755
119756
119757
119758
119759
119760
119761
119762
119763
119764
119765
119766
119767
119768
119769
119770
119771
119772
119773
119774
119775
119776
119777
119778
119779
119780
119781
119782
119783
119784
119785
119786
119787
119788
119789
119790
119791
119792
119793
119794
119795
119796
119797
119798
119799
119800
119801
119802
119803
119804
119805
119806
119807
119808
119809
119810
119811
119812
119813
119814
119815
119816
119817
119818
119819
119820
119821
119822
119823
119824
119825
119826
119827
119828
119829
119830
119831
119832
119833
119834
119835
119836
119837
119838
119839
119840
119841
119842
119843
119844
119845
119846
119847
119848
119849
119850
119851
119852
119853
119854
119855
119856
119857
119858
119859
119860
119861
119862
119863
119864
119865
119866
119867
119868
119869
119870
119871
119872
119873
119874
119875
119876
119877
119878
119879
119880
119881
119882
119883
119884
119885
119886
119887
119888
119889
119890
119891
119892
119893
119894
119895
119896
119897
119898
119899
119900
119901
119902
119903
119904
119905
119906
119907
119908
119909
119910
119911
119912
119913
119914
119915
119916
119917
119918
119919
119920
119921
119922
119923
119924
119925
119926
119927
119928
119929
119930
119931
119932
119933
119934
119935
119936
119937
119938
119939
119940
119941
119942
119943
119944
119945
119946
119947
119948
119949
119950
119951
119952
119953
119954
119955
119956
119957
119958
119959
119960
119961
119962
119963
119964
119965
119966
119967
119968
119969
119970
119971
119972
119973
119974
119975
119976
119977
119978
119979
119980
119981
119982
119983
119984
119985
119986
119987
119988
119989
119990
119991
119992
119993
119994
119995
119996
119997
119998
119999
120000
120001
120002
120003
120004
120005
120006
120007
120008
120009
120010
120011
120012
120013
120014
120015
120016
120017
120018
120019
120020
120021
120022
120023
120024
120025
120026
120027
120028
120029
120030
120031
120032
120033
120034
120035
120036
120037
120038
120039
120040
120041
120042
120043
120044
120045
120046
120047
120048
120049
120050
120051
120052
120053
120054
120055
120056
120057
120058
120059
120060
120061
120062
120063
120064
120065
120066
120067
120068
120069
120070
120071
120072
120073
120074
120075
120076
120077
120078
120079
120080
120081
120082
120083
120084
120085
120086
120087
120088
120089
120090
120091
120092
120093
120094
120095
120096
120097
120098
120099
120100
120101
120102
120103
120104
120105
120106
120107
120108
120109
120110
120111
120112
120113
120114
120115
120116
120117
120118
120119
120120
120121
120122
120123
120124
120125
120126
120127
120128
120129
120130
120131
120132
120133
120134
120135
120136
120137
120138
120139
120140
120141
120142
120143
120144
120145
120146
120147
120148
120149
120150
120151
120152
120153
120154
120155
120156
120157
120158
120159
120160
120161
120162
120163
120164
120165
120166
120167
120168
120169
120170
120171
120172
120173
120174
120175
120176
120177
120178
120179
120180
120181
120182
120183
120184
120185
120186
120187
120188
120189
120190
120191
120192
120193
120194
120195
120196
120197
120198
120199
120200
120201
120202
120203
120204
120205
120206
120207
120208
120209
120210
120211
120212
120213
120214
120215
120216
120217
120218
120219
120220
120221
120222
120223
120224
120225
120226
120227
120228
120229
120230
120231
120232
120233
120234
120235
120236
120237
120238
120239
120240
120241
120242
120243
120244
120245
120246
120247
120248
120249
120250
120251
120252
120253
120254
120255
120256
120257
120258
120259
120260
120261
120262
120263
120264
120265
120266
120267
120268
120269
120270
120271
120272
120273
120274
120275
120276
120277
120278
120279
120280
120281
120282
120283
120284
120285
120286
120287
120288
120289
120290
120291
120292
120293
120294
120295
120296
120297
120298
120299
120300
120301
120302
120303
120304
120305
120306
120307
120308
120309
120310
120311
120312
120313
120314
120315
120316
120317
120318
120319
120320
120321
120322
120323
120324
120325
120326
120327
120328
120329
120330
120331
120332
120333
120334
120335
120336
120337
120338
120339
120340
120341
120342
120343
120344
120345
120346
120347
120348
120349
120350
120351
120352
120353
120354
120355
120356
120357
120358
120359
120360
120361
120362
120363
120364
120365
120366
120367
120368
120369
120370
120371
120372
120373
120374
120375
120376
120377
120378
120379
120380
120381
120382
120383
120384
120385
120386
120387
120388
120389
120390
120391
120392
120393
120394
120395
120396
120397
120398
120399
120400
120401
120402
120403
120404
120405
120406
120407
120408
120409
120410
120411
120412
120413
120414
120415
120416
120417
120418
120419
120420
120421
120422
120423
120424
120425
120426
120427
120428
120429
120430
120431
120432
120433
120434
120435
120436
120437
120438
120439
120440
120441
120442
120443
120444
120445
120446
120447
120448
120449
120450
120451
120452
120453
120454
120455
120456
120457
120458
120459
120460
120461
120462
120463
120464
120465
120466
120467
120468
120469
120470
120471
120472
120473
120474
120475
120476
120477
120478
120479
120480
120481
120482
120483
120484
120485
120486
120487
120488
120489
120490
120491
120492
120493
120494
120495
120496
120497
120498
120499
120500
120501
120502
120503
120504
120505
120506
120507
120508
120509
120510
120511
120512
120513
120514
120515
120516
120517
120518
120519
120520
120521
120522
120523
120524
120525
120526
120527
120528
120529
120530
120531
120532
120533
120534
120535
120536
120537
120538
120539
120540
120541
120542
120543
120544
120545
120546
120547
120548
120549
120550
120551
120552
120553
120554
120555
120556
120557
120558
120559
120560
120561
120562
120563
120564
120565
120566
120567
120568
120569
120570
120571
120572
120573
120574
120575
120576
120577
120578
120579
120580
120581
120582
120583
120584
120585
120586
120587
120588
120589
120590
120591
120592
120593
120594
120595
120596
120597
120598
120599
120600
120601
120602
120603
120604
120605
120606
120607
120608
120609
120610
120611
120612
120613
120614
120615
120616
120617
120618
120619
120620
120621
120622
120623
120624
120625
120626
120627
120628
120629
120630
120631
120632
120633
120634
120635
120636
120637
120638
120639
120640
120641
120642
120643
120644
120645
120646
120647
120648
120649
120650
120651
120652
120653
120654
120655
120656
120657
120658
120659
120660
120661
120662
120663
120664
120665
120666
120667
120668
120669
120670
120671
120672
120673
120674
120675
120676
120677
120678
120679
120680
120681
120682
120683
120684
120685
120686
120687
120688
120689
120690
120691
120692
120693
120694
120695
120696
120697
120698
120699
120700
120701
120702
120703
120704
120705
120706
120707
120708
120709
120710
120711
120712
120713
120714
120715
120716
120717
120718
120719
120720
120721
120722
120723
120724
120725
120726
120727
120728
120729
120730
120731
120732
120733
120734
120735
120736
120737
120738
120739
120740
120741
120742
120743
120744
120745
120746
120747
120748
120749
120750
120751
120752
120753
120754
120755
120756
120757
120758
120759
120760
120761
120762
120763
120764
120765
120766
120767
120768
120769
120770
120771
120772
120773
120774
120775
120776
120777
120778
120779
120780
120781
120782
120783
120784
120785
120786
120787
120788
120789
120790
120791
120792
120793
120794
120795
120796
120797
120798
120799
120800
120801
120802
120803
120804
120805
120806
120807
120808
120809
120810
120811
120812
120813
120814
120815
120816
120817
120818
120819
120820
120821
120822
120823
120824
120825
120826
120827
120828
120829
120830
120831
120832
120833
120834
120835
120836
120837
120838
120839
120840
120841
120842
120843
120844
120845
120846
120847
120848
120849
120850
120851
120852
120853
120854
120855
120856
120857
120858
120859
120860
120861
120862
120863
120864
120865
120866
120867
120868
120869
120870
120871
120872
120873
120874
120875
120876
120877
120878
120879
120880
120881
120882
120883
120884
120885
120886
120887
120888
120889
120890
120891
120892
120893
120894
120895
120896
120897
120898
120899
120900
120901
120902
120903
120904
120905
120906
120907
120908
120909
120910
120911
120912
120913
120914
120915
120916
120917
120918
120919
120920
120921
120922
120923
120924
120925
120926
120927
120928
120929
120930
120931
120932
120933
120934
120935
120936
120937
120938
120939
120940
120941
120942
120943
120944
120945
120946
120947
120948
120949
120950
120951
120952
120953
120954
120955
120956
120957
120958
120959
120960
120961
120962
120963
120964
120965
120966
120967
120968
120969
120970
120971
120972
120973
120974
120975
120976
120977
120978
120979
120980
120981
120982
120983
120984
120985
120986
120987
120988
120989
120990
120991
120992
120993
120994
120995
120996
120997
120998
120999
121000
121001
121002
121003
121004
121005
121006
121007
121008
121009
121010
121011
121012
121013
121014
121015
121016
121017
121018
121019
121020
121021
121022
121023
121024
121025
121026
121027
121028
121029
121030
121031
121032
121033
121034
121035
121036
121037
121038
121039
121040
121041
121042
121043
121044
121045
121046
121047
121048
121049
121050
121051
121052
121053
121054
121055
121056
121057
121058
121059
121060
121061
121062
121063
121064
121065
121066
121067
121068
121069
121070
121071
121072
121073
121074
121075
121076
121077
121078
121079
121080
121081
121082
121083
121084
121085
121086
121087
121088
121089
121090
121091
121092
121093
121094
121095
121096
121097
121098
121099
121100
121101
121102
121103
121104
121105
121106
121107
121108
121109
121110
121111
121112
121113
121114
121115
121116
121117
121118
121119
121120
121121
121122
121123
121124
121125
121126
121127
121128
121129
121130
121131
121132
121133
121134
121135
121136
121137
121138
121139
121140
121141
121142
121143
121144
121145
121146
121147
121148
121149
121150
121151
121152
121153
121154
121155
121156
121157
121158
121159
121160
121161
121162
121163
121164
121165
121166
121167
121168
121169
121170
121171
121172
121173
121174
121175
121176
121177
121178
121179
121180
121181
121182
121183
121184
121185
121186
121187
121188
121189
121190
121191
121192
121193
121194
121195
121196
121197
121198
121199
121200
121201
121202
121203
121204
121205
121206
121207
121208
121209
121210
121211
121212
121213
121214
121215
121216
121217
121218
121219
121220
121221
121222
121223
121224
121225
121226
121227
121228
121229
121230
121231
121232
121233
121234
121235
121236
121237
121238
121239
121240
121241
121242
121243
121244
121245
121246
121247
121248
121249
121250
121251
121252
121253
121254
121255
121256
121257
121258
121259
121260
121261
121262
121263
121264
121265
121266
121267
121268
121269
121270
121271
121272
121273
121274
121275
121276
121277
121278
121279
121280
121281
121282
121283
121284
121285
121286
121287
121288
121289
121290
121291
121292
121293
121294
121295
121296
121297
121298
121299
121300
121301
121302
121303
121304
121305
121306
121307
121308
121309
121310
121311
121312
121313
121314
121315
121316
121317
121318
121319
121320
121321
121322
121323
121324
121325
121326
121327
121328
121329
121330
121331
121332
121333
121334
121335
121336
121337
121338
121339
121340
121341
121342
121343
121344
121345
121346
121347
121348
121349
121350
121351
121352
121353
121354
121355
121356
121357
121358
121359
121360
121361
121362
121363
121364
121365
121366
121367
121368
121369
121370
121371
121372
121373
121374
121375
121376
121377
121378
121379
121380
121381
121382
121383
121384
121385
121386
121387
121388
121389
121390
121391
121392
121393
121394
121395
121396
121397
121398
121399
121400
121401
121402
121403
121404
121405
121406
121407
121408
121409
121410
121411
121412
121413
121414
121415
121416
121417
121418
121419
121420
121421
121422
121423
121424
121425
121426
121427
121428
121429
121430
121431
121432
121433
121434
121435
121436
121437
121438
121439
121440
121441
121442
121443
121444
121445
121446
121447
121448
121449
121450
121451
121452
121453
121454
121455
121456
121457
121458
121459
121460
121461
121462
121463
121464
121465
121466
121467
121468
121469
121470
121471
121472
121473
121474
121475
121476
121477
121478
121479
121480
121481
121482
121483
121484
121485
121486
121487
121488
121489
121490
121491
121492
121493
121494
121495
121496
121497
121498
121499
121500
121501
121502
121503
121504
121505
121506
121507
121508
121509
121510
121511
121512
121513
121514
121515
121516
121517
121518
121519
121520
121521
121522
121523
121524
121525
121526
121527
121528
121529
121530
121531
121532
121533
121534
121535
121536
121537
121538
121539
121540
121541
121542
121543
121544
121545
121546
121547
121548
121549
121550
121551
121552
121553
121554
121555
121556
121557
121558
121559
121560
121561
121562
121563
121564
121565
121566
121567
121568
121569
121570
121571
121572
121573
121574
121575
121576
121577
121578
121579
121580
121581
121582
121583
121584
121585
121586
121587
121588
121589
121590
121591
121592
121593
121594
121595
121596
121597
121598
121599
121600
121601
121602
121603
121604
121605
121606
121607
121608
121609
121610
121611
121612
121613
121614
121615
121616
121617
121618
121619
121620
121621
121622
121623
121624
121625
121626
121627
121628
121629
121630
121631
121632
121633
121634
121635
121636
121637
121638
121639
121640
121641
121642
121643
121644
121645
121646
121647
121648
121649
121650
121651
121652
121653
121654
121655
121656
121657
121658
121659
121660
121661
121662
121663
121664
121665
121666
121667
121668
121669
121670
121671
121672
121673
121674
121675
121676
121677
121678
121679
121680
121681
121682
121683
121684
121685
121686
121687
121688
121689
121690
121691
121692
121693
121694
121695
121696
121697
121698
121699
121700
121701
121702
121703
121704
121705
121706
121707
121708
121709
121710
121711
121712
121713
121714
121715
121716
121717
121718
121719
121720
121721
121722
121723
121724
121725
121726
121727
121728
121729
121730
121731
121732
121733
121734
121735
121736
121737
121738
121739
121740
121741
121742
121743
121744
121745
121746
121747
121748
121749
121750
121751
121752
121753
121754
121755
121756
121757
121758
121759
121760
121761
121762
121763
121764
121765
121766
121767
121768
121769
121770
121771
121772
121773
121774
121775
121776
121777
121778
121779
121780
121781
121782
121783
121784
121785
121786
121787
121788
121789
121790
121791
121792
121793
121794
121795
121796
121797
121798
121799
121800
121801
121802
121803
121804
121805
121806
121807
121808
121809
121810
121811
121812
121813
121814
121815
121816
121817
121818
121819
121820
121821
121822
121823
121824
121825
121826
121827
121828
121829
121830
121831
121832
121833
121834
121835
121836
121837
121838
121839
121840
121841
121842
121843
121844
121845
121846
121847
121848
121849
121850
121851
121852
121853
121854
121855
121856
121857
121858
121859
121860
121861
121862
121863
121864
121865
121866
121867
121868
121869
121870
121871
121872
121873
121874
121875
121876
121877
121878
121879
121880
121881
121882
121883
121884
121885
121886
121887
121888
121889
121890
121891
121892
121893
121894
121895
121896
121897
121898
121899
121900
121901
121902
121903
121904
121905
121906
121907
121908
121909
121910
121911
121912
121913
121914
121915
121916
121917
121918
121919
121920
121921
121922
121923
121924
121925
121926
121927
121928
121929
121930
121931
121932
121933
121934
121935
121936
121937
121938
121939
121940
121941
121942
121943
121944
121945
121946
121947
121948
121949
121950
121951
121952
121953
121954
121955
121956
121957
121958
121959
121960
121961
121962
121963
121964
121965
121966
121967
121968
121969
121970
121971
121972
121973
121974
121975
121976
121977
121978
121979
121980
121981
121982
121983
121984
121985
121986
121987
121988
121989
121990
121991
121992
121993
121994
121995
121996
121997
121998
121999
122000
122001
122002
122003
122004
122005
122006
122007
122008
122009
122010
122011
122012
122013
122014
122015
122016
122017
122018
122019
122020
122021
122022
122023
122024
122025
122026
122027
122028
122029
122030
122031
122032
122033
122034
122035
122036
122037
122038
122039
122040
122041
122042
122043
122044
122045
122046
122047
122048
122049
122050
122051
122052
122053
122054
122055
122056
122057
122058
122059
122060
122061
122062
122063
122064
122065
122066
122067
122068
122069
122070
122071
122072
122073
122074
122075
122076
122077
122078
122079
122080
122081
122082
122083
122084
122085
122086
122087
122088
122089
122090
122091
122092
122093
122094
122095
122096
122097
122098
122099
122100
122101
122102
122103
122104
122105
122106
122107
122108
122109
122110
122111
122112
122113
122114
122115
122116
122117
122118
122119
122120
122121
122122
122123
122124
122125
122126
122127
122128
122129
122130
122131
122132
122133
122134
122135
122136
122137
122138
122139
122140
122141
122142
122143
122144
122145
122146
122147
122148
122149
122150
122151
122152
122153
122154
122155
122156
122157
122158
122159
122160
122161
122162
122163
122164
122165
122166
122167
122168
122169
122170
122171
122172
122173
122174
122175
122176
122177
122178
122179
122180
122181
122182
122183
122184
122185
122186
122187
122188
122189
122190
122191
122192
122193
122194
122195
122196
122197
122198
122199
122200
122201
122202
122203
122204
122205
122206
122207
122208
122209
122210
122211
122212
122213
122214
122215
122216
122217
122218
122219
122220
122221
122222
122223
122224
122225
122226
122227
122228
122229
122230
122231
122232
122233
122234
122235
122236
122237
122238
122239
122240
122241
122242
122243
122244
122245
122246
122247
122248
122249
122250
122251
122252
122253
122254
122255
122256
122257
122258
122259
122260
122261
122262
122263
122264
122265
122266
122267
122268
122269
122270
122271
122272
122273
122274
122275
122276
122277
122278
122279
122280
122281
122282
122283
122284
122285
122286
122287
122288
122289
122290
122291
122292
122293
122294
122295
122296
122297
122298
122299
122300
122301
122302
122303
122304
122305
122306
122307
122308
122309
122310
122311
122312
122313
122314
122315
122316
122317
122318
122319
122320
122321
122322
122323
122324
122325
122326
122327
122328
122329
122330
122331
122332
122333
122334
122335
122336
122337
122338
122339
122340
122341
122342
122343
122344
122345
122346
122347
122348
122349
122350
122351
122352
122353
122354
122355
122356
122357
122358
122359
122360
122361
122362
122363
122364
122365
122366
122367
122368
122369
122370
122371
122372
122373
122374
122375
122376
122377
122378
122379
122380
122381
122382
122383
122384
122385
122386
122387
122388
122389
122390
122391
122392
122393
122394
122395
122396
122397
122398
122399
122400
122401
122402
122403
122404
122405
122406
122407
122408
122409
122410
122411
122412
122413
122414
122415
122416
122417
122418
122419
122420
122421
122422
122423
122424
122425
122426
122427
122428
122429
122430
122431
122432
122433
122434
122435
122436
122437
122438
122439
122440
122441
122442
122443
122444
122445
122446
122447
122448
122449
122450
122451
122452
122453
122454
122455
122456
122457
122458
122459
122460
122461
122462
122463
122464
122465
122466
122467
122468
122469
122470
122471
122472
122473
122474
122475
122476
122477
122478
122479
122480
122481
122482
122483
122484
122485
122486
122487
122488
122489
122490
122491
122492
122493
122494
122495
122496
122497
122498
122499
122500
122501
122502
122503
122504
122505
122506
122507
122508
122509
122510
122511
122512
122513
122514
122515
122516
122517
122518
122519
122520
122521
122522
122523
122524
122525
122526
122527
122528
122529
122530
122531
122532
122533
122534
122535
122536
122537
122538
122539
122540
122541
122542
122543
122544
122545
122546
122547
122548
122549
122550
122551
122552
122553
122554
122555
122556
122557
122558
122559
122560
122561
122562
122563
122564
122565
122566
122567
122568
122569
122570
122571
122572
122573
122574
122575
122576
122577
122578
122579
122580
122581
122582
122583
122584
122585
122586
122587
122588
122589
122590
122591
122592
122593
122594
122595
122596
122597
122598
122599
122600
122601
122602
122603
122604
122605
122606
122607
122608
122609
122610
122611
122612
122613
122614
122615
122616
122617
122618
122619
122620
122621
122622
122623
122624
122625
122626
122627
122628
122629
122630
122631
122632
122633
122634
122635
122636
122637
122638
122639
122640
122641
122642
122643
122644
122645
122646
122647
122648
122649
122650
122651
122652
122653
122654
122655
122656
122657
122658
122659
122660
122661
122662
122663
122664
122665
122666
122667
122668
122669
122670
122671
122672
122673
122674
122675
122676
122677
122678
122679
122680
122681
122682
122683
122684
122685
122686
122687
122688
122689
122690
122691
122692
122693
122694
122695
122696
122697
122698
122699
122700
122701
122702
122703
122704
122705
122706
122707
122708
122709
122710
122711
122712
122713
122714
122715
122716
122717
122718
122719
122720
122721
122722
122723
122724
122725
122726
122727
122728
122729
122730
122731
122732
122733
122734
122735
122736
122737
122738
122739
122740
122741
122742
122743
122744
122745
122746
122747
122748
122749
122750
122751
122752
122753
122754
122755
122756
122757
122758
122759
122760
122761
122762
122763
122764
122765
122766
122767
122768
122769
122770
122771
122772
122773
122774
122775
122776
122777
122778
122779
122780
122781
122782
122783
122784
122785
122786
122787
122788
122789
122790
122791
122792
122793
122794
122795
122796
122797
122798
122799
122800
122801
122802
122803
122804
122805
122806
122807
122808
122809
122810
122811
122812
122813
122814
122815
122816
122817
122818
122819
122820
122821
122822
122823
122824
122825
122826
122827
122828
122829
122830
122831
122832
122833
122834
122835
122836
122837
122838
122839
122840
122841
122842
122843
122844
122845
122846
122847
122848
122849
122850
122851
122852
122853
122854
122855
122856
122857
122858
122859
122860
122861
122862
122863
122864
122865
122866
122867
122868
122869
122870
122871
122872
122873
122874
122875
122876
122877
122878
122879
122880
122881
122882
122883
122884
122885
122886
122887
122888
122889
122890
122891
122892
122893
122894
122895
122896
122897
122898
122899
122900
122901
122902
122903
122904
122905
122906
122907
122908
122909
122910
122911
122912
122913
122914
122915
122916
122917
122918
122919
122920
122921
122922
122923
122924
122925
122926
122927
122928
122929
122930
122931
122932
122933
122934
122935
122936
122937
122938
122939
122940
122941
122942
122943
122944
122945
122946
122947
122948
122949
122950
122951
122952
122953
122954
122955
122956
122957
122958
122959
122960
122961
122962
122963
122964
122965
122966
122967
122968
122969
122970
122971
122972
122973
122974
122975
122976
122977
122978
122979
122980
122981
122982
122983
122984
122985
122986
122987
122988
122989
122990
122991
122992
122993
122994
122995
122996
122997
122998
122999
123000
123001
123002
123003
123004
123005
123006
123007
123008
123009
123010
123011
123012
123013
123014
123015
123016
123017
123018
123019
123020
123021
123022
123023
123024
123025
123026
123027
123028
123029
123030
123031
123032
123033
123034
123035
123036
123037
123038
123039
123040
123041
123042
123043
123044
123045
123046
123047
123048
123049
123050
123051
123052
123053
123054
123055
123056
123057
123058
123059
123060
123061
123062
123063
123064
123065
123066
123067
123068
123069
123070
123071
123072
123073
123074
123075
123076
123077
123078
123079
123080
123081
123082
123083
123084
123085
123086
123087
123088
123089
123090
123091
123092
123093
123094
123095
123096
123097
123098
123099
123100
123101
123102
123103
123104
123105
123106
123107
123108
123109
123110
123111
123112
123113
123114
123115
123116
123117
123118
123119
123120
123121
123122
123123
123124
123125
123126
123127
123128
123129
123130
123131
123132
123133
123134
123135
123136
123137
123138
123139
123140
123141
123142
123143
123144
123145
123146
123147
123148
123149
123150
123151
123152
123153
123154
123155
123156
123157
123158
123159
123160
123161
123162
123163
123164
123165
123166
123167
123168
123169
123170
123171
123172
123173
123174
123175
123176
123177
123178
123179
123180
123181
123182
123183
123184
123185
123186
123187
123188
123189
123190
123191
123192
123193
123194
123195
123196
123197
123198
123199
123200
123201
123202
123203
123204
123205
123206
123207
123208
123209
123210
123211
123212
123213
123214
123215
123216
123217
123218
123219
123220
123221
123222
123223
123224
123225
123226
123227
123228
123229
123230
123231
123232
123233
123234
123235
123236
123237
123238
123239
123240
123241
123242
123243
123244
123245
123246
123247
123248
123249
123250
123251
123252
123253
123254
123255
123256
123257
123258
123259
123260
123261
123262
123263
123264
123265
123266
123267
123268
123269
123270
123271
123272
123273
123274
123275
123276
123277
123278
123279
123280
123281
123282
123283
123284
123285
123286
123287
123288
123289
123290
123291
123292
123293
123294
123295
123296
123297
123298
123299
123300
123301
123302
123303
123304
123305
123306
123307
123308
123309
123310
123311
123312
123313
123314
123315
123316
123317
123318
123319
123320
123321
123322
123323
123324
123325
123326
123327
123328
123329
123330
123331
123332
123333
123334
123335
123336
123337
123338
123339
123340
123341
123342
123343
123344
123345
123346
123347
123348
123349
123350
123351
123352
123353
123354
123355
123356
123357
123358
123359
123360
123361
123362
123363
123364
123365
123366
123367
123368
123369
123370
123371
123372
123373
123374
123375
123376
123377
123378
123379
123380
123381
123382
123383
123384
123385
123386
123387
123388
123389
123390
123391
123392
123393
123394
123395
123396
123397
123398
123399
123400
123401
123402
123403
123404
123405
123406
123407
123408
123409
123410
123411
123412
123413
123414
123415
123416
123417
123418
123419
123420
123421
123422
123423
123424
123425
123426
123427
123428
123429
123430
123431
123432
123433
123434
123435
123436
123437
123438
123439
123440
123441
123442
123443
123444
123445
123446
123447
123448
123449
123450
123451
123452
123453
123454
123455
123456
123457
123458
123459
123460
123461
123462
123463
123464
123465
123466
123467
123468
123469
123470
123471
123472
123473
123474
123475
123476
123477
123478
123479
123480
123481
123482
123483
123484
123485
123486
123487
123488
123489
123490
123491
123492
123493
123494
123495
123496
123497
123498
123499
123500
123501
123502
123503
123504
123505
123506
123507
123508
123509
123510
123511
123512
123513
123514
123515
123516
123517
123518
123519
123520
123521
123522
123523
123524
123525
123526
123527
123528
123529
123530
123531
123532
123533
123534
123535
123536
123537
123538
123539
123540
123541
123542
123543
123544
123545
123546
123547
123548
123549
123550
123551
123552
123553
123554
123555
123556
123557
123558
123559
123560
123561
123562
123563
123564
123565
123566
123567
123568
123569
123570
123571
123572
123573
123574
123575
123576
123577
123578
123579
123580
123581
123582
123583
123584
123585
123586
123587
123588
123589
123590
123591
123592
123593
123594
123595
123596
123597
123598
123599
123600
123601
123602
123603
123604
123605
123606
123607
123608
123609
123610
123611
123612
123613
123614
123615
123616
123617
123618
123619
123620
123621
123622
123623
123624
123625
123626
123627
123628
123629
123630
123631
123632
123633
123634
123635
123636
123637
123638
123639
123640
123641
123642
123643
123644
123645
123646
123647
123648
123649
123650
123651
123652
123653
123654
123655
123656
123657
123658
123659
123660
123661
123662
123663
123664
123665
123666
123667
123668
123669
123670
123671
123672
123673
123674
123675
123676
123677
123678
123679
123680
123681
123682
123683
123684
123685
123686
123687
123688
123689
123690
123691
123692
123693
123694
123695
123696
123697
123698
123699
123700
123701
123702
123703
123704
123705
123706
123707
123708
123709
123710
123711
123712
123713
123714
123715
123716
123717
123718
123719
123720
123721
123722
123723
123724
123725
123726
123727
123728
123729
123730
123731
123732
123733
123734
123735
123736
123737
123738
123739
123740
123741
123742
123743
123744
123745
123746
123747
123748
123749
123750
123751
123752
123753
123754
123755
123756
123757
123758
123759
123760
123761
123762
123763
123764
123765
123766
123767
123768
123769
123770
123771
123772
123773
123774
123775
123776
123777
123778
123779
123780
123781
123782
123783
123784
123785
123786
123787
123788
123789
123790
123791
123792
123793
123794
123795
123796
123797
123798
123799
123800
123801
123802
123803
123804
123805
123806
123807
123808
123809
123810
123811
123812
123813
123814
123815
123816
123817
123818
123819
123820
123821
123822
123823
123824
123825
123826
123827
123828
123829
123830
123831
123832
123833
123834
123835
123836
123837
123838
123839
123840
123841
123842
123843
123844
123845
123846
123847
123848
123849
123850
123851
123852
123853
123854
123855
123856
123857
123858
123859
123860
123861
123862
123863
123864
123865
123866
123867
123868
123869
123870
123871
123872
123873
123874
123875
123876
123877
123878
123879
123880
123881
123882
123883
123884
123885
123886
123887
123888
123889
123890
123891
123892
123893
123894
123895
123896
123897
123898
123899
123900
123901
123902
123903
123904
123905
123906
123907
123908
123909
123910
123911
123912
123913
123914
123915
123916
123917
123918
123919
123920
123921
123922
123923
123924
123925
123926
123927
123928
123929
123930
123931
123932
123933
123934
123935
123936
123937
123938
123939
123940
123941
123942
123943
123944
123945
123946
123947
123948
123949
123950
123951
123952
123953
123954
123955
123956
123957
123958
123959
123960
123961
123962
123963
123964
123965
123966
123967
123968
123969
123970
123971
123972
123973
123974
123975
123976
123977
123978
123979
123980
123981
123982
123983
123984
123985
123986
123987
123988
123989
123990
123991
123992
123993
123994
123995
123996
123997
123998
123999
124000
124001
124002
124003
124004
124005
124006
124007
124008
124009
124010
124011
124012
124013
124014
124015
124016
124017
124018
124019
124020
124021
124022
124023
124024
124025
124026
124027
124028
124029
124030
124031
124032
124033
124034
124035
124036
124037
124038
124039
124040
124041
124042
124043
124044
124045
124046
124047
124048
124049
124050
124051
124052
124053
124054
124055
124056
124057
124058
124059
124060
124061
124062
124063
124064
124065
124066
124067
124068
124069
124070
124071
124072
124073
124074
124075
124076
124077
124078
124079
124080
124081
124082
124083
124084
124085
124086
124087
124088
124089
124090
124091
124092
124093
124094
124095
124096
124097
124098
124099
124100
124101
124102
124103
124104
124105
124106
124107
124108
124109
124110
124111
124112
124113
124114
124115
124116
124117
124118
124119
124120
124121
124122
124123
124124
124125
124126
124127
124128
124129
124130
124131
124132
124133
124134
124135
124136
124137
124138
124139
124140
124141
124142
124143
124144
124145
124146
124147
124148
124149
124150
124151
124152
124153
124154
124155
124156
124157
124158
124159
124160
124161
124162
124163
124164
124165
124166
124167
124168
124169
124170
124171
124172
124173
124174
124175
124176
124177
124178
124179
124180
124181
124182
124183
124184
124185
124186
124187
124188
124189
124190
124191
124192
124193
124194
124195
124196
124197
124198
124199
124200
124201
124202
124203
124204
124205
124206
124207
124208
124209
124210
124211
124212
124213
124214
124215
124216
124217
124218
124219
124220
124221
124222
124223
124224
124225
124226
124227
124228
124229
124230
124231
124232
124233
124234
124235
124236
124237
124238
124239
124240
124241
124242
124243
124244
124245
124246
124247
124248
124249
124250
124251
124252
124253
124254
124255
124256
124257
124258
124259
124260
124261
124262
124263
124264
124265
124266
124267
124268
124269
124270
124271
124272
124273
124274
124275
124276
124277
124278
124279
124280
124281
124282
124283
124284
124285
124286
124287
124288
124289
124290
124291
124292
124293
124294
124295
124296
124297
124298
124299
124300
124301
124302
124303
124304
124305
124306
124307
124308
124309
124310
124311
124312
124313
124314
124315
124316
124317
124318
124319
124320
124321
124322
124323
124324
124325
124326
124327
124328
124329
124330
124331
124332
124333
124334
124335
124336
124337
124338
124339
124340
124341
124342
124343
124344
124345
124346
124347
124348
124349
124350
124351
124352
124353
124354
124355
124356
124357
124358
124359
124360
124361
124362
124363
124364
124365
124366
124367
124368
124369
124370
124371
124372
124373
124374
124375
124376
124377
124378
124379
124380
124381
124382
124383
124384
124385
124386
124387
124388
124389
124390
124391
124392
124393
124394
124395
124396
124397
124398
124399
124400
124401
124402
124403
124404
124405
124406
124407
124408
124409
124410
124411
124412
124413
124414
124415
124416
124417
124418
124419
124420
124421
124422
124423
124424
124425
124426
124427
124428
124429
124430
124431
124432
124433
124434
124435
124436
124437
124438
124439
124440
124441
124442
124443
124444
124445
124446
124447
124448
124449
124450
124451
124452
124453
124454
124455
124456
124457
124458
124459
124460
124461
124462
124463
124464
124465
124466
124467
124468
124469
124470
124471
124472
124473
124474
124475
124476
124477
124478
124479
124480
124481
124482
124483
124484
124485
124486
124487
124488
124489
124490
124491
124492
124493
124494
124495
124496
124497
124498
124499
124500
124501
124502
124503
124504
124505
124506
124507
124508
124509
124510
124511
124512
124513
124514
124515
124516
124517
124518
124519
124520
124521
124522
124523
124524
124525
124526
124527
124528
124529
124530
124531
124532
124533
124534
124535
124536
124537
124538
124539
124540
124541
124542
124543
124544
124545
124546
124547
124548
124549
124550
124551
124552
124553
124554
124555
124556
124557
124558
124559
124560
124561
124562
124563
124564
124565
124566
124567
124568
124569
124570
124571
124572
124573
124574
124575
124576
124577
124578
124579
124580
124581
124582
124583
124584
124585
124586
124587
124588
124589
124590
124591
124592
124593
124594
124595
124596
124597
124598
124599
124600
124601
124602
124603
124604
124605
124606
124607
124608
124609
124610
124611
124612
124613
124614
124615
124616
124617
124618
124619
124620
124621
124622
124623
124624
124625
124626
124627
124628
124629
124630
124631
124632
124633
124634
124635
124636
124637
124638
124639
124640
124641
124642
124643
124644
124645
124646
124647
124648
124649
124650
124651
124652
124653
124654
124655
124656
124657
124658
124659
124660
124661
124662
124663
124664
124665
124666
124667
124668
124669
124670
124671
124672
124673
124674
124675
124676
124677
124678
124679
124680
124681
124682
124683
124684
124685
124686
124687
124688
124689
124690
124691
124692
124693
124694
124695
124696
124697
124698
124699
124700
124701
124702
124703
124704
124705
124706
124707
124708
124709
124710
124711
124712
124713
124714
124715
124716
124717
124718
124719
124720
124721
124722
124723
124724
124725
124726
124727
124728
124729
124730
124731
124732
124733
124734
124735
124736
124737
124738
124739
124740
124741
124742
124743
124744
124745
124746
124747
124748
124749
124750
124751
124752
124753
124754
124755
124756
124757
124758
124759
124760
124761
124762
124763
124764
124765
124766
124767
124768
124769
124770
124771
124772
124773
124774
124775
124776
124777
124778
124779
124780
124781
124782
124783
124784
124785
124786
124787
124788
124789
124790
124791
124792
124793
124794
124795
124796
124797
124798
124799
124800
124801
124802
124803
124804
124805
124806
124807
124808
124809
124810
124811
124812
124813
124814
124815
124816
124817
124818
124819
124820
124821
124822
124823
124824
124825
124826
124827
124828
124829
124830
124831
124832
124833
124834
124835
124836
124837
124838
124839
124840
124841
124842
124843
124844
124845
124846
124847
124848
124849
124850
124851
124852
124853
124854
124855
124856
124857
124858
124859
124860
124861
124862
124863
124864
124865
124866
124867
124868
124869
124870
124871
124872
124873
124874
124875
124876
124877
124878
124879
124880
124881
124882
124883
124884
124885
124886
124887
124888
124889
124890
124891
124892
124893
124894
124895
124896
124897
124898
124899
124900
124901
124902
124903
124904
124905
124906
124907
124908
124909
124910
124911
124912
124913
124914
124915
124916
124917
124918
124919
124920
124921
124922
124923
124924
124925
124926
124927
124928
124929
124930
124931
124932
124933
124934
124935
124936
124937
124938
124939
124940
124941
124942
124943
124944
124945
124946
124947
124948
124949
124950
124951
124952
124953
124954
124955
124956
124957
124958
124959
124960
124961
124962
124963
124964
124965
124966
124967
124968
124969
124970
124971
124972
124973
124974
124975
124976
124977
124978
124979
124980
124981
124982
124983
124984
124985
124986
124987
124988
124989
124990
124991
124992
124993
124994
124995
124996
124997
124998
124999
125000
125001
125002
125003
125004
125005
125006
125007
125008
125009
125010
125011
125012
125013
125014
125015
125016
125017
125018
125019
125020
125021
125022
125023
125024
125025
125026
125027
125028
125029
125030
125031
125032
125033
125034
125035
125036
125037
125038
125039
125040
125041
125042
125043
125044
125045
125046
125047
125048
125049
125050
125051
125052
125053
125054
125055
125056
125057
125058
125059
125060
125061
125062
125063
125064
125065
125066
125067
125068
125069
125070
125071
125072
125073
125074
125075
125076
125077
125078
125079
125080
125081
125082
125083
125084
125085
125086
125087
125088
125089
125090
125091
125092
125093
125094
125095
125096
125097
125098
125099
125100
125101
125102
125103
125104
125105
125106
125107
125108
125109
125110
125111
125112
125113
125114
125115
125116
125117
125118
125119
125120
125121
125122
125123
125124
125125
125126
125127
125128
125129
125130
125131
125132
125133
125134
125135
125136
125137
125138
125139
125140
125141
125142
125143
125144
125145
125146
125147
125148
125149
125150
125151
125152
125153
125154
125155
125156
125157
125158
125159
125160
125161
125162
125163
125164
125165
125166
125167
125168
125169
125170
125171
125172
125173
125174
125175
125176
125177
125178
125179
125180
125181
125182
125183
125184
125185
125186
125187
125188
125189
125190
125191
125192
125193
125194
125195
125196
125197
125198
125199
125200
125201
125202
125203
125204
125205
125206
125207
125208
125209
125210
125211
125212
125213
125214
125215
125216
125217
125218
125219
125220
125221
125222
125223
125224
125225
125226
125227
125228
125229
125230
125231
125232
125233
125234
125235
125236
125237
125238
125239
125240
125241
125242
125243
125244
125245
125246
125247
125248
125249
125250
125251
125252
125253
125254
125255
125256
125257
125258
125259
125260
125261
125262
125263
125264
125265
125266
125267
125268
125269
125270
125271
125272
125273
125274
125275
125276
125277
125278
125279
125280
125281
125282
125283
125284
125285
125286
125287
125288
125289
125290
125291
125292
125293
125294
125295
125296
125297
125298
125299
125300
125301
125302
125303
125304
125305
125306
125307
125308
125309
125310
125311
125312
125313
125314
125315
125316
125317
125318
125319
125320
125321
125322
125323
125324
125325
125326
125327
125328
125329
125330
125331
125332
125333
125334
125335
125336
125337
125338
125339
125340
125341
125342
125343
125344
125345
125346
125347
125348
125349
125350
125351
125352
125353
125354
125355
125356
125357
125358
125359
125360
125361
125362
125363
125364
125365
125366
125367
125368
125369
125370
125371
125372
125373
125374
125375
125376
125377
125378
125379
125380
125381
125382
125383
125384
125385
125386
125387
125388
125389
125390
125391
125392
125393
125394
125395
125396
125397
125398
125399
125400
125401
125402
125403
125404
125405
125406
125407
125408
125409
125410
125411
125412
125413
125414
125415
125416
125417
125418
125419
125420
125421
125422
125423
125424
125425
125426
125427
125428
125429
125430
125431
125432
125433
125434
125435
125436
125437
125438
125439
125440
125441
125442
125443
125444
125445
125446
125447
125448
125449
125450
125451
125452
125453
125454
125455
125456
125457
125458
125459
125460
125461
125462
125463
125464
125465
125466
125467
125468
125469
125470
125471
125472
125473
125474
125475
125476
125477
125478
125479
125480
125481
125482
125483
125484
125485
125486
125487
125488
125489
125490
125491
125492
125493
125494
125495
125496
125497
125498
125499
125500
125501
125502
125503
125504
125505
125506
125507
125508
125509
125510
125511
125512
125513
125514
125515
125516
125517
125518
125519
125520
125521
125522
125523
125524
125525
125526
125527
125528
125529
125530
125531
125532
125533
125534
125535
125536
125537
125538
125539
125540
125541
125542
125543
125544
125545
125546
125547
125548
125549
125550
125551
125552
125553
125554
125555
125556
125557
125558
125559
125560
125561
125562
125563
125564
125565
125566
125567
125568
125569
125570
125571
125572
125573
125574
125575
125576
125577
125578
125579
125580
125581
125582
125583
125584
125585
125586
125587
125588
125589
125590
125591
125592
125593
125594
125595
125596
125597
125598
125599
125600
125601
125602
125603
125604
125605
125606
125607
125608
125609
125610
125611
125612
125613
125614
125615
125616
125617
125618
125619
125620
125621
125622
125623
125624
125625
125626
125627
125628
125629
125630
125631
125632
125633
125634
125635
125636
125637
125638
125639
125640
125641
125642
125643
125644
125645
125646
125647
125648
125649
125650
125651
125652
125653
125654
125655
125656
125657
125658
125659
125660
125661
125662
125663
125664
125665
125666
125667
125668
125669
125670
125671
125672
125673
125674
125675
125676
125677
125678
125679
125680
125681
125682
125683
125684
125685
125686
125687
125688
125689
125690
125691
125692
125693
125694
125695
125696
125697
125698
125699
125700
125701
125702
125703
125704
125705
125706
125707
125708
125709
125710
125711
125712
125713
125714
125715
125716
125717
125718
125719
125720
125721
125722
125723
125724
125725
125726
125727
125728
125729
125730
125731
125732
125733
125734
125735
125736
125737
125738
125739
125740
125741
125742
125743
125744
125745
125746
125747
125748
125749
125750
125751
125752
125753
125754
125755
125756
125757
125758
125759
125760
125761
125762
125763
125764
125765
125766
125767
125768
125769
125770
125771
125772
125773
125774
125775
125776
125777
125778
125779
125780
125781
125782
125783
125784
125785
125786
125787
125788
125789
125790
125791
125792
125793
125794
125795
125796
125797
125798
125799
125800
125801
125802
125803
125804
125805
125806
125807
125808
125809
125810
125811
125812
125813
125814
125815
125816
125817
125818
125819
125820
125821
125822
125823
125824
125825
125826
125827
125828
125829
125830
125831
125832
125833
125834
125835
125836
125837
125838
125839
125840
125841
125842
125843
125844
125845
125846
125847
125848
125849
125850
125851
125852
125853
125854
125855
125856
125857
125858
125859
125860
125861
125862
125863
125864
125865
125866
125867
125868
125869
125870
125871
125872
125873
125874
125875
125876
125877
125878
125879
125880
125881
125882
125883
125884
125885
125886
125887
125888
125889
125890
125891
125892
125893
125894
125895
125896
125897
125898
125899
125900
125901
125902
125903
125904
125905
125906
125907
125908
125909
125910
125911
125912
125913
125914
125915
125916
125917
125918
125919
125920
125921
125922
125923
125924
125925
125926
125927
125928
125929
125930
125931
125932
125933
125934
125935
125936
125937
125938
125939
125940
125941
125942
125943
125944
125945
125946
125947
125948
125949
125950
125951
125952
125953
125954
125955
125956
125957
125958
125959
125960
125961
125962
125963
125964
125965
125966
125967
125968
125969
125970
125971
125972
125973
125974
125975
125976
125977
125978
125979
125980
125981
125982
125983
125984
125985
125986
125987
125988
125989
125990
125991
125992
125993
125994
125995
125996
125997
125998
125999
126000
126001
126002
126003
126004
126005
126006
126007
126008
126009
126010
126011
126012
126013
126014
126015
126016
126017
126018
126019
126020
126021
126022
126023
126024
126025
126026
126027
126028
126029
126030
126031
126032
126033
126034
126035
126036
126037
126038
126039
126040
126041
126042
126043
126044
126045
126046
126047
126048
126049
126050
126051
126052
126053
126054
126055
126056
126057
126058
126059
126060
126061
126062
126063
126064
126065
126066
126067
126068
126069
126070
126071
126072
126073
126074
126075
126076
126077
126078
126079
126080
126081
126082
126083
126084
126085
126086
126087
126088
126089
126090
126091
126092
126093
126094
126095
126096
126097
126098
126099
126100
126101
126102
126103
126104
126105
126106
126107
126108
126109
126110
126111
126112
126113
126114
126115
126116
126117
126118
126119
126120
126121
126122
126123
126124
126125
126126
126127
126128
126129
126130
126131
126132
126133
126134
126135
126136
126137
126138
126139
126140
126141
126142
126143
126144
126145
126146
126147
126148
126149
126150
126151
126152
126153
126154
126155
126156
126157
126158
126159
126160
126161
126162
126163
126164
126165
126166
126167
126168
126169
126170
126171
126172
126173
126174
126175
126176
126177
126178
126179
126180
126181
126182
126183
126184
126185
126186
126187
126188
126189
126190
126191
126192
126193
126194
126195
126196
126197
126198
126199
126200
126201
126202
126203
126204
126205
126206
126207
126208
126209
126210
126211
126212
126213
126214
126215
126216
126217
126218
126219
126220
126221
126222
126223
126224
126225
126226
126227
126228
126229
126230
126231
126232
126233
126234
126235
126236
126237
126238
126239
126240
126241
126242
126243
126244
126245
126246
126247
126248
126249
126250
126251
126252
126253
126254
126255
126256
126257
126258
126259
126260
126261
126262
126263
126264
126265
126266
126267
126268
126269
126270
126271
126272
126273
126274
126275
126276
126277
126278
126279
126280
126281
126282
126283
126284
126285
126286
126287
126288
126289
126290
126291
126292
126293
126294
126295
126296
126297
126298
126299
126300
126301
126302
126303
126304
126305
126306
126307
126308
126309
126310
126311
126312
126313
126314
126315
126316
126317
126318
126319
126320
126321
126322
126323
126324
126325
126326
126327
126328
126329
126330
126331
126332
126333
126334
126335
126336
126337
126338
126339
126340
126341
126342
126343
126344
126345
126346
126347
126348
126349
126350
126351
126352
126353
126354
126355
126356
126357
126358
126359
126360
126361
126362
126363
126364
126365
126366
126367
126368
126369
126370
126371
126372
126373
126374
126375
126376
126377
126378
126379
126380
126381
126382
126383
126384
126385
126386
126387
126388
126389
126390
126391
126392
126393
126394
126395
126396
126397
126398
126399
126400
126401
126402
126403
126404
126405
126406
126407
126408
126409
126410
126411
126412
126413
126414
126415
126416
126417
126418
126419
126420
126421
126422
126423
126424
126425
126426
126427
126428
126429
126430
126431
126432
126433
126434
126435
126436
126437
126438
126439
126440
126441
126442
126443
126444
126445
126446
126447
126448
126449
126450
126451
126452
126453
126454
126455
126456
126457
126458
126459
126460
126461
126462
126463
126464
126465
126466
126467
126468
126469
126470
126471
126472
126473
126474
126475
126476
126477
126478
126479
126480
126481
126482
126483
126484
126485
126486
126487
126488
126489
126490
126491
126492
126493
126494
126495
126496
126497
126498
126499
126500
126501
126502
126503
126504
126505
126506
126507
126508
126509
126510
126511
126512
126513
126514
126515
126516
126517
126518
126519
126520
126521
126522
126523
126524
126525
126526
126527
126528
126529
126530
126531
126532
126533
126534
126535
126536
126537
126538
126539
126540
126541
126542
126543
126544
126545
126546
126547
126548
126549
126550
126551
126552
126553
126554
126555
126556
126557
126558
126559
126560
126561
126562
126563
126564
126565
126566
126567
126568
126569
126570
126571
126572
126573
126574
126575
126576
126577
126578
126579
126580
126581
126582
126583
126584
126585
126586
126587
126588
126589
126590
126591
126592
126593
126594
126595
126596
126597
126598
126599
126600
126601
126602
126603
126604
126605
126606
126607
126608
126609
126610
126611
126612
126613
126614
126615
126616
126617
126618
126619
126620
126621
126622
126623
126624
126625
126626
126627
126628
126629
126630
126631
126632
126633
126634
126635
126636
126637
126638
126639
126640
126641
126642
126643
126644
126645
126646
126647
126648
126649
126650
126651
126652
126653
126654
126655
126656
126657
126658
126659
126660
126661
126662
126663
126664
126665
126666
126667
126668
126669
126670
126671
126672
126673
126674
126675
126676
126677
126678
126679
126680
126681
126682
126683
126684
126685
126686
126687
126688
126689
126690
126691
126692
126693
126694
126695
126696
126697
126698
126699
126700
126701
126702
126703
126704
126705
126706
126707
126708
126709
126710
126711
126712
126713
126714
126715
126716
126717
126718
126719
126720
126721
126722
126723
126724
126725
126726
126727
126728
126729
126730
126731
126732
126733
126734
126735
126736
126737
126738
126739
126740
126741
126742
126743
126744
126745
126746
126747
126748
126749
126750
126751
126752
126753
126754
126755
126756
126757
126758
126759
126760
126761
126762
126763
126764
126765
126766
126767
126768
126769
126770
126771
126772
126773
126774
126775
126776
126777
126778
126779
126780
126781
126782
126783
126784
126785
126786
126787
126788
126789
126790
126791
126792
126793
126794
126795
126796
126797
126798
126799
126800
126801
126802
126803
126804
126805
126806
126807
126808
126809
126810
126811
126812
126813
126814
126815
126816
126817
126818
126819
126820
126821
126822
126823
126824
126825
126826
126827
126828
126829
126830
126831
126832
126833
126834
126835
126836
126837
126838
126839
126840
126841
126842
126843
126844
126845
126846
126847
126848
126849
126850
126851
126852
126853
126854
126855
126856
126857
126858
126859
126860
126861
126862
126863
126864
126865
126866
126867
126868
126869
126870
126871
126872
126873
126874
126875
126876
126877
126878
126879
126880
126881
126882
126883
126884
126885
126886
126887
126888
126889
126890
126891
126892
126893
126894
126895
126896
126897
126898
126899
126900
126901
126902
126903
126904
126905
126906
126907
126908
126909
126910
126911
126912
126913
126914
126915
126916
126917
126918
126919
126920
126921
126922
126923
126924
126925
126926
126927
126928
126929
126930
126931
126932
126933
126934
126935
126936
126937
126938
126939
126940
126941
126942
126943
126944
126945
126946
126947
126948
126949
126950
126951
126952
126953
126954
126955
126956
126957
126958
126959
126960
126961
126962
126963
126964
126965
126966
126967
126968
126969
126970
126971
126972
126973
126974
126975
126976
126977
126978
126979
126980
126981
126982
126983
126984
126985
126986
126987
126988
126989
126990
126991
126992
126993
126994
126995
126996
126997
126998
126999
127000
127001
127002
127003
127004
127005
127006
127007
127008
127009
127010
127011
127012
127013
127014
127015
127016
127017
127018
127019
127020
127021
127022
127023
127024
127025
127026
127027
127028
127029
127030
127031
127032
127033
127034
127035
127036
127037
127038
127039
127040
127041
127042
127043
127044
127045
127046
127047
127048
127049
127050
127051
127052
127053
127054
127055
127056
127057
127058
127059
127060
127061
127062
127063
127064
127065
127066
127067
127068
127069
127070
127071
127072
127073
127074
127075
127076
127077
127078
127079
127080
127081
127082
127083
127084
127085
127086
127087
127088
127089
127090
127091
127092
127093
127094
127095
127096
127097
127098
127099
127100
127101
127102
127103
127104
127105
127106
127107
127108
127109
127110
127111
127112
127113
127114
127115
127116
127117
127118
127119
127120
127121
127122
127123
127124
127125
127126
127127
127128
127129
127130
127131
127132
127133
127134
127135
127136
127137
127138
127139
127140
127141
127142
127143
127144
127145
127146
127147
127148
127149
127150
127151
127152
127153
127154
127155
127156
127157
127158
127159
127160
127161
127162
127163
127164
127165
127166
127167
127168
127169
127170
127171
127172
127173
127174
127175
127176
127177
127178
127179
127180
127181
127182
127183
127184
127185
127186
127187
127188
127189
127190
127191
127192
127193
127194
127195
127196
127197
127198
127199
127200
127201
127202
127203
127204
127205
127206
127207
127208
127209
127210
127211
127212
127213
127214
127215
127216
127217
127218
127219
127220
127221
127222
127223
127224
127225
127226
127227
127228
127229
127230
127231
127232
127233
127234
127235
127236
127237
127238
127239
127240
127241
127242
127243
127244
127245
127246
127247
127248
127249
127250
127251
127252
127253
127254
127255
127256
127257
127258
127259
127260
127261
127262
127263
127264
127265
127266
127267
127268
127269
127270
127271
127272
127273
127274
127275
127276
127277
127278
127279
127280
127281
127282
127283
127284
127285
127286
127287
127288
127289
127290
127291
127292
127293
127294
127295
127296
127297
127298
127299
127300
127301
127302
127303
127304
127305
127306
127307
127308
127309
127310
127311
127312
127313
127314
127315
127316
127317
127318
127319
127320
127321
127322
127323
127324
127325
127326
127327
127328
127329
127330
127331
127332
127333
127334
127335
127336
127337
127338
127339
127340
127341
127342
127343
127344
127345
127346
127347
127348
127349
127350
127351
127352
127353
127354
127355
127356
127357
127358
127359
127360
127361
127362
127363
127364
127365
127366
127367
127368
127369
127370
127371
127372
127373
127374
127375
127376
127377
127378
127379
127380
127381
127382
127383
127384
127385
127386
127387
127388
127389
127390
127391
127392
127393
127394
127395
127396
127397
127398
127399
127400
127401
127402
127403
127404
127405
127406
127407
127408
127409
127410
127411
127412
127413
127414
127415
127416
127417
127418
127419
127420
127421
127422
127423
127424
127425
127426
127427
127428
127429
127430
127431
127432
127433
127434
127435
127436
127437
127438
127439
127440
127441
127442
127443
127444
127445
127446
127447
127448
127449
127450
127451
127452
127453
127454
127455
127456
127457
127458
127459
127460
127461
127462
127463
127464
127465
127466
127467
127468
127469
127470
127471
127472
127473
127474
127475
127476
127477
127478
127479
127480
127481
127482
127483
127484
127485
127486
127487
127488
127489
127490
127491
127492
127493
127494
127495
127496
127497
127498
127499
127500
127501
127502
127503
127504
127505
127506
127507
127508
127509
127510
127511
127512
127513
127514
127515
127516
127517
127518
127519
127520
127521
127522
127523
127524
127525
127526
127527
127528
127529
127530
127531
127532
127533
127534
127535
127536
127537
127538
127539
127540
127541
127542
127543
127544
127545
127546
127547
127548
127549
127550
127551
127552
127553
127554
127555
127556
127557
127558
127559
127560
127561
127562
127563
127564
127565
127566
127567
127568
127569
127570
127571
127572
127573
127574
127575
127576
127577
127578
127579
127580
127581
127582
127583
127584
127585
127586
127587
127588
127589
127590
127591
127592
127593
127594
127595
127596
127597
127598
127599
127600
127601
127602
127603
127604
127605
127606
127607
127608
127609
127610
127611
127612
127613
127614
127615
127616
127617
127618
127619
127620
127621
127622
127623
127624
127625
127626
127627
127628
127629
127630
127631
127632
127633
127634
127635
127636
127637
127638
127639
127640
127641
127642
127643
127644
127645
127646
127647
127648
127649
127650
127651
127652
127653
127654
127655
127656
127657
127658
127659
127660
127661
127662
127663
127664
127665
127666
127667
127668
127669
127670
127671
127672
127673
127674
127675
127676
127677
127678
127679
127680
127681
127682
127683
127684
127685
127686
127687
127688
127689
127690
127691
127692
127693
127694
127695
127696
127697
127698
127699
127700
127701
127702
127703
127704
127705
127706
127707
127708
127709
127710
127711
127712
127713
127714
127715
127716
127717
127718
127719
127720
127721
127722
127723
127724
127725
127726
127727
127728
127729
127730
127731
127732
127733
127734
127735
127736
127737
127738
127739
127740
127741
127742
127743
127744
127745
127746
127747
127748
127749
127750
127751
127752
127753
127754
127755
127756
127757
127758
127759
127760
127761
127762
127763
127764
127765
127766
127767
127768
127769
127770
127771
127772
127773
127774
127775
127776
127777
127778
127779
127780
127781
127782
127783
127784
127785
127786
127787
127788
127789
127790
127791
127792
127793
127794
127795
127796
127797
127798
127799
127800
127801
127802
127803
127804
127805
127806
127807
127808
127809
127810
127811
127812
127813
127814
127815
127816
127817
127818
127819
127820
127821
127822
127823
127824
127825
127826
127827
127828
127829
127830
127831
127832
127833
127834
127835
127836
127837
127838
127839
127840
127841
127842
127843
127844
127845
127846
127847
127848
127849
127850
127851
127852
127853
127854
127855
127856
127857
127858
127859
127860
127861
127862
127863
127864
127865
127866
127867
127868
127869
127870
127871
127872
127873
127874
127875
127876
127877
127878
127879
127880
127881
127882
127883
127884
127885
127886
127887
127888
127889
127890
127891
127892
127893
127894
127895
127896
127897
127898
127899
127900
127901
127902
127903
127904
127905
127906
127907
127908
127909
127910
127911
127912
127913
127914
127915
127916
127917
127918
127919
127920
127921
127922
127923
127924
127925
127926
127927
127928
127929
127930
127931
127932
127933
127934
127935
127936
127937
127938
127939
127940
127941
127942
127943
127944
127945
127946
127947
127948
127949
127950
127951
127952
127953
127954
127955
127956
127957
127958
127959
127960
127961
127962
127963
127964
127965
127966
127967
127968
127969
127970
127971
127972
127973
127974
127975
127976
127977
127978
127979
127980
127981
127982
127983
127984
127985
127986
127987
127988
127989
127990
127991
127992
127993
127994
127995
127996
127997
127998
127999
128000
128001
128002
128003
128004
128005
128006
128007
128008
128009
128010
128011
128012
128013
128014
128015
128016
128017
128018
128019
128020
128021
128022
128023
128024
128025
128026
128027
128028
128029
128030
128031
128032
128033
128034
128035
128036
128037
128038
128039
128040
128041
128042
128043
128044
128045
128046
128047
128048
128049
128050
128051
128052
128053
128054
128055
128056
128057
128058
128059
128060
128061
128062
128063
128064
128065
128066
128067
128068
128069
128070
128071
128072
128073
128074
128075
128076
128077
128078
128079
128080
128081
128082
128083
128084
128085
128086
128087
128088
128089
128090
128091
128092
128093
128094
128095
128096
128097
128098
128099
128100
128101
128102
128103
128104
128105
128106
128107
128108
128109
128110
128111
128112
128113
128114
128115
128116
128117
128118
128119
128120
128121
128122
128123
128124
128125
128126
128127
128128
128129
128130
128131
128132
128133
128134
128135
128136
128137
128138
128139
128140
128141
128142
128143
128144
128145
128146
128147
128148
128149
128150
128151
128152
128153
128154
128155
128156
128157
128158
128159
128160
128161
128162
128163
128164
128165
128166
128167
128168
128169
128170
128171
128172
128173
128174
128175
128176
128177
128178
128179
128180
128181
128182
128183
128184
128185
128186
128187
128188
128189
128190
128191
128192
128193
128194
128195
128196
128197
128198
128199
128200
128201
128202
128203
128204
128205
128206
128207
128208
128209
128210
128211
128212
128213
128214
128215
128216
128217
128218
128219
128220
128221
128222
128223
128224
128225
128226
128227
128228
128229
128230
128231
128232
128233
128234
128235
128236
128237
128238
128239
128240
128241
128242
128243
128244
128245
128246
128247
128248
128249
128250
128251
128252
128253
128254
128255
128256
128257
128258
128259
128260
128261
128262
128263
128264
128265
128266
128267
128268
128269
128270
128271
128272
128273
128274
128275
128276
128277
128278
128279
128280
128281
128282
128283
128284
128285
128286
128287
128288
128289
128290
128291
128292
128293
128294
128295
128296
128297
128298
128299
128300
128301
128302
128303
128304
128305
128306
128307
128308
128309
128310
128311
128312
128313
128314
128315
128316
128317
128318
128319
128320
128321
128322
128323
128324
128325
128326
128327
128328
128329
128330
128331
128332
128333
128334
128335
128336
128337
128338
128339
128340
128341
128342
128343
128344
128345
128346
128347
128348
128349
128350
128351
128352
128353
128354
128355
128356
128357
128358
128359
128360
128361
128362
128363
128364
128365
128366
128367
128368
128369
128370
128371
128372
128373
128374
128375
128376
128377
128378
128379
128380
128381
128382
128383
128384
128385
128386
128387
128388
128389
128390
128391
128392
128393
128394
128395
128396
128397
128398
128399
128400
128401
128402
128403
128404
128405
128406
128407
128408
128409
128410
128411
128412
128413
128414
128415
128416
128417
128418
128419
128420
128421
128422
128423
128424
128425
128426
128427
128428
128429
128430
128431
128432
128433
128434
128435
128436
128437
128438
128439
128440
128441
128442
128443
128444
128445
128446
128447
128448
128449
128450
128451
128452
128453
128454
128455
128456
128457
128458
128459
128460
128461
128462
128463
128464
128465
128466
128467
128468
128469
128470
128471
128472
128473
128474
128475
128476
128477
128478
128479
128480
128481
128482
128483
128484
128485
128486
128487
128488
128489
128490
128491
128492
128493
128494
128495
128496
128497
128498
128499
128500
128501
128502
128503
128504
128505
128506
128507
128508
128509
128510
128511
128512
128513
128514
128515
128516
128517
128518
128519
128520
128521
128522
128523
128524
128525
128526
128527
128528
128529
128530
128531
128532
128533
128534
128535
128536
128537
128538
128539
128540
128541
128542
128543
128544
128545
128546
128547
128548
128549
128550
128551
128552
128553
128554
128555
128556
128557
128558
128559
128560
128561
128562
128563
128564
128565
128566
128567
128568
128569
128570
128571
128572
128573
128574
128575
128576
128577
128578
128579
128580
128581
128582
128583
128584
128585
128586
128587
128588
128589
128590
128591
128592
128593
128594
128595
128596
128597
128598
128599
128600
128601
128602
128603
128604
128605
128606
128607
128608
128609
128610
128611
128612
128613
128614
128615
128616
128617
128618
128619
128620
128621
128622
128623
128624
128625
128626
128627
128628
128629
128630
128631
128632
128633
128634
128635
128636
128637
128638
128639
128640
128641
128642
128643
128644
128645
128646
128647
128648
128649
128650
128651
128652
128653
128654
128655
128656
128657
128658
128659
128660
128661
128662
128663
128664
128665
128666
128667
128668
128669
128670
128671
128672
128673
128674
128675
128676
128677
128678
128679
128680
128681
128682
128683
128684
128685
128686
128687
128688
128689
128690
128691
128692
128693
128694
128695
128696
128697
128698
128699
128700
128701
128702
128703
128704
128705
128706
128707
128708
128709
128710
128711
128712
128713
128714
128715
128716
128717
128718
128719
128720
128721
128722
128723
128724
128725
128726
128727
128728
128729
128730
128731
128732
128733
128734
128735
128736
128737
128738
128739
128740
128741
128742
128743
128744
128745
128746
128747
128748
128749
128750
128751
128752
128753
128754
128755
128756
128757
128758
128759
128760
128761
128762
128763
128764
128765
128766
128767
128768
128769
128770
128771
128772
128773
128774
128775
128776
128777
128778
128779
128780
128781
128782
128783
128784
128785
128786
128787
128788
128789
128790
128791
128792
128793
128794
128795
128796
128797
128798
128799
128800
128801
128802
128803
128804
128805
128806
128807
128808
128809
128810
128811
128812
128813
128814
128815
128816
128817
128818
128819
128820
128821
128822
128823
128824
128825
128826
128827
128828
128829
128830
128831
128832
128833
128834
128835
128836
128837
128838
128839
128840
128841
128842
128843
128844
128845
128846
128847
128848
128849
128850
128851
128852
128853
128854
128855
128856
128857
128858
128859
128860
128861
128862
128863
128864
128865
128866
128867
128868
128869
128870
128871
128872
128873
128874
128875
128876
128877
128878
128879
128880
128881
128882
128883
128884
128885
128886
128887
128888
128889
128890
128891
128892
128893
128894
128895
128896
128897
128898
128899
128900
128901
128902
128903
128904
128905
128906
128907
128908
128909
128910
128911
128912
128913
128914
128915
128916
128917
128918
128919
128920
128921
128922
128923
128924
128925
128926
128927
128928
128929
128930
128931
128932
128933
128934
128935
128936
128937
128938
128939
128940
128941
128942
128943
128944
128945
128946
128947
128948
128949
128950
128951
128952
128953
128954
128955
128956
128957
128958
128959
128960
128961
128962
128963
128964
128965
128966
128967
128968
128969
128970
128971
128972
128973
128974
128975
128976
128977
128978
128979
128980
128981
128982
128983
128984
128985
128986
128987
128988
128989
128990
128991
128992
128993
128994
128995
128996
128997
128998
128999
129000
129001
129002
129003
129004
129005
129006
129007
129008
129009
129010
129011
129012
129013
129014
129015
129016
129017
129018
129019
129020
129021
129022
129023
129024
129025
129026
129027
129028
129029
129030
129031
129032
129033
129034
129035
129036
129037
129038
129039
129040
129041
129042
129043
129044
129045
129046
129047
129048
129049
129050
129051
129052
129053
129054
129055
129056
129057
129058
129059
129060
129061
129062
129063
129064
129065
129066
129067
129068
129069
129070
129071
129072
129073
129074
129075
129076
129077
129078
129079
129080
129081
129082
129083
129084
129085
129086
129087
129088
129089
129090
129091
129092
129093
129094
129095
129096
129097
129098
129099
129100
129101
129102
129103
129104
129105
129106
129107
129108
129109
129110
129111
129112
129113
129114
129115
129116
129117
129118
129119
129120
129121
129122
129123
129124
129125
129126
129127
129128
129129
129130
129131
129132
129133
129134
129135
129136
129137
129138
129139
129140
129141
129142
129143
129144
129145
129146
129147
129148
129149
129150
129151
129152
129153
129154
129155
129156
129157
129158
129159
129160
129161
129162
129163
129164
129165
129166
129167
129168
129169
129170
129171
129172
129173
129174
129175
129176
129177
129178
129179
129180
129181
129182
129183
129184
129185
129186
129187
129188
129189
129190
129191
129192
129193
129194
129195
129196
129197
129198
129199
129200
129201
129202
129203
129204
129205
129206
129207
129208
129209
129210
129211
129212
129213
129214
129215
129216
129217
129218
129219
129220
129221
129222
129223
129224
129225
129226
129227
129228
129229
129230
129231
129232
129233
129234
129235
129236
129237
129238
129239
129240
129241
129242
129243
129244
129245
129246
129247
129248
129249
129250
129251
129252
129253
129254
129255
129256
129257
129258
129259
129260
129261
129262
129263
129264
129265
129266
129267
129268
129269
129270
129271
129272
129273
129274
129275
129276
129277
129278
129279
129280
129281
129282
129283
129284
129285
129286
129287
129288
129289
129290
129291
129292
129293
129294
129295
129296
129297
129298
129299
129300
129301
129302
129303
129304
129305
129306
129307
129308
129309
129310
129311
129312
129313
129314
129315
129316
129317
129318
129319
129320
129321
129322
129323
129324
129325
129326
129327
129328
129329
129330
129331
129332
129333
129334
129335
129336
129337
129338
129339
129340
129341
129342
129343
129344
129345
129346
129347
129348
129349
129350
129351
129352
129353
129354
129355
129356
129357
129358
129359
129360
129361
129362
129363
129364
129365
129366
129367
129368
129369
129370
129371
129372
129373
129374
129375
129376
129377
129378
129379
129380
129381
129382
129383
129384
129385
129386
129387
129388
129389
129390
129391
129392
129393
129394
129395
129396
129397
129398
129399
129400
129401
129402
129403
129404
129405
129406
129407
129408
129409
129410
129411
129412
129413
129414
129415
129416
129417
129418
129419
129420
129421
129422
129423
129424
129425
129426
129427
129428
129429
129430
129431
129432
129433
129434
129435
129436
129437
129438
129439
129440
129441
129442
129443
129444
129445
129446
129447
129448
129449
129450
129451
129452
129453
129454
129455
129456
129457
129458
129459
129460
129461
129462
129463
129464
129465
129466
129467
129468
129469
129470
129471
129472
129473
129474
129475
129476
129477
129478
129479
129480
129481
129482
129483
129484
129485
129486
129487
129488
129489
129490
129491
129492
129493
129494
129495
129496
129497
129498
129499
129500
129501
129502
129503
129504
129505
129506
129507
129508
129509
129510
129511
129512
129513
129514
129515
129516
129517
129518
129519
129520
129521
129522
129523
129524
129525
129526
129527
129528
129529
129530
129531
129532
129533
129534
129535
129536
129537
129538
129539
129540
129541
129542
129543
129544
129545
129546
129547
129548
129549
129550
129551
129552
129553
129554
129555
129556
129557
129558
129559
129560
129561
129562
129563
129564
129565
129566
129567
129568
129569
129570
129571
129572
129573
129574
129575
129576
129577
129578
129579
129580
129581
129582
129583
129584
129585
129586
129587
129588
129589
129590
129591
129592
129593
129594
129595
129596
129597
129598
129599
129600
129601
129602
129603
129604
129605
129606
129607
129608
129609
129610
129611
129612
129613
129614
129615
129616
129617
129618
129619
129620
129621
129622
129623
129624
129625
129626
129627
129628
129629
129630
129631
129632
129633
129634
129635
129636
129637
129638
129639
129640
129641
129642
129643
129644
129645
129646
129647
129648
129649
129650
129651
129652
129653
129654
129655
129656
129657
129658
129659
129660
129661
129662
129663
129664
129665
129666
129667
129668
129669
129670
129671
129672
129673
129674
129675
129676
129677
129678
129679
129680
129681
129682
129683
129684
129685
129686
129687
129688
129689
129690
129691
129692
129693
129694
129695
129696
129697
129698
129699
129700
129701
129702
129703
129704
129705
129706
129707
129708
129709
129710
129711
129712
129713
129714
129715
129716
129717
129718
129719
129720
129721
129722
129723
129724
129725
129726
129727
129728
129729
129730
129731
129732
129733
129734
129735
129736
129737
129738
129739
129740
129741
129742
129743
129744
129745
129746
129747
129748
129749
129750
129751
129752
129753
129754
129755
129756
129757
129758
129759
129760
129761
129762
129763
129764
129765
129766
129767
129768
129769
129770
129771
129772
129773
129774
129775
129776
129777
129778
129779
129780
129781
129782
129783
129784
129785
129786
129787
129788
129789
129790
129791
129792
129793
129794
129795
129796
129797
129798
129799
129800
129801
129802
129803
129804
129805
129806
129807
129808
129809
129810
129811
129812
129813
129814
129815
129816
129817
129818
129819
129820
129821
129822
129823
129824
129825
129826
129827
129828
129829
129830
129831
129832
129833
129834
129835
129836
129837
129838
129839
129840
129841
129842
129843
129844
129845
129846
129847
129848
129849
129850
129851
129852
129853
129854
129855
129856
129857
129858
129859
129860
129861
129862
129863
129864
129865
129866
129867
129868
129869
129870
129871
129872
129873
129874
129875
129876
129877
129878
129879
129880
129881
129882
129883
129884
129885
129886
129887
129888
129889
129890
129891
129892
129893
129894
129895
129896
129897
129898
129899
129900
129901
129902
129903
129904
129905
129906
129907
129908
129909
129910
129911
129912
129913
129914
129915
129916
129917
129918
129919
129920
129921
129922
129923
129924
129925
129926
129927
129928
129929
129930
129931
129932
129933
129934
129935
129936
129937
129938
129939
129940
129941
129942
129943
129944
129945
129946
129947
129948
129949
129950
129951
129952
129953
129954
129955
129956
129957
129958
129959
129960
129961
129962
129963
129964
129965
129966
129967
129968
129969
129970
129971
129972
129973
129974
129975
129976
129977
129978
129979
129980
129981
129982
129983
129984
129985
129986
129987
129988
129989
129990
129991
129992
129993
129994
129995
129996
129997
129998
129999
130000
130001
130002
130003
130004
130005
130006
130007
130008
130009
130010
130011
130012
130013
130014
130015
130016
130017
130018
130019
130020
130021
130022
130023
130024
130025
130026
130027
130028
130029
130030
130031
130032
130033
130034
130035
130036
130037
130038
130039
130040
130041
130042
130043
130044
130045
130046
130047
130048
130049
130050
130051
130052
130053
130054
130055
130056
130057
130058
130059
130060
130061
130062
130063
130064
130065
130066
130067
130068
130069
130070
130071
130072
130073
130074
130075
130076
130077
130078
130079
130080
130081
130082
130083
130084
130085
130086
130087
130088
130089
130090
130091
130092
130093
130094
130095
130096
130097
130098
130099
130100
130101
130102
130103
130104
130105
130106
130107
130108
130109
130110
130111
130112
130113
130114
130115
130116
130117
130118
130119
130120
130121
130122
130123
130124
130125
130126
130127
130128
130129
130130
130131
130132
130133
130134
130135
130136
130137
130138
130139
130140
130141
130142
130143
130144
130145
130146
130147
130148
130149
130150
130151
130152
130153
130154
130155
130156
130157
130158
130159
130160
130161
130162
130163
130164
130165
130166
130167
130168
130169
130170
130171
130172
130173
130174
130175
130176
130177
130178
130179
130180
130181
130182
130183
130184
130185
130186
130187
130188
130189
130190
130191
130192
130193
130194
130195
130196
130197
130198
130199
130200
130201
130202
130203
130204
130205
130206
130207
130208
130209
130210
130211
130212
130213
130214
130215
130216
130217
130218
130219
130220
130221
130222
130223
130224
130225
130226
130227
130228
130229
130230
130231
130232
130233
130234
130235
130236
130237
130238
130239
130240
130241
130242
130243
130244
130245
130246
130247
130248
130249
130250
130251
130252
130253
130254
130255
130256
130257
130258
130259
130260
130261
130262
130263
130264
130265
130266
130267
130268
130269
130270
130271
130272
130273
130274
130275
130276
130277
130278
130279
130280
130281
130282
130283
130284
130285
130286
130287
130288
130289
130290
130291
130292
130293
130294
130295
130296
130297
130298
130299
130300
130301
130302
130303
130304
130305
130306
130307
130308
130309
130310
130311
130312
130313
130314
130315
130316
130317
130318
130319
130320
130321
130322
130323
130324
130325
130326
130327
130328
130329
130330
130331
130332
130333
130334
130335
130336
130337
130338
130339
130340
130341
130342
130343
130344
130345
130346
130347
130348
130349
130350
130351
130352
130353
130354
130355
130356
130357
130358
130359
130360
130361
130362
130363
130364
130365
130366
130367
130368
130369
130370
130371
130372
130373
130374
130375
130376
130377
130378
130379
130380
130381
130382
130383
130384
130385
130386
130387
130388
130389
130390
130391
130392
130393
130394
130395
130396
130397
130398
130399
130400
130401
130402
130403
130404
130405
130406
130407
130408
130409
130410
130411
130412
130413
130414
130415
130416
130417
130418
130419
130420
130421
130422
130423
130424
130425
130426
130427
130428
130429
130430
130431
130432
130433
130434
130435
130436
130437
130438
130439
130440
130441
130442
130443
130444
130445
130446
130447
130448
130449
130450
130451
130452
130453
130454
130455
130456
130457
130458
130459
130460
130461
130462
130463
130464
130465
130466
130467
130468
130469
130470
130471
130472
130473
130474
130475
130476
130477
130478
130479
130480
130481
130482
130483
130484
130485
130486
130487
130488
130489
130490
130491
130492
130493
130494
130495
130496
130497
130498
130499
130500
130501
130502
130503
130504
130505
130506
130507
130508
130509
130510
130511
130512
130513
130514
130515
130516
130517
130518
130519
130520
130521
130522
130523
130524
130525
130526
130527
130528
130529
130530
130531
130532
130533
130534
130535
130536
130537
130538
130539
130540
130541
130542
130543
130544
130545
130546
130547
130548
130549
130550
130551
130552
130553
130554
130555
130556
130557
130558
130559
130560
130561
130562
130563
130564
130565
130566
130567
130568
130569
130570
130571
130572
130573
130574
130575
130576
130577
130578
130579
130580
130581
130582
130583
130584
130585
130586
130587
130588
130589
130590
130591
130592
130593
130594
130595
130596
130597
130598
130599
130600
130601
130602
130603
130604
130605
130606
130607
130608
130609
130610
130611
130612
130613
130614
130615
130616
130617
130618
130619
130620
130621
130622
130623
130624
130625
130626
130627
130628
130629
130630
130631
130632
130633
130634
130635
130636
130637
130638
130639
130640
130641
130642
130643
130644
130645
130646
130647
130648
130649
130650
130651
130652
130653
130654
130655
130656
130657
130658
130659
130660
130661
130662
130663
130664
130665
130666
130667
130668
130669
130670
130671
130672
130673
130674
130675
130676
130677
130678
130679
130680
130681
130682
130683
130684
130685
130686
130687
130688
130689
130690
130691
130692
130693
130694
130695
130696
130697
130698
130699
130700
130701
130702
130703
130704
130705
130706
130707
130708
130709
130710
130711
130712
130713
130714
130715
130716
130717
130718
130719
130720
130721
130722
130723
130724
130725
130726
130727
130728
130729
130730
130731
130732
130733
130734
130735
130736
130737
130738
130739
130740
130741
130742
130743
130744
130745
130746
130747
130748
130749
130750
130751
130752
130753
130754
130755
130756
130757
130758
130759
130760
130761
130762
130763
130764
130765
130766
130767
130768
130769
130770
130771
130772
130773
130774
130775
130776
130777
130778
130779
130780
130781
130782
130783
130784
130785
130786
130787
130788
130789
130790
130791
130792
130793
130794
130795
130796
130797
130798
130799
130800
130801
130802
130803
130804
130805
130806
130807
130808
130809
130810
130811
130812
130813
130814
130815
130816
130817
130818
130819
130820
130821
130822
130823
130824
130825
130826
130827
130828
130829
130830
130831
130832
130833
130834
130835
130836
130837
130838
130839
130840
130841
130842
130843
130844
130845
130846
130847
130848
130849
130850
130851
130852
130853
130854
130855
130856
130857
130858
130859
130860
130861
130862
130863
130864
130865
130866
130867
130868
130869
130870
130871
130872
130873
130874
130875
130876
130877
130878
130879
130880
130881
130882
130883
130884
130885
130886
130887
130888
130889
130890
130891
130892
130893
130894
130895
130896
130897
130898
130899
130900
130901
130902
130903
130904
130905
130906
130907
130908
130909
130910
130911
130912
130913
130914
130915
130916
130917
130918
130919
130920
130921
130922
130923
130924
130925
130926
130927
130928
130929
130930
130931
130932
130933
130934
130935
130936
130937
130938
130939
130940
130941
130942
130943
130944
130945
130946
130947
130948
130949
130950
130951
130952
130953
130954
130955
130956
130957
130958
130959
130960
130961
130962
130963
130964
130965
130966
130967
130968
130969
130970
130971
130972
130973
130974
130975
130976
130977
130978
130979
130980
130981
130982
130983
130984
130985
130986
130987
130988
130989
130990
130991
130992
130993
130994
130995
130996
130997
130998
130999
131000
131001
131002
131003
131004
131005
131006
131007
131008
131009
131010
131011
131012
131013
131014
131015
131016
131017
131018
131019
131020
131021
131022
131023
131024
131025
131026
131027
131028
131029
131030
131031
131032
131033
131034
131035
131036
131037
131038
131039
131040
131041
131042
131043
131044
131045
131046
131047
131048
131049
131050
131051
131052
131053
131054
131055
131056
131057
131058
131059
131060
131061
131062
131063
131064
131065
131066
131067
131068
131069
131070
131071
131072
131073
131074
131075
131076
131077
131078
131079
131080
131081
131082
131083
131084
131085
131086
131087
131088
131089
131090
131091
131092
131093
131094
131095
131096
131097
131098
131099
131100
131101
131102
131103
131104
131105
131106
131107
131108
131109
131110
131111
131112
131113
131114
131115
131116
131117
131118
131119
131120
131121
131122
131123
131124
131125
131126
131127
131128
131129
131130
131131
131132
131133
131134
131135
131136
131137
131138
131139
131140
131141
131142
131143
131144
131145
131146
131147
131148
131149
131150
131151
131152
131153
131154
131155
131156
131157
131158
131159
131160
131161
131162
131163
131164
131165
131166
131167
131168
131169
131170
131171
131172
131173
131174
131175
131176
131177
131178
131179
131180
131181
131182
131183
131184
131185
131186
131187
131188
131189
131190
131191
131192
131193
131194
131195
131196
131197
131198
131199
131200
131201
131202
131203
131204
131205
131206
131207
131208
131209
131210
131211
131212
131213
131214
131215
131216
131217
131218
131219
131220
131221
131222
131223
131224
131225
131226
131227
131228
131229
131230
131231
131232
131233
131234
131235
131236
131237
131238
131239
131240
131241
131242
131243
131244
131245
131246
131247
131248
131249
131250
131251
131252
131253
131254
131255
131256
131257
131258
131259
131260
131261
131262
131263
131264
131265
131266
131267
131268
131269
131270
131271
131272
131273
131274
131275
131276
131277
131278
131279
131280
131281
131282
131283
131284
131285
131286
131287
131288
131289
131290
131291
131292
131293
131294
131295
131296
131297
131298
131299
131300
131301
131302
131303
131304
131305
131306
131307
131308
131309
131310
131311
131312
131313
131314
131315
131316
131317
131318
131319
131320
131321
131322
131323
131324
131325
131326
131327
131328
131329
131330
131331
131332
131333
131334
131335
131336
131337
131338
131339
131340
131341
131342
131343
131344
131345
131346
131347
131348
131349
131350
131351
131352
131353
131354
131355
131356
131357
131358
131359
131360
131361
131362
131363
131364
131365
131366
131367
131368
131369
131370
131371
131372
131373
131374
131375
131376
131377
131378
131379
131380
131381
131382
131383
131384
131385
131386
131387
131388
131389
131390
131391
131392
131393
131394
131395
131396
131397
131398
131399
131400
131401
131402
131403
131404
131405
131406
131407
131408
131409
131410
131411
131412
131413
131414
131415
131416
131417
131418
131419
131420
131421
131422
131423
131424
131425
131426
131427
131428
131429
131430
131431
131432
131433
131434
131435
131436
131437
131438
131439
131440
131441
131442
131443
131444
131445
131446
131447
131448
131449
131450
131451
131452
131453
131454
131455
131456
131457
131458
131459
131460
131461
131462
131463
131464
131465
131466
131467
131468
131469
131470
131471
131472
131473
131474
131475
131476
131477
131478
131479
131480
131481
131482
131483
131484
131485
131486
131487
131488
131489
131490
131491
131492
131493
131494
131495
131496
131497
131498
131499
131500
131501
131502
131503
131504
131505
131506
131507
131508
131509
131510
131511
131512
131513
131514
131515
131516
131517
131518
131519
131520
131521
131522
131523
131524
131525
131526
131527
131528
131529
131530
131531
131532
131533
131534
131535
131536
131537
131538
131539
131540
131541
131542
131543
131544
131545
131546
131547
131548
131549
131550
131551
131552
131553
131554
131555
131556
131557
131558
131559
131560
131561
131562
131563
131564
131565
131566
131567
131568
131569
131570
131571
131572
131573
131574
131575
131576
131577
131578
131579
131580
131581
131582
131583
131584
131585
131586
131587
131588
131589
131590
131591
131592
131593
131594
131595
131596
131597
131598
131599
131600
131601
131602
131603
131604
131605
131606
131607
131608
131609
131610
131611
131612
131613
131614
131615
131616
131617
131618
131619
131620
131621
131622
131623
131624
131625
131626
131627
131628
131629
131630
131631
131632
131633
131634
131635
131636
131637
131638
131639
131640
131641
131642
131643
131644
131645
131646
131647
131648
131649
131650
131651
131652
131653
131654
131655
131656
131657
131658
131659
131660
131661
131662
131663
131664
131665
131666
131667
131668
131669
131670
131671
131672
131673
131674
131675
131676
131677
131678
131679
131680
131681
131682
131683
131684
131685
131686
131687
131688
131689
131690
131691
131692
131693
131694
131695
131696
131697
131698
131699
131700
131701
131702
131703
131704
131705
131706
131707
131708
131709
131710
131711
131712
131713
131714
131715
131716
131717
131718
131719
131720
131721
131722
131723
131724
131725
131726
131727
131728
131729
131730
131731
131732
131733
131734
131735
131736
131737
131738
131739
131740
131741
131742
131743
131744
131745
131746
131747
131748
131749
131750
131751
131752
131753
131754
131755
131756
131757
131758
131759
131760
131761
131762
131763
131764
131765
131766
131767
131768
131769
131770
131771
131772
131773
131774
131775
131776
131777
131778
131779
131780
131781
131782
131783
131784
131785
131786
131787
131788
131789
131790
131791
131792
131793
131794
131795
131796
131797
131798
131799
131800
131801
131802
131803
131804
131805
131806
131807
131808
131809
131810
131811
131812
131813
131814
131815
131816
131817
131818
131819
131820
131821
131822
131823
131824
131825
131826
131827
131828
131829
131830
131831
131832
131833
131834
131835
131836
131837
131838
131839
131840
131841
131842
131843
131844
131845
131846
131847
131848
131849
131850
131851
131852
131853
131854
131855
131856
131857
131858
131859
131860
131861
131862
131863
131864
131865
131866
131867
131868
131869
131870
131871
131872
131873
131874
131875
131876
131877
131878
131879
131880
131881
131882
131883
131884
131885
131886
131887
131888
131889
131890
131891
131892
131893
131894
131895
131896
131897
131898
131899
131900
131901
131902
131903
131904
131905
131906
131907
131908
131909
131910
131911
131912
131913
131914
131915
131916
131917
131918
131919
131920
131921
131922
131923
131924
131925
131926
131927
131928
131929
131930
131931
131932
131933
131934
131935
131936
131937
131938
131939
131940
131941
131942
131943
131944
131945
131946
131947
131948
131949
131950
131951
131952
131953
131954
131955
131956
131957
131958
131959
131960
131961
131962
131963
131964
131965
131966
131967
131968
131969
131970
131971
131972
131973
131974
131975
131976
131977
131978
131979
131980
131981
131982
131983
131984
131985
131986
131987
131988
131989
131990
131991
131992
131993
131994
131995
131996
131997
131998
131999
132000
132001
132002
132003
132004
132005
132006
132007
132008
132009
132010
132011
132012
132013
132014
132015
132016
132017
132018
132019
132020
132021
132022
132023
132024
132025
132026
132027
132028
132029
132030
132031
132032
132033
132034
132035
132036
132037
132038
132039
132040
132041
132042
132043
132044
132045
132046
132047
132048
132049
132050
132051
132052
132053
132054
132055
132056
132057
132058
132059
132060
132061
132062
132063
132064
132065
132066
132067
132068
132069
132070
132071
132072
132073
132074
132075
132076
132077
132078
132079
132080
132081
132082
132083
132084
132085
132086
132087
132088
132089
132090
132091
132092
132093
132094
132095
132096
132097
132098
132099
132100
132101
132102
132103
132104
132105
132106
132107
132108
132109
132110
132111
132112
132113
132114
132115
132116
132117
132118
132119
132120
132121
132122
132123
132124
132125
132126
132127
132128
132129
132130
132131
132132
132133
132134
132135
132136
132137
132138
132139
132140
132141
132142
132143
132144
132145
132146
132147
132148
132149
132150
132151
132152
132153
132154
132155
132156
132157
132158
132159
132160
132161
132162
132163
132164
132165
132166
132167
132168
132169
132170
132171
132172
132173
132174
132175
132176
132177
132178
132179
132180
132181
132182
132183
132184
132185
132186
132187
132188
132189
132190
132191
132192
132193
132194
132195
132196
132197
132198
132199
132200
132201
132202
132203
132204
132205
132206
132207
132208
132209
132210
132211
132212
132213
132214
132215
132216
132217
132218
132219
132220
132221
132222
132223
132224
132225
132226
132227
132228
132229
132230
132231
132232
132233
132234
132235
132236
132237
132238
132239
132240
132241
132242
132243
132244
132245
132246
132247
132248
132249
132250
132251
132252
132253
132254
132255
132256
132257
132258
132259
132260
132261
132262
132263
132264
132265
132266
132267
132268
132269
132270
132271
132272
132273
132274
132275
132276
132277
132278
132279
132280
132281
132282
132283
132284
132285
132286
132287
132288
132289
132290
132291
132292
132293
132294
132295
132296
132297
132298
132299
132300
132301
132302
132303
132304
132305
132306
132307
132308
132309
132310
132311
132312
132313
132314
132315
132316
132317
132318
132319
132320
132321
132322
132323
132324
132325
132326
132327
132328
132329
132330
132331
132332
132333
132334
132335
132336
132337
132338
132339
132340
132341
132342
132343
132344
132345
132346
132347
132348
132349
132350
132351
132352
132353
132354
132355
132356
132357
132358
132359
132360
132361
132362
132363
132364
132365
132366
132367
132368
132369
132370
132371
132372
132373
132374
132375
132376
132377
132378
132379
132380
132381
132382
132383
132384
132385
132386
132387
132388
132389
132390
132391
132392
132393
132394
132395
132396
132397
132398
132399
132400
132401
132402
132403
132404
132405
132406
132407
132408
132409
132410
132411
132412
132413
132414
132415
132416
132417
132418
132419
132420
132421
132422
132423
132424
132425
132426
132427
132428
132429
132430
132431
132432
132433
132434
132435
132436
132437
132438
132439
132440
132441
132442
132443
132444
132445
132446
132447
132448
132449
132450
132451
132452
132453
132454
132455
132456
132457
132458
132459
132460
132461
132462
132463
132464
132465
132466
132467
132468
132469
132470
132471
132472
132473
132474
132475
132476
132477
132478
132479
132480
132481
132482
132483
132484
132485
132486
132487
132488
132489
132490
132491
132492
132493
132494
132495
132496
132497
132498
132499
132500
132501
132502
132503
132504
132505
132506
132507
132508
132509
132510
132511
132512
132513
132514
132515
132516
132517
132518
132519
132520
132521
132522
132523
132524
132525
132526
132527
132528
132529
132530
132531
132532
132533
132534
132535
132536
132537
132538
132539
132540
132541
132542
132543
132544
132545
132546
132547
132548
132549
132550
132551
132552
132553
132554
132555
132556
132557
132558
132559
132560
132561
132562
132563
132564
132565
132566
132567
132568
132569
132570
132571
132572
132573
132574
132575
132576
132577
132578
132579
132580
132581
132582
132583
132584
132585
132586
132587
132588
132589
132590
132591
132592
132593
132594
132595
132596
132597
132598
132599
132600
132601
132602
132603
132604
132605
132606
132607
132608
132609
132610
132611
132612
132613
132614
132615
132616
132617
132618
132619
132620
132621
132622
132623
132624
132625
132626
132627
132628
132629
132630
132631
132632
132633
132634
132635
132636
132637
132638
132639
132640
132641
132642
132643
132644
132645
132646
132647
132648
132649
132650
132651
132652
132653
132654
132655
132656
132657
132658
132659
132660
132661
132662
132663
132664
132665
132666
132667
132668
132669
132670
132671
132672
132673
132674
132675
132676
132677
132678
132679
132680
132681
132682
132683
132684
132685
132686
132687
132688
132689
132690
132691
132692
132693
132694
132695
132696
132697
132698
132699
132700
132701
132702
132703
132704
132705
132706
132707
132708
132709
132710
132711
132712
132713
132714
132715
132716
132717
132718
132719
132720
132721
132722
132723
132724
132725
132726
132727
132728
132729
132730
132731
132732
132733
132734
132735
132736
132737
132738
132739
132740
132741
132742
132743
132744
132745
132746
132747
132748
132749
132750
132751
132752
132753
132754
132755
132756
132757
132758
132759
132760
132761
132762
132763
132764
132765
132766
132767
132768
132769
132770
132771
132772
132773
132774
132775
132776
132777
132778
132779
132780
132781
132782
132783
132784
132785
132786
132787
132788
132789
132790
132791
132792
132793
132794
132795
132796
132797
132798
132799
132800
132801
132802
132803
132804
132805
132806
132807
132808
132809
132810
132811
132812
132813
132814
132815
132816
132817
132818
132819
132820
132821
132822
132823
132824
132825
132826
132827
132828
132829
132830
132831
132832
132833
132834
132835
132836
132837
132838
132839
132840
132841
132842
132843
132844
132845
132846
132847
132848
132849
132850
132851
132852
132853
132854
132855
132856
132857
132858
132859
132860
132861
132862
132863
132864
132865
132866
132867
132868
132869
132870
132871
132872
132873
132874
132875
132876
132877
132878
132879
132880
132881
132882
132883
132884
132885
132886
132887
132888
132889
132890
132891
132892
132893
132894
132895
132896
132897
132898
132899
132900
132901
132902
132903
132904
132905
132906
132907
132908
132909
132910
132911
132912
132913
132914
132915
132916
132917
132918
132919
132920
132921
132922
132923
132924
132925
132926
132927
132928
132929
132930
132931
132932
132933
132934
132935
132936
132937
132938
132939
132940
132941
132942
132943
132944
132945
132946
132947
132948
132949
132950
132951
132952
132953
132954
132955
132956
132957
132958
132959
132960
132961
132962
132963
132964
132965
132966
132967
132968
132969
132970
132971
132972
132973
132974
132975
132976
132977
132978
132979
132980
132981
132982
132983
132984
132985
132986
132987
132988
132989
132990
132991
132992
132993
132994
132995
132996
132997
132998
132999
133000
133001
133002
133003
133004
133005
133006
133007
133008
133009
133010
133011
133012
133013
133014
133015
133016
133017
133018
133019
133020
133021
133022
133023
133024
133025
133026
133027
133028
133029
133030
133031
133032
133033
133034
133035
133036
133037
133038
133039
133040
133041
133042
133043
133044
133045
133046
133047
133048
133049
133050
133051
133052
133053
133054
133055
133056
133057
133058
133059
133060
133061
133062
133063
133064
133065
133066
133067
133068
133069
133070
133071
133072
133073
133074
133075
133076
133077
133078
133079
133080
133081
133082
133083
133084
133085
133086
133087
133088
133089
133090
133091
133092
133093
133094
133095
133096
133097
133098
133099
133100
133101
133102
133103
133104
133105
133106
133107
133108
133109
133110
133111
133112
133113
133114
133115
133116
133117
133118
133119
133120
133121
133122
133123
133124
133125
133126
133127
133128
133129
133130
133131
133132
133133
133134
133135
133136
133137
133138
133139
133140
133141
133142
133143
133144
133145
133146
133147
133148
133149
133150
133151
133152
133153
133154
133155
133156
133157
133158
133159
133160
133161
133162
133163
133164
133165
133166
133167
133168
133169
133170
133171
133172
133173
133174
133175
133176
133177
133178
133179
133180
133181
133182
133183
133184
133185
133186
133187
133188
133189
133190
133191
133192
133193
133194
133195
133196
133197
133198
133199
133200
133201
133202
133203
133204
133205
133206
133207
133208
133209
133210
133211
133212
133213
133214
133215
133216
133217
133218
133219
133220
133221
133222
133223
133224
133225
133226
133227
133228
133229
133230
133231
133232
133233
133234
133235
133236
133237
133238
133239
133240
133241
133242
133243
133244
133245
133246
133247
133248
133249
133250
133251
133252
133253
133254
133255
133256
133257
133258
133259
133260
133261
133262
133263
133264
133265
133266
133267
133268
133269
133270
133271
133272
133273
133274
133275
133276
133277
133278
133279
133280
133281
133282
133283
133284
133285
133286
133287
133288
133289
133290
133291
133292
133293
133294
133295
133296
133297
133298
133299
133300
133301
133302
133303
133304
133305
133306
133307
133308
133309
133310
133311
133312
133313
133314
133315
133316
133317
133318
133319
133320
133321
133322
133323
133324
133325
133326
133327
133328
133329
133330
133331
133332
133333
133334
133335
133336
133337
133338
133339
133340
133341
133342
133343
133344
133345
133346
133347
133348
133349
133350
133351
133352
133353
133354
133355
133356
133357
133358
133359
133360
133361
133362
133363
133364
133365
133366
133367
133368
133369
133370
133371
133372
133373
133374
133375
133376
133377
133378
133379
133380
133381
133382
133383
133384
133385
133386
133387
133388
133389
133390
133391
133392
133393
133394
133395
133396
133397
133398
133399
133400
133401
133402
133403
133404
133405
133406
133407
133408
133409
133410
133411
133412
133413
133414
133415
133416
133417
133418
133419
133420
133421
133422
133423
133424
133425
133426
133427
133428
133429
133430
133431
133432
133433
133434
133435
133436
133437
133438
133439
133440
133441
133442
133443
133444
133445
133446
133447
133448
133449
133450
133451
133452
133453
133454
133455
133456
133457
133458
133459
133460
133461
133462
133463
133464
133465
133466
133467
133468
133469
133470
133471
133472
133473
133474
133475
133476
133477
133478
133479
133480
133481
133482
133483
133484
133485
133486
133487
133488
133489
133490
133491
133492
133493
133494
133495
133496
133497
133498
133499
133500
133501
133502
133503
133504
133505
133506
133507
133508
133509
133510
133511
133512
133513
133514
133515
133516
133517
133518
133519
133520
133521
133522
133523
133524
133525
133526
133527
133528
133529
133530
133531
133532
133533
133534
133535
133536
133537
133538
133539
133540
133541
133542
133543
133544
133545
133546
133547
133548
133549
133550
133551
133552
133553
133554
133555
133556
133557
133558
133559
133560
133561
133562
133563
133564
133565
133566
133567
133568
133569
133570
133571
133572
133573
133574
133575
133576
133577
133578
133579
133580
133581
133582
133583
133584
133585
133586
133587
133588
133589
133590
133591
133592
133593
133594
133595
133596
133597
133598
133599
133600
133601
133602
133603
133604
133605
133606
133607
133608
133609
133610
133611
133612
133613
133614
133615
133616
133617
133618
133619
133620
133621
133622
133623
133624
133625
133626
133627
133628
133629
133630
133631
133632
133633
133634
133635
133636
133637
133638
133639
133640
133641
133642
133643
133644
133645
133646
133647
133648
133649
133650
133651
133652
133653
133654
133655
133656
133657
133658
133659
133660
133661
133662
133663
133664
133665
133666
133667
133668
133669
133670
133671
133672
133673
133674
133675
133676
133677
133678
133679
133680
133681
133682
133683
133684
133685
133686
133687
133688
133689
133690
133691
133692
133693
133694
133695
133696
133697
133698
133699
133700
133701
133702
133703
133704
133705
133706
133707
133708
133709
133710
133711
133712
133713
133714
133715
133716
133717
133718
133719
133720
133721
133722
133723
133724
133725
133726
133727
133728
133729
133730
133731
133732
133733
133734
133735
133736
133737
133738
133739
133740
133741
133742
133743
133744
133745
133746
133747
133748
133749
133750
133751
133752
133753
133754
133755
133756
133757
133758
133759
133760
133761
133762
133763
133764
133765
133766
133767
133768
133769
133770
133771
133772
133773
133774
133775
133776
133777
133778
133779
133780
133781
133782
133783
133784
133785
133786
133787
133788
133789
133790
133791
133792
133793
133794
133795
133796
133797
133798
133799
133800
133801
133802
133803
133804
133805
133806
133807
133808
133809
133810
133811
133812
133813
133814
133815
133816
133817
133818
133819
133820
133821
133822
133823
133824
133825
133826
133827
133828
133829
133830
133831
133832
133833
133834
133835
133836
133837
133838
133839
133840
133841
133842
133843
133844
133845
133846
133847
133848
133849
133850
133851
133852
133853
133854
133855
133856
133857
133858
133859
133860
133861
133862
133863
133864
133865
133866
133867
133868
133869
133870
133871
133872
133873
133874
133875
133876
133877
133878
133879
133880
133881
133882
133883
133884
133885
133886
133887
133888
133889
133890
133891
133892
133893
133894
133895
133896
133897
133898
133899
133900
133901
133902
133903
133904
133905
133906
133907
133908
133909
133910
133911
133912
133913
133914
133915
133916
133917
133918
133919
133920
133921
133922
133923
133924
133925
133926
133927
133928
133929
133930
133931
133932
133933
133934
133935
133936
133937
133938
133939
133940
133941
133942
133943
133944
133945
133946
133947
133948
133949
133950
133951
133952
133953
133954
133955
133956
133957
133958
133959
133960
133961
133962
133963
133964
133965
133966
133967
133968
133969
133970
133971
133972
133973
133974
133975
133976
133977
133978
133979
133980
133981
133982
133983
133984
133985
133986
133987
133988
133989
133990
133991
133992
133993
133994
133995
133996
133997
133998
133999
134000
134001
134002
134003
134004
134005
134006
134007
134008
134009
134010
134011
134012
134013
134014
134015
134016
134017
134018
134019
134020
134021
134022
134023
134024
134025
134026
134027
134028
134029
134030
134031
134032
134033
134034
134035
134036
134037
134038
134039
134040
134041
134042
134043
134044
134045
134046
134047
134048
134049
134050
134051
134052
134053
134054
134055
134056
134057
134058
134059
134060
134061
134062
134063
134064
134065
134066
134067
134068
134069
134070
134071
134072
134073
134074
134075
134076
134077
134078
134079
134080
134081
134082
134083
134084
134085
134086
134087
134088
134089
134090
134091
134092
134093
134094
134095
134096
134097
134098
134099
134100
134101
134102
134103
134104
134105
134106
134107
134108
134109
134110
134111
134112
134113
134114
134115
134116
134117
134118
134119
134120
134121
134122
134123
134124
134125
134126
134127
134128
134129
134130
134131
134132
134133
134134
134135
134136
134137
134138
134139
134140
134141
134142
134143
134144
134145
134146
134147
134148
134149
134150
134151
134152
134153
134154
134155
134156
134157
134158
134159
134160
134161
134162
134163
134164
134165
134166
134167
134168
134169
134170
134171
134172
134173
134174
134175
134176
134177
134178
134179
134180
134181
134182
134183
134184
134185
134186
134187
134188
134189
134190
134191
134192
134193
134194
134195
134196
134197
134198
134199
134200
134201
134202
134203
134204
134205
134206
134207
134208
134209
134210
134211
134212
134213
134214
134215
134216
134217
134218
134219
134220
134221
134222
134223
134224
134225
134226
134227
134228
134229
134230
134231
134232
134233
134234
134235
134236
134237
134238
134239
134240
134241
134242
134243
134244
134245
134246
134247
134248
134249
134250
134251
134252
134253
134254
134255
134256
134257
134258
134259
134260
134261
134262
134263
134264
134265
134266
134267
134268
134269
134270
134271
134272
134273
134274
134275
134276
134277
134278
134279
134280
134281
134282
134283
134284
134285
134286
134287
134288
134289
134290
134291
134292
134293
134294
134295
134296
134297
134298
134299
134300
134301
134302
134303
134304
134305
134306
134307
134308
134309
134310
134311
134312
134313
134314
134315
134316
134317
134318
134319
134320
134321
134322
134323
134324
134325
134326
134327
134328
134329
134330
134331
134332
134333
134334
134335
134336
134337
134338
134339
134340
134341
134342
134343
134344
134345
134346
134347
134348
134349
134350
134351
134352
134353
134354
134355
134356
134357
134358
134359
134360
134361
134362
134363
134364
134365
134366
134367
134368
134369
134370
134371
134372
134373
134374
134375
134376
134377
134378
134379
134380
134381
134382
134383
134384
134385
134386
134387
134388
134389
134390
134391
134392
134393
134394
134395
134396
134397
134398
134399
134400
134401
134402
134403
134404
134405
134406
134407
134408
134409
134410
134411
134412
134413
134414
134415
134416
134417
134418
134419
134420
134421
134422
134423
134424
134425
134426
134427
134428
134429
134430
134431
134432
134433
134434
134435
134436
134437
134438
134439
134440
134441
134442
134443
134444
134445
134446
134447
134448
134449
134450
134451
134452
134453
134454
134455
134456
134457
134458
134459
134460
134461
134462
134463
134464
134465
134466
134467
134468
134469
134470
134471
134472
134473
134474
134475
134476
134477
134478
134479
134480
134481
134482
134483
134484
134485
134486
134487
134488
134489
134490
134491
134492
134493
134494
134495
134496
134497
134498
134499
134500
134501
134502
134503
134504
134505
134506
134507
134508
134509
134510
134511
134512
134513
134514
134515
134516
134517
134518
134519
134520
134521
134522
134523
134524
134525
134526
134527
134528
134529
134530
134531
134532
134533
134534
134535
134536
134537
134538
134539
134540
134541
134542
134543
134544
134545
134546
134547
134548
134549
134550
134551
134552
134553
134554
134555
134556
134557
134558
134559
134560
134561
134562
134563
134564
134565
134566
134567
134568
134569
134570
134571
134572
134573
134574
134575
134576
134577
134578
134579
134580
134581
134582
134583
134584
134585
134586
134587
134588
134589
134590
134591
134592
134593
134594
134595
134596
134597
134598
134599
134600
134601
134602
134603
134604
134605
134606
134607
134608
134609
134610
134611
134612
134613
134614
134615
134616
134617
134618
134619
134620
134621
134622
134623
134624
134625
134626
134627
134628
134629
134630
134631
134632
134633
134634
134635
134636
134637
134638
134639
134640
134641
134642
134643
134644
134645
134646
134647
134648
134649
134650
134651
134652
134653
134654
134655
134656
134657
134658
134659
134660
134661
134662
134663
134664
134665
134666
134667
134668
134669
134670
134671
134672
134673
134674
134675
134676
134677
134678
134679
134680
134681
134682
134683
134684
134685
134686
134687
134688
134689
134690
134691
134692
134693
134694
134695
134696
134697
134698
134699
134700
134701
134702
134703
134704
134705
134706
134707
134708
134709
134710
134711
134712
134713
134714
134715
134716
134717
134718
134719
134720
134721
134722
134723
134724
134725
134726
134727
134728
134729
134730
134731
134732
134733
134734
134735
134736
134737
134738
134739
134740
134741
134742
134743
134744
134745
134746
134747
134748
134749
134750
134751
134752
134753
134754
134755
134756
134757
134758
134759
134760
134761
134762
134763
134764
134765
134766
134767
134768
134769
134770
134771
134772
134773
134774
134775
134776
134777
134778
134779
134780
134781
134782
134783
134784
134785
134786
134787
134788
134789
134790
134791
134792
134793
134794
134795
134796
134797
134798
134799
134800
134801
134802
134803
134804
134805
134806
134807
134808
134809
134810
134811
134812
134813
134814
134815
134816
134817
134818
134819
134820
134821
134822
134823
134824
134825
134826
134827
134828
134829
134830
134831
134832
134833
134834
134835
134836
134837
134838
134839
134840
134841
134842
134843
134844
134845
134846
134847
134848
134849
134850
134851
134852
134853
134854
134855
134856
134857
134858
134859
134860
134861
134862
134863
134864
134865
134866
134867
134868
134869
134870
134871
134872
134873
134874
134875
134876
134877
134878
134879
134880
134881
134882
134883
134884
134885
134886
134887
134888
134889
134890
134891
134892
134893
134894
134895
134896
134897
134898
134899
134900
134901
134902
134903
134904
134905
134906
134907
134908
134909
134910
134911
134912
134913
134914
134915
134916
134917
134918
134919
134920
134921
134922
134923
134924
134925
134926
134927
134928
134929
134930
134931
134932
134933
134934
134935
134936
134937
134938
134939
134940
134941
134942
134943
134944
134945
134946
134947
134948
134949
134950
134951
134952
134953
134954
134955
134956
134957
134958
134959
134960
134961
134962
134963
134964
134965
134966
134967
134968
134969
134970
134971
134972
134973
134974
134975
134976
134977
134978
134979
134980
134981
134982
134983
134984
134985
134986
134987
134988
134989
134990
134991
134992
134993
134994
134995
134996
134997
134998
134999
135000
135001
135002
135003
135004
135005
135006
135007
135008
135009
135010
135011
135012
135013
135014
135015
135016
135017
135018
135019
135020
135021
135022
135023
135024
135025
135026
135027
135028
135029
135030
135031
135032
135033
135034
135035
135036
135037
135038
135039
135040
135041
135042
135043
135044
135045
135046
135047
135048
135049
135050
135051
135052
135053
135054
135055
135056
135057
135058
135059
135060
135061
135062
135063
135064
135065
135066
135067
135068
135069
135070
135071
135072
135073
135074
135075
135076
135077
135078
135079
135080
135081
135082
135083
135084
135085
135086
135087
135088
135089
135090
135091
135092
135093
135094
135095
135096
135097
135098
135099
135100
135101
135102
135103
135104
135105
135106
135107
135108
135109
135110
135111
135112
135113
135114
135115
135116
135117
135118
135119
135120
135121
135122
135123
135124
135125
135126
135127
135128
135129
135130
135131
135132
135133
135134
135135
135136
135137
135138
135139
135140
135141
135142
135143
135144
135145
135146
135147
135148
135149
135150
135151
135152
135153
135154
135155
135156
135157
135158
135159
135160
135161
135162
135163
135164
135165
135166
135167
135168
135169
135170
135171
135172
135173
135174
135175
135176
135177
135178
135179
135180
135181
135182
135183
135184
135185
135186
135187
135188
135189
135190
135191
135192
135193
135194
135195
135196
135197
135198
135199
135200
135201
135202
135203
135204
135205
135206
135207
135208
135209
135210
135211
135212
135213
135214
135215
135216
135217
135218
135219
135220
135221
135222
135223
135224
135225
135226
135227
135228
135229
135230
135231
135232
135233
135234
135235
135236
135237
135238
135239
135240
135241
135242
135243
135244
135245
135246
135247
135248
135249
135250
135251
135252
135253
135254
135255
135256
135257
135258
135259
135260
135261
135262
135263
135264
135265
135266
135267
135268
135269
135270
135271
135272
135273
135274
135275
135276
135277
135278
135279
135280
135281
135282
135283
135284
135285
135286
135287
135288
135289
135290
135291
135292
135293
135294
135295
135296
135297
135298
135299
135300
135301
135302
135303
135304
135305
135306
135307
135308
135309
135310
135311
135312
135313
135314
135315
135316
135317
135318
135319
135320
135321
135322
135323
135324
135325
135326
135327
135328
135329
135330
135331
135332
135333
135334
135335
135336
135337
135338
135339
135340
135341
135342
135343
135344
135345
135346
135347
135348
135349
135350
135351
135352
135353
135354
135355
135356
135357
135358
135359
135360
135361
135362
135363
135364
135365
135366
135367
135368
135369
135370
135371
135372
135373
135374
135375
135376
135377
135378
135379
135380
135381
135382
135383
135384
135385
135386
135387
135388
135389
135390
135391
135392
135393
135394
135395
135396
135397
135398
135399
135400
135401
135402
135403
135404
135405
135406
135407
135408
135409
135410
135411
135412
135413
135414
135415
135416
135417
135418
135419
135420
135421
135422
135423
135424
135425
135426
135427
135428
135429
135430
135431
135432
135433
135434
135435
135436
135437
135438
135439
135440
135441
135442
135443
135444
135445
135446
135447
135448
135449
135450
135451
135452
135453
135454
135455
135456
135457
135458
135459
135460
135461
135462
135463
135464
135465
135466
135467
135468
135469
135470
135471
135472
135473
135474
135475
135476
135477
135478
135479
135480
135481
135482
135483
135484
135485
135486
135487
135488
135489
135490
135491
135492
135493
135494
135495
135496
135497
135498
135499
135500
135501
135502
135503
135504
135505
135506
135507
135508
135509
135510
135511
135512
135513
135514
135515
135516
135517
135518
135519
135520
135521
135522
135523
135524
135525
135526
135527
135528
135529
135530
135531
135532
135533
135534
135535
135536
135537
135538
135539
135540
135541
135542
135543
135544
135545
135546
135547
135548
135549
135550
135551
135552
135553
135554
135555
135556
135557
135558
135559
135560
135561
135562
135563
135564
135565
135566
135567
135568
135569
135570
135571
135572
135573
135574
135575
135576
135577
135578
135579
135580
135581
135582
135583
135584
135585
135586
135587
135588
135589
135590
135591
135592
135593
135594
135595
135596
135597
135598
135599
135600
135601
135602
135603
135604
135605
135606
135607
135608
135609
135610
135611
135612
135613
135614
135615
135616
135617
135618
135619
135620
135621
135622
135623
135624
135625
135626
135627
135628
135629
135630
135631
135632
135633
135634
135635
135636
135637
135638
135639
135640
135641
135642
135643
135644
135645
135646
135647
135648
135649
135650
135651
135652
135653
135654
135655
135656
135657
135658
135659
135660
135661
135662
135663
135664
135665
135666
135667
135668
135669
135670
135671
135672
135673
135674
135675
135676
135677
135678
135679
135680
135681
135682
135683
135684
135685
135686
135687
135688
135689
135690
135691
135692
135693
135694
135695
135696
135697
135698
135699
135700
135701
135702
135703
135704
135705
135706
135707
135708
135709
135710
135711
135712
135713
135714
135715
135716
135717
135718
135719
135720
135721
135722
135723
135724
135725
135726
135727
135728
135729
135730
135731
135732
135733
135734
135735
135736
135737
135738
135739
135740
135741
135742
135743
135744
135745
135746
135747
135748
135749
135750
135751
135752
135753
135754
135755
135756
135757
135758
135759
135760
135761
135762
135763
135764
135765
135766
135767
135768
135769
135770
135771
135772
135773
135774
135775
135776
135777
135778
135779
135780
135781
135782
135783
135784
135785
135786
135787
135788
135789
135790
135791
135792
135793
135794
135795
135796
135797
135798
135799
135800
135801
135802
135803
135804
135805
135806
135807
135808
135809
135810
135811
135812
135813
135814
135815
135816
135817
135818
135819
135820
135821
135822
135823
135824
135825
135826
135827
135828
135829
135830
135831
135832
135833
135834
135835
135836
135837
135838
135839
135840
135841
135842
135843
135844
135845
135846
135847
135848
135849
135850
135851
135852
135853
135854
135855
135856
135857
135858
135859
135860
135861
135862
135863
135864
135865
135866
135867
135868
135869
135870
135871
135872
135873
135874
135875
135876
135877
135878
135879
135880
135881
135882
135883
135884
135885
135886
135887
135888
135889
135890
135891
135892
135893
135894
135895
135896
135897
135898
135899
135900
135901
135902
135903
135904
135905
135906
135907
135908
135909
135910
135911
135912
135913
135914
135915
135916
135917
135918
135919
135920
135921
135922
135923
135924
135925
135926
135927
135928
135929
135930
135931
135932
135933
135934
135935
135936
135937
135938
135939
135940
135941
135942
135943
135944
135945
135946
135947
135948
135949
135950
135951
135952
135953
135954
135955
135956
135957
135958
135959
135960
135961
135962
135963
135964
135965
135966
135967
135968
135969
135970
135971
135972
135973
135974
135975
135976
135977
135978
135979
135980
135981
135982
135983
135984
135985
135986
135987
135988
135989
135990
135991
135992
135993
135994
135995
135996
135997
135998
135999
136000
136001
136002
136003
136004
136005
136006
136007
136008
136009
136010
136011
136012
136013
136014
136015
136016
136017
136018
136019
136020
136021
136022
136023
136024
136025
136026
136027
136028
136029
136030
136031
136032
136033
136034
136035
136036
136037
136038
136039
136040
136041
136042
136043
136044
136045
136046
136047
136048
136049
136050
136051
136052
136053
136054
136055
136056
136057
136058
136059
136060
136061
136062
136063
136064
136065
136066
136067
136068
136069
136070
136071
136072
136073
136074
136075
136076
136077
136078
136079
136080
136081
136082
136083
136084
136085
136086
136087
136088
136089
136090
136091
136092
136093
136094
136095
136096
136097
136098
136099
136100
136101
136102
136103
136104
136105
136106
136107
136108
136109
136110
136111
136112
136113
136114
136115
136116
136117
136118
136119
136120
136121
136122
136123
136124
136125
136126
136127
136128
136129
136130
136131
136132
136133
136134
136135
136136
136137
136138
136139
136140
136141
136142
136143
136144
136145
136146
136147
136148
136149
136150
136151
136152
136153
136154
136155
136156
136157
136158
136159
136160
136161
136162
136163
136164
136165
136166
136167
136168
136169
136170
136171
136172
136173
136174
136175
136176
136177
136178
136179
136180
136181
136182
136183
136184
136185
136186
136187
136188
136189
136190
136191
136192
136193
136194
136195
136196
136197
136198
136199
136200
136201
136202
136203
136204
136205
136206
136207
136208
136209
136210
136211
136212
136213
136214
136215
136216
136217
136218
136219
136220
136221
136222
136223
136224
136225
136226
136227
136228
136229
136230
136231
136232
136233
136234
136235
136236
136237
136238
136239
136240
136241
136242
136243
136244
136245
136246
136247
136248
136249
136250
136251
136252
136253
136254
136255
136256
136257
136258
136259
136260
136261
136262
136263
136264
136265
136266
136267
136268
136269
136270
136271
136272
136273
136274
136275
136276
136277
136278
136279
136280
136281
136282
136283
136284
136285
136286
136287
136288
136289
136290
136291
136292
136293
136294
136295
136296
136297
136298
136299
136300
136301
136302
136303
136304
136305
136306
136307
136308
136309
136310
136311
136312
136313
136314
136315
136316
136317
136318
136319
136320
136321
136322
136323
136324
136325
136326
136327
136328
136329
136330
136331
136332
136333
136334
136335
136336
136337
136338
136339
136340
136341
136342
136343
136344
136345
136346
136347
136348
136349
136350
136351
136352
136353
136354
136355
136356
136357
136358
136359
136360
136361
136362
136363
136364
136365
136366
136367
136368
136369
136370
136371
136372
136373
136374
136375
136376
136377
136378
136379
136380
136381
136382
136383
136384
136385
136386
136387
136388
136389
136390
136391
136392
136393
136394
136395
136396
136397
136398
136399
136400
136401
136402
136403
136404
136405
136406
136407
136408
136409
136410
136411
136412
136413
136414
136415
136416
136417
136418
136419
136420
136421
136422
136423
136424
136425
136426
136427
136428
136429
136430
136431
136432
136433
136434
136435
136436
136437
136438
136439
136440
136441
136442
136443
136444
136445
136446
136447
136448
136449
136450
136451
136452
136453
136454
136455
136456
136457
136458
136459
136460
136461
136462
136463
136464
136465
136466
136467
136468
136469
136470
136471
136472
136473
136474
136475
136476
136477
136478
136479
136480
136481
136482
136483
136484
136485
136486
136487
136488
136489
136490
136491
136492
136493
136494
136495
136496
136497
136498
136499
136500
136501
136502
136503
136504
136505
136506
136507
136508
136509
136510
136511
136512
136513
136514
136515
136516
136517
136518
136519
136520
136521
136522
136523
136524
136525
136526
136527
136528
136529
136530
136531
136532
136533
136534
136535
136536
136537
136538
136539
136540
136541
136542
136543
136544
136545
136546
136547
136548
136549
136550
136551
136552
136553
136554
136555
136556
136557
136558
136559
136560
136561
136562
136563
136564
136565
136566
136567
136568
136569
136570
136571
136572
136573
136574
136575
136576
136577
136578
136579
136580
136581
136582
136583
136584
136585
136586
136587
136588
136589
136590
136591
136592
136593
136594
136595
136596
136597
136598
136599
136600
136601
136602
136603
136604
136605
136606
136607
136608
136609
136610
136611
136612
136613
136614
136615
136616
136617
136618
136619
136620
136621
136622
136623
136624
136625
136626
136627
136628
136629
136630
136631
136632
136633
136634
136635
136636
136637
136638
136639
136640
136641
136642
136643
136644
136645
136646
136647
136648
136649
136650
136651
136652
136653
136654
136655
136656
136657
136658
136659
136660
136661
136662
136663
136664
136665
136666
136667
136668
136669
136670
136671
136672
136673
136674
136675
136676
136677
136678
136679
136680
136681
136682
136683
136684
136685
136686
136687
136688
136689
136690
136691
136692
136693
136694
136695
136696
136697
136698
136699
136700
136701
136702
136703
136704
136705
136706
136707
136708
136709
136710
136711
136712
136713
136714
136715
136716
136717
136718
136719
136720
136721
136722
136723
136724
136725
136726
136727
136728
136729
136730
136731
136732
136733
136734
136735
136736
136737
136738
136739
136740
136741
136742
136743
136744
136745
136746
136747
136748
136749
136750
136751
136752
136753
136754
136755
136756
136757
136758
136759
136760
136761
136762
136763
136764
136765
136766
136767
136768
136769
136770
136771
136772
136773
136774
136775
136776
136777
136778
136779
136780
136781
136782
136783
136784
136785
136786
136787
136788
136789
136790
136791
136792
136793
136794
136795
136796
136797
136798
136799
136800
136801
136802
136803
136804
136805
136806
136807
136808
136809
136810
136811
136812
136813
136814
136815
136816
136817
136818
136819
136820
136821
136822
136823
136824
136825
136826
136827
136828
136829
136830
136831
136832
136833
136834
136835
136836
136837
136838
136839
136840
136841
136842
136843
136844
136845
136846
136847
136848
136849
136850
136851
136852
136853
136854
136855
136856
136857
136858
136859
136860
136861
136862
136863
136864
136865
136866
136867
136868
136869
136870
136871
136872
136873
136874
136875
136876
136877
136878
136879
136880
136881
136882
136883
136884
136885
136886
136887
136888
136889
136890
136891
136892
136893
136894
136895
136896
136897
136898
136899
136900
136901
136902
136903
136904
136905
136906
136907
136908
136909
136910
136911
136912
136913
136914
136915
136916
136917
136918
136919
136920
136921
136922
136923
136924
136925
136926
136927
136928
136929
136930
136931
136932
136933
136934
136935
136936
136937
136938
136939
136940
136941
136942
136943
136944
136945
136946
136947
136948
136949
136950
136951
136952
136953
136954
136955
136956
136957
136958
136959
136960
136961
136962
136963
136964
136965
136966
136967
136968
136969
136970
136971
136972
136973
136974
136975
136976
136977
136978
136979
136980
136981
136982
136983
136984
136985
136986
136987
136988
136989
136990
136991
136992
136993
136994
136995
136996
136997
136998
136999
137000
137001
137002
137003
137004
137005
137006
137007
137008
137009
137010
137011
137012
137013
137014
137015
137016
137017
137018
137019
137020
137021
137022
137023
137024
137025
137026
137027
137028
137029
137030
137031
137032
137033
137034
137035
137036
137037
137038
137039
137040
137041
137042
137043
137044
137045
137046
137047
137048
137049
137050
137051
137052
137053
137054
137055
137056
137057
137058
137059
137060
137061
137062
137063
137064
137065
137066
137067
137068
137069
137070
137071
137072
137073
137074
137075
137076
137077
137078
137079
137080
137081
137082
137083
137084
137085
137086
137087
137088
137089
137090
137091
137092
137093
137094
137095
137096
137097
137098
137099
137100
137101
137102
137103
137104
137105
137106
137107
137108
137109
137110
137111
137112
137113
137114
137115
137116
137117
137118
137119
137120
137121
137122
137123
137124
137125
137126
137127
137128
137129
137130
137131
137132
137133
137134
137135
137136
137137
137138
137139
137140
137141
137142
137143
137144
137145
137146
137147
137148
137149
137150
137151
137152
137153
137154
137155
137156
137157
137158
137159
137160
137161
137162
137163
137164
137165
137166
137167
137168
137169
137170
137171
137172
137173
137174
137175
137176
137177
137178
137179
137180
137181
137182
137183
137184
137185
137186
137187
137188
137189
137190
137191
137192
137193
137194
137195
137196
137197
137198
137199
137200
137201
137202
137203
137204
137205
137206
137207
137208
137209
137210
137211
137212
137213
137214
137215
137216
137217
137218
137219
137220
137221
137222
137223
137224
137225
137226
137227
137228
137229
137230
137231
137232
137233
137234
137235
137236
137237
137238
137239
137240
137241
137242
137243
137244
137245
137246
137247
137248
137249
137250
137251
137252
137253
137254
137255
137256
137257
137258
137259
137260
137261
137262
137263
137264
137265
137266
137267
137268
137269
137270
137271
137272
137273
137274
137275
137276
137277
137278
137279
137280
137281
137282
137283
137284
137285
137286
137287
137288
137289
137290
137291
137292
137293
137294
137295
137296
137297
137298
137299
137300
137301
137302
137303
137304
137305
137306
137307
137308
137309
137310
137311
137312
137313
137314
137315
137316
137317
137318
137319
137320
137321
137322
137323
137324
137325
137326
137327
137328
137329
137330
137331
137332
137333
137334
137335
137336
137337
137338
137339
137340
137341
137342
137343
137344
137345
137346
137347
137348
137349
137350
137351
137352
137353
137354
137355
137356
137357
137358
137359
137360
137361
137362
137363
137364
137365
137366
137367
137368
137369
137370
137371
137372
137373
137374
137375
137376
137377
137378
137379
137380
137381
137382
137383
137384
137385
137386
137387
137388
137389
137390
137391
137392
137393
137394
137395
137396
137397
137398
137399
137400
137401
137402
137403
137404
137405
137406
137407
137408
137409
137410
137411
137412
137413
137414
137415
137416
137417
137418
137419
137420
137421
137422
137423
137424
137425
137426
137427
137428
137429
137430
137431
137432
137433
137434
137435
137436
137437
137438
137439
137440
137441
137442
137443
137444
137445
137446
137447
137448
137449
137450
137451
137452
137453
137454
137455
137456
137457
137458
137459
137460
137461
137462
137463
137464
137465
137466
137467
137468
137469
137470
137471
137472
137473
137474
137475
137476
137477
137478
137479
137480
137481
137482
137483
137484
137485
137486
137487
137488
137489
137490
137491
137492
137493
137494
137495
137496
137497
137498
137499
137500
137501
137502
137503
137504
137505
137506
137507
137508
137509
137510
137511
137512
137513
137514
137515
137516
137517
137518
137519
137520
137521
137522
137523
137524
137525
137526
137527
137528
137529
137530
137531
137532
137533
137534
137535
137536
137537
137538
137539
137540
137541
137542
137543
137544
137545
137546
137547
137548
137549
137550
137551
137552
137553
137554
137555
137556
137557
137558
137559
137560
137561
137562
137563
137564
137565
137566
137567
137568
137569
137570
137571
137572
137573
137574
137575
137576
137577
137578
137579
137580
137581
137582
137583
137584
137585
137586
137587
137588
137589
137590
137591
137592
137593
137594
137595
137596
137597
137598
137599
137600
137601
137602
137603
137604
137605
137606
137607
137608
137609
137610
137611
137612
137613
137614
137615
137616
137617
137618
137619
137620
137621
137622
137623
137624
137625
137626
137627
137628
137629
137630
137631
137632
137633
137634
137635
137636
137637
137638
137639
137640
137641
137642
137643
137644
137645
137646
137647
137648
137649
137650
137651
137652
137653
137654
137655
137656
137657
137658
137659
137660
137661
137662
137663
137664
137665
137666
137667
137668
137669
137670
137671
137672
137673
137674
137675
137676
137677
137678
137679
137680
137681
137682
137683
137684
137685
137686
137687
137688
137689
137690
137691
137692
137693
137694
137695
137696
137697
137698
137699
137700
137701
137702
137703
137704
137705
137706
137707
137708
137709
137710
137711
137712
137713
137714
137715
137716
137717
137718
137719
137720
137721
137722
137723
137724
137725
137726
137727
137728
137729
137730
137731
137732
137733
137734
137735
137736
137737
137738
137739
137740
137741
137742
137743
137744
137745
137746
137747
137748
137749
137750
137751
137752
137753
137754
137755
137756
137757
137758
137759
137760
137761
137762
137763
137764
137765
137766
137767
137768
137769
137770
137771
137772
137773
137774
137775
137776
137777
137778
137779
137780
137781
137782
137783
137784
137785
137786
137787
137788
137789
137790
137791
137792
137793
137794
137795
137796
137797
137798
137799
137800
137801
137802
137803
137804
137805
137806
137807
137808
137809
137810
137811
137812
137813
137814
137815
137816
137817
137818
137819
137820
137821
137822
137823
137824
137825
137826
137827
137828
137829
137830
137831
137832
137833
137834
137835
137836
137837
137838
137839
137840
137841
137842
137843
137844
137845
137846
137847
137848
137849
137850
137851
137852
137853
137854
137855
137856
137857
137858
137859
137860
137861
137862
137863
137864
137865
137866
137867
137868
137869
137870
137871
137872
137873
137874
137875
137876
137877
137878
137879
137880
137881
137882
137883
137884
137885
137886
137887
137888
137889
137890
137891
137892
137893
137894
137895
137896
137897
137898
137899
137900
137901
137902
137903
137904
137905
137906
137907
137908
137909
137910
137911
137912
137913
137914
137915
137916
137917
137918
137919
137920
137921
137922
137923
137924
137925
137926
137927
137928
137929
137930
137931
137932
137933
137934
137935
137936
137937
137938
137939
137940
137941
137942
137943
137944
137945
137946
137947
137948
137949
137950
137951
137952
137953
137954
137955
137956
137957
137958
137959
137960
137961
137962
137963
137964
137965
137966
137967
137968
137969
137970
137971
137972
137973
137974
137975
137976
137977
137978
137979
137980
137981
137982
137983
137984
137985
137986
137987
137988
137989
137990
137991
137992
137993
137994
137995
137996
137997
137998
137999
138000
138001
138002
138003
138004
138005
138006
138007
138008
138009
138010
138011
138012
138013
138014
138015
138016
138017
138018
138019
138020
138021
138022
138023
138024
138025
138026
138027
138028
138029
138030
138031
138032
138033
138034
138035
138036
138037
138038
138039
138040
138041
138042
138043
138044
138045
138046
138047
138048
138049
138050
138051
138052
138053
138054
138055
138056
138057
138058
138059
138060
138061
138062
138063
138064
138065
138066
138067
138068
138069
138070
138071
138072
138073
138074
138075
138076
138077
138078
138079
138080
138081
138082
138083
138084
138085
138086
138087
138088
138089
138090
138091
138092
138093
138094
138095
138096
138097
138098
138099
138100
138101
138102
138103
138104
138105
138106
138107
138108
138109
138110
138111
138112
138113
138114
138115
138116
138117
138118
138119
138120
138121
138122
138123
138124
138125
138126
138127
138128
138129
138130
138131
138132
138133
138134
138135
138136
138137
138138
138139
138140
138141
138142
138143
138144
138145
138146
138147
138148
138149
138150
138151
138152
138153
138154
138155
138156
138157
138158
138159
138160
138161
138162
138163
138164
138165
138166
138167
138168
138169
138170
138171
138172
138173
138174
138175
138176
138177
138178
138179
138180
138181
138182
138183
138184
138185
138186
138187
138188
138189
138190
138191
138192
138193
138194
138195
138196
138197
138198
138199
138200
138201
138202
138203
138204
138205
138206
138207
138208
138209
138210
138211
138212
138213
138214
138215
138216
138217
138218
138219
138220
138221
138222
138223
138224
138225
138226
138227
138228
138229
138230
138231
138232
138233
138234
138235
138236
138237
138238
138239
138240
138241
138242
138243
138244
138245
138246
138247
138248
138249
138250
138251
138252
138253
138254
138255
138256
138257
138258
138259
138260
138261
138262
138263
138264
138265
138266
138267
138268
138269
138270
138271
138272
138273
138274
138275
138276
138277
138278
138279
138280
138281
138282
138283
138284
138285
138286
138287
138288
138289
138290
138291
138292
138293
138294
138295
138296
138297
138298
138299
138300
138301
138302
138303
138304
138305
138306
138307
138308
138309
138310
138311
138312
138313
138314
138315
138316
138317
138318
138319
138320
138321
138322
138323
138324
138325
138326
138327
138328
138329
138330
138331
138332
138333
138334
138335
138336
138337
138338
138339
138340
138341
138342
138343
138344
138345
138346
138347
138348
138349
138350
138351
138352
138353
138354
138355
138356
138357
138358
138359
138360
138361
138362
138363
138364
138365
138366
138367
138368
138369
138370
138371
138372
138373
138374
138375
138376
138377
138378
138379
138380
138381
138382
138383
138384
138385
138386
138387
138388
138389
138390
138391
138392
138393
138394
138395
138396
138397
138398
138399
138400
138401
138402
138403
138404
138405
138406
138407
138408
138409
138410
138411
138412
138413
138414
138415
138416
138417
138418
138419
138420
138421
138422
138423
138424
138425
138426
138427
138428
138429
138430
138431
138432
138433
138434
138435
138436
138437
138438
138439
138440
138441
138442
138443
138444
138445
138446
138447
138448
138449
138450
138451
138452
138453
138454
138455
138456
138457
138458
138459
138460
138461
138462
138463
138464
138465
138466
138467
138468
138469
138470
138471
138472
138473
138474
138475
138476
138477
138478
138479
138480
138481
138482
138483
138484
138485
138486
138487
138488
138489
138490
138491
138492
138493
138494
138495
138496
138497
138498
138499
138500
138501
138502
138503
138504
138505
138506
138507
138508
138509
138510
138511
138512
138513
138514
138515
138516
138517
138518
138519
138520
138521
138522
138523
138524
138525
138526
138527
138528
138529
138530
138531
138532
138533
138534
138535
138536
138537
138538
138539
138540
138541
138542
138543
138544
138545
138546
138547
138548
138549
138550
138551
138552
138553
138554
138555
138556
138557
138558
138559
138560
138561
138562
138563
138564
138565
138566
138567
138568
138569
138570
138571
138572
138573
138574
138575
138576
138577
138578
138579
138580
138581
138582
138583
138584
138585
138586
138587
138588
138589
138590
138591
138592
138593
138594
138595
138596
138597
138598
138599
138600
138601
138602
138603
138604
138605
138606
138607
138608
138609
138610
138611
138612
138613
138614
138615
138616
138617
138618
138619
138620
138621
138622
138623
138624
138625
138626
138627
138628
138629
138630
138631
138632
138633
138634
138635
138636
138637
138638
138639
138640
138641
138642
138643
138644
138645
138646
138647
138648
138649
138650
138651
138652
138653
138654
138655
138656
138657
138658
138659
138660
138661
138662
138663
138664
138665
138666
138667
138668
138669
138670
138671
138672
138673
138674
138675
138676
138677
138678
138679
138680
138681
138682
138683
138684
138685
138686
138687
138688
138689
138690
138691
138692
138693
138694
138695
138696
138697
138698
138699
138700
138701
138702
138703
138704
138705
138706
138707
138708
138709
138710
138711
138712
138713
138714
138715
138716
138717
138718
138719
138720
138721
138722
138723
138724
138725
138726
138727
138728
138729
138730
138731
138732
138733
138734
138735
138736
138737
138738
138739
138740
138741
138742
138743
138744
138745
138746
138747
138748
138749
138750
138751
138752
138753
138754
138755
138756
138757
138758
138759
138760
138761
138762
138763
138764
138765
138766
138767
138768
138769
138770
138771
138772
138773
138774
138775
138776
138777
138778
138779
138780
138781
138782
138783
138784
138785
138786
138787
138788
138789
138790
138791
138792
138793
138794
138795
138796
138797
138798
138799
138800
138801
138802
138803
138804
138805
138806
138807
138808
138809
138810
138811
138812
138813
138814
138815
138816
138817
138818
138819
138820
138821
138822
138823
138824
138825
138826
138827
138828
138829
138830
138831
138832
138833
138834
138835
138836
138837
138838
138839
138840
138841
138842
138843
138844
138845
138846
138847
138848
138849
138850
138851
138852
138853
138854
138855
138856
138857
138858
138859
138860
138861
138862
138863
138864
138865
138866
138867
138868
138869
138870
138871
138872
138873
138874
138875
138876
138877
138878
138879
138880
138881
138882
138883
138884
138885
138886
138887
138888
138889
138890
138891
138892
138893
138894
138895
138896
138897
138898
138899
138900
138901
138902
138903
138904
138905
138906
138907
138908
138909
138910
138911
138912
138913
138914
138915
138916
138917
138918
138919
138920
138921
138922
138923
138924
138925
138926
138927
138928
138929
138930
138931
138932
138933
138934
138935
138936
138937
138938
138939
138940
138941
138942
138943
138944
138945
138946
138947
138948
138949
138950
138951
138952
138953
138954
138955
138956
138957
138958
138959
138960
138961
138962
138963
138964
138965
138966
138967
138968
138969
138970
138971
138972
138973
138974
138975
138976
138977
138978
138979
138980
138981
138982
138983
138984
138985
138986
138987
138988
138989
138990
138991
138992
138993
138994
138995
138996
138997
138998
138999
139000
139001
139002
139003
139004
139005
139006
139007
139008
139009
139010
139011
139012
139013
139014
139015
139016
139017
139018
139019
139020
139021
139022
139023
139024
139025
139026
139027
139028
139029
139030
139031
139032
139033
139034
139035
139036
139037
139038
139039
139040
139041
139042
139043
139044
139045
139046
139047
139048
139049
139050
139051
139052
139053
139054
139055
139056
139057
139058
139059
139060
139061
139062
139063
139064
139065
139066
139067
139068
139069
139070
139071
139072
139073
139074
139075
139076
139077
139078
139079
139080
139081
139082
139083
139084
139085
139086
139087
139088
139089
139090
139091
139092
139093
139094
139095
139096
139097
139098
139099
139100
139101
139102
139103
139104
139105
139106
139107
139108
139109
139110
139111
139112
139113
139114
139115
139116
139117
139118
139119
139120
139121
139122
139123
139124
139125
139126
139127
139128
139129
139130
139131
139132
139133
139134
139135
139136
139137
139138
139139
139140
139141
139142
139143
139144
139145
139146
139147
139148
139149
139150
139151
139152
139153
139154
139155
139156
139157
139158
139159
139160
139161
139162
139163
139164
139165
139166
139167
139168
139169
139170
139171
139172
139173
139174
139175
139176
139177
139178
139179
139180
139181
139182
139183
139184
139185
139186
139187
139188
139189
139190
139191
139192
139193
139194
139195
139196
139197
139198
139199
139200
139201
139202
139203
139204
139205
139206
139207
139208
139209
139210
139211
139212
139213
139214
139215
139216
139217
139218
139219
139220
139221
139222
139223
139224
139225
139226
139227
139228
139229
139230
139231
139232
139233
139234
139235
139236
139237
139238
139239
139240
139241
139242
139243
139244
139245
139246
139247
139248
139249
139250
139251
139252
139253
139254
139255
139256
139257
139258
139259
139260
139261
139262
139263
139264
139265
139266
139267
139268
139269
139270
139271
139272
139273
139274
139275
139276
139277
139278
139279
139280
139281
139282
139283
139284
139285
139286
139287
139288
139289
139290
139291
139292
139293
139294
139295
139296
139297
139298
139299
139300
139301
139302
139303
139304
139305
139306
139307
139308
139309
139310
139311
139312
139313
139314
139315
139316
139317
139318
139319
139320
139321
139322
139323
139324
139325
139326
139327
139328
139329
139330
139331
139332
139333
139334
139335
139336
139337
139338
139339
139340
139341
139342
139343
139344
139345
139346
139347
139348
139349
139350
139351
139352
139353
139354
139355
139356
139357
139358
139359
139360
139361
139362
139363
139364
139365
139366
139367
139368
139369
139370
139371
139372
139373
139374
139375
139376
139377
139378
139379
139380
139381
139382
139383
139384
139385
139386
139387
139388
139389
139390
139391
139392
139393
139394
139395
139396
139397
139398
139399
139400
139401
139402
139403
139404
139405
139406
139407
139408
139409
139410
139411
139412
139413
139414
139415
139416
139417
139418
139419
139420
139421
139422
139423
139424
139425
139426
139427
139428
139429
139430
139431
139432
139433
139434
139435
139436
139437
139438
139439
139440
139441
139442
139443
139444
139445
139446
139447
139448
139449
139450
139451
139452
139453
139454
139455
139456
139457
139458
139459
139460
139461
139462
139463
139464
139465
139466
139467
139468
139469
139470
139471
139472
139473
139474
139475
139476
139477
139478
139479
139480
139481
139482
139483
139484
139485
139486
139487
139488
139489
139490
139491
139492
139493
139494
139495
139496
139497
139498
139499
139500
139501
139502
139503
139504
139505
139506
139507
139508
139509
139510
139511
139512
139513
139514
139515
139516
139517
139518
139519
139520
139521
139522
139523
139524
139525
139526
139527
139528
139529
139530
139531
139532
139533
139534
139535
139536
139537
139538
139539
139540
139541
139542
139543
139544
139545
139546
139547
139548
139549
139550
139551
139552
139553
139554
139555
139556
139557
139558
139559
139560
139561
139562
139563
139564
139565
139566
139567
139568
139569
139570
139571
139572
139573
139574
139575
139576
139577
139578
139579
139580
139581
139582
139583
139584
139585
139586
139587
139588
139589
139590
139591
139592
139593
139594
139595
139596
139597
139598
139599
139600
139601
139602
139603
139604
139605
139606
139607
139608
139609
139610
139611
139612
139613
139614
139615
139616
139617
139618
139619
139620
139621
139622
139623
139624
139625
139626
139627
139628
139629
139630
139631
139632
139633
139634
139635
139636
139637
139638
139639
139640
139641
139642
139643
139644
139645
139646
139647
139648
139649
139650
139651
139652
139653
139654
139655
139656
139657
139658
139659
139660
139661
139662
139663
139664
139665
139666
139667
139668
139669
139670
139671
139672
139673
139674
139675
139676
139677
139678
139679
139680
139681
139682
139683
139684
139685
139686
139687
139688
139689
139690
139691
139692
139693
139694
139695
139696
139697
139698
139699
139700
139701
139702
139703
139704
139705
139706
139707
139708
139709
139710
139711
139712
139713
139714
139715
139716
139717
139718
139719
139720
139721
139722
139723
139724
139725
139726
139727
139728
139729
139730
139731
139732
139733
139734
139735
139736
139737
139738
139739
139740
139741
139742
139743
139744
139745
139746
139747
139748
139749
139750
139751
139752
139753
139754
139755
139756
139757
139758
139759
139760
139761
139762
139763
139764
139765
139766
139767
139768
139769
139770
139771
139772
139773
139774
139775
139776
139777
139778
139779
139780
139781
139782
139783
139784
139785
139786
139787
139788
139789
139790
139791
139792
139793
139794
139795
139796
139797
139798
139799
139800
139801
139802
139803
139804
139805
139806
139807
139808
139809
139810
139811
139812
139813
139814
139815
139816
139817
139818
139819
139820
139821
139822
139823
139824
139825
139826
139827
139828
139829
139830
139831
139832
139833
139834
139835
139836
139837
139838
139839
139840
139841
139842
139843
139844
139845
139846
139847
139848
139849
139850
139851
139852
139853
139854
139855
139856
139857
139858
139859
139860
139861
139862
139863
139864
139865
139866
139867
139868
139869
139870
139871
139872
139873
139874
139875
139876
139877
139878
139879
139880
139881
139882
139883
139884
139885
139886
139887
139888
139889
139890
139891
139892
139893
139894
139895
139896
139897
139898
139899
139900
139901
139902
139903
139904
139905
139906
139907
139908
139909
139910
139911
139912
139913
139914
139915
139916
139917
139918
139919
139920
139921
139922
139923
139924
139925
139926
139927
139928
139929
139930
139931
139932
139933
139934
139935
139936
139937
139938
139939
139940
139941
139942
139943
139944
139945
139946
139947
139948
139949
139950
139951
139952
139953
139954
139955
139956
139957
139958
139959
139960
139961
139962
139963
139964
139965
139966
139967
139968
139969
139970
139971
139972
139973
139974
139975
139976
139977
139978
139979
139980
139981
139982
139983
139984
139985
139986
139987
139988
139989
139990
139991
139992
139993
139994
139995
139996
139997
139998
139999
140000
140001
140002
140003
140004
140005
140006
140007
140008
140009
140010
140011
140012
140013
140014
140015
140016
140017
140018
140019
140020
140021
140022
140023
140024
140025
140026
140027
140028
140029
140030
140031
140032
140033
140034
140035
140036
140037
140038
140039
140040
140041
140042
140043
140044
140045
140046
140047
140048
140049
140050
140051
140052
140053
140054
140055
140056
140057
140058
140059
140060
140061
140062
140063
140064
140065
140066
140067
140068
140069
140070
140071
140072
140073
140074
140075
140076
140077
140078
140079
140080
140081
140082
140083
140084
140085
140086
140087
140088
140089
140090
140091
140092
140093
140094
140095
140096
140097
140098
140099
140100
140101
140102
140103
140104
140105
140106
140107
140108
140109
140110
140111
140112
140113
140114
140115
140116
140117
140118
140119
140120
140121
140122
140123
140124
140125
140126
140127
140128
140129
140130
140131
140132
140133
140134
140135
140136
140137
140138
140139
140140
140141
140142
140143
140144
140145
140146
140147
140148
140149
140150
140151
140152
140153
140154
140155
140156
140157
140158
140159
140160
140161
140162
140163
140164
140165
140166
140167
140168
140169
140170
140171
140172
140173
140174
140175
140176
140177
140178
140179
140180
140181
140182
140183
140184
140185
140186
140187
140188
140189
140190
140191
140192
140193
140194
140195
140196
140197
140198
140199
140200
140201
140202
140203
140204
140205
140206
140207
140208
140209
140210
140211
140212
140213
140214
140215
140216
140217
140218
140219
140220
140221
140222
140223
140224
140225
140226
140227
140228
140229
140230
140231
140232
140233
140234
140235
140236
140237
140238
140239
140240
140241
140242
140243
140244
140245
140246
140247
140248
140249
140250
140251
140252
140253
140254
140255
140256
140257
140258
140259
140260
140261
140262
140263
140264
140265
140266
140267
140268
140269
140270
140271
140272
140273
140274
140275
140276
140277
140278
140279
140280
140281
140282
140283
140284
140285
140286
140287
140288
140289
140290
140291
140292
140293
140294
140295
140296
140297
140298
140299
140300
140301
140302
140303
140304
140305
140306
140307
140308
140309
140310
140311
140312
140313
140314
140315
140316
140317
140318
140319
140320
140321
140322
140323
140324
140325
140326
140327
140328
140329
140330
140331
140332
140333
140334
140335
140336
140337
140338
140339
140340
140341
140342
140343
140344
140345
140346
140347
140348
140349
140350
140351
140352
140353
140354
140355
140356
140357
140358
140359
140360
140361
140362
140363
140364
140365
140366
140367
140368
140369
140370
140371
140372
140373
140374
140375
140376
140377
140378
140379
140380
140381
140382
140383
140384
140385
140386
140387
140388
140389
140390
140391
140392
140393
140394
140395
140396
140397
140398
140399
140400
140401
140402
140403
140404
140405
140406
140407
140408
140409
140410
140411
140412
140413
140414
140415
140416
140417
140418
140419
140420
140421
140422
140423
140424
140425
140426
140427
140428
140429
140430
140431
140432
140433
140434
140435
140436
140437
140438
140439
140440
140441
140442
140443
140444
140445
140446
140447
140448
140449
140450
140451
140452
140453
140454
140455
140456
140457
140458
140459
140460
140461
140462
140463
140464
140465
140466
140467
140468
140469
140470
140471
140472
140473
140474
140475
140476
140477
140478
140479
140480
140481
140482
140483
140484
140485
140486
140487
140488
140489
140490
140491
140492
140493
140494
140495
140496
140497
140498
140499
140500
140501
140502
140503
140504
140505
140506
140507
140508
140509
140510
140511
140512
140513
140514
140515
140516
140517
140518
140519
140520
140521
140522
140523
140524
140525
140526
140527
140528
140529
140530
140531
140532
140533
140534
140535
140536
140537
140538
140539
140540
140541
140542
140543
140544
140545
140546
140547
140548
140549
140550
140551
140552
140553
140554
140555
140556
140557
140558
140559
140560
140561
140562
140563
140564
140565
140566
140567
140568
140569
140570
140571
140572
140573
140574
140575
140576
140577
140578
140579
140580
140581
140582
140583
140584
140585
140586
140587
140588
140589
140590
140591
140592
140593
140594
140595
140596
140597
140598
140599
140600
140601
140602
140603
140604
140605
140606
140607
140608
140609
140610
140611
140612
140613
140614
140615
140616
140617
140618
140619
140620
140621
140622
140623
140624
140625
140626
140627
140628
140629
140630
140631
140632
140633
140634
140635
140636
140637
140638
140639
140640
140641
140642
140643
140644
140645
140646
140647
140648
140649
140650
140651
140652
140653
140654
140655
140656
140657
140658
140659
140660
140661
140662
140663
140664
140665
140666
140667
140668
140669
140670
140671
140672
140673
140674
140675
140676
140677
140678
140679
140680
140681
140682
140683
140684
140685
140686
140687
140688
140689
140690
140691
140692
140693
140694
140695
140696
140697
140698
140699
140700
140701
140702
140703
140704
140705
140706
140707
140708
140709
140710
140711
140712
140713
140714
140715
140716
140717
140718
140719
140720
140721
140722
140723
140724
140725
140726
140727
140728
140729
140730
140731
140732
140733
140734
140735
140736
140737
140738
140739
140740
140741
140742
140743
140744
140745
140746
140747
140748
140749
140750
140751
140752
140753
140754
140755
140756
140757
140758
140759
140760
140761
140762
140763
140764
140765
140766
140767
140768
140769
140770
140771
140772
140773
140774
140775
140776
140777
140778
140779
140780
140781
140782
140783
140784
140785
140786
140787
140788
140789
140790
140791
140792
140793
140794
140795
140796
140797
140798
140799
140800
140801
140802
140803
140804
140805
140806
140807
140808
140809
140810
140811
140812
140813
140814
140815
140816
140817
140818
140819
140820
140821
140822
140823
140824
140825
140826
140827
140828
140829
140830
140831
140832
140833
140834
140835
140836
140837
140838
140839
140840
140841
140842
140843
140844
140845
140846
140847
140848
140849
140850
140851
140852
140853
140854
140855
140856
140857
140858
140859
140860
140861
140862
140863
140864
140865
140866
140867
140868
140869
140870
140871
140872
140873
140874
140875
140876
140877
140878
140879
140880
140881
140882
140883
140884
140885
140886
140887
140888
140889
140890
140891
140892
140893
140894
140895
140896
140897
140898
140899
140900
140901
140902
140903
140904
140905
140906
140907
140908
140909
140910
140911
140912
140913
140914
140915
140916
140917
140918
140919
140920
140921
140922
140923
140924
140925
140926
140927
140928
140929
140930
140931
140932
140933
140934
140935
140936
140937
140938
140939
140940
140941
140942
140943
140944
140945
140946
140947
140948
140949
140950
140951
140952
140953
140954
140955
140956
140957
140958
140959
140960
140961
140962
140963
140964
140965
140966
140967
140968
140969
140970
140971
140972
140973
140974
140975
140976
140977
140978
140979
140980
140981
140982
140983
140984
140985
140986
140987
140988
140989
140990
140991
140992
140993
140994
140995
140996
140997
140998
140999
141000
141001
141002
141003
141004
141005
141006
141007
141008
141009
141010
141011
141012
141013
141014
141015
141016
141017
141018
141019
141020
141021
141022
141023
141024
141025
141026
141027
141028
141029
141030
141031
141032
141033
141034
141035
141036
141037
141038
141039
141040
141041
141042
141043
141044
141045
141046
141047
141048
141049
141050
141051
141052
141053
141054
141055
141056
141057
141058
141059
141060
141061
141062
141063
141064
141065
141066
141067
141068
141069
141070
141071
141072
141073
141074
141075
141076
141077
141078
141079
141080
141081
141082
141083
141084
141085
141086
141087
141088
141089
141090
141091
141092
141093
141094
141095
141096
141097
141098
141099
141100
141101
141102
141103
141104
141105
141106
141107
141108
141109
141110
141111
141112
141113
141114
141115
141116
141117
141118
141119
141120
141121
141122
141123
141124
141125
141126
141127
141128
141129
141130
141131
141132
141133
141134
141135
141136
141137
141138
141139
141140
141141
141142
141143
141144
141145
141146
141147
141148
141149
141150
141151
141152
141153
141154
141155
141156
141157
141158
141159
141160
141161
141162
141163
141164
141165
141166
141167
141168
141169
141170
141171
141172
141173
141174
141175
141176
141177
141178
141179
141180
141181
141182
141183
141184
141185
141186
141187
141188
141189
141190
141191
141192
141193
141194
141195
141196
141197
141198
141199
141200
141201
141202
141203
141204
141205
141206
141207
141208
141209
141210
141211
141212
141213
141214
141215
141216
141217
141218
141219
141220
141221
141222
141223
141224
141225
141226
141227
141228
141229
141230
141231
141232
141233
141234
141235
141236
141237
141238
141239
141240
141241
141242
141243
141244
141245
141246
141247
141248
141249
141250
141251
141252
141253
141254
141255
141256
141257
141258
141259
141260
141261
141262
141263
141264
141265
141266
141267
141268
141269
141270
141271
141272
141273
141274
141275
141276
141277
141278
141279
141280
141281
141282
141283
141284
141285
141286
141287
141288
141289
141290
141291
141292
141293
141294
141295
141296
141297
141298
141299
141300
141301
141302
141303
141304
141305
141306
141307
141308
141309
141310
141311
141312
141313
141314
141315
141316
141317
141318
141319
141320
141321
141322
141323
141324
141325
141326
141327
141328
141329
141330
141331
141332
141333
141334
141335
141336
141337
141338
141339
141340
141341
141342
141343
141344
141345
141346
141347
141348
141349
141350
141351
141352
141353
141354
141355
141356
141357
141358
141359
141360
141361
141362
141363
141364
141365
141366
141367
141368
141369
141370
141371
141372
141373
141374
141375
141376
141377
141378
141379
141380
141381
141382
141383
141384
141385
141386
141387
141388
141389
141390
141391
141392
141393
141394
141395
141396
141397
141398
141399
141400
141401
141402
141403
141404
141405
141406
141407
141408
141409
141410
141411
141412
141413
141414
141415
141416
141417
141418
141419
141420
141421
141422
141423
141424
141425
141426
141427
141428
141429
141430
141431
141432
141433
141434
141435
141436
141437
141438
141439
141440
141441
141442
141443
141444
141445
141446
141447
141448
141449
141450
141451
141452
141453
141454
141455
141456
141457
141458
141459
141460
141461
141462
141463
141464
141465
141466
141467
141468
141469
141470
141471
141472
141473
141474
141475
141476
141477
141478
141479
141480
141481
141482
141483
141484
141485
141486
141487
141488
141489
141490
141491
141492
141493
141494
141495
141496
141497
141498
141499
141500
141501
141502
141503
141504
141505
141506
141507
141508
141509
141510
141511
141512
141513
141514
141515
141516
141517
141518
141519
141520
141521
141522
141523
141524
141525
141526
141527
141528
141529
141530
141531
141532
141533
141534
141535
141536
141537
141538
141539
141540
141541
141542
141543
141544
141545
141546
141547
141548
141549
141550
141551
141552
141553
141554
141555
141556
141557
141558
141559
141560
141561
141562
141563
141564
141565
141566
141567
141568
141569
141570
141571
141572
141573
141574
141575
141576
141577
141578
141579
141580
141581
141582
141583
141584
141585
141586
141587
141588
141589
141590
141591
141592
141593
141594
141595
141596
141597
141598
141599
141600
141601
141602
141603
141604
141605
141606
141607
141608
141609
141610
141611
141612
141613
141614
141615
141616
141617
141618
141619
141620
141621
141622
141623
141624
141625
141626
141627
141628
141629
141630
141631
141632
141633
141634
141635
141636
141637
141638
141639
141640
141641
141642
141643
141644
141645
141646
141647
141648
141649
141650
141651
141652
141653
141654
141655
141656
141657
141658
141659
141660
141661
141662
141663
141664
141665
141666
141667
141668
141669
141670
141671
141672
141673
141674
141675
141676
141677
141678
141679
141680
141681
141682
141683
141684
141685
141686
141687
141688
141689
141690
141691
141692
141693
141694
141695
141696
141697
141698
141699
141700
141701
141702
141703
141704
141705
141706
141707
141708
141709
141710
141711
141712
141713
141714
141715
141716
141717
141718
141719
141720
141721
141722
141723
141724
141725
141726
141727
141728
141729
141730
141731
141732
141733
141734
141735
141736
141737
141738
141739
141740
141741
141742
141743
141744
141745
141746
141747
141748
141749
141750
141751
141752
141753
141754
141755
141756
141757
141758
141759
141760
141761
141762
141763
141764
141765
141766
141767
141768
141769
141770
141771
141772
141773
141774
141775
141776
141777
141778
141779
141780
141781
141782
141783
141784
141785
141786
141787
141788
141789
141790
141791
141792
141793
141794
141795
141796
141797
141798
141799
141800
141801
141802
141803
141804
141805
141806
141807
141808
141809
141810
141811
141812
141813
141814
141815
141816
141817
141818
141819
141820
141821
141822
141823
141824
141825
141826
141827
141828
141829
141830
141831
141832
141833
141834
141835
141836
141837
141838
141839
141840
141841
141842
141843
141844
141845
141846
141847
141848
141849
141850
141851
141852
141853
141854
141855
141856
141857
141858
141859
141860
141861
141862
141863
141864
141865
141866
141867
141868
141869
141870
141871
141872
141873
141874
141875
141876
141877
141878
141879
141880
141881
141882
141883
141884
141885
141886
141887
141888
141889
141890
141891
141892
141893
141894
141895
141896
141897
141898
141899
141900
141901
141902
141903
141904
141905
141906
141907
141908
141909
141910
141911
141912
141913
141914
141915
141916
141917
141918
141919
141920
141921
141922
141923
141924
141925
141926
141927
141928
141929
141930
141931
141932
141933
141934
141935
141936
141937
141938
141939
141940
141941
141942
141943
141944
141945
141946
141947
141948
141949
141950
141951
141952
141953
141954
141955
141956
141957
141958
141959
141960
141961
141962
141963
141964
141965
141966
141967
141968
141969
141970
141971
141972
141973
141974
141975
141976
141977
141978
141979
141980
141981
141982
141983
141984
141985
141986
141987
141988
141989
141990
141991
141992
141993
141994
141995
141996
141997
141998
141999
142000
142001
142002
142003
142004
142005
142006
142007
142008
142009
142010
142011
142012
142013
142014
142015
142016
142017
142018
142019
142020
142021
142022
142023
142024
142025
142026
142027
142028
142029
142030
142031
142032
142033
142034
142035
142036
142037
142038
142039
142040
142041
142042
142043
142044
142045
142046
142047
142048
142049
142050
142051
142052
142053
142054
142055
142056
142057
142058
142059
142060
142061
142062
142063
142064
142065
142066
142067
142068
142069
142070
142071
142072
142073
142074
142075
142076
142077
142078
142079
142080
142081
142082
142083
142084
142085
142086
142087
142088
142089
142090
142091
142092
142093
142094
142095
142096
142097
142098
142099
142100
142101
142102
142103
142104
142105
142106
142107
142108
142109
142110
142111
142112
142113
142114
142115
142116
142117
142118
142119
142120
142121
142122
142123
142124
142125
142126
142127
142128
142129
142130
142131
142132
142133
142134
142135
142136
142137
142138
142139
142140
142141
142142
142143
142144
142145
142146
142147
142148
142149
142150
142151
142152
142153
142154
142155
142156
142157
142158
142159
142160
142161
142162
142163
142164
142165
142166
142167
142168
142169
142170
142171
142172
142173
142174
142175
142176
142177
142178
142179
142180
142181
142182
142183
142184
142185
142186
142187
142188
142189
142190
142191
142192
142193
142194
142195
142196
142197
142198
142199
142200
142201
142202
142203
142204
142205
142206
142207
142208
142209
142210
142211
142212
142213
142214
142215
142216
142217
142218
142219
142220
142221
142222
142223
142224
142225
142226
142227
142228
142229
142230
142231
142232
142233
142234
142235
142236
142237
142238
142239
142240
142241
142242
142243
142244
142245
142246
142247
142248
142249
142250
142251
142252
142253
142254
142255
142256
142257
142258
142259
142260
142261
142262
142263
142264
142265
142266
142267
142268
142269
142270
142271
142272
142273
142274
142275
142276
142277
142278
142279
142280
142281
142282
142283
142284
142285
142286
142287
142288
142289
142290
142291
142292
142293
142294
142295
142296
142297
142298
142299
142300
142301
142302
142303
142304
142305
142306
142307
142308
142309
142310
142311
142312
142313
142314
142315
142316
142317
142318
142319
142320
142321
142322
142323
142324
142325
142326
142327
142328
142329
142330
142331
142332
142333
142334
142335
142336
142337
142338
142339
142340
142341
142342
142343
142344
142345
142346
142347
142348
142349
142350
142351
142352
142353
142354
142355
142356
142357
142358
142359
142360
142361
142362
142363
142364
142365
142366
142367
142368
142369
142370
142371
142372
142373
142374
142375
142376
142377
142378
142379
142380
142381
142382
142383
142384
142385
142386
142387
142388
142389
142390
142391
142392
142393
142394
142395
142396
142397
142398
142399
142400
142401
142402
142403
142404
142405
142406
142407
142408
142409
142410
142411
142412
142413
142414
142415
142416
142417
142418
142419
142420
142421
142422
142423
142424
142425
142426
142427
142428
142429
142430
142431
142432
142433
142434
142435
142436
142437
142438
142439
142440
142441
142442
142443
142444
142445
142446
142447
142448
142449
142450
142451
142452
142453
142454
142455
142456
142457
142458
142459
142460
142461
142462
142463
142464
142465
142466
142467
142468
142469
142470
142471
142472
142473
142474
142475
142476
142477
142478
142479
142480
142481
142482
142483
142484
142485
142486
142487
142488
142489
142490
142491
142492
142493
142494
142495
142496
142497
142498
142499
142500
142501
142502
142503
142504
142505
142506
142507
142508
142509
142510
142511
142512
142513
142514
142515
142516
142517
142518
142519
142520
142521
142522
142523
142524
142525
142526
142527
142528
142529
142530
142531
142532
142533
142534
142535
142536
142537
142538
142539
142540
142541
142542
142543
142544
142545
142546
142547
142548
142549
142550
142551
142552
142553
142554
142555
142556
142557
142558
142559
142560
142561
142562
142563
142564
142565
142566
142567
142568
142569
142570
142571
142572
142573
142574
142575
142576
142577
142578
142579
142580
142581
142582
142583
142584
142585
142586
142587
142588
142589
142590
142591
142592
142593
142594
142595
142596
142597
142598
142599
142600
142601
142602
142603
142604
142605
142606
142607
142608
142609
142610
142611
142612
142613
142614
142615
142616
142617
142618
142619
142620
142621
142622
142623
142624
142625
142626
142627
142628
142629
142630
142631
142632
142633
142634
142635
142636
142637
142638
142639
142640
142641
142642
142643
142644
142645
142646
142647
142648
142649
142650
142651
142652
142653
142654
142655
142656
142657
142658
142659
142660
142661
142662
142663
142664
142665
142666
142667
142668
142669
142670
142671
142672
142673
142674
142675
142676
142677
142678
142679
142680
142681
142682
142683
142684
142685
142686
142687
142688
142689
142690
142691
142692
142693
142694
142695
142696
142697
142698
142699
142700
142701
142702
142703
142704
142705
142706
142707
142708
142709
142710
142711
142712
142713
142714
142715
142716
142717
142718
142719
142720
142721
142722
142723
142724
142725
142726
142727
142728
142729
142730
142731
142732
142733
142734
142735
142736
142737
142738
142739
142740
142741
142742
142743
142744
142745
142746
142747
142748
142749
142750
142751
142752
142753
142754
142755
142756
142757
142758
142759
142760
142761
142762
142763
142764
142765
142766
142767
142768
142769
142770
142771
142772
142773
142774
142775
142776
142777
142778
142779
142780
142781
142782
142783
142784
142785
142786
142787
142788
142789
142790
142791
142792
142793
142794
142795
142796
142797
142798
142799
142800
142801
142802
142803
142804
142805
142806
142807
142808
142809
142810
142811
142812
142813
142814
142815
142816
142817
142818
142819
142820
142821
142822
142823
142824
142825
142826
142827
142828
142829
142830
142831
142832
142833
142834
142835
142836
142837
142838
142839
142840
142841
142842
142843
142844
142845
142846
142847
142848
142849
142850
142851
142852
142853
142854
142855
142856
142857
142858
142859
142860
142861
142862
142863
142864
142865
142866
142867
142868
142869
142870
142871
142872
142873
142874
142875
142876
142877
142878
142879
142880
142881
142882
142883
142884
142885
142886
142887
142888
142889
142890
142891
142892
142893
142894
142895
142896
142897
142898
142899
142900
142901
142902
142903
142904
142905
142906
142907
142908
142909
142910
142911
142912
142913
142914
142915
142916
142917
142918
142919
142920
142921
142922
142923
142924
142925
142926
142927
142928
142929
142930
142931
142932
142933
142934
142935
142936
142937
142938
142939
142940
142941
142942
142943
142944
142945
142946
142947
142948
142949
142950
142951
142952
142953
142954
142955
142956
142957
142958
142959
142960
142961
142962
142963
142964
142965
142966
142967
142968
142969
142970
142971
142972
142973
142974
142975
142976
142977
142978
142979
142980
142981
142982
142983
142984
142985
142986
142987
142988
142989
142990
142991
142992
142993
142994
142995
142996
142997
142998
142999
143000
143001
143002
143003
143004
143005
143006
143007
143008
143009
143010
143011
143012
143013
143014
143015
143016
143017
143018
143019
143020
143021
143022
143023
143024
143025
143026
143027
143028
143029
143030
143031
143032
143033
143034
143035
143036
143037
143038
143039
143040
143041
143042
143043
143044
143045
143046
143047
143048
143049
143050
143051
143052
143053
143054
143055
143056
143057
143058
143059
143060
143061
143062
143063
143064
143065
143066
143067
143068
143069
143070
143071
143072
143073
143074
143075
143076
143077
143078
143079
143080
143081
143082
143083
143084
143085
143086
143087
143088
143089
143090
143091
143092
143093
143094
143095
143096
143097
143098
143099
143100
143101
143102
143103
143104
143105
143106
143107
143108
143109
143110
143111
143112
143113
143114
143115
143116
143117
143118
143119
143120
143121
143122
143123
143124
143125
143126
143127
143128
143129
143130
143131
143132
143133
143134
143135
143136
143137
143138
143139
143140
143141
143142
143143
143144
143145
143146
143147
143148
143149
143150
143151
143152
143153
143154
143155
143156
143157
143158
143159
143160
143161
143162
143163
143164
143165
143166
143167
143168
143169
143170
143171
143172
143173
143174
143175
143176
143177
143178
143179
143180
143181
143182
143183
143184
143185
143186
143187
143188
143189
143190
143191
143192
143193
143194
143195
143196
143197
143198
143199
143200
143201
143202
143203
143204
143205
143206
143207
143208
143209
143210
143211
143212
143213
143214
143215
143216
143217
143218
143219
143220
143221
143222
143223
143224
143225
143226
143227
143228
143229
143230
143231
143232
143233
143234
143235
143236
143237
143238
143239
143240
143241
143242
143243
143244
143245
143246
143247
143248
143249
143250
143251
143252
143253
143254
143255
143256
143257
143258
143259
143260
143261
143262
143263
143264
143265
143266
143267
143268
143269
143270
143271
143272
143273
143274
143275
143276
143277
143278
143279
143280
143281
143282
143283
143284
143285
143286
143287
143288
143289
143290
143291
143292
143293
143294
143295
143296
143297
143298
143299
143300
143301
143302
143303
143304
143305
143306
143307
143308
143309
143310
143311
143312
143313
143314
143315
143316
143317
143318
143319
143320
143321
143322
143323
143324
143325
143326
143327
143328
143329
143330
143331
143332
143333
143334
143335
143336
143337
143338
143339
143340
143341
143342
143343
143344
143345
143346
143347
143348
143349
143350
143351
143352
143353
143354
143355
143356
143357
143358
143359
143360
143361
143362
143363
143364
143365
143366
143367
143368
143369
143370
143371
143372
143373
143374
143375
143376
143377
143378
143379
143380
143381
143382
143383
143384
143385
143386
143387
143388
143389
143390
143391
143392
143393
143394
143395
143396
143397
143398
143399
143400
143401
143402
143403
143404
143405
143406
143407
143408
143409
143410
143411
143412
143413
143414
143415
143416
143417
143418
143419
143420
143421
143422
143423
143424
143425
143426
143427
143428
143429
143430
143431
143432
143433
143434
143435
143436
143437
143438
143439
143440
143441
143442
143443
143444
143445
143446
143447
143448
143449
143450
143451
143452
143453
143454
143455
143456
143457
143458
143459
143460
143461
143462
143463
143464
143465
143466
143467
143468
143469
143470
143471
143472
143473
143474
143475
143476
143477
143478
143479
143480
143481
143482
143483
143484
143485
143486
143487
143488
143489
143490
143491
143492
143493
143494
143495
143496
143497
143498
143499
143500
143501
143502
143503
143504
143505
143506
143507
143508
143509
143510
143511
143512
143513
143514
143515
143516
143517
143518
143519
143520
143521
143522
143523
143524
143525
143526
143527
143528
143529
143530
143531
143532
143533
143534
143535
143536
143537
143538
143539
143540
143541
143542
143543
143544
143545
143546
143547
143548
143549
143550
143551
143552
143553
143554
143555
143556
143557
143558
143559
143560
143561
143562
143563
143564
143565
143566
143567
143568
143569
143570
143571
143572
143573
143574
143575
143576
143577
143578
143579
143580
143581
143582
143583
143584
143585
143586
143587
143588
143589
143590
143591
143592
143593
143594
143595
143596
143597
143598
143599
143600
143601
143602
143603
143604
143605
143606
143607
143608
143609
143610
143611
143612
143613
143614
143615
143616
143617
143618
143619
143620
143621
143622
143623
143624
143625
143626
143627
143628
143629
143630
143631
143632
143633
143634
143635
143636
143637
143638
143639
143640
143641
143642
143643
143644
143645
143646
143647
143648
143649
143650
143651
143652
143653
143654
143655
143656
143657
143658
143659
143660
143661
143662
143663
143664
143665
143666
143667
143668
143669
143670
143671
143672
143673
143674
143675
143676
143677
143678
143679
143680
143681
143682
143683
143684
143685
143686
143687
143688
143689
143690
143691
143692
143693
143694
143695
143696
143697
143698
143699
143700
143701
143702
143703
143704
143705
143706
143707
143708
143709
143710
143711
143712
143713
143714
143715
143716
143717
143718
143719
143720
143721
143722
143723
143724
143725
143726
143727
143728
143729
143730
143731
143732
143733
143734
143735
143736
143737
143738
143739
143740
143741
143742
143743
143744
143745
143746
143747
143748
143749
143750
143751
143752
143753
143754
143755
143756
143757
143758
143759
143760
143761
143762
143763
143764
143765
143766
143767
143768
143769
143770
143771
143772
143773
143774
143775
143776
143777
143778
143779
143780
143781
143782
143783
143784
143785
143786
143787
143788
143789
143790
143791
143792
143793
143794
143795
143796
143797
143798
143799
143800
143801
143802
143803
143804
143805
143806
143807
143808
143809
143810
143811
143812
143813
143814
143815
143816
143817
143818
143819
143820
143821
143822
143823
143824
143825
143826
143827
143828
143829
143830
143831
143832
143833
143834
143835
143836
143837
143838
143839
143840
143841
143842
143843
143844
143845
143846
143847
143848
143849
143850
143851
143852
143853
143854
143855
143856
143857
143858
143859
143860
143861
143862
143863
143864
143865
143866
143867
143868
143869
143870
143871
143872
143873
143874
143875
143876
143877
143878
143879
143880
143881
143882
143883
143884
143885
143886
143887
143888
143889
143890
143891
143892
143893
143894
143895
143896
143897
143898
143899
143900
143901
143902
143903
143904
143905
143906
143907
143908
143909
143910
143911
143912
143913
143914
143915
143916
143917
143918
143919
143920
143921
143922
143923
143924
143925
143926
143927
143928
143929
143930
143931
143932
143933
143934
143935
143936
143937
143938
143939
143940
143941
143942
143943
143944
143945
143946
143947
143948
143949
143950
143951
143952
143953
143954
143955
143956
143957
143958
143959
143960
143961
143962
143963
143964
143965
143966
143967
143968
143969
143970
143971
143972
143973
143974
143975
143976
143977
143978
143979
143980
143981
143982
143983
143984
143985
143986
143987
143988
143989
143990
143991
143992
143993
143994
143995
143996
143997
143998
143999
144000
144001
144002
144003
144004
144005
144006
144007
144008
144009
144010
144011
144012
144013
144014
144015
144016
144017
144018
144019
144020
144021
144022
144023
144024
144025
144026
144027
144028
144029
144030
144031
144032
144033
144034
144035
144036
144037
144038
144039
144040
144041
144042
144043
144044
144045
144046
144047
144048
144049
144050
144051
144052
144053
144054
144055
144056
144057
144058
144059
144060
144061
144062
144063
144064
144065
144066
144067
144068
144069
144070
144071
144072
144073
144074
144075
144076
144077
144078
144079
144080
144081
144082
144083
144084
144085
144086
144087
144088
144089
144090
144091
144092
144093
144094
144095
144096
144097
144098
144099
144100
144101
144102
144103
144104
144105
144106
144107
144108
144109
144110
144111
144112
144113
144114
144115
144116
144117
144118
144119
144120
144121
144122
144123
144124
144125
144126
144127
144128
144129
144130
144131
144132
144133
144134
144135
144136
144137
144138
144139
144140
144141
144142
144143
144144
144145
144146
144147
144148
144149
144150
144151
144152
144153
144154
144155
144156
144157
144158
144159
144160
144161
144162
144163
144164
144165
144166
144167
144168
144169
144170
144171
144172
144173
144174
144175
144176
144177
144178
144179
144180
144181
144182
144183
144184
144185
144186
144187
144188
144189
144190
144191
144192
144193
144194
144195
144196
144197
144198
144199
144200
144201
144202
144203
144204
144205
144206
144207
144208
144209
144210
144211
144212
144213
144214
144215
144216
144217
144218
144219
144220
144221
144222
144223
144224
144225
144226
144227
144228
144229
144230
144231
144232
144233
144234
144235
144236
144237
144238
144239
144240
144241
144242
144243
144244
144245
144246
144247
144248
144249
144250
144251
144252
144253
144254
144255
144256
144257
144258
144259
144260
144261
144262
144263
144264
144265
144266
144267
144268
144269
144270
144271
144272
144273
144274
144275
144276
144277
144278
144279
144280
144281
144282
144283
144284
144285
144286
144287
144288
144289
144290
144291
144292
144293
144294
144295
144296
144297
144298
144299
144300
144301
144302
144303
144304
144305
144306
144307
144308
144309
144310
144311
144312
144313
144314
144315
144316
144317
144318
144319
144320
144321
144322
144323
144324
144325
144326
144327
144328
144329
144330
144331
144332
144333
144334
144335
144336
144337
144338
144339
144340
144341
144342
144343
144344
144345
144346
144347
144348
144349
144350
144351
144352
144353
144354
144355
144356
144357
144358
144359
144360
144361
144362
144363
144364
144365
144366
144367
144368
144369
144370
144371
144372
144373
144374
144375
144376
144377
144378
144379
144380
144381
144382
144383
144384
144385
144386
144387
144388
144389
144390
144391
144392
144393
144394
144395
144396
144397
144398
144399
144400
144401
144402
144403
144404
144405
144406
144407
144408
144409
144410
144411
144412
144413
144414
144415
144416
144417
144418
144419
144420
144421
144422
144423
144424
144425
144426
144427
144428
144429
144430
144431
144432
144433
144434
144435
144436
144437
144438
144439
144440
144441
144442
144443
144444
144445
144446
144447
144448
144449
144450
144451
144452
144453
144454
144455
144456
144457
144458
144459
144460
144461
144462
144463
144464
144465
144466
144467
144468
144469
144470
144471
144472
144473
144474
144475
144476
144477
144478
144479
144480
144481
144482
144483
144484
144485
144486
144487
144488
144489
144490
144491
144492
144493
144494
144495
144496
144497
144498
144499
144500
144501
144502
144503
144504
144505
144506
144507
144508
144509
144510
144511
144512
144513
144514
144515
144516
144517
144518
144519
144520
144521
144522
144523
144524
144525
144526
144527
144528
144529
144530
144531
144532
144533
144534
144535
144536
144537
144538
144539
144540
144541
144542
144543
144544
144545
144546
144547
144548
144549
144550
144551
144552
144553
144554
144555
144556
144557
144558
144559
144560
144561
144562
144563
144564
144565
144566
144567
144568
144569
144570
144571
144572
144573
144574
144575
144576
144577
144578
144579
144580
144581
144582
144583
144584
144585
144586
144587
144588
144589
144590
144591
144592
144593
144594
144595
144596
144597
144598
144599
144600
144601
144602
144603
144604
144605
144606
144607
144608
144609
144610
144611
144612
144613
144614
144615
144616
144617
144618
144619
144620
144621
144622
144623
144624
144625
144626
144627
144628
144629
144630
144631
144632
144633
144634
144635
144636
144637
144638
144639
144640
144641
144642
144643
144644
144645
144646
144647
144648
144649
144650
144651
144652
144653
144654
144655
144656
144657
144658
144659
144660
144661
144662
144663
144664
144665
144666
144667
144668
144669
144670
144671
144672
144673
144674
144675
144676
144677
144678
144679
144680
144681
144682
144683
144684
144685
144686
144687
144688
144689
144690
144691
144692
144693
144694
144695
144696
144697
144698
144699
144700
144701
144702
144703
144704
144705
144706
144707
144708
144709
144710
144711
144712
144713
144714
144715
144716
144717
144718
144719
144720
144721
144722
144723
144724
144725
144726
144727
144728
144729
144730
144731
144732
144733
144734
144735
144736
144737
144738
144739
144740
144741
144742
144743
144744
144745
144746
144747
144748
144749
144750
144751
144752
144753
144754
144755
144756
144757
144758
144759
144760
144761
144762
144763
144764
144765
144766
144767
144768
144769
144770
144771
144772
144773
144774
144775
144776
144777
144778
144779
144780
144781
144782
144783
144784
144785
144786
144787
144788
144789
144790
144791
144792
144793
144794
144795
144796
144797
144798
144799
144800
144801
144802
144803
144804
144805
144806
144807
144808
144809
144810
144811
144812
144813
144814
144815
144816
144817
144818
144819
144820
144821
144822
144823
144824
144825
144826
144827
144828
144829
144830
144831
144832
144833
144834
144835
144836
144837
144838
144839
144840
144841
144842
144843
144844
144845
144846
144847
144848
144849
144850
144851
144852
144853
144854
144855
144856
144857
144858
144859
144860
144861
144862
144863
144864
144865
144866
144867
144868
144869
144870
144871
144872
144873
144874
144875
144876
144877
144878
144879
144880
144881
144882
144883
144884
144885
144886
144887
144888
144889
144890
144891
144892
144893
144894
144895
144896
144897
144898
144899
144900
144901
144902
144903
144904
144905
144906
144907
144908
144909
144910
144911
144912
144913
144914
144915
144916
144917
144918
144919
144920
144921
144922
144923
144924
144925
144926
144927
144928
144929
144930
144931
144932
144933
144934
144935
144936
144937
144938
144939
144940
144941
144942
144943
144944
144945
144946
144947
144948
144949
144950
144951
144952
144953
144954
144955
144956
144957
144958
144959
144960
144961
144962
144963
144964
144965
144966
144967
144968
144969
144970
144971
144972
144973
144974
144975
144976
144977
144978
144979
144980
144981
144982
144983
144984
144985
144986
144987
144988
144989
144990
144991
144992
144993
144994
144995
144996
144997
144998
144999
145000
145001
145002
145003
145004
145005
145006
145007
145008
145009
145010
145011
145012
145013
145014
145015
145016
145017
145018
145019
145020
145021
145022
145023
145024
145025
145026
145027
145028
145029
145030
145031
145032
145033
145034
145035
145036
145037
145038
145039
145040
145041
145042
145043
145044
145045
145046
145047
145048
145049
145050
145051
145052
145053
145054
145055
145056
145057
145058
145059
145060
145061
145062
145063
145064
145065
145066
145067
145068
145069
145070
145071
145072
145073
145074
145075
145076
145077
145078
145079
145080
145081
145082
145083
145084
145085
145086
145087
145088
145089
145090
145091
145092
145093
145094
145095
145096
145097
145098
145099
145100
145101
145102
145103
145104
145105
145106
145107
145108
145109
145110
145111
145112
145113
145114
145115
145116
145117
145118
145119
145120
145121
145122
145123
145124
145125
145126
145127
145128
145129
145130
145131
145132
145133
145134
145135
145136
145137
145138
145139
145140
145141
145142
145143
145144
145145
145146
145147
145148
145149
145150
145151
145152
145153
145154
145155
145156
145157
145158
145159
145160
145161
145162
145163
145164
145165
145166
145167
145168
145169
145170
145171
145172
145173
145174
145175
145176
145177
145178
145179
145180
145181
145182
145183
145184
145185
145186
145187
145188
145189
145190
145191
145192
145193
145194
145195
145196
145197
145198
145199
145200
145201
145202
145203
145204
145205
145206
145207
145208
145209
145210
145211
145212
145213
145214
145215
145216
145217
145218
145219
145220
145221
145222
145223
145224
145225
145226
145227
145228
145229
145230
145231
145232
145233
145234
145235
145236
145237
145238
145239
145240
145241
145242
145243
145244
145245
145246
145247
145248
145249
145250
145251
145252
145253
145254
145255
145256
145257
145258
145259
145260
145261
145262
145263
145264
145265
145266
145267
145268
145269
145270
145271
145272
145273
145274
145275
145276
145277
145278
145279
145280
145281
145282
145283
145284
145285
145286
145287
145288
145289
145290
145291
145292
145293
145294
145295
145296
145297
145298
145299
145300
145301
145302
145303
145304
145305
145306
145307
145308
145309
145310
145311
145312
145313
145314
145315
145316
145317
145318
145319
145320
145321
145322
145323
145324
145325
145326
145327
145328
145329
145330
145331
145332
145333
145334
145335
145336
145337
145338
145339
145340
145341
145342
145343
145344
145345
145346
145347
145348
145349
145350
145351
145352
145353
145354
145355
145356
145357
145358
145359
145360
145361
145362
145363
145364
145365
145366
145367
145368
145369
145370
145371
145372
145373
145374
145375
145376
145377
145378
145379
145380
145381
145382
145383
145384
145385
145386
145387
145388
145389
145390
145391
145392
145393
145394
145395
145396
145397
145398
145399
145400
145401
145402
145403
145404
145405
145406
145407
145408
145409
145410
145411
145412
145413
145414
145415
145416
145417
145418
145419
145420
145421
145422
145423
145424
145425
145426
145427
145428
145429
145430
145431
145432
145433
145434
145435
145436
145437
145438
145439
145440
145441
145442
145443
145444
145445
145446
145447
145448
145449
145450
145451
145452
145453
145454
145455
145456
145457
145458
145459
145460
145461
145462
145463
145464
145465
145466
145467
145468
145469
145470
145471
145472
145473
145474
145475
145476
145477
145478
145479
145480
145481
145482
145483
145484
145485
145486
145487
145488
145489
145490
145491
145492
145493
145494
145495
145496
145497
145498
145499
145500
145501
145502
145503
145504
145505
145506
145507
145508
145509
145510
145511
145512
145513
145514
145515
145516
145517
145518
145519
145520
145521
145522
145523
145524
145525
145526
145527
145528
145529
145530
145531
145532
145533
145534
145535
145536
145537
145538
145539
145540
145541
145542
145543
145544
145545
145546
145547
145548
145549
145550
145551
145552
145553
145554
145555
145556
145557
145558
145559
145560
145561
145562
145563
145564
145565
145566
145567
145568
145569
145570
145571
145572
145573
145574
145575
145576
145577
145578
145579
145580
145581
145582
145583
145584
145585
145586
145587
145588
145589
145590
145591
145592
145593
145594
145595
145596
145597
145598
145599
145600
145601
145602
145603
145604
145605
145606
145607
145608
145609
145610
145611
145612
145613
145614
145615
145616
145617
145618
145619
145620
145621
145622
145623
145624
145625
145626
145627
145628
145629
145630
145631
145632
145633
145634
145635
145636
145637
145638
145639
145640
145641
145642
145643
145644
145645
145646
145647
145648
145649
145650
145651
145652
145653
145654
145655
145656
145657
145658
145659
145660
145661
145662
145663
145664
145665
145666
145667
145668
145669
145670
145671
145672
145673
145674
145675
145676
145677
145678
145679
145680
145681
145682
145683
145684
145685
145686
145687
145688
145689
145690
145691
145692
145693
145694
145695
145696
145697
145698
145699
145700
145701
145702
145703
145704
145705
145706
145707
145708
145709
145710
145711
145712
145713
145714
145715
145716
145717
145718
145719
145720
145721
145722
145723
145724
145725
145726
145727
145728
145729
145730
145731
145732
145733
145734
145735
145736
145737
145738
145739
145740
145741
145742
145743
145744
145745
145746
145747
145748
145749
145750
145751
145752
145753
145754
145755
145756
145757
145758
145759
145760
145761
145762
145763
145764
145765
145766
145767
145768
145769
145770
145771
145772
145773
145774
145775
145776
145777
145778
145779
145780
145781
145782
145783
145784
145785
145786
145787
145788
145789
145790
145791
145792
145793
145794
145795
145796
145797
145798
145799
145800
145801
145802
145803
145804
145805
145806
145807
145808
145809
145810
145811
145812
145813
145814
145815
145816
145817
145818
145819
145820
145821
145822
145823
145824
145825
145826
145827
145828
145829
145830
145831
145832
145833
145834
145835
145836
145837
145838
145839
145840
145841
145842
145843
145844
145845
145846
145847
145848
145849
145850
145851
145852
145853
145854
145855
145856
145857
145858
145859
145860
145861
145862
145863
145864
145865
145866
145867
145868
145869
145870
145871
145872
145873
145874
145875
145876
145877
145878
145879
145880
145881
145882
145883
145884
145885
145886
145887
145888
145889
145890
145891
145892
145893
145894
145895
145896
145897
145898
145899
145900
145901
145902
145903
145904
145905
145906
145907
145908
145909
145910
145911
145912
145913
145914
145915
145916
145917
145918
145919
145920
145921
145922
145923
145924
145925
145926
145927
145928
145929
145930
145931
145932
145933
145934
145935
145936
145937
145938
145939
145940
145941
145942
145943
145944
145945
145946
145947
145948
145949
145950
145951
145952
145953
145954
145955
145956
145957
145958
145959
145960
145961
145962
145963
145964
145965
145966
145967
145968
145969
145970
145971
145972
145973
145974
145975
145976
145977
145978
145979
145980
145981
145982
145983
145984
145985
145986
145987
145988
145989
145990
145991
145992
145993
145994
145995
145996
145997
145998
145999
146000
146001
146002
146003
146004
146005
146006
146007
146008
146009
146010
146011
146012
146013
146014
146015
146016
146017
146018
146019
146020
146021
146022
146023
146024
146025
146026
146027
146028
146029
146030
146031
146032
146033
146034
146035
146036
146037
146038
146039
146040
146041
146042
146043
146044
146045
146046
146047
146048
146049
146050
146051
146052
146053
146054
146055
146056
146057
146058
146059
146060
146061
146062
146063
146064
146065
146066
146067
146068
146069
146070
146071
146072
146073
146074
146075
146076
146077
146078
146079
146080
146081
146082
146083
146084
146085
146086
146087
146088
146089
146090
146091
146092
146093
146094
146095
146096
146097
146098
146099
146100
146101
146102
146103
146104
146105
146106
146107
146108
146109
146110
146111
146112
146113
146114
146115
146116
146117
146118
146119
146120
146121
146122
146123
146124
146125
146126
146127
146128
146129
146130
146131
146132
146133
146134
146135
146136
146137
146138
146139
146140
146141
146142
146143
146144
146145
146146
146147
146148
146149
146150
146151
146152
146153
146154
146155
146156
146157
146158
146159
146160
146161
146162
146163
146164
146165
146166
146167
146168
146169
146170
146171
146172
146173
146174
146175
146176
146177
146178
146179
146180
146181
146182
146183
146184
146185
146186
146187
146188
146189
146190
146191
146192
146193
146194
146195
146196
146197
146198
146199
146200
146201
146202
146203
146204
146205
146206
146207
146208
146209
146210
146211
146212
146213
146214
146215
146216
146217
146218
146219
146220
146221
146222
146223
146224
146225
146226
146227
146228
146229
146230
146231
146232
146233
146234
146235
146236
146237
146238
146239
146240
146241
146242
146243
146244
146245
146246
146247
146248
146249
146250
146251
146252
146253
146254
146255
146256
146257
146258
146259
146260
146261
146262
146263
146264
146265
146266
146267
146268
146269
146270
146271
146272
146273
146274
146275
146276
146277
146278
146279
146280
146281
146282
146283
146284
146285
146286
146287
146288
146289
146290
146291
146292
146293
146294
146295
146296
146297
146298
146299
146300
146301
146302
146303
146304
146305
146306
146307
146308
146309
146310
146311
146312
146313
146314
146315
146316
146317
146318
146319
146320
146321
146322
146323
146324
146325
146326
146327
146328
146329
146330
146331
146332
146333
146334
146335
146336
146337
146338
146339
146340
146341
146342
146343
146344
146345
146346
146347
146348
146349
146350
146351
146352
146353
146354
146355
146356
146357
146358
146359
146360
146361
146362
146363
146364
146365
146366
146367
146368
146369
146370
146371
146372
146373
146374
146375
146376
146377
146378
146379
146380
146381
146382
146383
146384
146385
146386
146387
146388
146389
146390
146391
146392
146393
146394
146395
146396
146397
146398
146399
146400
146401
146402
146403
146404
146405
146406
146407
146408
146409
146410
146411
146412
146413
146414
146415
146416
146417
146418
146419
146420
146421
146422
146423
146424
146425
146426
146427
146428
146429
146430
146431
146432
146433
146434
146435
146436
146437
146438
146439
146440
146441
146442
146443
146444
146445
146446
146447
146448
146449
146450
146451
146452
146453
146454
146455
146456
146457
146458
146459
146460
146461
146462
146463
146464
146465
146466
146467
146468
146469
146470
146471
146472
146473
146474
146475
146476
146477
146478
146479
146480
146481
146482
146483
146484
146485
146486
146487
146488
146489
146490
146491
146492
146493
146494
146495
146496
146497
146498
146499
146500
146501
146502
146503
146504
146505
146506
146507
146508
146509
146510
146511
146512
146513
146514
146515
146516
146517
146518
146519
146520
146521
146522
146523
146524
146525
146526
146527
146528
146529
146530
146531
146532
146533
146534
146535
146536
146537
146538
146539
146540
146541
146542
146543
146544
146545
146546
146547
146548
146549
146550
146551
146552
146553
146554
146555
146556
146557
146558
146559
146560
146561
146562
146563
146564
146565
146566
146567
146568
146569
146570
146571
146572
146573
146574
146575
146576
146577
146578
146579
146580
146581
146582
146583
146584
146585
146586
146587
146588
146589
146590
146591
146592
146593
146594
146595
146596
146597
146598
146599
146600
146601
146602
146603
146604
146605
146606
146607
146608
146609
146610
146611
146612
146613
146614
146615
146616
146617
146618
146619
146620
146621
146622
146623
146624
146625
146626
146627
146628
146629
146630
146631
146632
146633
146634
146635
146636
146637
146638
146639
146640
146641
146642
146643
146644
146645
146646
146647
146648
146649
146650
146651
146652
146653
146654
146655
146656
146657
146658
146659
146660
146661
146662
146663
146664
146665
146666
146667
146668
146669
146670
146671
146672
146673
146674
146675
146676
146677
146678
146679
146680
146681
146682
146683
146684
146685
146686
146687
146688
146689
146690
146691
146692
146693
146694
146695
146696
146697
146698
146699
146700
146701
146702
146703
146704
146705
146706
146707
146708
146709
146710
146711
146712
146713
146714
146715
146716
146717
146718
146719
146720
146721
146722
146723
146724
146725
146726
146727
146728
146729
146730
146731
146732
146733
146734
146735
146736
146737
146738
146739
146740
146741
146742
146743
146744
146745
146746
146747
146748
146749
146750
146751
146752
146753
146754
146755
146756
146757
146758
146759
146760
146761
146762
146763
146764
146765
146766
146767
146768
146769
146770
146771
146772
146773
146774
146775
146776
146777
146778
146779
146780
146781
146782
146783
146784
146785
146786
146787
146788
146789
146790
146791
146792
146793
146794
146795
146796
146797
146798
146799
146800
146801
146802
146803
146804
146805
146806
146807
146808
146809
146810
146811
146812
146813
146814
146815
146816
146817
146818
146819
146820
146821
146822
146823
146824
146825
146826
146827
146828
146829
146830
146831
146832
146833
146834
146835
146836
146837
146838
146839
146840
146841
146842
146843
146844
146845
146846
146847
146848
146849
146850
146851
146852
146853
146854
146855
146856
146857
146858
146859
146860
146861
146862
146863
146864
146865
146866
146867
146868
146869
146870
146871
146872
146873
146874
146875
146876
146877
146878
146879
146880
146881
146882
146883
146884
146885
146886
146887
146888
146889
146890
146891
146892
146893
146894
146895
146896
146897
146898
146899
146900
146901
146902
146903
146904
146905
146906
146907
146908
146909
146910
146911
146912
146913
146914
146915
146916
146917
146918
146919
146920
146921
146922
146923
146924
146925
146926
146927
146928
146929
146930
146931
146932
146933
146934
146935
146936
146937
146938
146939
146940
146941
146942
146943
146944
146945
146946
146947
146948
146949
146950
146951
146952
146953
146954
146955
146956
146957
146958
146959
146960
146961
146962
146963
146964
146965
146966
146967
146968
146969
146970
146971
146972
146973
146974
146975
146976
146977
146978
146979
146980
146981
146982
146983
146984
146985
146986
146987
146988
146989
146990
146991
146992
146993
146994
146995
146996
146997
146998
146999
147000
147001
147002
147003
147004
147005
147006
147007
147008
147009
147010
147011
147012
147013
147014
147015
147016
147017
147018
147019
147020
147021
147022
147023
147024
147025
147026
147027
147028
147029
147030
147031
147032
147033
147034
147035
147036
147037
147038
147039
147040
147041
147042
147043
147044
147045
147046
147047
147048
147049
147050
147051
147052
147053
147054
147055
147056
147057
147058
147059
147060
147061
147062
147063
147064
147065
147066
147067
147068
147069
147070
147071
147072
147073
147074
147075
147076
147077
147078
147079
147080
147081
147082
147083
147084
147085
147086
147087
147088
147089
147090
147091
147092
147093
147094
147095
147096
147097
147098
147099
147100
147101
147102
147103
147104
147105
147106
147107
147108
147109
147110
147111
147112
147113
147114
147115
147116
147117
147118
147119
147120
147121
147122
147123
147124
147125
147126
147127
147128
147129
147130
147131
147132
147133
147134
147135
147136
147137
147138
147139
147140
147141
147142
147143
147144
147145
147146
147147
147148
147149
147150
147151
147152
147153
147154
147155
147156
147157
147158
147159
147160
147161
147162
147163
147164
147165
147166
147167
147168
147169
147170
147171
147172
147173
147174
147175
147176
147177
147178
147179
147180
147181
147182
147183
147184
147185
147186
147187
147188
147189
147190
147191
147192
147193
147194
147195
147196
147197
147198
147199
147200
147201
147202
147203
147204
147205
147206
147207
147208
147209
147210
147211
147212
147213
147214
147215
147216
147217
147218
147219
147220
147221
147222
147223
147224
147225
147226
147227
147228
147229
147230
147231
147232
147233
147234
147235
147236
147237
147238
147239
147240
147241
147242
147243
147244
147245
147246
147247
147248
147249
147250
147251
147252
147253
147254
147255
147256
147257
147258
147259
147260
147261
147262
147263
147264
147265
147266
147267
147268
147269
147270
147271
147272
147273
147274
147275
147276
147277
147278
147279
147280
147281
147282
147283
147284
147285
147286
147287
147288
147289
147290
147291
147292
147293
147294
147295
147296
147297
147298
147299
147300
147301
147302
147303
147304
147305
147306
147307
147308
147309
147310
147311
147312
147313
147314
147315
147316
147317
147318
147319
147320
147321
147322
147323
147324
147325
147326
147327
147328
147329
147330
147331
147332
147333
147334
147335
147336
147337
147338
147339
147340
147341
147342
147343
147344
147345
147346
147347
147348
147349
147350
147351
147352
147353
147354
147355
147356
147357
147358
147359
147360
147361
147362
147363
147364
147365
147366
147367
147368
147369
147370
147371
147372
147373
147374
147375
147376
147377
147378
147379
147380
147381
147382
147383
147384
147385
147386
147387
147388
147389
147390
147391
147392
147393
147394
147395
147396
147397
147398
147399
147400
147401
147402
147403
147404
147405
147406
147407
147408
147409
147410
147411
147412
147413
147414
147415
147416
147417
147418
147419
147420
147421
147422
147423
147424
147425
147426
147427
147428
147429
147430
147431
147432
147433
147434
147435
147436
147437
147438
147439
147440
147441
147442
147443
147444
147445
147446
147447
147448
147449
147450
147451
147452
147453
147454
147455
147456
147457
147458
147459
147460
147461
147462
147463
147464
147465
147466
147467
147468
147469
147470
147471
147472
147473
147474
147475
147476
147477
147478
147479
147480
147481
147482
147483
147484
147485
147486
147487
147488
147489
147490
147491
147492
147493
147494
147495
147496
147497
147498
147499
147500
147501
147502
147503
147504
147505
147506
147507
147508
147509
147510
147511
147512
147513
147514
147515
147516
147517
147518
147519
147520
147521
147522
147523
147524
147525
147526
147527
147528
147529
147530
147531
147532
147533
147534
147535
147536
147537
147538
147539
147540
147541
147542
147543
147544
147545
147546
147547
147548
147549
147550
147551
147552
147553
147554
147555
147556
147557
147558
147559
147560
147561
147562
147563
147564
147565
147566
147567
147568
147569
147570
147571
147572
147573
147574
147575
147576
147577
147578
147579
147580
147581
147582
147583
147584
147585
147586
147587
147588
147589
147590
147591
147592
147593
147594
147595
147596
147597
147598
147599
147600
147601
147602
147603
147604
147605
147606
147607
147608
147609
147610
147611
147612
147613
147614
147615
147616
147617
147618
147619
147620
147621
147622
147623
147624
147625
147626
147627
147628
147629
147630
147631
147632
147633
147634
147635
147636
147637
147638
147639
147640
147641
147642
147643
147644
147645
147646
147647
147648
147649
147650
147651
147652
147653
147654
147655
147656
147657
147658
147659
147660
147661
147662
147663
147664
147665
147666
147667
147668
147669
147670
147671
147672
147673
147674
147675
147676
147677
147678
147679
147680
147681
147682
147683
147684
147685
147686
147687
147688
147689
147690
147691
147692
147693
147694
147695
147696
147697
147698
147699
147700
147701
147702
147703
147704
147705
147706
147707
147708
147709
147710
147711
147712
147713
147714
147715
147716
147717
147718
147719
147720
147721
147722
147723
147724
147725
147726
147727
147728
147729
147730
147731
147732
147733
147734
147735
147736
147737
147738
147739
147740
147741
147742
147743
147744
147745
147746
147747
147748
147749
147750
147751
147752
147753
147754
147755
147756
147757
147758
147759
147760
147761
147762
147763
147764
147765
147766
147767
147768
147769
147770
147771
147772
147773
147774
147775
147776
147777
147778
147779
147780
147781
147782
147783
147784
147785
147786
147787
147788
147789
147790
147791
147792
147793
147794
147795
147796
147797
147798
147799
147800
147801
147802
147803
147804
147805
147806
147807
147808
147809
147810
147811
147812
147813
147814
147815
147816
147817
147818
147819
147820
147821
147822
147823
147824
147825
147826
147827
147828
147829
147830
147831
147832
147833
147834
147835
147836
147837
147838
147839
147840
147841
147842
147843
147844
147845
147846
147847
147848
147849
147850
147851
147852
147853
147854
147855
147856
147857
147858
147859
147860
147861
147862
147863
147864
147865
147866
147867
147868
147869
147870
147871
147872
147873
147874
147875
147876
147877
147878
147879
147880
147881
147882
147883
147884
147885
147886
147887
147888
147889
147890
147891
147892
147893
147894
147895
147896
147897
147898
147899
147900
147901
147902
147903
147904
147905
147906
147907
147908
147909
147910
147911
147912
147913
147914
147915
147916
147917
147918
147919
147920
147921
147922
147923
147924
147925
147926
147927
147928
147929
147930
147931
147932
147933
147934
147935
147936
147937
147938
147939
147940
147941
147942
147943
147944
147945
147946
147947
147948
147949
147950
147951
147952
147953
147954
147955
147956
147957
147958
147959
147960
147961
147962
147963
147964
147965
147966
147967
147968
147969
147970
147971
147972
147973
147974
147975
147976
147977
147978
147979
147980
147981
147982
147983
147984
147985
147986
147987
147988
147989
147990
147991
147992
147993
147994
147995
147996
147997
147998
147999
148000
148001
148002
148003
148004
148005
148006
148007
148008
148009
148010
148011
148012
148013
148014
148015
148016
148017
148018
148019
148020
148021
148022
148023
148024
148025
148026
148027
148028
148029
148030
148031
148032
148033
148034
148035
148036
148037
148038
148039
148040
148041
148042
148043
148044
148045
148046
148047
148048
148049
148050
148051
148052
148053
148054
148055
148056
148057
148058
148059
148060
148061
148062
148063
148064
148065
148066
148067
148068
148069
148070
148071
148072
148073
148074
148075
148076
148077
148078
148079
148080
148081
148082
148083
148084
148085
148086
148087
148088
148089
148090
148091
148092
148093
148094
148095
148096
148097
148098
148099
148100
148101
148102
148103
148104
148105
148106
148107
148108
148109
148110
148111
148112
148113
148114
148115
148116
148117
148118
148119
148120
148121
148122
148123
148124
148125
148126
148127
148128
148129
148130
148131
148132
148133
148134
148135
148136
148137
148138
148139
148140
148141
148142
148143
148144
148145
148146
148147
148148
148149
148150
148151
148152
148153
148154
148155
148156
148157
148158
148159
148160
148161
148162
148163
148164
148165
148166
148167
148168
148169
148170
148171
148172
148173
148174
148175
148176
148177
148178
148179
148180
148181
148182
148183
148184
148185
148186
148187
148188
148189
148190
148191
148192
148193
148194
148195
148196
148197
148198
148199
148200
148201
148202
148203
148204
148205
148206
148207
148208
148209
148210
148211
148212
148213
148214
148215
148216
148217
148218
148219
148220
148221
148222
148223
148224
148225
148226
148227
148228
148229
148230
148231
148232
148233
148234
148235
148236
148237
148238
148239
148240
148241
148242
148243
148244
148245
148246
148247
148248
148249
148250
148251
148252
148253
148254
148255
148256
148257
148258
148259
148260
148261
148262
148263
148264
148265
148266
148267
148268
148269
148270
148271
148272
148273
148274
148275
148276
148277
148278
148279
148280
148281
148282
148283
148284
148285
148286
148287
148288
148289
148290
148291
148292
148293
148294
148295
148296
148297
148298
148299
148300
148301
148302
148303
148304
148305
148306
148307
148308
148309
148310
148311
148312
148313
148314
148315
148316
148317
148318
148319
148320
148321
148322
148323
148324
148325
148326
148327
148328
148329
148330
148331
148332
148333
148334
148335
148336
148337
148338
148339
148340
148341
148342
148343
148344
148345
148346
148347
148348
148349
148350
148351
148352
148353
148354
148355
148356
148357
148358
148359
148360
148361
148362
148363
148364
148365
148366
148367
148368
148369
148370
148371
148372
148373
148374
148375
148376
148377
148378
148379
148380
148381
148382
148383
148384
148385
148386
148387
148388
148389
148390
148391
148392
148393
148394
148395
148396
148397
148398
148399
148400
148401
148402
148403
148404
148405
148406
148407
148408
148409
148410
148411
148412
148413
148414
148415
148416
148417
148418
148419
148420
148421
148422
148423
148424
148425
148426
148427
148428
148429
148430
148431
148432
148433
148434
148435
148436
148437
148438
148439
148440
148441
148442
148443
148444
148445
148446
148447
148448
148449
148450
148451
148452
148453
148454
148455
148456
148457
148458
148459
148460
148461
148462
148463
148464
148465
148466
148467
148468
148469
148470
148471
148472
148473
148474
148475
148476
148477
148478
148479
148480
148481
148482
148483
148484
148485
148486
148487
148488
148489
148490
148491
148492
148493
148494
148495
148496
148497
148498
148499
148500
148501
148502
148503
148504
148505
148506
148507
148508
148509
148510
148511
148512
148513
148514
148515
148516
148517
148518
148519
148520
148521
148522
148523
148524
148525
148526
148527
148528
148529
148530
148531
148532
148533
148534
148535
148536
148537
148538
148539
148540
148541
148542
148543
148544
148545
148546
148547
148548
148549
148550
148551
148552
148553
148554
148555
148556
148557
148558
148559
148560
148561
148562
148563
148564
148565
148566
148567
148568
148569
148570
148571
148572
148573
148574
148575
148576
148577
148578
148579
148580
148581
148582
148583
148584
148585
148586
148587
148588
148589
148590
148591
148592
148593
148594
148595
148596
148597
148598
148599
148600
148601
148602
148603
148604
148605
148606
148607
148608
148609
148610
148611
148612
148613
148614
148615
148616
148617
148618
148619
148620
148621
148622
148623
148624
148625
148626
148627
148628
148629
148630
148631
148632
148633
148634
148635
148636
148637
148638
148639
148640
148641
148642
148643
148644
148645
148646
148647
148648
148649
148650
148651
148652
148653
148654
148655
148656
148657
148658
148659
148660
148661
148662
148663
148664
148665
148666
148667
148668
148669
148670
148671
148672
148673
148674
148675
148676
148677
148678
148679
148680
148681
148682
148683
148684
148685
148686
148687
148688
148689
148690
148691
148692
148693
148694
148695
148696
148697
148698
148699
148700
148701
148702
148703
148704
148705
148706
148707
148708
148709
148710
148711
148712
148713
148714
148715
148716
148717
148718
148719
148720
148721
148722
148723
148724
148725
148726
148727
148728
148729
148730
148731
148732
148733
148734
148735
148736
148737
148738
148739
148740
148741
148742
148743
148744
148745
148746
148747
148748
148749
148750
148751
148752
148753
148754
148755
148756
148757
148758
148759
148760
148761
148762
148763
148764
148765
148766
148767
148768
148769
148770
148771
148772
148773
148774
148775
148776
148777
148778
148779
148780
148781
148782
148783
148784
148785
148786
148787
148788
148789
148790
148791
148792
148793
148794
148795
148796
148797
148798
148799
148800
148801
148802
148803
148804
148805
148806
148807
148808
148809
148810
148811
148812
148813
148814
148815
148816
148817
148818
148819
148820
148821
148822
148823
148824
148825
148826
148827
148828
148829
148830
148831
148832
148833
148834
148835
148836
148837
148838
148839
148840
148841
148842
148843
148844
148845
148846
148847
148848
148849
148850
148851
148852
148853
148854
148855
148856
148857
148858
148859
148860
148861
148862
148863
148864
148865
148866
148867
148868
148869
148870
148871
148872
148873
148874
148875
148876
148877
148878
148879
148880
148881
148882
148883
148884
148885
148886
148887
148888
148889
148890
148891
148892
148893
148894
148895
148896
148897
148898
148899
148900
148901
148902
148903
148904
148905
148906
148907
148908
148909
148910
148911
148912
148913
148914
148915
148916
148917
148918
148919
148920
148921
148922
148923
148924
148925
148926
148927
148928
148929
148930
148931
148932
148933
148934
148935
148936
148937
148938
148939
148940
148941
148942
148943
148944
148945
148946
148947
148948
148949
148950
148951
148952
148953
148954
148955
148956
148957
148958
148959
148960
148961
148962
148963
148964
148965
148966
148967
148968
148969
148970
148971
148972
148973
148974
148975
148976
148977
148978
148979
148980
148981
148982
148983
148984
148985
148986
148987
148988
148989
148990
148991
148992
148993
148994
148995
148996
148997
148998
148999
149000
149001
149002
149003
149004
149005
149006
149007
149008
149009
149010
149011
149012
149013
149014
149015
149016
149017
149018
149019
149020
149021
149022
149023
149024
149025
149026
149027
149028
149029
149030
149031
149032
149033
149034
149035
149036
149037
149038
149039
149040
149041
149042
149043
149044
149045
149046
149047
149048
149049
149050
149051
149052
149053
149054
149055
149056
149057
149058
149059
149060
149061
149062
149063
149064
149065
149066
149067
149068
149069
149070
149071
149072
149073
149074
149075
149076
149077
149078
149079
149080
149081
149082
149083
149084
149085
149086
149087
149088
149089
149090
149091
149092
149093
149094
149095
149096
149097
149098
149099
149100
149101
149102
149103
149104
149105
149106
149107
149108
149109
149110
149111
149112
149113
149114
149115
149116
149117
149118
149119
149120
149121
149122
149123
149124
149125
149126
149127
149128
149129
149130
149131
149132
149133
149134
149135
149136
149137
149138
149139
149140
149141
149142
149143
149144
149145
149146
149147
149148
149149
149150
149151
149152
149153
149154
149155
149156
149157
149158
149159
149160
149161
149162
149163
149164
149165
149166
149167
149168
149169
149170
149171
149172
149173
149174
149175
149176
149177
149178
149179
149180
149181
149182
149183
149184
149185
149186
149187
149188
149189
149190
149191
149192
149193
149194
149195
149196
149197
149198
149199
149200
149201
149202
149203
149204
149205
149206
149207
149208
149209
149210
149211
149212
149213
149214
149215
149216
149217
149218
149219
149220
149221
149222
149223
149224
149225
149226
149227
149228
149229
149230
149231
149232
149233
149234
149235
149236
149237
149238
149239
149240
149241
149242
149243
149244
149245
149246
149247
149248
149249
149250
149251
149252
149253
149254
149255
149256
149257
149258
149259
149260
149261
149262
149263
149264
149265
149266
149267
149268
149269
149270
149271
149272
149273
149274
149275
149276
149277
149278
149279
149280
149281
149282
149283
149284
149285
149286
149287
149288
149289
149290
149291
149292
149293
149294
149295
149296
149297
149298
149299
149300
149301
149302
149303
149304
149305
149306
149307
149308
149309
149310
149311
149312
149313
149314
149315
149316
149317
149318
149319
149320
149321
149322
149323
149324
149325
149326
149327
149328
149329
149330
149331
149332
149333
149334
149335
149336
149337
149338
149339
149340
149341
149342
149343
149344
149345
149346
149347
149348
149349
149350
149351
149352
149353
149354
149355
149356
149357
149358
149359
149360
149361
149362
149363
149364
149365
149366
149367
149368
149369
149370
149371
149372
149373
149374
149375
149376
149377
149378
149379
149380
149381
149382
149383
149384
149385
149386
149387
149388
149389
149390
149391
149392
149393
149394
149395
149396
149397
149398
149399
149400
149401
149402
149403
149404
149405
149406
149407
149408
149409
149410
149411
149412
149413
149414
149415
149416
149417
149418
149419
149420
149421
149422
149423
149424
149425
149426
149427
149428
149429
149430
149431
149432
149433
149434
149435
149436
149437
149438
149439
149440
149441
149442
149443
149444
149445
149446
149447
149448
149449
149450
149451
149452
149453
149454
149455
149456
149457
149458
149459
149460
149461
149462
149463
149464
149465
149466
149467
149468
149469
149470
149471
149472
149473
149474
149475
149476
149477
149478
149479
149480
149481
149482
149483
149484
149485
149486
149487
149488
149489
149490
149491
149492
149493
149494
149495
149496
149497
149498
149499
149500
149501
149502
149503
149504
149505
149506
149507
149508
149509
149510
149511
149512
149513
149514
149515
149516
149517
149518
149519
149520
149521
149522
149523
149524
149525
149526
149527
149528
149529
149530
149531
149532
149533
149534
149535
149536
149537
149538
149539
149540
149541
149542
149543
149544
149545
149546
149547
149548
149549
149550
149551
149552
149553
149554
149555
149556
149557
149558
149559
149560
149561
149562
149563
149564
149565
149566
149567
149568
149569
149570
149571
149572
149573
149574
149575
149576
149577
149578
149579
149580
149581
149582
149583
149584
149585
149586
149587
149588
149589
149590
149591
149592
149593
149594
149595
149596
149597
149598
149599
149600
149601
149602
149603
149604
149605
149606
149607
149608
149609
149610
149611
149612
149613
149614
149615
149616
149617
149618
149619
149620
149621
149622
149623
149624
149625
149626
149627
149628
149629
149630
149631
149632
149633
149634
149635
149636
149637
149638
149639
149640
149641
149642
149643
149644
149645
149646
149647
149648
149649
149650
149651
149652
149653
149654
149655
149656
149657
149658
149659
149660
149661
149662
149663
149664
149665
149666
149667
149668
149669
149670
149671
149672
149673
149674
149675
149676
149677
149678
149679
149680
149681
149682
149683
149684
149685
149686
149687
149688
149689
149690
149691
149692
149693
149694
149695
149696
149697
149698
149699
149700
149701
149702
149703
149704
149705
149706
149707
149708
149709
149710
149711
149712
149713
149714
149715
149716
149717
149718
149719
149720
149721
149722
149723
149724
149725
149726
149727
149728
149729
149730
149731
149732
149733
149734
149735
149736
149737
149738
149739
149740
149741
149742
149743
149744
149745
149746
149747
149748
149749
149750
149751
149752
149753
149754
149755
149756
149757
149758
149759
149760
149761
149762
149763
149764
149765
149766
149767
149768
149769
149770
149771
149772
149773
149774
149775
149776
149777
149778
149779
149780
149781
149782
149783
149784
149785
149786
149787
149788
149789
149790
149791
149792
149793
149794
149795
149796
149797
149798
149799
149800
149801
149802
149803
149804
149805
149806
149807
149808
149809
149810
149811
149812
149813
149814
149815
149816
149817
149818
149819
149820
149821
149822
149823
149824
149825
149826
149827
149828
149829
149830
149831
149832
149833
149834
149835
149836
149837
149838
149839
149840
149841
149842
149843
149844
149845
149846
149847
149848
149849
149850
149851
149852
149853
149854
149855
149856
149857
149858
149859
149860
149861
149862
149863
149864
149865
149866
149867
149868
149869
149870
149871
149872
149873
149874
149875
149876
149877
149878
149879
149880
149881
149882
149883
149884
149885
149886
149887
149888
149889
149890
149891
149892
149893
149894
149895
149896
149897
149898
149899
149900
149901
149902
149903
149904
149905
149906
149907
149908
149909
149910
149911
149912
149913
149914
149915
149916
149917
149918
149919
149920
149921
149922
149923
149924
149925
149926
149927
149928
149929
149930
149931
149932
149933
149934
149935
149936
149937
149938
149939
149940
149941
149942
149943
149944
149945
149946
149947
149948
149949
149950
149951
149952
149953
149954
149955
149956
149957
149958
149959
149960
149961
149962
149963
149964
149965
149966
149967
149968
149969
149970
149971
149972
149973
149974
149975
149976
149977
149978
149979
149980
149981
149982
149983
149984
149985
149986
149987
149988
149989
149990
149991
149992
149993
149994
149995
149996
149997
149998
149999
150000
150001
150002
150003
150004
150005
150006
150007
150008
150009
150010
150011
150012
150013
150014
150015
150016
150017
150018
150019
150020
150021
150022
150023
150024
150025
150026
150027
150028
150029
150030
150031
150032
150033
150034
150035
150036
150037
150038
150039
150040
150041
150042
150043
150044
150045
150046
150047
150048
150049
150050
150051
150052
150053
150054
150055
150056
150057
150058
150059
150060
150061
150062
150063
150064
150065
150066
150067
150068
150069
150070
150071
150072
150073
150074
150075
150076
150077
150078
150079
150080
150081
150082
150083
150084
150085
150086
150087
150088
150089
150090
150091
150092
150093
150094
150095
150096
150097
150098
150099
150100
150101
150102
150103
150104
150105
150106
150107
150108
150109
150110
150111
150112
150113
150114
150115
150116
150117
150118
150119
150120
150121
150122
150123
150124
150125
150126
150127
150128
150129
150130
150131
150132
150133
150134
150135
150136
150137
150138
150139
150140
150141
150142
150143
150144
150145
150146
150147
150148
150149
150150
150151
150152
150153
150154
150155
150156
150157
150158
150159
150160
150161
150162
150163
150164
150165
150166
150167
150168
150169
150170
150171
150172
150173
150174
150175
150176
150177
150178
150179
150180
150181
150182
150183
150184
150185
150186
150187
150188
150189
150190
150191
150192
150193
150194
150195
150196
150197
150198
150199
150200
150201
150202
150203
150204
150205
150206
150207
150208
150209
150210
150211
150212
150213
150214
150215
150216
150217
150218
150219
150220
150221
150222
150223
150224
150225
150226
150227
150228
150229
150230
150231
150232
150233
150234
150235
150236
150237
150238
150239
150240
150241
150242
150243
150244
150245
150246
150247
150248
150249
150250
150251
150252
150253
150254
150255
150256
150257
150258
150259
150260
150261
150262
150263
150264
150265
150266
150267
150268
150269
150270
150271
150272
150273
150274
150275
150276
150277
150278
150279
150280
150281
150282
150283
150284
150285
150286
150287
150288
150289
150290
150291
150292
150293
150294
150295
150296
150297
150298
150299
150300
150301
150302
150303
150304
150305
150306
150307
150308
150309
150310
150311
150312
150313
150314
150315
150316
150317
150318
150319
150320
150321
150322
150323
150324
150325
150326
150327
150328
150329
150330
150331
150332
150333
150334
150335
150336
150337
150338
150339
150340
150341
150342
150343
150344
150345
150346
150347
150348
150349
150350
150351
150352
150353
150354
150355
150356
150357
150358
150359
150360
150361
150362
150363
150364
150365
150366
150367
150368
150369
150370
150371
150372
150373
150374
150375
150376
150377
150378
150379
150380
150381
150382
150383
150384
150385
150386
150387
150388
150389
150390
150391
150392
150393
150394
150395
150396
150397
150398
150399
150400
150401
150402
150403
150404
150405
150406
150407
150408
150409
150410
150411
150412
150413
150414
150415
150416
150417
150418
150419
150420
150421
150422
150423
150424
150425
150426
150427
150428
150429
150430
150431
150432
150433
150434
150435
150436
150437
150438
150439
150440
150441
150442
150443
150444
150445
150446
150447
150448
150449
150450
150451
150452
150453
150454
150455
150456
150457
150458
150459
150460
150461
150462
150463
150464
150465
150466
150467
150468
150469
150470
150471
150472
150473
150474
150475
150476
150477
150478
150479
150480
150481
150482
150483
150484
150485
150486
150487
150488
150489
150490
150491
150492
150493
150494
150495
150496
150497
150498
150499
150500
150501
150502
150503
150504
150505
150506
150507
150508
150509
150510
150511
150512
150513
150514
150515
150516
150517
150518
150519
150520
150521
150522
150523
150524
150525
150526
150527
150528
150529
150530
150531
150532
150533
150534
150535
150536
150537
150538
150539
150540
150541
150542
150543
150544
150545
150546
150547
150548
150549
150550
150551
150552
150553
150554
150555
150556
150557
150558
150559
150560
150561
150562
150563
150564
150565
150566
150567
150568
150569
150570
150571
150572
150573
150574
150575
150576
150577
150578
150579
150580
150581
150582
150583
150584
150585
150586
150587
150588
150589
150590
150591
150592
150593
150594
150595
150596
150597
150598
150599
150600
150601
150602
150603
150604
150605
150606
150607
150608
150609
150610
150611
150612
150613
150614
150615
150616
150617
150618
150619
150620
150621
150622
150623
150624
150625
150626
150627
150628
150629
150630
150631
150632
150633
150634
150635
150636
150637
150638
150639
150640
150641
150642
150643
150644
150645
150646
150647
150648
150649
150650
150651
150652
150653
150654
150655
150656
150657
150658
150659
150660
150661
150662
150663
150664
150665
150666
150667
150668
150669
150670
150671
150672
150673
150674
150675
150676
150677
150678
150679
150680
150681
150682
150683
150684
150685
150686
150687
150688
150689
150690
150691
150692
150693
150694
150695
150696
150697
150698
150699
150700
150701
150702
150703
150704
150705
150706
150707
150708
150709
150710
150711
150712
150713
150714
150715
150716
150717
150718
150719
150720
150721
150722
150723
150724
150725
150726
150727
150728
150729
150730
150731
150732
150733
150734
150735
150736
150737
150738
150739
150740
150741
150742
150743
150744
150745
150746
150747
150748
150749
150750
150751
150752
150753
150754
150755
150756
150757
150758
150759
150760
150761
150762
150763
150764
150765
150766
150767
150768
150769
150770
150771
150772
150773
150774
150775
150776
150777
150778
150779
150780
150781
150782
150783
150784
150785
150786
150787
150788
150789
150790
150791
150792
150793
150794
150795
150796
150797
150798
150799
150800
150801
150802
150803
150804
150805
150806
150807
150808
150809
150810
150811
150812
150813
150814
150815
150816
150817
150818
150819
150820
150821
150822
150823
150824
150825
150826
150827
150828
150829
150830
150831
150832
150833
150834
150835
150836
150837
150838
150839
150840
150841
150842
150843
150844
150845
150846
150847
150848
150849
150850
150851
150852
150853
150854
150855
150856
150857
150858
150859
150860
150861
150862
150863
150864
150865
150866
150867
150868
150869
150870
150871
150872
150873
150874
150875
150876
150877
150878
150879
150880
150881
150882
150883
150884
150885
150886
150887
150888
150889
150890
150891
150892
150893
150894
150895
150896
150897
150898
150899
150900
150901
150902
150903
150904
150905
150906
150907
150908
150909
150910
150911
150912
150913
150914
150915
150916
150917
150918
150919
150920
150921
150922
150923
150924
150925
150926
150927
150928
150929
150930
150931
150932
150933
150934
150935
150936
150937
150938
150939
150940
150941
150942
150943
150944
150945
150946
150947
150948
150949
150950
150951
150952
150953
150954
150955
150956
150957
150958
150959
150960
150961
150962
150963
150964
150965
150966
150967
150968
150969
150970
150971
150972
150973
150974
150975
150976
150977
150978
150979
150980
150981
150982
150983
150984
150985
150986
150987
150988
150989
150990
150991
150992
150993
150994
150995
150996
150997
150998
150999
151000
151001
151002
151003
151004
151005
151006
151007
151008
151009
151010
151011
151012
151013
151014
151015
151016
151017
151018
151019
151020
151021
151022
151023
151024
151025
151026
151027
151028
151029
151030
151031
151032
151033
151034
151035
151036
151037
151038
151039
151040
151041
151042
151043
151044
151045
151046
151047
151048
151049
151050
151051
151052
151053
151054
151055
151056
151057
151058
151059
151060
151061
151062
151063
151064
151065
151066
151067
151068
151069
151070
151071
151072
151073
151074
151075
151076
151077
151078
151079
151080
151081
151082
151083
151084
151085
151086
151087
151088
151089
151090
151091
151092
151093
151094
151095
151096
151097
151098
151099
151100
151101
151102
151103
151104
151105
151106
151107
151108
151109
151110
151111
151112
151113
151114
151115
151116
151117
151118
151119
151120
151121
151122
151123
151124
151125
151126
151127
151128
151129
151130
151131
151132
151133
151134
151135
151136
151137
151138
151139
151140
151141
151142
151143
151144
151145
151146
151147
151148
151149
151150
151151
151152
151153
151154
151155
151156
151157
151158
151159
151160
151161
151162
151163
151164
151165
151166
151167
151168
151169
151170
151171
151172
151173
151174
151175
151176
151177
151178
151179
151180
151181
151182
151183
151184
151185
151186
151187
151188
151189
151190
151191
151192
151193
151194
151195
151196
151197
151198
151199
151200
151201
151202
151203
151204
151205
151206
151207
151208
151209
151210
151211
151212
151213
151214
151215
151216
151217
151218
151219
151220
151221
151222
151223
151224
151225
151226
151227
151228
151229
151230
151231
151232
151233
151234
151235
151236
151237
151238
151239
151240
151241
151242
151243
151244
151245
151246
151247
151248
151249
151250
151251
151252
151253
151254
151255
151256
151257
151258
151259
151260
151261
151262
151263
151264
151265
151266
151267
151268
151269
151270
151271
151272
151273
151274
151275
151276
151277
151278
151279
151280
151281
151282
151283
151284
151285
151286
151287
151288
151289
151290
151291
151292
151293
151294
151295
151296
151297
151298
151299
151300
151301
151302
151303
151304
151305
151306
151307
151308
151309
151310
151311
151312
151313
151314
151315
151316
151317
151318
151319
151320
151321
151322
151323
151324
151325
151326
151327
151328
151329
151330
151331
151332
151333
151334
151335
151336
151337
151338
151339
151340
151341
151342
151343
151344
151345
151346
151347
151348
151349
151350
151351
151352
151353
151354
151355
151356
151357
151358
151359
151360
151361
151362
151363
151364
151365
151366
151367
151368
151369
151370
151371
151372
151373
151374
151375
151376
151377
151378
151379
151380
151381
151382
151383
151384
151385
151386
151387
151388
151389
151390
151391
151392
151393
151394
151395
151396
151397
151398
151399
151400
151401
151402
151403
151404
151405
151406
151407
151408
151409
151410
151411
151412
151413
151414
151415
151416
151417
151418
151419
151420
151421
151422
151423
151424
151425
151426
151427
151428
151429
151430
151431
151432
151433
151434
151435
151436
151437
151438
151439
151440
151441
151442
151443
151444
151445
151446
151447
151448
151449
151450
151451
151452
151453
151454
151455
151456
151457
151458
151459
151460
151461
151462
151463
151464
151465
151466
151467
151468
151469
151470
151471
151472
151473
151474
151475
151476
151477
151478
151479
151480
151481
151482
151483
151484
151485
151486
151487
151488
151489
151490
151491
151492
151493
151494
151495
151496
151497
151498
151499
151500
151501
151502
151503
151504
151505
151506
151507
151508
151509
151510
151511
151512
151513
151514
151515
151516
151517
151518
151519
151520
151521
151522
151523
151524
151525
151526
151527
151528
151529
151530
151531
151532
151533
151534
151535
151536
151537
151538
151539
151540
151541
151542
151543
151544
151545
151546
151547
151548
151549
151550
151551
151552
151553
151554
151555
151556
151557
151558
151559
151560
151561
151562
151563
151564
151565
151566
151567
151568
151569
151570
151571
151572
151573
151574
151575
151576
151577
151578
151579
151580
151581
151582
151583
151584
151585
151586
151587
151588
151589
151590
151591
151592
151593
151594
151595
151596
151597
151598
151599
151600
151601
151602
151603
151604
151605
151606
151607
151608
151609
151610
151611
151612
151613
151614
151615
151616
151617
151618
151619
151620
151621
151622
151623
151624
151625
151626
151627
151628
151629
151630
151631
151632
151633
151634
151635
151636
151637
151638
151639
151640
151641
151642
151643
151644
151645
151646
151647
151648
151649
151650
151651
151652
151653
151654
151655
151656
151657
151658
151659
151660
151661
151662
151663
151664
151665
151666
151667
151668
151669
151670
151671
151672
151673
151674
151675
151676
151677
151678
151679
151680
151681
151682
151683
151684
151685
151686
151687
151688
151689
151690
151691
151692
151693
151694
151695
151696
151697
151698
151699
151700
151701
151702
151703
151704
151705
151706
151707
151708
151709
151710
151711
151712
151713
151714
151715
151716
151717
151718
151719
151720
151721
151722
151723
151724
151725
151726
151727
151728
151729
151730
151731
151732
151733
151734
151735
151736
151737
151738
151739
151740
151741
151742
151743
151744
151745
151746
151747
151748
151749
151750
151751
151752
151753
151754
151755
151756
151757
151758
151759
151760
151761
151762
151763
151764
151765
151766
151767
151768
151769
151770
151771
151772
151773
151774
151775
151776
151777
151778
151779
151780
151781
151782
151783
151784
151785
151786
151787
151788
151789
151790
151791
151792
151793
151794
151795
151796
151797
151798
151799
151800
151801
151802
151803
151804
151805
151806
151807
151808
151809
151810
151811
151812
151813
151814
151815
151816
151817
151818
151819
151820
151821
151822
151823
151824
151825
151826
151827
151828
151829
151830
151831
151832
151833
151834
151835
151836
151837
151838
151839
151840
151841
151842
151843
151844
151845
151846
151847
151848
151849
151850
151851
151852
151853
151854
151855
151856
151857
151858
151859
151860
151861
151862
151863
151864
151865
151866
151867
151868
151869
151870
151871
151872
151873
151874
151875
151876
151877
151878
151879
151880
151881
151882
151883
151884
151885
151886
151887
151888
151889
151890
151891
151892
151893
151894
151895
151896
151897
151898
151899
151900
151901
151902
151903
151904
151905
151906
151907
151908
151909
151910
151911
151912
151913
151914
151915
151916
151917
151918
151919
151920
151921
151922
151923
151924
151925
151926
151927
151928
151929
151930
151931
151932
151933
151934
151935
151936
151937
151938
151939
151940
151941
151942
151943
151944
151945
151946
151947
151948
151949
151950
151951
151952
151953
151954
151955
151956
151957
151958
151959
151960
151961
151962
151963
151964
151965
151966
151967
151968
151969
151970
151971
151972
151973
151974
151975
151976
151977
151978
151979
151980
151981
151982
151983
151984
151985
151986
151987
151988
151989
151990
151991
151992
151993
151994
151995
151996
151997
151998
151999
152000
152001
152002
152003
152004
152005
152006
152007
152008
152009
152010
152011
152012
152013
152014
152015
152016
152017
152018
152019
152020
152021
152022
152023
152024
152025
152026
152027
152028
152029
152030
152031
152032
152033
152034
152035
152036
152037
152038
152039
152040
152041
152042
152043
152044
152045
152046
152047
152048
152049
152050
152051
152052
152053
152054
152055
152056
152057
152058
152059
152060
152061
152062
152063
152064
152065
152066
152067
152068
152069
152070
152071
152072
152073
152074
152075
152076
152077
152078
152079
152080
152081
152082
152083
152084
152085
152086
152087
152088
152089
152090
152091
152092
152093
152094
152095
152096
152097
152098
152099
152100
152101
152102
152103
152104
152105
152106
152107
152108
152109
152110
152111
152112
152113
152114
152115
152116
152117
152118
152119
152120
152121
152122
152123
152124
152125
152126
152127
152128
152129
152130
152131
152132
152133
152134
152135
152136
152137
152138
152139
152140
152141
152142
152143
152144
152145
152146
152147
152148
152149
152150
152151
152152
152153
152154
152155
152156
152157
152158
152159
152160
152161
152162
152163
152164
152165
152166
152167
152168
152169
152170
152171
152172
152173
152174
152175
152176
152177
152178
152179
152180
152181
152182
152183
152184
152185
152186
152187
152188
152189
152190
152191
152192
152193
152194
152195
152196
152197
152198
152199
152200
152201
152202
152203
152204
152205
152206
152207
152208
152209
152210
152211
152212
152213
152214
152215
152216
152217
152218
152219
152220
152221
152222
152223
152224
152225
152226
152227
152228
152229
152230
152231
152232
152233
152234
152235
152236
152237
152238
152239
152240
152241
152242
152243
152244
152245
152246
152247
152248
152249
152250
152251
152252
152253
152254
152255
152256
152257
152258
152259
152260
152261
152262
152263
152264
152265
152266
152267
152268
152269
152270
152271
152272
152273
152274
152275
152276
152277
152278
152279
152280
152281
152282
152283
152284
152285
152286
152287
152288
152289
152290
152291
152292
152293
152294
152295
152296
152297
152298
152299
152300
152301
152302
152303
152304
152305
152306
152307
152308
152309
152310
152311
152312
152313
152314
152315
152316
152317
152318
152319
152320
152321
152322
152323
152324
152325
152326
152327
152328
152329
152330
152331
152332
152333
152334
152335
152336
152337
152338
152339
152340
152341
152342
152343
152344
152345
152346
152347
152348
152349
152350
152351
152352
152353
152354
152355
152356
152357
152358
152359
152360
152361
152362
152363
152364
152365
152366
152367
152368
152369
152370
152371
152372
152373
152374
152375
152376
152377
152378
152379
152380
152381
152382
152383
152384
152385
152386
152387
152388
152389
152390
152391
152392
152393
152394
152395
152396
152397
152398
152399
152400
152401
152402
152403
152404
152405
152406
152407
152408
152409
152410
152411
152412
152413
152414
152415
152416
152417
152418
152419
152420
152421
152422
152423
152424
152425
152426
152427
152428
152429
152430
152431
152432
152433
152434
152435
152436
152437
152438
152439
152440
152441
152442
152443
152444
152445
152446
152447
152448
152449
152450
152451
152452
152453
152454
152455
152456
152457
152458
152459
152460
152461
152462
152463
152464
152465
152466
152467
152468
152469
152470
152471
152472
152473
152474
152475
152476
152477
152478
152479
152480
152481
152482
152483
152484
152485
152486
152487
152488
152489
152490
152491
152492
152493
152494
152495
152496
152497
152498
152499
152500
152501
152502
152503
152504
152505
152506
152507
152508
152509
152510
152511
152512
152513
152514
152515
152516
152517
152518
152519
152520
152521
152522
152523
152524
152525
152526
152527
152528
152529
152530
152531
152532
152533
152534
152535
152536
152537
152538
152539
152540
152541
152542
152543
152544
152545
152546
152547
152548
152549
152550
152551
152552
152553
152554
152555
152556
152557
152558
152559
152560
152561
152562
152563
152564
152565
152566
152567
152568
152569
152570
152571
152572
152573
152574
152575
152576
152577
152578
152579
152580
152581
152582
152583
152584
152585
152586
152587
152588
152589
152590
152591
152592
152593
152594
152595
152596
152597
152598
152599
152600
152601
152602
152603
152604
152605
152606
152607
152608
152609
152610
152611
152612
152613
152614
152615
152616
152617
152618
152619
152620
152621
152622
152623
152624
152625
152626
152627
152628
152629
152630
152631
152632
152633
152634
152635
152636
152637
152638
152639
152640
152641
152642
152643
152644
152645
152646
152647
152648
152649
152650
152651
152652
152653
152654
152655
152656
152657
152658
152659
152660
152661
152662
152663
152664
152665
152666
152667
152668
152669
152670
152671
152672
152673
152674
152675
152676
152677
152678
152679
152680
152681
152682
152683
152684
152685
152686
152687
152688
152689
152690
152691
152692
152693
152694
152695
152696
152697
152698
152699
152700
152701
152702
152703
152704
152705
152706
152707
152708
152709
152710
152711
152712
152713
152714
152715
152716
152717
152718
152719
152720
152721
152722
152723
152724
152725
152726
152727
152728
152729
152730
152731
152732
152733
152734
152735
152736
152737
152738
152739
152740
152741
152742
152743
152744
152745
152746
152747
152748
152749
152750
152751
152752
152753
152754
152755
152756
152757
152758
152759
152760
152761
152762
152763
152764
152765
152766
152767
152768
152769
152770
152771
152772
152773
152774
152775
152776
152777
152778
152779
152780
152781
152782
152783
152784
152785
152786
152787
152788
152789
152790
152791
152792
152793
152794
152795
152796
152797
152798
152799
152800
152801
152802
152803
152804
152805
152806
152807
152808
152809
152810
152811
152812
152813
152814
152815
152816
152817
152818
152819
152820
152821
152822
152823
152824
152825
152826
152827
152828
152829
152830
152831
152832
152833
152834
152835
152836
152837
152838
152839
152840
152841
152842
152843
152844
152845
152846
152847
152848
152849
152850
152851
152852
152853
152854
152855
152856
152857
152858
152859
152860
152861
152862
152863
152864
152865
152866
152867
152868
152869
152870
152871
152872
152873
152874
152875
152876
152877
152878
152879
152880
152881
152882
152883
152884
152885
152886
152887
152888
152889
152890
152891
152892
152893
152894
152895
152896
152897
152898
152899
152900
152901
152902
152903
152904
152905
152906
152907
152908
152909
152910
152911
152912
152913
152914
152915
152916
152917
152918
152919
152920
152921
152922
152923
152924
152925
152926
152927
152928
152929
152930
152931
152932
152933
152934
152935
152936
152937
152938
152939
152940
152941
152942
152943
152944
152945
152946
152947
152948
152949
152950
152951
152952
152953
152954
152955
152956
152957
152958
152959
152960
152961
152962
152963
152964
152965
152966
152967
152968
152969
152970
152971
152972
152973
152974
152975
152976
152977
152978
152979
152980
152981
152982
152983
152984
152985
152986
152987
152988
152989
152990
152991
152992
152993
152994
152995
152996
152997
152998
152999
153000
153001
153002
153003
153004
153005
153006
153007
153008
153009
153010
153011
153012
153013
153014
153015
153016
153017
153018
153019
153020
153021
153022
153023
153024
153025
153026
153027
153028
153029
153030
153031
153032
153033
153034
153035
153036
153037
153038
153039
153040
153041
153042
153043
153044
153045
153046
153047
153048
153049
153050
153051
153052
153053
153054
153055
153056
153057
153058
153059
153060
153061
153062
153063
153064
153065
153066
153067
153068
153069
153070
153071
153072
153073
153074
153075
153076
153077
153078
153079
153080
153081
153082
153083
153084
153085
153086
153087
153088
153089
153090
153091
153092
153093
153094
153095
153096
153097
153098
153099
153100
153101
153102
153103
153104
153105
153106
153107
153108
153109
153110
153111
153112
153113
153114
153115
153116
153117
153118
153119
153120
153121
153122
153123
153124
153125
153126
153127
153128
153129
153130
153131
153132
153133
153134
153135
153136
153137
153138
153139
153140
153141
153142
153143
153144
153145
153146
153147
153148
153149
153150
153151
153152
153153
153154
153155
153156
153157
153158
153159
153160
153161
153162
153163
153164
153165
153166
153167
153168
153169
153170
153171
153172
153173
153174
153175
153176
153177
153178
153179
153180
153181
153182
153183
153184
153185
153186
153187
153188
153189
153190
153191
153192
153193
153194
153195
153196
153197
153198
153199
153200
153201
153202
153203
153204
153205
153206
153207
153208
153209
153210
153211
153212
153213
153214
153215
153216
153217
153218
153219
153220
153221
153222
153223
153224
153225
153226
153227
153228
153229
153230
153231
153232
153233
153234
153235
153236
153237
153238
153239
153240
153241
153242
153243
153244
153245
153246
153247
153248
153249
153250
153251
153252
153253
153254
153255
153256
153257
153258
153259
153260
153261
153262
153263
153264
153265
153266
153267
153268
153269
153270
153271
153272
153273
153274
153275
153276
153277
153278
153279
153280
153281
153282
153283
153284
153285
153286
153287
153288
153289
153290
153291
153292
153293
153294
153295
153296
153297
153298
153299
153300
153301
153302
153303
153304
153305
153306
153307
153308
153309
153310
153311
153312
153313
153314
153315
153316
153317
153318
153319
153320
153321
153322
153323
153324
153325
153326
153327
153328
153329
153330
153331
153332
153333
153334
153335
153336
153337
153338
153339
153340
153341
153342
153343
153344
153345
153346
153347
153348
153349
153350
153351
153352
153353
153354
153355
153356
153357
153358
153359
153360
153361
153362
153363
153364
153365
153366
153367
153368
153369
153370
153371
153372
153373
153374
153375
153376
153377
153378
153379
153380
153381
153382
153383
153384
153385
153386
153387
153388
153389
153390
153391
153392
153393
153394
153395
153396
153397
153398
153399
153400
153401
153402
153403
153404
153405
153406
153407
153408
153409
153410
153411
153412
153413
153414
153415
153416
153417
153418
153419
153420
153421
153422
153423
153424
153425
153426
153427
153428
153429
153430
153431
153432
153433
153434
153435
153436
153437
153438
153439
153440
153441
153442
153443
153444
153445
153446
153447
153448
153449
153450
153451
153452
153453
153454
153455
153456
153457
153458
153459
153460
153461
153462
153463
153464
153465
153466
153467
153468
153469
153470
153471
153472
153473
153474
153475
153476
153477
153478
153479
153480
153481
153482
153483
153484
153485
153486
153487
153488
153489
153490
153491
153492
153493
153494
153495
153496
153497
153498
153499
153500
153501
153502
153503
153504
153505
153506
153507
153508
153509
153510
153511
153512
153513
153514
153515
153516
153517
153518
153519
153520
153521
153522
153523
153524
153525
153526
153527
153528
153529
153530
153531
153532
153533
153534
153535
153536
153537
153538
153539
153540
153541
153542
153543
153544
153545
153546
153547
153548
153549
153550
153551
153552
153553
153554
153555
153556
153557
153558
153559
153560
153561
153562
153563
153564
153565
153566
153567
153568
153569
153570
153571
153572
153573
153574
153575
153576
153577
153578
153579
153580
153581
153582
153583
153584
153585
153586
153587
153588
153589
153590
153591
153592
153593
153594
153595
153596
153597
153598
153599
153600
153601
153602
153603
153604
153605
153606
153607
153608
153609
153610
153611
153612
153613
153614
153615
153616
153617
153618
153619
153620
153621
153622
153623
153624
153625
153626
153627
153628
153629
153630
153631
153632
153633
153634
153635
153636
153637
153638
153639
153640
153641
153642
153643
153644
153645
153646
153647
153648
153649
153650
153651
153652
153653
153654
153655
153656
153657
153658
153659
153660
153661
153662
153663
153664
153665
153666
153667
153668
153669
153670
153671
153672
153673
153674
153675
153676
153677
153678
153679
153680
153681
153682
153683
153684
153685
153686
153687
153688
153689
153690
153691
153692
153693
153694
153695
153696
153697
153698
153699
153700
153701
153702
153703
153704
153705
153706
153707
153708
153709
153710
153711
153712
153713
153714
153715
153716
153717
153718
153719
153720
153721
153722
153723
153724
153725
153726
153727
153728
153729
153730
153731
153732
153733
153734
153735
153736
153737
153738
153739
153740
153741
153742
153743
153744
153745
153746
153747
153748
153749
153750
153751
153752
153753
153754
153755
153756
153757
153758
153759
153760
153761
153762
153763
153764
153765
153766
153767
153768
153769
153770
153771
153772
153773
153774
153775
153776
153777
153778
153779
153780
153781
153782
153783
153784
153785
153786
153787
153788
153789
153790
153791
153792
153793
153794
153795
153796
153797
153798
153799
153800
153801
153802
153803
153804
153805
153806
153807
153808
153809
153810
153811
153812
153813
153814
153815
153816
153817
153818
153819
153820
153821
153822
153823
153824
153825
153826
153827
153828
153829
153830
153831
153832
153833
153834
153835
153836
153837
153838
153839
153840
153841
153842
153843
153844
153845
153846
153847
153848
153849
153850
153851
153852
153853
153854
153855
153856
153857
153858
153859
153860
153861
153862
153863
153864
153865
153866
153867
153868
153869
153870
153871
153872
153873
153874
153875
153876
153877
153878
153879
153880
153881
153882
153883
153884
153885
153886
153887
153888
153889
153890
153891
153892
153893
153894
153895
153896
153897
153898
153899
153900
153901
153902
153903
153904
153905
153906
153907
153908
153909
153910
153911
153912
153913
153914
153915
153916
153917
153918
153919
153920
153921
153922
153923
153924
153925
153926
153927
153928
153929
153930
153931
153932
153933
153934
153935
153936
153937
153938
153939
153940
153941
153942
153943
153944
153945
153946
153947
153948
153949
153950
153951
153952
153953
153954
153955
153956
153957
153958
153959
153960
153961
153962
153963
153964
153965
153966
153967
153968
153969
153970
153971
153972
153973
153974
153975
153976
153977
153978
153979
153980
153981
153982
153983
153984
153985
153986
153987
153988
153989
153990
153991
153992
153993
153994
153995
153996
153997
153998
153999
154000
154001
154002
154003
154004
154005
154006
154007
154008
154009
154010
154011
154012
154013
154014
154015
154016
154017
154018
154019
154020
154021
154022
154023
154024
154025
154026
154027
154028
154029
154030
154031
154032
154033
154034
154035
154036
154037
154038
154039
154040
154041
154042
154043
154044
154045
154046
154047
154048
154049
154050
154051
154052
154053
154054
154055
154056
154057
154058
154059
154060
154061
154062
154063
154064
154065
154066
154067
154068
154069
154070
154071
154072
154073
154074
154075
154076
154077
154078
154079
154080
154081
154082
154083
154084
154085
154086
154087
154088
154089
154090
154091
154092
154093
154094
154095
154096
154097
154098
154099
154100
154101
154102
154103
154104
154105
154106
154107
154108
154109
154110
154111
154112
154113
154114
154115
154116
154117
154118
154119
154120
154121
154122
154123
154124
154125
154126
154127
154128
154129
154130
154131
154132
154133
154134
154135
154136
154137
154138
154139
154140
154141
154142
154143
154144
154145
154146
154147
154148
154149
154150
154151
154152
154153
154154
154155
154156
154157
154158
154159
154160
154161
154162
154163
154164
154165
154166
154167
154168
154169
154170
154171
154172
154173
154174
154175
154176
154177
154178
154179
154180
154181
154182
154183
154184
154185
154186
154187
154188
154189
154190
154191
154192
154193
154194
154195
154196
154197
154198
154199
154200
154201
154202
154203
154204
154205
154206
154207
154208
154209
154210
154211
154212
154213
154214
154215
154216
154217
154218
154219
154220
154221
154222
154223
154224
154225
154226
154227
154228
154229
154230
154231
154232
154233
154234
154235
154236
154237
154238
154239
154240
154241
154242
154243
154244
154245
154246
154247
154248
154249
154250
154251
154252
154253
154254
154255
154256
154257
154258
154259
154260
154261
154262
154263
154264
154265
154266
154267
154268
154269
154270
154271
154272
154273
154274
154275
154276
154277
154278
154279
154280
154281
154282
154283
154284
154285
154286
154287
154288
154289
154290
154291
154292
154293
154294
154295
154296
154297
154298
154299
154300
154301
154302
154303
154304
154305
154306
154307
154308
154309
154310
154311
154312
154313
154314
154315
154316
154317
154318
154319
154320
154321
154322
154323
154324
154325
154326
154327
154328
154329
154330
154331
154332
154333
154334
154335
154336
154337
154338
154339
154340
154341
154342
154343
154344
154345
154346
154347
154348
154349
154350
154351
154352
154353
154354
154355
154356
154357
154358
154359
154360
154361
154362
154363
154364
154365
154366
154367
154368
154369
154370
154371
154372
154373
154374
154375
154376
154377
154378
154379
154380
154381
154382
154383
154384
154385
154386
154387
154388
154389
154390
154391
154392
154393
154394
154395
154396
154397
154398
154399
154400
154401
154402
154403
154404
154405
154406
154407
154408
154409
154410
154411
154412
154413
154414
154415
154416
154417
154418
154419
154420
154421
154422
154423
154424
154425
154426
154427
154428
154429
154430
154431
154432
154433
154434
154435
154436
154437
154438
154439
154440
154441
154442
154443
154444
154445
154446
154447
154448
154449
154450
154451
154452
154453
154454
154455
154456
154457
154458
154459
154460
154461
154462
154463
154464
154465
154466
154467
154468
154469
154470
154471
154472
154473
154474
154475
154476
154477
154478
154479
154480
154481
154482
154483
154484
154485
154486
154487
154488
154489
154490
154491
154492
154493
154494
154495
154496
154497
154498
154499
154500
154501
154502
154503
154504
154505
154506
154507
154508
154509
154510
154511
154512
154513
154514
154515
154516
154517
154518
154519
154520
154521
154522
154523
154524
154525
154526
154527
154528
154529
154530
154531
154532
154533
154534
154535
154536
154537
154538
154539
154540
154541
154542
154543
154544
154545
154546
154547
154548
154549
154550
154551
154552
154553
154554
154555
154556
154557
154558
154559
154560
154561
154562
154563
154564
154565
154566
154567
154568
154569
154570
154571
154572
154573
154574
154575
154576
154577
154578
154579
154580
154581
154582
154583
154584
154585
154586
154587
154588
154589
154590
154591
154592
154593
154594
154595
154596
154597
154598
154599
154600
154601
154602
154603
154604
154605
154606
154607
154608
154609
154610
154611
154612
154613
154614
154615
154616
154617
154618
154619
154620
154621
154622
154623
154624
154625
154626
154627
154628
154629
154630
154631
154632
154633
154634
154635
154636
154637
154638
154639
154640
154641
154642
154643
154644
154645
154646
154647
154648
154649
154650
154651
154652
154653
154654
154655
154656
154657
154658
154659
154660
154661
154662
154663
154664
154665
154666
154667
154668
154669
154670
154671
154672
154673
154674
154675
154676
154677
154678
154679
154680
154681
154682
154683
154684
154685
154686
154687
154688
154689
154690
154691
154692
154693
154694
154695
154696
154697
154698
154699
154700
154701
154702
154703
154704
154705
154706
154707
154708
154709
154710
154711
154712
154713
154714
154715
154716
154717
154718
154719
154720
154721
154722
154723
154724
154725
154726
154727
154728
154729
154730
154731
154732
154733
154734
154735
154736
154737
154738
154739
154740
154741
154742
154743
154744
154745
154746
154747
154748
154749
154750
154751
154752
154753
154754
154755
154756
154757
154758
154759
154760
154761
154762
154763
154764
154765
154766
154767
154768
154769
154770
154771
154772
154773
154774
154775
154776
154777
154778
154779
154780
154781
154782
154783
154784
154785
154786
154787
154788
154789
154790
154791
154792
154793
154794
154795
154796
154797
154798
154799
154800
154801
154802
154803
154804
154805
154806
154807
154808
154809
154810
154811
154812
154813
154814
154815
154816
154817
154818
154819
154820
154821
154822
154823
154824
154825
154826
154827
154828
154829
154830
154831
154832
154833
154834
154835
154836
154837
154838
154839
154840
154841
154842
154843
154844
154845
154846
154847
154848
154849
154850
154851
154852
154853
154854
154855
154856
154857
154858
154859
154860
154861
154862
154863
154864
154865
154866
154867
154868
154869
154870
154871
154872
154873
154874
154875
154876
154877
154878
154879
154880
154881
154882
154883
154884
154885
154886
154887
154888
154889
154890
154891
154892
154893
154894
154895
154896
154897
154898
154899
154900
154901
154902
154903
154904
154905
154906
154907
154908
154909
154910
154911
154912
154913
154914
154915
154916
154917
154918
154919
154920
154921
154922
154923
154924
154925
154926
154927
154928
154929
154930
154931
154932
154933
154934
154935
154936
154937
154938
154939
154940
154941
154942
154943
154944
154945
154946
154947
154948
154949
154950
154951
154952
154953
154954
154955
154956
154957
154958
154959
154960
154961
154962
154963
154964
154965
154966
154967
154968
154969
154970
154971
154972
154973
154974
154975
154976
154977
154978
154979
154980
154981
154982
154983
154984
154985
154986
154987
154988
154989
154990
154991
154992
154993
154994
154995
154996
154997
154998
154999
155000
155001
155002
155003
155004
155005
155006
155007
155008
155009
155010
155011
155012
155013
155014
155015
155016
155017
155018
155019
155020
155021
155022
155023
155024
155025
155026
155027
155028
155029
155030
155031
155032
155033
155034
155035
155036
155037
155038
155039
155040
155041
155042
155043
155044
155045
155046
155047
155048
155049
155050
155051
155052
155053
155054
155055
155056
155057
155058
155059
155060
155061
155062
155063
155064
155065
155066
155067
155068
155069
155070
155071
155072
155073
155074
155075
155076
155077
155078
155079
155080
155081
155082
155083
155084
155085
155086
155087
155088
155089
155090
155091
155092
155093
155094
155095
155096
155097
155098
155099
155100
155101
155102
155103
155104
155105
155106
155107
155108
155109
155110
155111
155112
155113
155114
155115
155116
155117
155118
155119
155120
155121
155122
155123
155124
155125
155126
155127
155128
155129
155130
155131
155132
155133
155134
155135
155136
155137
155138
155139
155140
155141
155142
155143
155144
155145
155146
155147
155148
155149
155150
155151
155152
155153
155154
155155
155156
155157
155158
155159
155160
155161
155162
155163
155164
155165
155166
155167
155168
155169
155170
155171
155172
155173
155174
155175
155176
155177
155178
155179
155180
155181
155182
155183
155184
155185
155186
155187
155188
155189
155190
155191
155192
155193
155194
155195
155196
155197
155198
155199
155200
155201
155202
155203
155204
155205
155206
155207
155208
155209
155210
155211
155212
155213
155214
155215
155216
155217
155218
155219
155220
155221
155222
155223
155224
155225
155226
155227
155228
155229
155230
155231
155232
155233
155234
155235
155236
155237
155238
155239
155240
155241
155242
155243
155244
155245
155246
155247
155248
155249
155250
155251
155252
155253
155254
155255
155256
155257
155258
155259
155260
155261
155262
155263
155264
155265
155266
155267
155268
155269
155270
155271
155272
155273
155274
155275
155276
155277
155278
155279
155280
155281
155282
155283
155284
155285
155286
155287
155288
155289
155290
155291
155292
155293
155294
155295
155296
155297
155298
155299
155300
155301
155302
155303
155304
155305
155306
155307
155308
155309
155310
155311
155312
155313
155314
155315
155316
155317
155318
155319
155320
155321
155322
155323
155324
155325
155326
155327
155328
155329
155330
155331
155332
155333
155334
155335
155336
155337
155338
155339
155340
155341
155342
155343
155344
155345
155346
155347
155348
155349
155350
155351
155352
155353
155354
155355
155356
155357
155358
155359
155360
155361
155362
155363
155364
155365
155366
155367
155368
155369
155370
155371
155372
155373
155374
155375
155376
155377
155378
155379
155380
155381
155382
155383
155384
155385
155386
155387
155388
155389
155390
155391
155392
155393
155394
155395
155396
155397
155398
155399
155400
155401
155402
155403
155404
155405
155406
155407
155408
155409
155410
155411
155412
155413
155414
155415
155416
155417
155418
155419
155420
155421
155422
155423
155424
155425
155426
155427
155428
155429
155430
155431
155432
155433
155434
155435
155436
155437
155438
155439
155440
155441
155442
155443
155444
155445
155446
155447
155448
155449
155450
155451
155452
155453
155454
155455
155456
155457
155458
155459
155460
155461
155462
155463
155464
155465
155466
155467
155468
155469
155470
155471
155472
155473
155474
155475
155476
155477
155478
155479
155480
155481
155482
155483
155484
155485
155486
155487
155488
155489
155490
155491
155492
155493
155494
155495
155496
155497
155498
155499
155500
155501
155502
155503
155504
155505
155506
155507
155508
155509
155510
155511
155512
155513
155514
155515
155516
155517
155518
155519
155520
155521
155522
155523
155524
155525
155526
155527
155528
155529
155530
155531
155532
155533
155534
155535
155536
155537
155538
155539
155540
155541
155542
155543
155544
155545
155546
155547
155548
155549
155550
155551
155552
155553
155554
155555
155556
155557
155558
155559
155560
155561
155562
155563
155564
155565
155566
155567
155568
155569
155570
155571
155572
155573
155574
155575
155576
155577
155578
155579
155580
155581
155582
155583
155584
155585
155586
155587
155588
155589
155590
155591
155592
155593
155594
155595
155596
155597
155598
155599
155600
155601
155602
155603
155604
155605
155606
155607
155608
155609
155610
155611
155612
155613
155614
155615
155616
155617
155618
155619
155620
155621
155622
155623
155624
155625
155626
155627
155628
155629
155630
155631
155632
155633
155634
155635
155636
155637
155638
155639
155640
155641
155642
155643
155644
155645
155646
155647
155648
155649
155650
155651
155652
155653
155654
155655
155656
155657
155658
155659
155660
155661
155662
155663
155664
155665
155666
155667
155668
155669
155670
155671
155672
155673
155674
155675
155676
155677
155678
155679
155680
155681
155682
155683
155684
155685
155686
155687
155688
155689
155690
155691
155692
155693
155694
155695
155696
155697
155698
155699
155700
155701
155702
155703
155704
155705
155706
155707
155708
155709
155710
155711
155712
155713
155714
155715
155716
155717
155718
155719
155720
155721
155722
155723
155724
155725
155726
155727
155728
155729
155730
155731
155732
155733
155734
155735
155736
155737
155738
155739
155740
155741
155742
155743
155744
155745
155746
155747
155748
155749
155750
155751
155752
155753
155754
155755
155756
155757
155758
155759
155760
155761
155762
155763
155764
155765
155766
155767
155768
155769
155770
155771
155772
155773
155774
155775
155776
155777
155778
155779
155780
155781
155782
155783
155784
155785
155786
155787
155788
155789
155790
155791
155792
155793
155794
155795
155796
155797
155798
155799
155800
155801
155802
155803
155804
155805
155806
155807
155808
155809
155810
155811
155812
155813
155814
155815
155816
155817
155818
155819
155820
155821
155822
155823
155824
155825
155826
155827
155828
155829
155830
155831
155832
155833
155834
155835
155836
155837
155838
155839
155840
155841
155842
155843
155844
155845
155846
155847
155848
155849
155850
155851
155852
155853
155854
155855
155856
155857
155858
155859
155860
155861
155862
155863
155864
155865
155866
155867
155868
155869
155870
155871
155872
155873
155874
155875
155876
155877
155878
155879
155880
155881
155882
155883
155884
155885
155886
155887
155888
155889
155890
155891
155892
155893
155894
155895
155896
155897
155898
155899
155900
155901
155902
155903
155904
155905
155906
155907
155908
155909
155910
155911
155912
155913
155914
155915
155916
155917
155918
155919
155920
155921
155922
155923
155924
155925
155926
155927
155928
155929
155930
155931
155932
155933
155934
155935
155936
155937
155938
155939
155940
155941
155942
155943
155944
155945
155946
155947
155948
155949
155950
155951
155952
155953
155954
155955
155956
155957
155958
155959
155960
155961
155962
155963
155964
155965
155966
155967
155968
155969
155970
155971
155972
155973
155974
155975
155976
155977
155978
155979
155980
155981
155982
155983
155984
155985
155986
155987
155988
155989
155990
155991
155992
155993
155994
155995
155996
155997
155998
155999
156000
156001
156002
156003
156004
156005
156006
156007
156008
156009
156010
156011
156012
156013
156014
156015
156016
156017
156018
156019
156020
156021
156022
156023
156024
156025
156026
156027
156028
156029
156030
156031
156032
156033
156034
156035
156036
156037
156038
156039
156040
156041
156042
156043
156044
156045
156046
156047
156048
156049
156050
156051
156052
156053
156054
156055
156056
156057
156058
156059
156060
156061
156062
156063
156064
156065
156066
156067
156068
156069
156070
156071
156072
156073
156074
156075
156076
156077
156078
156079
156080
156081
156082
156083
156084
156085
156086
156087
156088
156089
156090
156091
156092
156093
156094
156095
156096
156097
156098
156099
156100
156101
156102
156103
156104
156105
156106
156107
156108
156109
156110
156111
156112
156113
156114
156115
156116
156117
156118
156119
156120
156121
156122
156123
156124
156125
156126
156127
156128
156129
156130
156131
156132
156133
156134
156135
156136
156137
156138
156139
156140
156141
156142
156143
156144
156145
156146
156147
156148
156149
156150
156151
156152
156153
156154
156155
156156
156157
156158
156159
156160
156161
156162
156163
156164
156165
156166
156167
156168
156169
156170
156171
156172
156173
156174
156175
156176
156177
156178
156179
156180
156181
156182
156183
156184
156185
156186
156187
156188
156189
156190
156191
156192
156193
156194
156195
156196
156197
156198
156199
156200
156201
156202
156203
156204
156205
156206
156207
156208
156209
156210
156211
156212
156213
156214
156215
156216
156217
156218
156219
156220
156221
156222
156223
156224
156225
156226
156227
156228
156229
156230
156231
156232
156233
156234
156235
156236
156237
156238
156239
156240
156241
156242
156243
156244
156245
156246
156247
156248
156249
156250
156251
156252
156253
156254
156255
156256
156257
156258
156259
156260
156261
156262
156263
156264
156265
156266
156267
156268
156269
156270
156271
156272
156273
156274
156275
156276
156277
156278
156279
156280
156281
156282
156283
156284
156285
156286
156287
156288
156289
156290
156291
156292
156293
156294
156295
156296
156297
156298
156299
156300
156301
156302
156303
156304
156305
156306
156307
156308
156309
156310
156311
156312
156313
156314
156315
156316
156317
156318
156319
156320
156321
156322
156323
156324
156325
156326
156327
156328
156329
156330
156331
156332
156333
156334
156335
156336
156337
156338
156339
156340
156341
156342
156343
156344
156345
156346
156347
156348
156349
156350
156351
156352
156353
156354
156355
156356
156357
156358
156359
156360
156361
156362
156363
156364
156365
156366
156367
156368
156369
156370
156371
156372
156373
156374
156375
156376
156377
156378
156379
156380
156381
156382
156383
156384
156385
156386
156387
156388
156389
156390
156391
156392
156393
156394
156395
156396
156397
156398
156399
156400
156401
156402
156403
156404
156405
156406
156407
156408
156409
156410
156411
156412
156413
156414
156415
156416
156417
156418
156419
156420
156421
156422
156423
156424
156425
156426
156427
156428
156429
156430
156431
156432
156433
156434
156435
156436
156437
156438
156439
156440
156441
156442
156443
156444
156445
156446
156447
156448
156449
156450
156451
156452
156453
156454
156455
156456
156457
156458
156459
156460
156461
156462
156463
156464
156465
156466
156467
156468
156469
156470
156471
156472
156473
156474
156475
156476
156477
156478
156479
156480
156481
156482
156483
156484
156485
156486
156487
156488
156489
156490
156491
156492
156493
156494
156495
156496
156497
156498
156499
156500
156501
156502
156503
156504
156505
156506
156507
156508
156509
156510
156511
156512
156513
156514
156515
156516
156517
156518
156519
156520
156521
156522
156523
156524
156525
156526
156527
156528
156529
156530
156531
156532
156533
156534
156535
156536
156537
156538
156539
156540
156541
156542
156543
156544
156545
156546
156547
156548
156549
156550
156551
156552
156553
156554
156555
156556
156557
156558
156559
156560
156561
156562
156563
156564
156565
156566
156567
156568
156569
156570
156571
156572
156573
156574
156575
156576
156577
156578
156579
156580
156581
156582
156583
156584
156585
156586
156587
156588
156589
156590
156591
156592
156593
156594
156595
156596
156597
156598
156599
156600
156601
156602
156603
156604
156605
156606
156607
156608
156609
156610
156611
156612
156613
156614
156615
156616
156617
156618
156619
156620
156621
156622
156623
156624
156625
156626
156627
156628
156629
156630
156631
156632
156633
156634
156635
156636
156637
156638
156639
156640
156641
156642
156643
156644
156645
156646
156647
156648
156649
156650
156651
156652
156653
156654
156655
156656
156657
156658
156659
156660
156661
156662
156663
156664
156665
156666
156667
156668
156669
156670
156671
156672
156673
156674
156675
156676
156677
156678
156679
156680
156681
156682
156683
156684
156685
156686
156687
156688
156689
156690
156691
156692
156693
156694
156695
156696
156697
156698
156699
156700
156701
156702
156703
156704
156705
156706
156707
156708
156709
156710
156711
156712
156713
156714
156715
156716
156717
156718
156719
156720
156721
156722
156723
156724
156725
156726
156727
156728
156729
156730
156731
156732
156733
156734
156735
156736
156737
156738
156739
156740
156741
156742
156743
156744
156745
156746
156747
156748
156749
156750
156751
156752
156753
156754
156755
156756
156757
156758
156759
156760
156761
156762
156763
156764
156765
156766
156767
156768
156769
156770
156771
156772
156773
156774
156775
156776
156777
156778
156779
156780
156781
156782
156783
156784
156785
156786
156787
156788
156789
156790
156791
156792
156793
156794
156795
156796
156797
156798
156799
156800
156801
156802
156803
156804
156805
156806
156807
156808
156809
156810
156811
156812
156813
156814
156815
156816
156817
156818
156819
156820
156821
156822
156823
156824
156825
156826
156827
156828
156829
156830
156831
156832
156833
156834
156835
156836
156837
156838
156839
156840
156841
156842
156843
156844
156845
156846
156847
156848
156849
156850
156851
156852
156853
156854
156855
156856
156857
156858
156859
156860
156861
156862
156863
156864
156865
156866
156867
156868
156869
156870
156871
156872
156873
156874
156875
156876
156877
156878
156879
156880
156881
156882
156883
156884
156885
156886
156887
156888
156889
156890
156891
156892
156893
156894
156895
156896
156897
156898
156899
156900
156901
156902
156903
156904
156905
156906
156907
156908
156909
156910
156911
156912
156913
156914
156915
156916
156917
156918
156919
156920
156921
156922
156923
156924
156925
156926
156927
156928
156929
156930
156931
156932
156933
156934
156935
156936
156937
156938
156939
156940
156941
156942
156943
156944
156945
156946
156947
156948
156949
156950
156951
156952
156953
156954
156955
156956
156957
156958
156959
156960
156961
156962
156963
156964
156965
156966
156967
156968
156969
156970
156971
156972
156973
156974
156975
156976
156977
156978
156979
156980
156981
156982
156983
156984
156985
156986
156987
156988
156989
156990
156991
156992
156993
156994
156995
156996
156997
156998
156999
157000
157001
157002
157003
157004
157005
157006
157007
157008
157009
157010
157011
157012
157013
157014
157015
157016
157017
157018
157019
157020
157021
157022
157023
157024
157025
157026
157027
157028
157029
157030
157031
157032
157033
157034
157035
157036
157037
157038
157039
157040
157041
157042
157043
157044
157045
157046
157047
157048
157049
157050
157051
157052
157053
157054
157055
157056
157057
157058
157059
157060
157061
157062
157063
157064
157065
157066
157067
157068
157069
157070
157071
157072
157073
157074
157075
157076
157077
157078
157079
157080
157081
157082
157083
157084
157085
157086
157087
157088
157089
157090
157091
157092
157093
157094
157095
157096
157097
157098
157099
157100
157101
157102
157103
157104
157105
157106
157107
157108
157109
157110
157111
157112
157113
157114
157115
157116
157117
157118
157119
157120
157121
157122
157123
157124
157125
157126
157127
157128
157129
157130
157131
157132
157133
157134
157135
157136
157137
157138
157139
157140
157141
157142
157143
157144
157145
157146
157147
157148
157149
157150
157151
157152
157153
157154
157155
157156
157157
157158
157159
157160
157161
157162
157163
157164
157165
157166
157167
157168
157169
157170
157171
157172
157173
157174
157175
157176
157177
157178
157179
157180
157181
157182
157183
157184
157185
157186
157187
157188
157189
157190
157191
157192
157193
157194
157195
157196
157197
157198
157199
157200
157201
157202
157203
157204
157205
157206
157207
157208
157209
157210
157211
157212
157213
157214
157215
157216
157217
157218
157219
157220
157221
157222
157223
157224
157225
157226
157227
157228
157229
157230
157231
157232
157233
157234
157235
157236
157237
157238
157239
157240
157241
157242
157243
157244
157245
157246
157247
157248
157249
157250
157251
157252
157253
157254
157255
157256
157257
157258
157259
157260
157261
157262
157263
157264
157265
157266
157267
157268
157269
157270
157271
157272
157273
157274
157275
157276
157277
157278
157279
157280
157281
157282
157283
157284
157285
157286
157287
157288
157289
157290
157291
157292
157293
157294
157295
157296
157297
157298
157299
157300
157301
157302
157303
157304
157305
157306
157307
157308
157309
157310
157311
157312
157313
157314
157315
157316
157317
157318
157319
157320
157321
157322
157323
157324
157325
157326
157327
157328
157329
157330
157331
157332
157333
157334
157335
157336
157337
157338
157339
157340
157341
157342
157343
157344
157345
157346
157347
157348
157349
157350
157351
157352
157353
157354
157355
157356
157357
157358
157359
157360
157361
157362
157363
157364
157365
157366
157367
157368
157369
157370
157371
157372
157373
157374
157375
157376
157377
157378
157379
157380
157381
157382
157383
157384
157385
157386
157387
157388
157389
157390
157391
157392
157393
157394
157395
157396
157397
157398
157399
157400
157401
157402
157403
157404
157405
157406
157407
157408
157409
157410
157411
157412
157413
157414
157415
157416
157417
157418
157419
157420
157421
157422
157423
157424
157425
157426
157427
157428
157429
157430
157431
157432
157433
157434
157435
157436
157437
157438
157439
157440
157441
157442
157443
157444
157445
157446
157447
157448
157449
157450
157451
157452
157453
157454
157455
157456
157457
157458
157459
157460
157461
157462
157463
157464
157465
157466
157467
157468
157469
157470
157471
157472
157473
157474
157475
157476
157477
157478
157479
157480
157481
157482
157483
157484
157485
157486
157487
157488
157489
157490
157491
157492
157493
157494
157495
157496
157497
157498
157499
157500
157501
157502
157503
157504
157505
157506
157507
157508
157509
157510
157511
157512
157513
157514
157515
157516
157517
157518
157519
157520
157521
157522
157523
157524
157525
157526
157527
157528
157529
157530
157531
157532
157533
157534
157535
157536
157537
157538
157539
157540
157541
157542
157543
157544
157545
157546
157547
157548
157549
157550
157551
157552
157553
157554
157555
157556
157557
157558
157559
157560
157561
157562
157563
157564
157565
157566
157567
157568
157569
157570
157571
157572
157573
157574
157575
157576
157577
157578
157579
157580
157581
157582
157583
157584
157585
157586
157587
157588
157589
157590
157591
157592
157593
157594
157595
157596
157597
157598
157599
157600
157601
157602
157603
157604
157605
157606
157607
157608
157609
157610
157611
157612
157613
157614
157615
157616
157617
157618
157619
157620
157621
157622
157623
157624
157625
157626
157627
157628
157629
157630
157631
157632
157633
157634
157635
157636
157637
157638
157639
157640
157641
157642
157643
157644
157645
157646
157647
157648
157649
157650
157651
157652
157653
157654
157655
157656
157657
157658
157659
157660
157661
157662
157663
157664
157665
157666
157667
157668
157669
157670
157671
157672
157673
157674
157675
157676
157677
157678
157679
157680
157681
157682
157683
157684
157685
157686
157687
157688
157689
157690
157691
157692
157693
157694
157695
157696
157697
157698
157699
157700
157701
157702
157703
157704
157705
157706
157707
157708
157709
157710
157711
157712
157713
157714
157715
157716
157717
157718
157719
157720
157721
157722
157723
157724
157725
157726
157727
157728
157729
157730
157731
157732
157733
157734
157735
157736
157737
157738
157739
157740
157741
157742
157743
157744
157745
157746
157747
157748
157749
157750
157751
157752
157753
157754
157755
157756
157757
157758
157759
157760
157761
157762
157763
157764
157765
157766
157767
157768
157769
157770
157771
157772
157773
157774
157775
157776
157777
157778
157779
157780
157781
157782
157783
157784
157785
157786
157787
157788
157789
157790
157791
157792
157793
157794
157795
157796
157797
157798
157799
157800
157801
157802
157803
157804
157805
157806
157807
157808
157809
157810
157811
157812
157813
157814
157815
157816
157817
157818
157819
157820
157821
157822
157823
157824
157825
157826
157827
157828
157829
157830
157831
157832
157833
157834
157835
157836
157837
157838
157839
157840
157841
157842
157843
157844
157845
157846
157847
157848
157849
157850
157851
157852
157853
157854
157855
157856
157857
157858
157859
157860
157861
157862
157863
157864
157865
157866
157867
157868
157869
157870
157871
157872
157873
157874
157875
157876
157877
157878
157879
157880
157881
157882
157883
157884
157885
157886
157887
157888
157889
157890
157891
157892
157893
157894
157895
157896
157897
157898
157899
157900
157901
157902
157903
157904
157905
157906
157907
157908
157909
157910
157911
157912
157913
157914
157915
157916
157917
157918
157919
157920
157921
157922
157923
157924
157925
157926
157927
157928
157929
157930
157931
157932
157933
157934
157935
157936
157937
157938
157939
157940
157941
157942
157943
157944
157945
157946
157947
157948
157949
157950
157951
157952
157953
157954
157955
157956
157957
157958
157959
157960
157961
157962
157963
157964
157965
157966
157967
157968
157969
157970
157971
157972
157973
157974
157975
157976
157977
157978
157979
157980
157981
157982
157983
157984
157985
157986
157987
157988
157989
157990
157991
157992
157993
157994
157995
157996
157997
157998
157999
158000
158001
158002
158003
158004
158005
158006
158007
158008
158009
158010
158011
158012
158013
158014
158015
158016
158017
158018
158019
158020
158021
158022
158023
158024
158025
158026
158027
158028
158029
158030
158031
158032
158033
158034
158035
158036
158037
158038
158039
158040
158041
158042
158043
158044
158045
158046
158047
158048
158049
158050
158051
158052
158053
158054
158055
158056
158057
158058
158059
158060
158061
158062
158063
158064
158065
158066
158067
158068
158069
158070
158071
158072
158073
158074
158075
158076
158077
158078
158079
158080
158081
158082
158083
158084
158085
158086
158087
158088
158089
158090
158091
158092
158093
158094
158095
158096
158097
158098
158099
158100
158101
158102
158103
158104
158105
158106
158107
158108
158109
158110
158111
158112
158113
158114
158115
158116
158117
158118
158119
158120
158121
158122
158123
158124
158125
158126
158127
158128
158129
158130
158131
158132
158133
158134
158135
158136
158137
158138
158139
158140
158141
158142
158143
158144
158145
158146
158147
158148
158149
158150
158151
158152
158153
158154
158155
158156
158157
158158
158159
158160
158161
158162
158163
158164
158165
158166
158167
158168
158169
158170
158171
158172
158173
158174
158175
158176
158177
158178
158179
158180
158181
158182
158183
158184
158185
158186
158187
158188
158189
158190
158191
158192
158193
158194
158195
158196
158197
158198
158199
158200
158201
158202
158203
158204
158205
158206
158207
158208
158209
158210
158211
158212
158213
158214
158215
158216
158217
158218
158219
158220
158221
158222
158223
158224
158225
158226
158227
158228
158229
158230
158231
158232
158233
158234
158235
158236
158237
158238
158239
158240
158241
158242
158243
158244
158245
158246
158247
158248
158249
158250
158251
158252
158253
158254
158255
158256
158257
158258
158259
158260
158261
158262
158263
158264
158265
158266
158267
158268
158269
158270
158271
158272
158273
158274
158275
158276
158277
158278
158279
158280
158281
158282
158283
158284
158285
158286
158287
158288
158289
158290
158291
158292
158293
158294
158295
158296
158297
158298
158299
158300
158301
158302
158303
158304
158305
158306
158307
158308
158309
158310
158311
158312
158313
158314
158315
158316
158317
158318
158319
158320
158321
158322
158323
158324
158325
158326
158327
158328
158329
158330
158331
158332
158333
158334
158335
158336
158337
158338
158339
158340
158341
158342
158343
158344
158345
158346
158347
158348
158349
158350
158351
158352
158353
158354
158355
158356
158357
158358
158359
158360
158361
158362
158363
158364
158365
158366
158367
158368
158369
158370
158371
158372
158373
158374
158375
158376
158377
158378
158379
158380
158381
158382
158383
158384
158385
158386
158387
158388
158389
158390
158391
158392
158393
158394
158395
158396
158397
158398
158399
158400
158401
158402
158403
158404
158405
158406
158407
158408
158409
158410
158411
158412
158413
158414
158415
158416
158417
158418
158419
158420
158421
158422
158423
158424
158425
158426
158427
158428
158429
158430
158431
158432
158433
158434
158435
158436
158437
158438
158439
158440
158441
158442
158443
158444
158445
158446
158447
158448
158449
158450
158451
158452
158453
158454
158455
158456
158457
158458
158459
158460
158461
158462
158463
158464
158465
158466
158467
158468
158469
158470
158471
158472
158473
158474
158475
158476
158477
158478
158479
158480
158481
158482
158483
158484
158485
158486
158487
158488
158489
158490
158491
158492
158493
158494
158495
158496
158497
158498
158499
158500
158501
158502
158503
158504
158505
158506
158507
158508
158509
158510
158511
158512
158513
158514
158515
158516
158517
158518
158519
158520
158521
158522
158523
158524
158525
158526
158527
158528
158529
158530
158531
158532
158533
158534
158535
158536
158537
158538
158539
158540
158541
158542
158543
158544
158545
158546
158547
158548
158549
158550
158551
158552
158553
158554
158555
158556
158557
158558
158559
158560
158561
158562
158563
158564
158565
158566
158567
158568
158569
158570
158571
158572
158573
158574
158575
158576
158577
158578
158579
158580
158581
158582
158583
158584
158585
158586
158587
158588
158589
158590
158591
158592
158593
158594
158595
158596
158597
158598
158599
158600
158601
158602
158603
158604
158605
158606
158607
158608
158609
158610
158611
158612
158613
158614
158615
158616
158617
158618
158619
158620
158621
158622
158623
158624
158625
158626
158627
158628
158629
158630
158631
158632
158633
158634
158635
158636
158637
158638
158639
158640
158641
158642
158643
158644
158645
158646
158647
158648
158649
158650
158651
158652
158653
158654
158655
158656
158657
158658
158659
158660
158661
158662
158663
158664
158665
158666
158667
158668
158669
158670
158671
158672
158673
158674
158675
158676
158677
158678
158679
158680
158681
158682
158683
158684
158685
158686
158687
158688
158689
158690
158691
158692
158693
158694
158695
158696
158697
158698
158699
158700
158701
158702
158703
158704
158705
158706
158707
158708
158709
158710
158711
158712
158713
158714
158715
158716
158717
158718
158719
158720
158721
158722
158723
158724
158725
158726
158727
158728
158729
158730
158731
158732
158733
158734
158735
158736
158737
158738
158739
158740
158741
158742
158743
158744
158745
158746
158747
158748
158749
158750
158751
158752
158753
158754
158755
158756
158757
158758
158759
158760
158761
158762
158763
158764
158765
158766
158767
158768
158769
158770
158771
158772
158773
158774
158775
158776
158777
158778
158779
158780
158781
158782
158783
158784
158785
158786
158787
158788
158789
158790
158791
158792
158793
158794
158795
158796
158797
158798
158799
158800
158801
158802
158803
158804
158805
158806
158807
158808
158809
158810
158811
158812
158813
158814
158815
158816
158817
158818
158819
158820
158821
158822
158823
158824
158825
158826
158827
158828
158829
158830
158831
158832
158833
158834
158835
158836
158837
158838
158839
158840
158841
158842
158843
158844
158845
158846
158847
158848
158849
158850
158851
158852
158853
158854
158855
158856
158857
158858
158859
158860
158861
158862
158863
158864
158865
158866
158867
158868
158869
158870
158871
158872
158873
158874
158875
158876
158877
158878
158879
158880
158881
158882
158883
158884
158885
158886
158887
158888
158889
158890
158891
158892
158893
158894
158895
158896
158897
158898
158899
158900
158901
158902
158903
158904
158905
158906
158907
158908
158909
158910
158911
158912
158913
158914
158915
158916
158917
158918
158919
158920
158921
158922
158923
158924
158925
158926
158927
158928
158929
158930
158931
158932
158933
158934
158935
158936
158937
158938
158939
158940
158941
158942
158943
158944
158945
158946
158947
158948
158949
158950
158951
158952
158953
158954
158955
158956
158957
158958
158959
158960
158961
158962
158963
158964
158965
158966
158967
158968
158969
158970
158971
158972
158973
158974
158975
158976
158977
158978
158979
158980
158981
158982
158983
158984
158985
158986
158987
158988
158989
158990
158991
158992
158993
158994
158995
158996
158997
158998
158999
159000
159001
159002
159003
159004
159005
159006
159007
159008
159009
159010
159011
159012
159013
159014
159015
159016
159017
159018
159019
159020
159021
159022
159023
159024
159025
159026
159027
159028
159029
159030
159031
159032
159033
159034
159035
159036
159037
159038
159039
159040
159041
159042
159043
159044
159045
159046
159047
159048
159049
159050
159051
159052
159053
159054
159055
159056
159057
159058
159059
159060
159061
159062
159063
159064
159065
159066
159067
159068
159069
159070
159071
159072
159073
159074
159075
159076
159077
159078
159079
159080
159081
159082
159083
159084
159085
159086
159087
159088
159089
159090
159091
159092
159093
159094
159095
159096
159097
159098
159099
159100
159101
159102
159103
159104
159105
159106
159107
159108
159109
159110
159111
159112
159113
159114
159115
159116
159117
159118
159119
159120
159121
159122
159123
159124
159125
159126
159127
159128
159129
159130
159131
159132
159133
159134
159135
159136
159137
159138
159139
159140
159141
159142
159143
159144
159145
159146
159147
159148
159149
159150
159151
159152
159153
159154
159155
159156
159157
159158
159159
159160
159161
159162
159163
159164
159165
159166
159167
159168
159169
159170
159171
159172
159173
159174
159175
159176
159177
159178
159179
159180
159181
159182
159183
159184
159185
159186
159187
159188
159189
159190
159191
159192
159193
159194
159195
159196
159197
159198
159199
159200
159201
159202
159203
159204
159205
159206
159207
159208
159209
159210
159211
159212
159213
159214
159215
159216
159217
159218
159219
159220
159221
159222
159223
159224
159225
159226
159227
159228
159229
159230
159231
159232
159233
159234
159235
159236
159237
159238
159239
159240
159241
159242
159243
159244
159245
159246
159247
159248
159249
159250
159251
159252
159253
159254
159255
159256
159257
159258
159259
159260
159261
159262
159263
159264
159265
159266
159267
159268
159269
159270
159271
159272
159273
159274
159275
159276
159277
159278
159279
159280
159281
159282
159283
159284
159285
159286
159287
159288
159289
159290
159291
159292
159293
159294
159295
159296
159297
159298
159299
159300
159301
159302
159303
159304
159305
159306
159307
159308
159309
159310
159311
159312
159313
159314
159315
159316
159317
159318
159319
159320
159321
159322
159323
159324
159325
159326
159327
159328
159329
159330
159331
159332
159333
159334
159335
159336
159337
159338
159339
159340
159341
159342
159343
159344
159345
159346
159347
159348
159349
159350
159351
159352
159353
159354
159355
159356
159357
159358
159359
159360
159361
159362
159363
159364
159365
159366
159367
159368
159369
159370
159371
159372
159373
159374
159375
159376
159377
159378
159379
159380
159381
159382
159383
159384
159385
159386
159387
159388
159389
159390
159391
159392
159393
159394
159395
159396
159397
159398
159399
159400
159401
159402
159403
159404
159405
159406
159407
159408
159409
159410
159411
159412
159413
159414
159415
159416
159417
159418
159419
159420
159421
159422
159423
159424
159425
159426
159427
159428
159429
159430
159431
159432
159433
159434
159435
159436
159437
159438
159439
159440
159441
159442
159443
159444
159445
159446
159447
159448
159449
159450
159451
159452
159453
159454
159455
159456
159457
159458
159459
159460
159461
159462
159463
159464
159465
159466
159467
159468
159469
159470
159471
159472
159473
159474
159475
159476
159477
159478
159479
159480
159481
159482
159483
159484
159485
159486
159487
159488
159489
159490
159491
159492
159493
159494
159495
159496
159497
159498
159499
159500
159501
159502
159503
159504
159505
159506
159507
159508
159509
159510
159511
159512
159513
159514
159515
159516
159517
159518
159519
159520
159521
159522
159523
159524
159525
159526
159527
159528
159529
159530
159531
159532
159533
159534
159535
159536
159537
159538
159539
159540
159541
159542
159543
159544
159545
159546
159547
159548
159549
159550
159551
159552
159553
159554
159555
159556
159557
159558
159559
159560
159561
159562
159563
159564
159565
159566
159567
159568
159569
159570
159571
159572
159573
159574
159575
159576
159577
159578
159579
159580
159581
159582
159583
159584
159585
159586
159587
159588
159589
159590
159591
159592
159593
159594
159595
159596
159597
159598
159599
159600
159601
159602
159603
159604
159605
159606
159607
159608
159609
159610
159611
159612
159613
159614
159615
159616
159617
159618
159619
159620
159621
159622
159623
159624
159625
159626
159627
159628
159629
159630
159631
159632
159633
159634
159635
159636
159637
159638
159639
159640
159641
159642
159643
159644
159645
159646
159647
159648
159649
159650
159651
159652
159653
159654
159655
159656
159657
159658
159659
159660
159661
159662
159663
159664
159665
159666
159667
159668
159669
159670
159671
159672
159673
159674
159675
159676
159677
159678
159679
159680
159681
159682
159683
159684
159685
159686
159687
159688
159689
159690
159691
159692
159693
159694
159695
159696
159697
159698
159699
159700
159701
159702
159703
159704
159705
159706
159707
159708
159709
159710
159711
159712
159713
159714
159715
159716
159717
159718
159719
159720
159721
159722
159723
159724
159725
159726
159727
159728
159729
159730
159731
159732
159733
159734
159735
159736
159737
159738
159739
159740
159741
159742
159743
159744
159745
159746
159747
159748
159749
159750
159751
159752
159753
159754
159755
159756
159757
159758
159759
159760
159761
159762
159763
159764
159765
159766
159767
159768
159769
159770
159771
159772
159773
159774
159775
159776
159777
159778
159779
159780
159781
159782
159783
159784
159785
159786
159787
159788
159789
159790
159791
159792
159793
159794
159795
159796
159797
159798
159799
159800
159801
159802
159803
159804
159805
159806
159807
159808
159809
159810
159811
159812
159813
159814
159815
159816
159817
159818
159819
159820
159821
159822
159823
159824
159825
159826
159827
159828
159829
159830
159831
159832
159833
159834
159835
159836
159837
159838
159839
159840
159841
159842
159843
159844
159845
159846
159847
159848
159849
159850
159851
159852
159853
159854
159855
159856
159857
159858
159859
159860
159861
159862
159863
159864
159865
159866
159867
159868
159869
159870
159871
159872
159873
159874
159875
159876
159877
159878
159879
159880
159881
159882
159883
159884
159885
159886
159887
159888
159889
159890
159891
159892
159893
159894
159895
159896
159897
159898
159899
159900
159901
159902
159903
159904
159905
159906
159907
159908
159909
159910
159911
159912
159913
159914
159915
159916
159917
159918
159919
159920
159921
159922
159923
159924
159925
159926
159927
159928
159929
159930
159931
159932
159933
159934
159935
159936
159937
159938
159939
159940
159941
159942
159943
159944
159945
159946
159947
159948
159949
159950
159951
159952
159953
159954
159955
159956
159957
159958
159959
159960
159961
159962
159963
159964
159965
159966
159967
159968
159969
159970
159971
159972
159973
159974
159975
159976
159977
159978
159979
159980
159981
159982
159983
159984
159985
159986
159987
159988
159989
159990
159991
159992
159993
159994
159995
159996
159997
159998
159999
160000
160001
160002
160003
160004
160005
160006
160007
160008
160009
160010
160011
160012
160013
160014
160015
160016
160017
160018
160019
160020
160021
160022
160023
160024
160025
160026
160027
160028
160029
160030
160031
160032
160033
160034
160035
160036
160037
160038
160039
160040
160041
160042
160043
160044
160045
160046
160047
160048
160049
160050
160051
160052
160053
160054
160055
160056
160057
160058
160059
160060
160061
160062
160063
160064
160065
160066
160067
160068
160069
160070
160071
160072
160073
160074
160075
160076
160077
160078
160079
160080
160081
160082
160083
160084
160085
160086
160087
160088
160089
160090
160091
160092
160093
160094
160095
160096
160097
160098
160099
160100
160101
160102
160103
160104
160105
160106
160107
160108
160109
160110
160111
160112
160113
160114
160115
160116
160117
160118
160119
160120
160121
160122
160123
160124
160125
160126
160127
160128
160129
160130
160131
160132
160133
160134
160135
160136
160137
160138
160139
160140
160141
160142
160143
160144
160145
160146
160147
160148
160149
160150
160151
160152
160153
160154
160155
160156
160157
160158
160159
160160
160161
160162
160163
160164
160165
160166
160167
160168
160169
160170
160171
160172
160173
160174
160175
160176
160177
160178
160179
160180
160181
160182
160183
160184
160185
160186
160187
160188
160189
160190
160191
160192
160193
160194
160195
160196
160197
160198
160199
160200
160201
160202
160203
160204
160205
160206
160207
160208
160209
160210
160211
160212
160213
160214
160215
160216
160217
160218
160219
160220
160221
160222
160223
160224
160225
160226
160227
160228
160229
160230
160231
160232
160233
160234
160235
160236
160237
160238
160239
160240
160241
160242
160243
160244
160245
160246
160247
160248
160249
160250
160251
160252
160253
160254
160255
160256
160257
160258
160259
160260
160261
160262
160263
160264
160265
160266
160267
160268
160269
160270
160271
160272
160273
160274
160275
160276
160277
160278
160279
160280
160281
160282
160283
160284
160285
160286
160287
160288
160289
160290
160291
160292
160293
160294
160295
160296
160297
160298
160299
160300
160301
160302
160303
160304
160305
160306
160307
160308
160309
160310
160311
160312
160313
160314
160315
160316
160317
160318
160319
160320
160321
160322
160323
160324
160325
160326
160327
160328
160329
160330
160331
160332
160333
160334
160335
160336
160337
160338
160339
160340
160341
160342
160343
160344
160345
160346
160347
160348
160349
160350
160351
160352
160353
160354
160355
160356
160357
160358
160359
160360
160361
160362
160363
160364
160365
160366
160367
160368
160369
160370
160371
160372
160373
160374
160375
160376
160377
160378
160379
160380
160381
160382
160383
160384
160385
160386
160387
160388
160389
160390
160391
160392
160393
160394
160395
160396
160397
160398
160399
160400
160401
160402
160403
160404
160405
160406
160407
160408
160409
160410
160411
160412
160413
160414
160415
160416
160417
160418
160419
160420
160421
160422
160423
160424
160425
160426
160427
160428
160429
160430
160431
160432
160433
160434
160435
160436
160437
160438
160439
160440
160441
160442
160443
160444
160445
160446
160447
160448
160449
160450
160451
160452
160453
160454
160455
160456
160457
160458
160459
160460
160461
160462
160463
160464
160465
160466
160467
160468
160469
160470
160471
160472
160473
160474
160475
160476
160477
160478
160479
160480
160481
160482
160483
160484
160485
160486
160487
160488
160489
160490
160491
160492
160493
160494
160495
160496
160497
160498
160499
160500
160501
160502
160503
160504
160505
160506
160507
160508
160509
160510
160511
160512
160513
160514
160515
160516
160517
160518
160519
160520
160521
160522
160523
160524
160525
160526
160527
160528
160529
160530
160531
160532
160533
160534
160535
160536
160537
160538
160539
160540
160541
160542
160543
160544
160545
160546
160547
160548
160549
160550
160551
160552
160553
160554
160555
160556
160557
160558
160559
160560
160561
160562
160563
160564
160565
160566
160567
160568
160569
160570
160571
160572
160573
160574
160575
160576
160577
160578
160579
160580
160581
160582
160583
160584
160585
160586
160587
160588
160589
160590
160591
160592
160593
160594
160595
160596
160597
160598
160599
160600
160601
160602
160603
160604
160605
160606
160607
160608
160609
160610
160611
160612
160613
160614
160615
160616
160617
160618
160619
160620
160621
160622
160623
160624
160625
160626
160627
160628
160629
160630
160631
160632
160633
160634
160635
160636
160637
160638
160639
160640
160641
160642
160643
160644
160645
160646
160647
160648
160649
160650
160651
160652
160653
160654
160655
160656
160657
160658
160659
160660
160661
160662
160663
160664
160665
160666
160667
160668
160669
160670
160671
160672
160673
160674
160675
160676
160677
160678
160679
160680
160681
160682
160683
160684
160685
160686
160687
160688
160689
160690
160691
160692
160693
160694
160695
160696
160697
160698
160699
160700
160701
160702
160703
160704
160705
160706
160707
160708
160709
160710
160711
160712
160713
160714
160715
160716
160717
160718
160719
160720
160721
160722
160723
160724
160725
160726
160727
160728
160729
160730
160731
160732
160733
160734
160735
160736
160737
160738
160739
160740
160741
160742
160743
160744
160745
160746
160747
160748
160749
160750
160751
160752
160753
160754
160755
160756
160757
160758
160759
160760
160761
160762
160763
160764
160765
160766
160767
160768
160769
160770
160771
160772
160773
160774
160775
160776
160777
160778
160779
160780
160781
160782
160783
160784
160785
160786
160787
160788
160789
160790
160791
160792
160793
160794
160795
160796
160797
160798
160799
160800
160801
160802
160803
160804
160805
160806
160807
160808
160809
160810
160811
160812
160813
160814
160815
160816
160817
160818
160819
160820
160821
160822
160823
160824
160825
160826
160827
160828
160829
160830
160831
160832
160833
160834
160835
160836
160837
160838
160839
160840
160841
160842
160843
160844
160845
160846
160847
160848
160849
160850
160851
160852
160853
160854
160855
160856
160857
160858
160859
160860
160861
160862
160863
160864
160865
160866
160867
160868
160869
160870
160871
160872
160873
160874
160875
160876
160877
160878
160879
160880
160881
160882
160883
160884
160885
160886
160887
160888
160889
160890
160891
160892
160893
160894
160895
160896
160897
160898
160899
160900
160901
160902
160903
160904
160905
160906
160907
160908
160909
160910
160911
160912
160913
160914
160915
160916
160917
160918
160919
160920
160921
160922
160923
160924
160925
160926
160927
160928
160929
160930
160931
160932
160933
160934
160935
160936
160937
160938
160939
160940
160941
160942
160943
160944
160945
160946
160947
160948
160949
160950
160951
160952
160953
160954
160955
160956
160957
160958
160959
160960
160961
160962
160963
160964
160965
160966
160967
160968
160969
160970
160971
160972
160973
160974
160975
160976
160977
160978
160979
160980
160981
160982
160983
160984
160985
160986
160987
160988
160989
160990
160991
160992
160993
160994
160995
160996
160997
160998
160999
161000
161001
161002
161003
161004
161005
161006
161007
161008
161009
161010
161011
161012
161013
161014
161015
161016
161017
161018
161019
161020
161021
161022
161023
161024
161025
161026
161027
161028
161029
161030
161031
161032
161033
161034
161035
161036
161037
161038
161039
161040
161041
161042
161043
161044
161045
161046
161047
161048
161049
161050
161051
161052
161053
161054
161055
161056
161057
161058
161059
161060
161061
161062
161063
161064
161065
161066
161067
161068
161069
161070
161071
161072
161073
161074
161075
161076
161077
161078
161079
161080
161081
161082
161083
161084
161085
161086
161087
161088
161089
161090
161091
161092
161093
161094
161095
161096
161097
161098
161099
161100
161101
161102
161103
161104
161105
161106
161107
161108
161109
161110
161111
161112
161113
161114
161115
161116
161117
161118
161119
161120
161121
161122
161123
161124
161125
161126
161127
161128
161129
161130
161131
161132
161133
161134
161135
161136
161137
161138
161139
161140
161141
161142
161143
161144
161145
161146
161147
161148
161149
161150
161151
161152
161153
161154
161155
161156
161157
161158
161159
161160
161161
161162
161163
161164
161165
161166
161167
161168
161169
161170
161171
161172
161173
161174
161175
161176
161177
161178
161179
161180
161181
161182
161183
161184
161185
161186
161187
161188
161189
161190
161191
161192
161193
161194
161195
161196
161197
161198
161199
161200
161201
161202
161203
161204
161205
161206
161207
161208
161209
161210
161211
161212
161213
161214
161215
161216
161217
161218
161219
161220
161221
161222
161223
161224
161225
161226
161227
161228
161229
161230
161231
161232
161233
161234
161235
161236
161237
161238
161239
161240
161241
161242
161243
161244
161245
161246
161247
161248
161249
161250
161251
161252
161253
161254
161255
161256
161257
161258
161259
161260
161261
161262
161263
161264
161265
161266
161267
161268
161269
161270
161271
161272
161273
161274
161275
161276
161277
161278
161279
161280
161281
161282
161283
161284
161285
161286
161287
161288
161289
161290
161291
161292
161293
161294
161295
161296
161297
161298
161299
161300
161301
161302
161303
161304
161305
161306
161307
161308
161309
161310
161311
161312
161313
161314
161315
161316
161317
161318
161319
161320
161321
161322
161323
161324
161325
161326
161327
161328
161329
161330
161331
161332
161333
161334
161335
161336
161337
161338
161339
161340
161341
161342
161343
161344
161345
161346
161347
161348
161349
161350
161351
161352
161353
161354
161355
161356
161357
161358
161359
161360
161361
161362
161363
161364
161365
161366
161367
161368
161369
161370
161371
161372
161373
161374
161375
161376
161377
161378
161379
161380
161381
161382
161383
161384
161385
161386
161387
161388
161389
161390
161391
161392
161393
161394
161395
161396
161397
161398
161399
161400
161401
161402
161403
161404
161405
161406
161407
161408
161409
161410
161411
161412
161413
161414
161415
161416
161417
161418
161419
161420
161421
161422
161423
161424
161425
161426
161427
161428
161429
161430
161431
161432
161433
161434
161435
161436
161437
161438
161439
161440
161441
161442
161443
161444
161445
161446
161447
161448
161449
161450
161451
161452
161453
161454
161455
161456
161457
161458
161459
161460
161461
161462
161463
161464
161465
161466
161467
161468
161469
161470
161471
161472
161473
161474
161475
161476
161477
161478
161479
161480
161481
161482
161483
161484
161485
161486
161487
161488
161489
161490
161491
161492
161493
161494
161495
161496
161497
161498
161499
161500
161501
161502
161503
161504
161505
161506
161507
161508
161509
161510
161511
161512
161513
161514
161515
161516
161517
161518
161519
161520
161521
161522
161523
161524
161525
161526
161527
161528
161529
161530
161531
161532
161533
161534
161535
161536
161537
161538
161539
161540
161541
161542
161543
161544
161545
161546
161547
161548
161549
161550
161551
161552
161553
161554
161555
161556
161557
161558
161559
161560
161561
161562
161563
161564
161565
161566
161567
161568
161569
161570
161571
161572
161573
161574
161575
161576
161577
161578
161579
161580
161581
161582
161583
161584
161585
161586
161587
161588
161589
161590
161591
161592
161593
161594
161595
161596
161597
161598
161599
161600
161601
161602
161603
161604
161605
161606
161607
161608
161609
161610
161611
161612
161613
161614
161615
161616
161617
161618
161619
161620
161621
161622
161623
161624
161625
161626
161627
161628
161629
161630
161631
161632
161633
161634
161635
161636
161637
161638
161639
161640
161641
161642
161643
161644
161645
161646
161647
161648
161649
161650
161651
161652
161653
161654
161655
161656
161657
161658
161659
161660
161661
161662
161663
161664
161665
161666
161667
161668
161669
161670
161671
161672
161673
161674
161675
161676
161677
161678
161679
161680
161681
161682
161683
161684
161685
161686
161687
161688
161689
161690
161691
161692
161693
161694
161695
161696
161697
161698
161699
161700
161701
161702
161703
161704
161705
161706
161707
161708
161709
161710
161711
161712
161713
161714
161715
161716
161717
161718
161719
161720
161721
161722
161723
161724
161725
161726
161727
161728
161729
161730
161731
161732
161733
161734
161735
161736
161737
161738
161739
161740
161741
161742
161743
161744
161745
161746
161747
161748
161749
161750
161751
161752
161753
161754
161755
161756
161757
161758
161759
161760
161761
161762
161763
161764
161765
161766
161767
161768
161769
161770
161771
161772
161773
161774
161775
161776
161777
161778
161779
161780
161781
161782
161783
161784
161785
161786
161787
161788
161789
161790
161791
161792
161793
161794
161795
161796
161797
161798
161799
161800
161801
161802
161803
161804
161805
161806
161807
161808
161809
161810
161811
161812
161813
161814
161815
161816
161817
161818
161819
161820
161821
161822
161823
161824
161825
161826
161827
161828
161829
161830
161831
161832
161833
161834
161835
161836
161837
161838
161839
161840
161841
161842
161843
161844
161845
161846
161847
161848
161849
161850
161851
161852
161853
161854
161855
161856
161857
161858
161859
161860
161861
161862
161863
161864
161865
161866
161867
161868
161869
161870
161871
161872
161873
161874
161875
161876
161877
161878
161879
161880
161881
161882
161883
161884
161885
161886
161887
161888
161889
161890
161891
161892
161893
161894
161895
161896
161897
161898
161899
161900
161901
161902
161903
161904
161905
161906
161907
161908
161909
161910
161911
161912
161913
161914
161915
161916
161917
161918
161919
161920
161921
161922
161923
161924
161925
161926
161927
161928
161929
161930
161931
161932
161933
161934
161935
161936
161937
161938
161939
161940
161941
161942
161943
161944
161945
161946
161947
161948
161949
161950
161951
161952
161953
161954
161955
161956
161957
161958
161959
161960
161961
161962
161963
161964
161965
161966
161967
161968
161969
161970
161971
161972
161973
161974
161975
161976
161977
161978
161979
161980
161981
161982
161983
161984
161985
161986
161987
161988
161989
161990
161991
161992
161993
161994
161995
161996
161997
161998
161999
162000
162001
162002
162003
162004
162005
162006
162007
162008
162009
162010
162011
162012
162013
162014
162015
162016
162017
162018
162019
162020
162021
162022
162023
162024
162025
162026
162027
162028
162029
162030
162031
162032
162033
162034
162035
162036
162037
162038
162039
162040
162041
162042
162043
162044
162045
162046
162047
162048
162049
162050
162051
162052
162053
162054
162055
162056
162057
162058
162059
162060
162061
162062
162063
162064
162065
162066
162067
162068
162069
162070
162071
162072
162073
162074
162075
162076
162077
162078
162079
162080
162081
162082
162083
162084
162085
162086
162087
162088
162089
162090
162091
162092
162093
162094
162095
162096
162097
162098
162099
162100
162101
162102
162103
162104
162105
162106
162107
162108
162109
162110
162111
162112
162113
162114
162115
162116
162117
162118
162119
162120
162121
162122
162123
162124
162125
162126
162127
162128
162129
162130
162131
162132
162133
162134
162135
162136
162137
162138
162139
162140
162141
162142
162143
162144
162145
162146
162147
162148
162149
162150
162151
162152
162153
162154
162155
162156
162157
162158
162159
162160
162161
162162
162163
162164
162165
162166
162167
162168
162169
162170
162171
162172
162173
162174
162175
162176
162177
162178
162179
162180
162181
162182
162183
162184
162185
162186
162187
162188
162189
162190
162191
162192
162193
162194
162195
162196
162197
162198
162199
162200
162201
162202
162203
162204
162205
162206
162207
162208
162209
162210
162211
162212
162213
162214
162215
162216
162217
162218
162219
162220
162221
162222
162223
162224
162225
162226
162227
162228
162229
162230
162231
162232
162233
162234
162235
162236
162237
162238
162239
162240
162241
162242
162243
162244
162245
162246
162247
162248
162249
162250
162251
162252
162253
162254
162255
162256
162257
162258
162259
162260
162261
162262
162263
162264
162265
162266
162267
162268
162269
162270
162271
162272
162273
162274
162275
162276
162277
162278
162279
162280
162281
162282
162283
162284
162285
162286
162287
162288
162289
162290
162291
162292
162293
162294
162295
162296
162297
162298
162299
162300
162301
162302
162303
162304
162305
162306
162307
162308
162309
162310
162311
162312
162313
162314
162315
162316
162317
162318
162319
162320
162321
162322
162323
162324
162325
162326
162327
162328
162329
162330
162331
162332
162333
162334
162335
162336
162337
162338
162339
162340
162341
162342
162343
162344
162345
162346
162347
162348
162349
162350
162351
162352
162353
162354
162355
162356
162357
162358
162359
162360
162361
162362
162363
162364
162365
162366
162367
162368
162369
162370
162371
162372
162373
162374
162375
162376
162377
162378
162379
162380
162381
162382
162383
162384
162385
162386
162387
162388
162389
162390
162391
162392
162393
162394
162395
162396
162397
162398
162399
162400
162401
162402
162403
162404
162405
162406
162407
162408
162409
162410
162411
162412
162413
162414
162415
162416
162417
162418
162419
162420
162421
162422
162423
162424
162425
162426
162427
162428
162429
162430
162431
162432
162433
162434
162435
162436
162437
162438
162439
162440
162441
162442
162443
162444
162445
162446
162447
162448
162449
162450
162451
162452
162453
162454
162455
162456
162457
162458
162459
162460
162461
162462
162463
162464
162465
162466
162467
162468
162469
162470
162471
162472
162473
162474
162475
162476
162477
162478
162479
162480
162481
162482
162483
162484
162485
162486
162487
162488
162489
162490
162491
162492
162493
162494
162495
162496
162497
162498
162499
162500
162501
162502
162503
162504
162505
162506
162507
162508
162509
162510
162511
162512
162513
162514
162515
162516
162517
162518
162519
162520
162521
162522
162523
162524
162525
162526
162527
162528
162529
162530
162531
162532
162533
162534
162535
162536
162537
162538
162539
162540
162541
162542
162543
162544
162545
162546
162547
162548
162549
162550
162551
162552
162553
162554
162555
162556
162557
162558
162559
162560
162561
162562
162563
162564
162565
162566
162567
162568
162569
162570
162571
162572
162573
162574
162575
162576
162577
162578
162579
162580
162581
162582
162583
162584
162585
162586
162587
162588
162589
162590
162591
162592
162593
162594
162595
162596
162597
162598
162599
162600
162601
162602
162603
162604
162605
162606
162607
162608
162609
162610
162611
162612
162613
162614
162615
162616
162617
162618
162619
162620
162621
162622
162623
162624
162625
162626
162627
162628
162629
162630
162631
162632
162633
162634
162635
162636
162637
162638
162639
162640
162641
162642
162643
162644
162645
162646
162647
162648
162649
162650
162651
162652
162653
162654
162655
162656
162657
162658
162659
162660
162661
162662
162663
162664
162665
162666
162667
162668
162669
162670
162671
162672
162673
162674
162675
162676
162677
162678
162679
162680
162681
162682
162683
162684
162685
162686
162687
162688
162689
162690
162691
162692
162693
162694
162695
162696
162697
162698
162699
162700
162701
162702
162703
162704
162705
162706
162707
162708
162709
162710
162711
162712
162713
162714
162715
162716
162717
162718
162719
162720
162721
162722
162723
162724
162725
162726
162727
162728
162729
162730
162731
162732
162733
162734
162735
162736
162737
162738
162739
162740
162741
162742
162743
162744
162745
162746
162747
162748
162749
162750
162751
162752
162753
162754
162755
162756
162757
162758
162759
162760
162761
162762
162763
162764
162765
162766
162767
162768
162769
162770
162771
162772
162773
162774
162775
162776
162777
162778
162779
162780
162781
162782
162783
162784
162785
162786
162787
162788
162789
162790
162791
162792
162793
162794
162795
162796
162797
162798
162799
162800
162801
162802
162803
162804
162805
162806
162807
162808
162809
162810
162811
162812
162813
162814
162815
162816
162817
162818
162819
162820
162821
162822
162823
162824
162825
162826
162827
162828
162829
162830
162831
162832
162833
162834
162835
162836
162837
162838
162839
162840
162841
162842
162843
162844
162845
162846
162847
162848
162849
162850
162851
162852
162853
162854
162855
162856
162857
162858
162859
162860
162861
162862
162863
162864
162865
162866
162867
162868
162869
162870
162871
162872
162873
162874
162875
162876
162877
162878
162879
162880
162881
162882
162883
162884
162885
162886
162887
162888
162889
162890
162891
162892
162893
162894
162895
162896
162897
162898
162899
162900
162901
162902
162903
162904
162905
162906
162907
162908
162909
162910
162911
162912
162913
162914
162915
162916
162917
162918
162919
162920
162921
162922
162923
162924
162925
162926
162927
162928
162929
162930
162931
162932
162933
162934
162935
162936
162937
162938
162939
162940
162941
162942
162943
162944
162945
162946
162947
162948
162949
162950
162951
162952
162953
162954
162955
162956
162957
162958
162959
162960
162961
162962
162963
162964
162965
162966
162967
162968
162969
162970
162971
162972
162973
162974
162975
162976
162977
162978
162979
162980
162981
162982
162983
162984
162985
162986
162987
162988
162989
162990
162991
162992
162993
162994
162995
162996
162997
162998
162999
163000
163001
163002
163003
163004
163005
163006
163007
163008
163009
163010
163011
163012
163013
163014
163015
163016
163017
163018
163019
163020
163021
163022
163023
163024
163025
163026
163027
163028
163029
163030
163031
163032
163033
163034
163035
163036
163037
163038
163039
163040
163041
163042
163043
163044
163045
163046
163047
163048
163049
163050
163051
163052
163053
163054
163055
163056
163057
163058
163059
163060
163061
163062
163063
163064
163065
163066
163067
163068
163069
163070
163071
163072
163073
163074
163075
163076
163077
163078
163079
163080
163081
163082
163083
163084
163085
163086
163087
163088
163089
163090
163091
163092
163093
163094
163095
163096
163097
163098
163099
163100
163101
163102
163103
163104
163105
163106
163107
163108
163109
163110
163111
163112
163113
163114
163115
163116
163117
163118
163119
163120
163121
163122
163123
163124
163125
163126
163127
163128
163129
163130
163131
163132
163133
163134
163135
163136
163137
163138
163139
163140
163141
163142
163143
163144
163145
163146
163147
163148
163149
163150
163151
163152
163153
163154
163155
163156
163157
163158
163159
163160
163161
163162
163163
163164
163165
163166
163167
163168
163169
163170
163171
163172
163173
163174
163175
163176
163177
163178
163179
163180
163181
163182
163183
163184
163185
163186
163187
163188
163189
163190
163191
163192
163193
163194
163195
163196
163197
163198
163199
163200
163201
163202
163203
163204
163205
163206
163207
163208
163209
163210
163211
163212
163213
163214
163215
163216
163217
163218
163219
163220
163221
163222
163223
163224
163225
163226
163227
163228
163229
163230
163231
163232
163233
163234
163235
163236
163237
163238
163239
163240
163241
163242
163243
163244
163245
163246
163247
163248
163249
163250
163251
163252
163253
163254
163255
163256
163257
163258
163259
163260
163261
163262
163263
163264
163265
163266
163267
163268
163269
163270
163271
163272
163273
163274
163275
163276
163277
163278
163279
163280
163281
163282
163283
163284
163285
163286
163287
163288
163289
163290
163291
163292
163293
163294
163295
163296
163297
163298
163299
163300
163301
163302
163303
163304
163305
163306
163307
163308
163309
163310
163311
163312
163313
163314
163315
163316
163317
163318
163319
163320
163321
163322
163323
163324
163325
163326
163327
163328
163329
163330
163331
163332
163333
163334
163335
163336
163337
163338
163339
163340
163341
163342
163343
163344
163345
163346
163347
163348
163349
163350
163351
163352
163353
163354
163355
163356
163357
163358
163359
163360
163361
163362
163363
163364
163365
163366
163367
163368
163369
163370
163371
163372
163373
163374
163375
163376
163377
163378
163379
163380
163381
163382
163383
163384
163385
163386
163387
163388
163389
163390
163391
163392
163393
163394
163395
163396
163397
163398
163399
163400
163401
163402
163403
163404
163405
163406
163407
163408
163409
163410
163411
163412
163413
163414
163415
163416
163417
163418
163419
163420
163421
163422
163423
163424
163425
163426
163427
163428
163429
163430
163431
163432
163433
163434
163435
163436
163437
163438
163439
163440
163441
163442
163443
163444
163445
163446
163447
163448
163449
163450
163451
163452
163453
163454
163455
163456
163457
163458
163459
163460
163461
163462
163463
163464
163465
163466
163467
163468
163469
163470
163471
163472
163473
163474
163475
163476
163477
163478
163479
163480
163481
163482
163483
163484
163485
163486
163487
163488
163489
163490
163491
163492
163493
163494
163495
163496
163497
163498
163499
163500
163501
163502
163503
163504
163505
163506
163507
163508
163509
163510
163511
163512
163513
163514
163515
163516
163517
163518
163519
163520
163521
163522
163523
163524
163525
163526
163527
163528
163529
163530
163531
163532
163533
163534
163535
163536
163537
163538
163539
163540
163541
163542
163543
163544
163545
163546
163547
163548
163549
163550
163551
163552
163553
163554
163555
163556
163557
163558
163559
163560
163561
163562
163563
163564
163565
163566
163567
163568
163569
163570
163571
163572
163573
163574
163575
163576
163577
163578
163579
163580
163581
163582
163583
163584
163585
163586
163587
163588
163589
163590
163591
163592
163593
163594
163595
163596
163597
163598
163599
163600
163601
163602
163603
163604
163605
163606
163607
163608
163609
163610
163611
163612
163613
163614
163615
163616
163617
163618
163619
163620
163621
163622
163623
163624
163625
163626
163627
163628
163629
163630
163631
163632
163633
163634
163635
163636
163637
163638
163639
163640
163641
163642
163643
163644
163645
163646
163647
163648
163649
163650
163651
163652
163653
163654
163655
163656
163657
163658
163659
163660
163661
163662
163663
163664
163665
163666
163667
163668
163669
163670
163671
163672
163673
163674
163675
163676
163677
163678
163679
163680
163681
163682
163683
163684
163685
163686
163687
163688
163689
163690
163691
163692
163693
163694
163695
163696
163697
163698
163699
163700
163701
163702
163703
163704
163705
163706
163707
163708
163709
163710
163711
163712
163713
163714
163715
163716
163717
163718
163719
163720
163721
163722
163723
163724
163725
163726
163727
163728
163729
163730
163731
163732
163733
163734
163735
163736
163737
163738
163739
163740
163741
163742
163743
163744
163745
163746
163747
163748
163749
163750
163751
163752
163753
163754
163755
163756
163757
163758
163759
163760
163761
163762
163763
163764
163765
163766
163767
163768
163769
163770
163771
163772
163773
163774
163775
163776
163777
163778
163779
163780
163781
163782
163783
163784
163785
163786
163787
163788
163789
163790
163791
163792
163793
163794
163795
163796
163797
163798
163799
163800
163801
163802
163803
163804
163805
163806
163807
163808
163809
163810
163811
163812
163813
163814
163815
163816
163817
163818
163819
163820
163821
163822
163823
163824
163825
163826
163827
163828
163829
163830
163831
163832
163833
163834
163835
163836
163837
163838
163839
163840
163841
163842
163843
163844
163845
163846
163847
163848
163849
163850
163851
163852
163853
163854
163855
163856
163857
163858
163859
163860
163861
163862
163863
163864
163865
163866
163867
163868
163869
163870
163871
163872
163873
163874
163875
163876
163877
163878
163879
163880
163881
163882
163883
163884
163885
163886
163887
163888
163889
163890
163891
163892
163893
163894
163895
163896
163897
163898
163899
163900
163901
163902
163903
163904
163905
163906
163907
163908
163909
163910
163911
163912
163913
163914
163915
163916
163917
163918
163919
163920
163921
163922
163923
163924
163925
163926
163927
163928
163929
163930
163931
163932
163933
163934
163935
163936
163937
163938
163939
163940
163941
163942
163943
163944
163945
163946
163947
163948
163949
163950
163951
163952
163953
163954
163955
163956
163957
163958
163959
163960
163961
163962
163963
163964
163965
163966
163967
163968
163969
163970
163971
163972
163973
163974
163975
163976
163977
163978
163979
163980
163981
163982
163983
163984
163985
163986
163987
163988
163989
163990
163991
163992
163993
163994
163995
163996
163997
163998
163999
164000
164001
164002
164003
164004
164005
164006
164007
164008
164009
164010
164011
164012
164013
164014
164015
164016
164017
164018
164019
164020
164021
164022
164023
164024
164025
164026
164027
164028
164029
164030
164031
164032
164033
164034
164035
164036
164037
164038
164039
164040
164041
164042
164043
164044
164045
164046
164047
164048
164049
164050
164051
164052
164053
164054
164055
164056
164057
164058
164059
164060
164061
164062
164063
164064
164065
164066
164067
164068
164069
164070
164071
164072
164073
164074
164075
164076
164077
164078
164079
164080
164081
164082
164083
164084
164085
164086
164087
164088
164089
164090
164091
164092
164093
164094
164095
164096
164097
164098
164099
164100
164101
164102
164103
164104
164105
164106
164107
164108
164109
164110
164111
164112
164113
164114
164115
164116
164117
164118
164119
164120
164121
164122
164123
164124
164125
164126
164127
164128
164129
164130
164131
164132
164133
164134
164135
164136
164137
164138
164139
164140
164141
164142
164143
164144
164145
164146
164147
164148
164149
164150
164151
164152
164153
164154
164155
164156
164157
164158
164159
164160
164161
164162
164163
164164
164165
164166
164167
164168
164169
164170
164171
164172
164173
164174
164175
164176
164177
164178
164179
164180
164181
164182
164183
164184
164185
164186
164187
164188
164189
164190
164191
164192
164193
164194
164195
164196
164197
164198
164199
164200
164201
164202
164203
164204
164205
164206
164207
164208
164209
164210
164211
164212
164213
164214
164215
164216
164217
164218
164219
164220
164221
164222
164223
164224
164225
164226
164227
164228
164229
164230
164231
164232
164233
164234
164235
164236
164237
164238
164239
164240
164241
164242
164243
164244
164245
164246
164247
164248
164249
164250
164251
164252
164253
164254
164255
164256
164257
164258
164259
164260
164261
164262
164263
164264
164265
164266
164267
164268
164269
164270
164271
164272
164273
164274
164275
164276
164277
164278
164279
164280
164281
164282
164283
164284
164285
164286
164287
164288
164289
164290
164291
164292
164293
164294
164295
164296
164297
164298
164299
164300
164301
164302
164303
164304
164305
164306
164307
164308
164309
164310
164311
164312
164313
164314
164315
164316
164317
164318
164319
164320
164321
164322
164323
164324
164325
164326
164327
164328
164329
164330
164331
164332
164333
164334
164335
164336
164337
164338
164339
164340
164341
164342
164343
164344
164345
164346
164347
164348
164349
164350
164351
164352
164353
164354
164355
164356
164357
164358
164359
164360
164361
164362
164363
164364
164365
164366
164367
164368
164369
164370
164371
164372
164373
164374
164375
164376
164377
164378
164379
164380
164381
164382
164383
164384
164385
164386
164387
164388
164389
164390
164391
164392
164393
164394
164395
164396
164397
164398
164399
164400
164401
164402
164403
164404
164405
164406
164407
164408
164409
164410
164411
164412
164413
164414
164415
164416
164417
164418
164419
164420
164421
164422
164423
164424
164425
164426
164427
164428
164429
164430
164431
164432
164433
164434
164435
164436
164437
164438
164439
164440
164441
164442
164443
164444
164445
164446
164447
164448
164449
164450
164451
164452
164453
164454
164455
164456
164457
164458
164459
164460
164461
164462
164463
164464
164465
164466
164467
164468
164469
164470
164471
164472
164473
164474
164475
164476
164477
164478
164479
164480
164481
164482
164483
164484
164485
164486
164487
164488
164489
164490
164491
164492
164493
164494
164495
164496
164497
164498
164499
164500
164501
164502
164503
164504
164505
164506
164507
164508
164509
164510
164511
164512
164513
164514
164515
164516
164517
164518
164519
164520
164521
164522
164523
164524
164525
164526
164527
164528
164529
164530
164531
164532
164533
164534
164535
164536
164537
164538
164539
164540
164541
164542
164543
164544
164545
164546
164547
164548
164549
164550
164551
164552
164553
164554
164555
164556
164557
164558
164559
164560
164561
164562
164563
164564
164565
164566
164567
164568
164569
164570
164571
164572
164573
164574
164575
164576
164577
164578
164579
164580
164581
164582
164583
164584
164585
164586
164587
164588
164589
164590
164591
164592
164593
164594
164595
164596
164597
164598
164599
164600
164601
164602
164603
164604
164605
164606
164607
164608
164609
164610
164611
164612
164613
164614
164615
164616
164617
164618
164619
164620
164621
164622
164623
164624
164625
164626
164627
164628
164629
164630
164631
164632
164633
164634
164635
164636
164637
164638
164639
164640
164641
164642
164643
164644
164645
164646
164647
164648
164649
164650
164651
164652
164653
164654
164655
164656
164657
164658
164659
164660
164661
164662
164663
164664
164665
164666
164667
164668
164669
164670
164671
164672
164673
164674
164675
164676
164677
164678
164679
164680
164681
164682
164683
164684
164685
164686
164687
164688
164689
164690
164691
164692
164693
164694
164695
164696
164697
164698
164699
164700
164701
164702
164703
164704
164705
164706
164707
164708
164709
164710
164711
164712
164713
164714
164715
164716
164717
164718
164719
164720
164721
164722
164723
164724
164725
164726
164727
164728
164729
164730
164731
164732
164733
164734
164735
164736
164737
164738
164739
164740
164741
164742
164743
164744
164745
164746
164747
164748
164749
164750
164751
164752
164753
164754
164755
164756
164757
164758
164759
164760
164761
164762
164763
164764
164765
164766
164767
164768
164769
164770
164771
164772
164773
164774
164775
164776
164777
164778
164779
164780
164781
164782
164783
164784
164785
164786
164787
164788
164789
164790
164791
164792
164793
164794
164795
164796
164797
164798
164799
164800
164801
164802
164803
164804
164805
164806
164807
164808
164809
164810
164811
164812
164813
164814
164815
164816
164817
164818
164819
164820
164821
164822
164823
164824
164825
164826
164827
164828
164829
164830
164831
164832
164833
164834
164835
164836
164837
164838
164839
164840
164841
164842
164843
164844
164845
164846
164847
164848
164849
164850
164851
164852
164853
164854
164855
164856
164857
164858
164859
164860
164861
164862
164863
164864
164865
164866
164867
164868
164869
164870
164871
164872
164873
164874
164875
164876
164877
164878
164879
164880
164881
164882
164883
164884
164885
164886
164887
164888
164889
164890
164891
164892
164893
164894
164895
164896
164897
164898
164899
164900
164901
164902
164903
164904
164905
164906
164907
164908
164909
164910
164911
164912
164913
164914
164915
164916
164917
164918
164919
164920
164921
164922
164923
164924
164925
164926
164927
164928
164929
164930
164931
164932
164933
164934
164935
164936
164937
164938
164939
164940
164941
164942
164943
164944
164945
164946
164947
164948
164949
164950
164951
164952
164953
164954
164955
164956
164957
164958
164959
164960
164961
164962
164963
164964
164965
164966
164967
164968
164969
164970
164971
164972
164973
164974
164975
164976
164977
164978
164979
164980
164981
164982
164983
164984
164985
164986
164987
164988
164989
164990
164991
164992
164993
164994
164995
164996
164997
164998
164999
165000
165001
165002
165003
165004
165005
165006
165007
165008
165009
165010
165011
165012
165013
165014
165015
165016
165017
165018
165019
165020
165021
165022
165023
165024
165025
165026
165027
165028
165029
165030
165031
165032
165033
165034
165035
165036
165037
165038
165039
165040
165041
165042
165043
165044
165045
165046
165047
165048
165049
165050
165051
165052
165053
165054
165055
165056
165057
165058
165059
165060
165061
165062
165063
165064
165065
165066
165067
165068
165069
165070
165071
165072
165073
165074
165075
165076
165077
165078
165079
165080
165081
165082
165083
165084
165085
165086
165087
165088
165089
165090
165091
165092
165093
165094
165095
165096
165097
165098
165099
165100
165101
165102
165103
165104
165105
165106
165107
165108
165109
165110
165111
165112
165113
165114
165115
165116
165117
165118
165119
165120
165121
165122
165123
165124
165125
165126
165127
165128
165129
165130
165131
165132
165133
165134
165135
165136
165137
165138
165139
165140
165141
165142
165143
165144
165145
165146
165147
165148
165149
165150
165151
165152
165153
165154
165155
165156
165157
165158
165159
165160
165161
165162
165163
165164
165165
165166
165167
165168
165169
165170
165171
165172
165173
165174
165175
165176
165177
165178
165179
165180
165181
165182
165183
165184
165185
165186
165187
165188
165189
165190
165191
165192
165193
165194
165195
165196
165197
165198
165199
165200
165201
165202
165203
165204
165205
165206
165207
165208
165209
165210
165211
165212
165213
165214
165215
165216
165217
165218
165219
165220
165221
165222
165223
165224
165225
165226
165227
165228
165229
165230
165231
165232
165233
165234
165235
165236
165237
165238
165239
165240
165241
165242
165243
165244
165245
165246
165247
165248
165249
165250
165251
165252
165253
165254
165255
165256
165257
165258
165259
165260
165261
165262
165263
165264
165265
165266
165267
165268
165269
165270
165271
165272
165273
165274
165275
165276
165277
165278
165279
165280
165281
165282
165283
165284
165285
165286
165287
165288
165289
165290
165291
165292
165293
165294
165295
165296
165297
165298
165299
165300
165301
165302
165303
165304
165305
165306
165307
165308
165309
165310
165311
165312
165313
165314
165315
165316
165317
165318
165319
165320
165321
165322
165323
165324
165325
165326
165327
165328
165329
165330
165331
165332
165333
165334
165335
165336
165337
165338
165339
165340
165341
165342
165343
165344
165345
165346
165347
165348
165349
165350
165351
165352
165353
165354
165355
165356
165357
165358
165359
165360
165361
165362
165363
165364
165365
165366
165367
165368
165369
165370
165371
165372
165373
165374
165375
165376
165377
165378
165379
165380
165381
165382
165383
165384
165385
165386
165387
165388
165389
165390
165391
165392
165393
165394
165395
165396
165397
165398
165399
165400
165401
165402
165403
165404
165405
165406
165407
165408
165409
165410
165411
165412
165413
165414
165415
165416
165417
165418
165419
165420
165421
165422
165423
165424
165425
165426
165427
165428
165429
165430
165431
165432
165433
165434
165435
165436
165437
165438
165439
165440
165441
165442
165443
165444
165445
165446
165447
165448
165449
165450
165451
165452
165453
165454
165455
165456
165457
165458
165459
165460
165461
165462
165463
165464
165465
165466
165467
165468
165469
165470
165471
165472
165473
165474
165475
165476
165477
165478
165479
165480
165481
165482
165483
165484
165485
165486
165487
165488
165489
165490
165491
165492
165493
165494
165495
165496
165497
165498
165499
165500
165501
165502
165503
165504
165505
165506
165507
165508
165509
165510
165511
165512
165513
165514
165515
165516
165517
165518
165519
165520
165521
165522
165523
165524
165525
165526
165527
165528
165529
165530
165531
165532
165533
165534
165535
165536
165537
165538
165539
165540
165541
165542
165543
165544
165545
165546
165547
165548
165549
165550
165551
165552
165553
165554
165555
165556
165557
165558
165559
165560
165561
165562
165563
165564
165565
165566
165567
165568
165569
165570
165571
165572
165573
165574
165575
165576
165577
165578
165579
165580
165581
165582
165583
165584
165585
165586
165587
165588
165589
165590
165591
165592
165593
165594
165595
165596
165597
165598
165599
165600
165601
165602
165603
165604
165605
165606
165607
165608
165609
165610
165611
165612
165613
165614
165615
165616
165617
165618
165619
165620
165621
165622
165623
165624
165625
165626
165627
165628
165629
165630
165631
165632
165633
165634
165635
165636
165637
165638
165639
165640
165641
165642
165643
165644
165645
165646
165647
165648
165649
165650
165651
165652
165653
165654
165655
165656
165657
165658
165659
165660
165661
165662
165663
165664
165665
165666
165667
165668
165669
165670
165671
165672
165673
165674
165675
165676
165677
165678
165679
165680
165681
165682
165683
165684
165685
165686
165687
165688
165689
165690
165691
165692
165693
165694
165695
165696
165697
165698
165699
165700
165701
165702
165703
165704
165705
165706
165707
165708
165709
165710
165711
165712
165713
165714
165715
165716
165717
165718
165719
165720
165721
165722
165723
165724
165725
165726
165727
165728
165729
165730
165731
165732
165733
165734
165735
165736
165737
165738
165739
165740
165741
165742
165743
165744
165745
165746
165747
165748
165749
165750
165751
165752
165753
165754
165755
165756
165757
165758
165759
165760
165761
165762
165763
165764
165765
165766
165767
165768
165769
165770
165771
165772
165773
165774
165775
165776
165777
165778
165779
165780
165781
165782
165783
165784
165785
165786
165787
165788
165789
165790
165791
165792
165793
165794
165795
165796
165797
165798
165799
165800
165801
165802
165803
165804
165805
165806
165807
165808
165809
165810
165811
165812
165813
165814
165815
165816
165817
165818
165819
165820
165821
165822
165823
165824
165825
165826
165827
165828
165829
165830
165831
165832
165833
165834
165835
165836
165837
165838
165839
165840
165841
165842
165843
165844
165845
165846
165847
165848
165849
165850
165851
165852
165853
165854
165855
165856
165857
165858
165859
165860
165861
165862
165863
165864
165865
165866
165867
165868
165869
165870
165871
165872
165873
165874
165875
165876
165877
165878
165879
165880
165881
165882
165883
165884
165885
165886
165887
165888
165889
165890
165891
165892
165893
165894
165895
165896
165897
165898
165899
165900
165901
165902
165903
165904
165905
165906
165907
165908
165909
165910
165911
165912
165913
165914
165915
165916
165917
165918
165919
165920
165921
165922
165923
165924
165925
165926
165927
165928
165929
165930
165931
165932
165933
165934
165935
165936
165937
165938
165939
165940
165941
165942
165943
165944
165945
165946
165947
165948
165949
165950
165951
165952
165953
165954
165955
165956
165957
165958
165959
165960
165961
165962
165963
165964
165965
165966
165967
165968
165969
165970
165971
165972
165973
165974
165975
165976
165977
165978
165979
165980
165981
165982
165983
165984
165985
165986
165987
165988
165989
165990
165991
165992
165993
165994
165995
165996
165997
165998
165999
166000
166001
166002
166003
166004
166005
166006
166007
166008
166009
166010
166011
166012
166013
166014
166015
166016
166017
166018
166019
166020
166021
166022
166023
166024
166025
166026
166027
166028
166029
166030
166031
166032
166033
166034
166035
166036
166037
166038
166039
166040
166041
166042
166043
166044
166045
166046
166047
166048
166049
166050
166051
166052
166053
166054
166055
166056
166057
166058
166059
166060
166061
166062
166063
166064
166065
166066
166067
166068
166069
166070
166071
166072
166073
166074
166075
166076
166077
166078
166079
166080
166081
166082
166083
166084
166085
166086
166087
166088
166089
166090
166091
166092
166093
166094
166095
166096
166097
166098
166099
166100
166101
166102
166103
166104
166105
166106
166107
166108
166109
166110
166111
166112
166113
166114
166115
166116
166117
166118
166119
166120
166121
166122
166123
166124
166125
166126
166127
166128
166129
166130
166131
166132
166133
166134
166135
166136
166137
166138
166139
166140
166141
166142
166143
166144
166145
166146
166147
166148
166149
166150
166151
166152
166153
166154
166155
166156
166157
166158
166159
166160
166161
166162
166163
166164
166165
166166
166167
166168
166169
166170
166171
166172
166173
166174
166175
166176
166177
166178
166179
166180
166181
166182
166183
166184
166185
166186
166187
166188
166189
166190
166191
166192
166193
166194
166195
166196
166197
166198
166199
166200
166201
166202
166203
166204
166205
166206
166207
166208
166209
166210
166211
166212
166213
166214
166215
166216
166217
166218
166219
166220
166221
166222
166223
166224
166225
166226
166227
166228
166229
166230
166231
166232
166233
166234
166235
166236
166237
166238
166239
166240
166241
166242
166243
166244
166245
166246
166247
166248
166249
166250
166251
166252
166253
166254
166255
166256
166257
166258
166259
166260
166261
166262
166263
166264
166265
166266
166267
166268
166269
166270
166271
166272
166273
166274
166275
166276
166277
166278
166279
166280
166281
166282
166283
166284
166285
166286
166287
166288
166289
166290
166291
166292
166293
166294
166295
166296
166297
166298
166299
166300
166301
166302
166303
166304
166305
166306
166307
166308
166309
166310
166311
166312
166313
166314
166315
166316
166317
166318
166319
166320
166321
166322
166323
166324
166325
166326
166327
166328
166329
166330
166331
166332
166333
166334
166335
166336
166337
166338
166339
166340
166341
166342
166343
166344
166345
166346
166347
166348
166349
166350
166351
166352
166353
166354
166355
166356
166357
166358
166359
166360
166361
166362
166363
166364
166365
166366
166367
166368
166369
166370
166371
166372
166373
166374
166375
166376
166377
166378
166379
166380
166381
166382
166383
166384
166385
166386
166387
166388
166389
166390
166391
166392
166393
166394
166395
166396
166397
166398
166399
166400
166401
166402
166403
166404
166405
166406
166407
166408
166409
166410
166411
166412
166413
166414
166415
166416
166417
166418
166419
166420
166421
166422
166423
166424
166425
166426
166427
166428
166429
166430
166431
166432
166433
166434
166435
166436
166437
166438
166439
166440
166441
166442
166443
166444
166445
166446
166447
166448
166449
166450
166451
166452
166453
166454
166455
166456
166457
166458
166459
166460
166461
166462
166463
166464
166465
166466
166467
166468
166469
166470
166471
166472
166473
166474
166475
166476
166477
166478
166479
166480
166481
166482
166483
166484
166485
166486
166487
166488
166489
166490
166491
166492
166493
166494
166495
166496
166497
166498
166499
166500
166501
166502
166503
166504
166505
166506
166507
166508
166509
166510
166511
166512
166513
166514
166515
166516
166517
166518
166519
166520
166521
166522
166523
166524
166525
166526
166527
166528
166529
166530
166531
166532
166533
166534
166535
166536
166537
166538
166539
166540
166541
166542
166543
166544
166545
166546
166547
166548
166549
166550
166551
166552
166553
166554
166555
166556
166557
166558
166559
166560
166561
166562
166563
166564
166565
166566
166567
166568
166569
166570
166571
166572
166573
166574
166575
166576
166577
166578
166579
166580
166581
166582
166583
166584
166585
166586
166587
166588
166589
166590
166591
166592
166593
166594
166595
166596
166597
166598
166599
166600
166601
166602
166603
166604
166605
166606
166607
166608
166609
166610
166611
166612
166613
166614
166615
166616
166617
166618
166619
166620
166621
166622
166623
166624
166625
166626
166627
166628
166629
166630
166631
166632
166633
166634
166635
166636
166637
166638
166639
166640
166641
166642
166643
166644
166645
166646
166647
166648
166649
166650
166651
166652
166653
166654
166655
166656
166657
166658
166659
166660
166661
166662
166663
166664
166665
166666
166667
166668
166669
166670
166671
166672
166673
166674
166675
166676
166677
166678
166679
166680
166681
166682
166683
166684
166685
166686
166687
166688
166689
166690
166691
166692
166693
166694
166695
166696
166697
166698
166699
166700
166701
166702
166703
166704
166705
166706
166707
166708
166709
166710
166711
166712
166713
166714
166715
166716
166717
166718
166719
166720
166721
166722
166723
166724
166725
166726
166727
166728
166729
166730
166731
166732
166733
166734
166735
166736
166737
166738
166739
166740
166741
166742
166743
166744
166745
166746
166747
166748
166749
166750
166751
166752
166753
166754
166755
166756
166757
166758
166759
166760
166761
166762
166763
166764
166765
166766
166767
166768
166769
166770
166771
166772
166773
166774
166775
166776
166777
166778
166779
166780
166781
166782
166783
166784
166785
166786
166787
166788
166789
166790
166791
166792
166793
166794
166795
166796
166797
166798
166799
166800
166801
166802
166803
166804
166805
166806
166807
166808
166809
166810
166811
166812
166813
166814
166815
166816
166817
166818
166819
166820
166821
166822
166823
166824
166825
166826
166827
166828
166829
166830
166831
166832
166833
166834
166835
166836
166837
166838
166839
166840
166841
166842
166843
166844
166845
166846
166847
166848
166849
166850
166851
166852
166853
166854
166855
166856
166857
166858
166859
166860
166861
166862
166863
166864
166865
166866
166867
166868
166869
166870
166871
166872
166873
166874
166875
166876
166877
166878
166879
166880
166881
166882
166883
166884
166885
166886
166887
166888
166889
166890
166891
166892
166893
166894
166895
166896
166897
166898
166899
166900
166901
166902
166903
166904
166905
166906
166907
166908
166909
166910
166911
166912
166913
166914
166915
166916
166917
166918
166919
166920
166921
166922
166923
166924
166925
166926
166927
166928
166929
166930
166931
166932
166933
166934
166935
166936
166937
166938
166939
166940
166941
166942
166943
166944
166945
166946
166947
166948
166949
166950
166951
166952
166953
166954
166955
166956
166957
166958
166959
166960
166961
166962
166963
166964
166965
166966
166967
166968
166969
166970
166971
166972
166973
166974
166975
166976
166977
166978
166979
166980
166981
166982
166983
166984
166985
166986
166987
166988
166989
166990
166991
166992
166993
166994
166995
166996
166997
166998
166999
167000
167001
167002
167003
167004
167005
167006
167007
167008
167009
167010
167011
167012
167013
167014
167015
167016
167017
167018
167019
167020
167021
167022
167023
167024
167025
167026
167027
167028
167029
167030
167031
167032
167033
167034
167035
167036
167037
167038
167039
167040
167041
167042
167043
167044
167045
167046
167047
167048
167049
167050
167051
167052
167053
167054
167055
167056
167057
167058
167059
167060
167061
167062
167063
167064
167065
167066
167067
167068
167069
167070
167071
167072
167073
167074
167075
167076
167077
167078
167079
167080
167081
167082
167083
167084
167085
167086
167087
167088
167089
167090
167091
167092
167093
167094
167095
167096
167097
167098
167099
167100
167101
167102
167103
167104
167105
167106
167107
167108
167109
167110
167111
167112
167113
167114
167115
167116
167117
167118
167119
167120
167121
167122
167123
167124
167125
167126
167127
167128
167129
167130
167131
167132
167133
167134
167135
167136
167137
167138
167139
167140
167141
167142
167143
167144
167145
167146
167147
167148
167149
167150
167151
167152
167153
167154
167155
167156
167157
167158
167159
167160
167161
167162
167163
167164
167165
167166
167167
167168
167169
167170
167171
167172
167173
167174
167175
167176
167177
167178
167179
167180
167181
167182
167183
167184
167185
167186
167187
167188
167189
167190
167191
167192
167193
167194
167195
167196
167197
167198
167199
167200
167201
167202
167203
167204
167205
167206
167207
167208
167209
167210
167211
167212
167213
167214
167215
167216
167217
167218
167219
167220
167221
167222
167223
167224
167225
167226
167227
167228
167229
167230
167231
167232
167233
167234
167235
167236
167237
167238
167239
167240
167241
167242
167243
167244
167245
167246
167247
167248
167249
167250
167251
167252
167253
167254
167255
167256
167257
167258
167259
167260
167261
167262
167263
167264
167265
167266
167267
167268
167269
167270
167271
167272
167273
167274
167275
167276
167277
167278
167279
167280
167281
167282
167283
167284
167285
167286
167287
167288
167289
167290
167291
167292
167293
167294
167295
167296
167297
167298
167299
167300
167301
167302
167303
167304
167305
167306
167307
167308
167309
167310
167311
167312
167313
167314
167315
167316
167317
167318
167319
167320
167321
167322
167323
167324
167325
167326
167327
167328
167329
167330
167331
167332
167333
167334
167335
167336
167337
167338
167339
167340
167341
167342
167343
167344
167345
167346
167347
167348
167349
167350
167351
167352
167353
167354
167355
167356
167357
167358
167359
167360
167361
167362
167363
167364
167365
167366
167367
167368
167369
167370
167371
167372
167373
167374
167375
167376
167377
167378
167379
167380
167381
167382
167383
167384
167385
167386
167387
167388
167389
167390
167391
167392
167393
167394
167395
167396
167397
167398
167399
167400
167401
167402
167403
167404
167405
167406
167407
167408
167409
167410
167411
167412
167413
167414
167415
167416
167417
167418
167419
167420
167421
167422
167423
167424
167425
167426
167427
167428
167429
167430
167431
167432
167433
167434
167435
167436
167437
167438
167439
167440
167441
167442
167443
167444
167445
167446
167447
167448
167449
167450
167451
167452
167453
167454
167455
167456
167457
167458
167459
167460
167461
167462
167463
167464
167465
167466
167467
167468
167469
167470
167471
167472
167473
167474
167475
167476
167477
167478
167479
167480
167481
167482
167483
167484
167485
167486
167487
167488
167489
167490
167491
167492
167493
167494
167495
167496
167497
167498
167499
167500
167501
167502
167503
167504
167505
167506
167507
167508
167509
167510
167511
167512
167513
167514
167515
167516
167517
167518
167519
167520
167521
167522
167523
167524
167525
167526
167527
167528
167529
167530
167531
167532
167533
167534
167535
167536
167537
167538
167539
167540
167541
167542
167543
167544
167545
167546
167547
167548
167549
167550
167551
167552
167553
167554
167555
167556
167557
167558
167559
167560
167561
167562
167563
167564
167565
167566
167567
167568
167569
167570
167571
167572
167573
167574
167575
167576
167577
167578
167579
167580
167581
167582
167583
167584
167585
167586
167587
167588
167589
167590
167591
167592
167593
167594
167595
167596
167597
167598
167599
167600
167601
167602
167603
167604
167605
167606
167607
167608
167609
167610
167611
167612
167613
167614
167615
167616
167617
167618
167619
167620
167621
167622
167623
167624
167625
167626
167627
167628
167629
167630
167631
167632
167633
167634
167635
167636
167637
167638
167639
167640
167641
167642
167643
167644
167645
167646
167647
167648
167649
167650
167651
167652
167653
167654
167655
167656
167657
167658
167659
167660
167661
167662
167663
167664
167665
167666
167667
167668
167669
167670
167671
167672
167673
167674
167675
167676
167677
167678
167679
167680
167681
167682
167683
167684
167685
167686
167687
167688
167689
167690
167691
167692
167693
167694
167695
167696
167697
167698
167699
167700
167701
167702
167703
167704
167705
167706
167707
167708
167709
167710
167711
167712
167713
167714
167715
167716
167717
167718
167719
167720
167721
167722
167723
167724
167725
167726
167727
167728
167729
167730
167731
167732
167733
167734
167735
167736
167737
167738
167739
167740
167741
167742
167743
167744
167745
167746
167747
167748
167749
167750
167751
167752
167753
167754
167755
167756
167757
167758
167759
167760
167761
167762
167763
167764
167765
167766
167767
167768
167769
167770
167771
167772
167773
167774
167775
167776
167777
167778
167779
167780
167781
167782
167783
167784
167785
167786
167787
167788
167789
167790
167791
167792
167793
167794
167795
167796
167797
167798
167799
167800
167801
167802
167803
167804
167805
167806
167807
167808
167809
167810
167811
167812
167813
167814
167815
167816
167817
167818
167819
167820
167821
167822
167823
167824
167825
167826
167827
167828
167829
167830
167831
167832
167833
167834
167835
167836
167837
167838
167839
167840
167841
167842
167843
167844
167845
167846
167847
167848
167849
167850
167851
167852
167853
167854
167855
167856
167857
167858
167859
167860
167861
167862
167863
167864
167865
167866
167867
167868
167869
167870
167871
167872
167873
167874
167875
167876
167877
167878
167879
167880
167881
167882
167883
167884
167885
167886
167887
167888
167889
167890
167891
167892
167893
167894
167895
167896
167897
167898
167899
167900
167901
167902
167903
167904
167905
167906
167907
167908
167909
167910
167911
167912
167913
167914
167915
167916
167917
167918
167919
167920
167921
167922
167923
167924
167925
167926
167927
167928
167929
167930
167931
167932
167933
167934
167935
167936
167937
167938
167939
167940
167941
167942
167943
167944
167945
167946
167947
167948
167949
167950
167951
167952
167953
167954
167955
167956
167957
167958
167959
167960
167961
167962
167963
167964
167965
167966
167967
167968
167969
167970
167971
167972
167973
167974
167975
167976
167977
167978
167979
167980
167981
167982
167983
167984
167985
167986
167987
167988
167989
167990
167991
167992
167993
167994
167995
167996
167997
167998
167999
168000
168001
168002
168003
168004
168005
168006
168007
168008
168009
168010
168011
168012
168013
168014
168015
168016
168017
168018
168019
168020
168021
168022
168023
168024
168025
168026
168027
168028
168029
168030
168031
168032
168033
168034
168035
168036
168037
168038
168039
168040
168041
168042
168043
168044
168045
168046
168047
168048
168049
168050
168051
168052
168053
168054
168055
168056
168057
168058
168059
168060
168061
168062
168063
168064
168065
168066
168067
168068
168069
168070
168071
168072
168073
168074
168075
168076
168077
168078
168079
168080
168081
168082
168083
168084
168085
168086
168087
168088
168089
168090
168091
168092
168093
168094
168095
168096
168097
168098
168099
168100
168101
168102
168103
168104
168105
168106
168107
168108
168109
168110
168111
168112
168113
168114
168115
168116
168117
168118
168119
168120
168121
168122
168123
168124
168125
168126
168127
168128
168129
168130
168131
168132
168133
168134
168135
168136
168137
168138
168139
168140
168141
168142
168143
168144
168145
168146
168147
168148
168149
168150
168151
168152
168153
168154
168155
168156
168157
168158
168159
168160
168161
168162
168163
168164
168165
168166
168167
168168
168169
168170
168171
168172
168173
168174
168175
168176
168177
168178
168179
168180
168181
168182
168183
168184
168185
168186
168187
168188
168189
168190
168191
168192
168193
168194
168195
168196
168197
168198
168199
168200
168201
168202
168203
168204
168205
168206
168207
168208
168209
168210
168211
168212
168213
168214
168215
168216
168217
168218
168219
168220
168221
168222
168223
168224
168225
168226
168227
168228
168229
168230
168231
168232
168233
168234
168235
168236
168237
168238
168239
168240
168241
168242
168243
168244
168245
168246
168247
168248
168249
168250
168251
168252
168253
168254
168255
168256
168257
168258
168259
168260
168261
168262
168263
168264
168265
168266
168267
168268
168269
168270
168271
168272
168273
168274
168275
168276
168277
168278
168279
168280
168281
168282
168283
168284
168285
168286
168287
168288
168289
168290
168291
168292
168293
168294
168295
168296
168297
168298
168299
168300
168301
168302
168303
168304
168305
168306
168307
168308
168309
168310
168311
168312
168313
168314
168315
168316
168317
168318
168319
168320
168321
168322
168323
168324
168325
168326
168327
168328
168329
168330
168331
168332
168333
168334
168335
168336
168337
168338
168339
168340
168341
168342
168343
168344
168345
168346
168347
168348
168349
168350
168351
168352
168353
168354
168355
168356
168357
168358
168359
168360
168361
168362
168363
168364
168365
168366
168367
168368
168369
168370
168371
168372
168373
168374
168375
168376
168377
168378
168379
168380
168381
168382
168383
168384
168385
168386
168387
168388
168389
168390
168391
168392
168393
168394
168395
168396
168397
168398
168399
168400
168401
168402
168403
168404
168405
168406
168407
168408
168409
168410
168411
168412
168413
168414
168415
168416
168417
168418
168419
168420
168421
168422
168423
168424
168425
168426
168427
168428
168429
168430
168431
168432
168433
168434
168435
168436
168437
168438
168439
168440
168441
168442
168443
168444
168445
168446
168447
168448
168449
168450
168451
168452
168453
168454
168455
168456
168457
168458
168459
168460
168461
168462
168463
168464
168465
168466
168467
168468
168469
168470
168471
168472
168473
168474
168475
168476
168477
168478
168479
168480
168481
168482
168483
168484
168485
168486
168487
168488
168489
168490
168491
168492
168493
168494
168495
168496
168497
168498
168499
168500
168501
168502
168503
168504
168505
168506
168507
168508
168509
168510
168511
168512
168513
168514
168515
168516
168517
168518
168519
168520
168521
168522
168523
168524
168525
168526
168527
168528
168529
168530
168531
168532
168533
168534
168535
168536
168537
168538
168539
168540
168541
168542
168543
168544
168545
168546
168547
168548
168549
168550
168551
168552
168553
168554
168555
168556
168557
168558
168559
168560
168561
168562
168563
168564
168565
168566
168567
168568
168569
168570
168571
168572
168573
168574
168575
168576
168577
168578
168579
168580
168581
168582
168583
168584
168585
168586
168587
168588
168589
168590
168591
168592
168593
168594
168595
168596
168597
168598
168599
168600
168601
168602
168603
168604
168605
168606
168607
168608
168609
168610
168611
168612
168613
168614
168615
168616
168617
168618
168619
168620
168621
168622
168623
168624
168625
168626
168627
168628
168629
168630
168631
168632
168633
168634
168635
168636
168637
168638
168639
168640
168641
168642
168643
168644
168645
168646
168647
168648
168649
168650
168651
168652
168653
168654
168655
168656
168657
168658
168659
168660
168661
168662
168663
168664
168665
168666
168667
168668
168669
168670
168671
168672
168673
168674
168675
168676
168677
168678
168679
168680
168681
168682
168683
168684
168685
168686
168687
168688
168689
168690
168691
168692
168693
168694
168695
168696
168697
168698
168699
168700
168701
168702
168703
168704
168705
168706
168707
168708
168709
168710
168711
168712
168713
168714
168715
168716
168717
168718
168719
168720
168721
168722
168723
168724
168725
168726
168727
168728
168729
168730
168731
168732
168733
168734
168735
168736
168737
168738
168739
168740
168741
168742
168743
168744
168745
168746
168747
168748
168749
168750
168751
168752
168753
168754
168755
168756
168757
168758
168759
168760
168761
168762
168763
168764
168765
168766
168767
168768
168769
168770
168771
168772
168773
168774
168775
168776
168777
168778
168779
168780
168781
168782
168783
168784
168785
168786
168787
168788
168789
168790
168791
168792
168793
168794
168795
168796
168797
168798
168799
168800
168801
168802
168803
168804
168805
168806
168807
168808
168809
168810
168811
168812
168813
168814
168815
168816
168817
168818
168819
168820
168821
168822
168823
168824
168825
168826
168827
168828
168829
168830
168831
168832
168833
168834
168835
168836
168837
168838
168839
168840
168841
168842
168843
168844
168845
168846
168847
168848
168849
168850
168851
168852
168853
168854
168855
168856
168857
168858
168859
168860
168861
168862
168863
168864
168865
168866
168867
168868
168869
168870
168871
168872
168873
168874
168875
168876
168877
168878
168879
168880
168881
168882
168883
168884
168885
168886
168887
168888
168889
168890
168891
168892
168893
168894
168895
168896
168897
168898
168899
168900
168901
168902
168903
168904
168905
168906
168907
168908
168909
168910
168911
168912
168913
168914
168915
168916
168917
168918
168919
168920
168921
168922
168923
168924
168925
168926
168927
168928
168929
168930
168931
168932
168933
168934
168935
168936
168937
168938
168939
168940
168941
168942
168943
168944
168945
168946
168947
168948
168949
168950
168951
168952
168953
168954
168955
168956
168957
168958
168959
168960
168961
168962
168963
168964
168965
168966
168967
168968
168969
168970
168971
168972
168973
168974
168975
168976
168977
168978
168979
168980
168981
168982
168983
168984
168985
168986
168987
168988
168989
168990
168991
168992
168993
168994
168995
168996
168997
168998
168999
169000
169001
169002
169003
169004
169005
169006
169007
169008
169009
169010
169011
169012
169013
169014
169015
169016
169017
169018
169019
169020
169021
169022
169023
169024
169025
169026
169027
169028
169029
169030
169031
169032
169033
169034
169035
169036
169037
169038
169039
169040
169041
169042
169043
169044
169045
169046
169047
169048
169049
169050
169051
169052
169053
169054
169055
169056
169057
169058
169059
169060
169061
169062
169063
169064
169065
169066
169067
169068
169069
169070
169071
169072
169073
169074
169075
169076
169077
169078
169079
169080
169081
169082
169083
169084
169085
169086
169087
169088
169089
169090
169091
169092
169093
169094
169095
169096
169097
169098
169099
169100
169101
169102
169103
169104
169105
169106
169107
169108
169109
169110
169111
169112
169113
169114
169115
169116
169117
169118
169119
169120
169121
169122
169123
169124
169125
169126
169127
169128
169129
169130
169131
169132
169133
169134
169135
169136
169137
169138
169139
169140
169141
169142
169143
169144
169145
169146
169147
169148
169149
169150
169151
169152
169153
169154
169155
169156
169157
169158
169159
169160
169161
169162
169163
169164
169165
169166
169167
169168
169169
169170
169171
169172
169173
169174
169175
169176
169177
169178
169179
169180
169181
169182
169183
169184
169185
169186
169187
169188
169189
169190
169191
169192
169193
169194
169195
169196
169197
169198
169199
169200
169201
169202
169203
169204
169205
169206
169207
169208
169209
169210
169211
169212
169213
169214
169215
169216
169217
169218
169219
169220
169221
169222
169223
169224
169225
169226
169227
169228
169229
169230
169231
169232
169233
169234
169235
169236
169237
169238
169239
169240
169241
169242
169243
169244
169245
169246
169247
169248
169249
169250
169251
169252
169253
169254
169255
169256
169257
169258
169259
169260
169261
169262
169263
169264
169265
169266
169267
169268
169269
169270
169271
169272
169273
169274
169275
169276
169277
169278
169279
169280
169281
169282
169283
169284
169285
169286
169287
169288
169289
169290
169291
169292
169293
169294
169295
169296
169297
169298
169299
169300
169301
169302
169303
169304
169305
169306
169307
169308
169309
169310
169311
169312
169313
169314
169315
169316
169317
169318
169319
169320
169321
169322
169323
169324
169325
169326
169327
169328
169329
169330
169331
169332
169333
169334
169335
169336
169337
169338
169339
169340
169341
169342
169343
169344
169345
169346
169347
169348
169349
169350
169351
169352
169353
169354
169355
169356
169357
169358
169359
169360
169361
169362
169363
169364
169365
169366
169367
169368
169369
169370
169371
169372
169373
169374
169375
169376
169377
169378
169379
169380
169381
169382
169383
169384
169385
169386
169387
169388
169389
169390
169391
169392
169393
169394
169395
169396
169397
169398
169399
169400
169401
169402
169403
169404
169405
169406
169407
169408
169409
169410
169411
169412
169413
169414
169415
169416
169417
169418
169419
169420
169421
169422
169423
169424
169425
169426
169427
169428
169429
169430
169431
169432
169433
169434
169435
169436
169437
169438
169439
169440
169441
169442
169443
169444
169445
169446
169447
169448
169449
169450
169451
169452
169453
169454
169455
169456
169457
169458
169459
169460
169461
169462
169463
169464
169465
169466
169467
169468
169469
169470
169471
169472
169473
169474
169475
169476
169477
169478
169479
169480
169481
169482
169483
169484
169485
169486
169487
169488
169489
169490
169491
169492
169493
169494
169495
169496
169497
169498
169499
169500
169501
169502
169503
169504
169505
169506
169507
169508
169509
169510
169511
169512
169513
169514
169515
169516
169517
169518
169519
169520
169521
169522
169523
169524
169525
169526
169527
169528
169529
169530
169531
169532
169533
169534
169535
169536
169537
169538
169539
169540
169541
169542
169543
169544
169545
169546
169547
169548
169549
169550
169551
169552
169553
169554
169555
169556
169557
169558
169559
169560
169561
169562
169563
169564
169565
169566
169567
169568
169569
169570
169571
169572
169573
169574
169575
169576
169577
169578
169579
169580
169581
169582
169583
169584
169585
169586
169587
169588
169589
169590
169591
169592
169593
169594
169595
169596
169597
169598
169599
169600
169601
169602
169603
169604
169605
169606
169607
169608
169609
169610
169611
169612
169613
169614
169615
169616
169617
169618
169619
169620
169621
169622
169623
169624
169625
169626
169627
169628
169629
169630
169631
169632
169633
169634
169635
169636
169637
169638
169639
169640
169641
169642
169643
169644
169645
169646
169647
169648
169649
169650
169651
169652
169653
169654
169655
169656
169657
169658
169659
169660
169661
169662
169663
169664
169665
169666
169667
169668
169669
169670
169671
169672
169673
169674
169675
169676
169677
169678
169679
169680
169681
169682
169683
169684
169685
169686
169687
169688
169689
169690
169691
169692
169693
169694
169695
169696
169697
169698
169699
169700
169701
169702
169703
169704
169705
169706
169707
169708
169709
169710
169711
169712
169713
169714
169715
169716
169717
169718
169719
169720
169721
169722
169723
169724
169725
169726
169727
169728
169729
169730
169731
169732
169733
169734
169735
169736
169737
169738
169739
169740
169741
169742
169743
169744
169745
169746
169747
169748
169749
169750
169751
169752
169753
169754
169755
169756
169757
169758
169759
169760
169761
169762
169763
169764
169765
169766
169767
169768
169769
169770
169771
169772
169773
169774
169775
169776
169777
169778
169779
169780
169781
169782
169783
169784
169785
169786
169787
169788
169789
169790
169791
169792
169793
169794
169795
169796
169797
169798
169799
169800
169801
169802
169803
169804
169805
169806
169807
169808
169809
169810
169811
169812
169813
169814
169815
169816
169817
169818
169819
169820
169821
169822
169823
169824
169825
169826
169827
169828
169829
169830
169831
169832
169833
169834
169835
169836
169837
169838
169839
169840
169841
169842
169843
169844
169845
169846
169847
169848
169849
169850
169851
169852
169853
169854
169855
169856
169857
169858
169859
169860
169861
169862
169863
169864
169865
169866
169867
169868
169869
169870
169871
169872
169873
169874
169875
169876
169877
169878
169879
169880
169881
169882
169883
169884
169885
169886
169887
169888
169889
169890
169891
169892
169893
169894
169895
169896
169897
169898
169899
169900
169901
169902
169903
169904
169905
169906
169907
169908
169909
169910
169911
169912
169913
169914
169915
169916
169917
169918
169919
169920
169921
169922
169923
169924
169925
169926
169927
169928
169929
169930
169931
169932
169933
169934
169935
169936
169937
169938
169939
169940
169941
169942
169943
169944
169945
169946
169947
169948
169949
169950
169951
169952
169953
169954
169955
169956
169957
169958
169959
169960
169961
169962
169963
169964
169965
169966
169967
169968
169969
169970
169971
169972
169973
169974
169975
169976
169977
169978
169979
169980
169981
169982
169983
169984
169985
169986
169987
169988
169989
169990
169991
169992
169993
169994
169995
169996
169997
169998
169999
170000
170001
170002
170003
170004
170005
170006
170007
170008
170009
170010
170011
170012
170013
170014
170015
170016
170017
170018
170019
170020
170021
170022
170023
170024
170025
170026
170027
170028
170029
170030
170031
170032
170033
170034
170035
170036
170037
170038
170039
170040
170041
170042
170043
170044
170045
170046
170047
170048
170049
170050
170051
170052
170053
170054
170055
170056
170057
170058
170059
170060
170061
170062
170063
170064
170065
170066
170067
170068
170069
170070
170071
170072
170073
170074
170075
170076
170077
170078
170079
170080
170081
170082
170083
170084
170085
170086
170087
170088
170089
170090
170091
170092
170093
170094
170095
170096
170097
170098
170099
170100
170101
170102
170103
170104
170105
170106
170107
170108
170109
170110
170111
170112
170113
170114
170115
170116
170117
170118
170119
170120
170121
170122
170123
170124
170125
170126
170127
170128
170129
170130
170131
170132
170133
170134
170135
170136
170137
170138
170139
170140
170141
170142
170143
170144
170145
170146
170147
170148
170149
170150
170151
170152
170153
170154
170155
170156
170157
170158
170159
170160
170161
170162
170163
170164
170165
170166
170167
170168
170169
170170
170171
170172
170173
170174
170175
170176
170177
170178
170179
170180
170181
170182
170183
170184
170185
170186
170187
170188
170189
170190
170191
170192
170193
170194
170195
170196
170197
170198
170199
170200
170201
170202
170203
170204
170205
170206
170207
170208
170209
170210
170211
170212
170213
170214
170215
170216
170217
170218
170219
170220
170221
170222
170223
170224
170225
170226
170227
170228
170229
170230
170231
170232
170233
170234
170235
170236
170237
170238
170239
170240
170241
170242
170243
170244
170245
170246
170247
170248
170249
170250
170251
170252
170253
170254
170255
170256
170257
170258
170259
170260
170261
170262
170263
170264
170265
170266
170267
170268
170269
170270
170271
170272
170273
170274
170275
170276
170277
170278
170279
170280
170281
170282
170283
170284
170285
170286
170287
170288
170289
170290
170291
170292
170293
170294
170295
170296
170297
170298
170299
170300
170301
170302
170303
170304
170305
170306
170307
170308
170309
170310
170311
170312
170313
170314
170315
170316
170317
170318
170319
170320
170321
170322
170323
170324
170325
170326
170327
170328
170329
170330
170331
170332
170333
170334
170335
170336
170337
170338
170339
170340
170341
170342
170343
170344
170345
170346
170347
170348
170349
170350
170351
170352
170353
170354
170355
170356
170357
170358
170359
170360
170361
170362
170363
170364
170365
170366
170367
170368
170369
170370
170371
170372
170373
170374
170375
170376
170377
170378
170379
170380
170381
170382
170383
170384
170385
170386
170387
170388
170389
170390
170391
170392
170393
170394
170395
170396
170397
170398
170399
170400
170401
170402
170403
170404
170405
170406
170407
170408
170409
170410
170411
170412
170413
170414
170415
170416
170417
170418
170419
170420
170421
170422
170423
170424
170425
170426
170427
170428
170429
170430
170431
170432
170433
170434
170435
170436
170437
170438
170439
170440
170441
170442
170443
170444
170445
170446
170447
170448
170449
170450
170451
170452
170453
170454
170455
170456
170457
170458
170459
170460
170461
170462
170463
170464
170465
170466
170467
170468
170469
170470
170471
170472
170473
170474
170475
170476
170477
170478
170479
170480
170481
170482
170483
170484
170485
170486
170487
170488
170489
170490
170491
170492
170493
170494
170495
170496
170497
170498
170499
170500
170501
170502
170503
170504
170505
170506
170507
170508
170509
170510
170511
170512
170513
170514
170515
170516
170517
170518
170519
170520
170521
170522
170523
170524
170525
170526
170527
170528
170529
170530
170531
170532
170533
170534
170535
170536
170537
170538
170539
170540
170541
170542
170543
170544
170545
170546
170547
170548
170549
170550
170551
170552
170553
170554
170555
170556
170557
170558
170559
170560
170561
170562
170563
170564
170565
170566
170567
170568
170569
170570
170571
170572
170573
170574
170575
170576
170577
170578
170579
170580
170581
170582
170583
170584
170585
170586
170587
170588
170589
170590
170591
170592
170593
170594
170595
170596
170597
170598
170599
170600
170601
170602
170603
170604
170605
170606
170607
170608
170609
170610
170611
170612
170613
170614
170615
170616
170617
170618
170619
170620
170621
170622
170623
170624
170625
170626
170627
170628
170629
170630
170631
170632
170633
170634
170635
170636
170637
170638
170639
170640
170641
170642
170643
170644
170645
170646
170647
170648
170649
170650
170651
170652
170653
170654
170655
170656
170657
170658
170659
170660
170661
170662
170663
170664
170665
170666
170667
170668
170669
170670
170671
170672
170673
170674
170675
170676
170677
170678
170679
170680
170681
170682
170683
170684
170685
170686
170687
170688
170689
170690
170691
170692
170693
170694
170695
170696
170697
170698
170699
170700
170701
170702
170703
170704
170705
170706
170707
170708
170709
170710
170711
170712
170713
170714
170715
170716
170717
170718
170719
170720
170721
170722
170723
170724
170725
170726
170727
170728
170729
170730
170731
170732
170733
170734
170735
170736
170737
170738
170739
170740
170741
170742
170743
170744
170745
170746
170747
170748
170749
170750
170751
170752
170753
170754
170755
170756
170757
170758
170759
170760
170761
170762
170763
170764
170765
170766
170767
170768
170769
170770
170771
170772
170773
170774
170775
170776
170777
170778
170779
170780
170781
170782
170783
170784
170785
170786
170787
170788
170789
170790
170791
170792
170793
170794
170795
170796
170797
170798
170799
170800
170801
170802
170803
170804
170805
170806
170807
170808
170809
170810
170811
170812
170813
170814
170815
170816
170817
170818
170819
170820
170821
170822
170823
170824
170825
170826
170827
170828
170829
170830
170831
170832
170833
170834
170835
170836
170837
170838
170839
170840
170841
170842
170843
170844
170845
170846
170847
170848
170849
170850
170851
170852
170853
170854
170855
170856
170857
170858
170859
170860
170861
170862
170863
170864
170865
170866
170867
170868
170869
170870
170871
170872
170873
170874
170875
170876
170877
170878
170879
170880
170881
170882
170883
170884
170885
170886
170887
170888
170889
170890
170891
170892
170893
170894
170895
170896
170897
170898
170899
170900
170901
170902
170903
170904
170905
170906
170907
170908
170909
170910
170911
170912
170913
170914
170915
170916
170917
170918
170919
170920
170921
170922
170923
170924
170925
170926
170927
170928
170929
170930
170931
170932
170933
170934
170935
170936
170937
170938
170939
170940
170941
170942
170943
170944
170945
170946
170947
170948
170949
170950
170951
170952
170953
170954
170955
170956
170957
170958
170959
170960
170961
170962
170963
170964
170965
170966
170967
170968
170969
170970
170971
170972
170973
170974
170975
170976
170977
170978
170979
170980
170981
170982
170983
170984
170985
170986
170987
170988
170989
170990
170991
170992
170993
170994
170995
170996
170997
170998
170999
171000
171001
171002
171003
171004
171005
171006
171007
171008
171009
171010
171011
171012
171013
171014
171015
171016
171017
171018
171019
171020
171021
171022
171023
171024
171025
171026
171027
171028
171029
171030
171031
171032
171033
171034
171035
171036
171037
171038
171039
171040
171041
171042
171043
171044
171045
171046
171047
171048
171049
171050
171051
171052
171053
171054
171055
171056
171057
171058
171059
171060
171061
171062
171063
171064
171065
171066
171067
171068
171069
171070
171071
171072
171073
171074
171075
171076
171077
171078
171079
171080
171081
171082
171083
171084
171085
171086
171087
171088
171089
171090
171091
171092
171093
171094
171095
171096
171097
171098
171099
171100
171101
171102
171103
171104
171105
171106
171107
171108
171109
171110
171111
171112
171113
171114
171115
171116
171117
171118
171119
171120
171121
171122
171123
171124
171125
171126
171127
171128
171129
171130
171131
171132
171133
171134
171135
171136
171137
171138
171139
171140
171141
171142
171143
171144
171145
171146
171147
171148
171149
171150
171151
171152
171153
171154
171155
171156
171157
171158
171159
171160
171161
171162
171163
171164
171165
171166
171167
171168
171169
171170
171171
171172
171173
171174
171175
171176
171177
171178
171179
171180
171181
171182
171183
171184
171185
171186
171187
171188
171189
171190
171191
171192
171193
171194
171195
171196
171197
171198
171199
171200
171201
171202
171203
171204
171205
171206
171207
171208
171209
171210
171211
171212
171213
171214
171215
171216
171217
171218
171219
171220
171221
171222
171223
171224
171225
171226
171227
171228
171229
171230
171231
171232
171233
171234
171235
171236
171237
171238
171239
171240
171241
171242
171243
171244
171245
171246
171247
171248
171249
171250
171251
171252
171253
171254
171255
171256
171257
171258
171259
171260
171261
171262
171263
171264
171265
171266
171267
171268
171269
171270
171271
171272
171273
171274
171275
171276
171277
171278
171279
171280
171281
171282
171283
171284
171285
171286
171287
171288
171289
171290
171291
171292
171293
171294
171295
171296
171297
171298
171299
171300
171301
171302
171303
171304
171305
171306
171307
171308
171309
171310
171311
171312
171313
171314
171315
171316
171317
171318
171319
171320
171321
171322
171323
171324
171325
171326
171327
171328
171329
171330
171331
171332
171333
171334
171335
171336
171337
171338
171339
171340
171341
171342
171343
171344
171345
171346
171347
171348
171349
171350
171351
171352
171353
171354
171355
171356
171357
171358
171359
171360
171361
171362
171363
171364
171365
171366
171367
171368
171369
171370
171371
171372
171373
171374
171375
171376
171377
171378
171379
171380
171381
171382
171383
171384
171385
171386
171387
171388
171389
171390
171391
171392
171393
171394
171395
171396
171397
171398
171399
171400
171401
171402
171403
171404
171405
171406
171407
171408
171409
171410
171411
171412
171413
171414
171415
171416
171417
171418
171419
171420
171421
171422
171423
171424
171425
171426
171427
171428
171429
171430
171431
171432
171433
171434
171435
171436
171437
171438
171439
171440
171441
171442
171443
171444
171445
171446
171447
171448
171449
171450
171451
171452
171453
171454
171455
171456
171457
171458
171459
171460
171461
171462
171463
171464
171465
171466
171467
171468
171469
171470
171471
171472
171473
171474
171475
171476
171477
171478
171479
171480
171481
171482
171483
171484
171485
171486
171487
171488
171489
171490
171491
171492
171493
171494
171495
171496
171497
171498
171499
171500
171501
171502
171503
171504
171505
171506
171507
171508
171509
171510
171511
171512
171513
171514
171515
171516
171517
171518
171519
171520
171521
171522
171523
171524
171525
171526
171527
171528
171529
171530
171531
171532
171533
171534
171535
171536
171537
171538
171539
171540
171541
171542
171543
171544
171545
171546
171547
171548
171549
171550
171551
171552
171553
171554
171555
171556
171557
171558
171559
171560
171561
171562
171563
171564
171565
171566
171567
171568
171569
171570
171571
171572
171573
171574
171575
171576
171577
171578
171579
171580
171581
171582
171583
171584
171585
171586
171587
171588
171589
171590
171591
171592
171593
171594
171595
171596
171597
171598
171599
171600
171601
171602
171603
171604
171605
171606
171607
171608
171609
171610
171611
171612
171613
171614
171615
171616
171617
171618
171619
171620
171621
171622
171623
171624
171625
171626
171627
171628
171629
171630
171631
171632
171633
171634
171635
171636
171637
171638
171639
171640
171641
171642
171643
171644
171645
171646
171647
171648
171649
171650
171651
171652
171653
171654
171655
171656
171657
171658
171659
171660
171661
171662
171663
171664
171665
171666
171667
171668
171669
171670
171671
171672
171673
171674
171675
171676
171677
171678
171679
171680
171681
171682
171683
171684
171685
171686
171687
171688
171689
171690
171691
171692
171693
171694
171695
171696
171697
171698
171699
171700
171701
171702
171703
171704
171705
171706
171707
171708
171709
171710
171711
171712
171713
171714
171715
171716
171717
171718
171719
171720
171721
171722
171723
171724
171725
171726
171727
171728
171729
171730
171731
171732
171733
171734
171735
171736
171737
171738
171739
171740
171741
171742
171743
171744
171745
171746
171747
171748
171749
171750
171751
171752
171753
171754
171755
171756
171757
171758
171759
171760
171761
171762
171763
171764
171765
171766
171767
171768
171769
171770
171771
171772
171773
171774
171775
171776
171777
171778
171779
171780
171781
171782
171783
171784
171785
171786
171787
171788
171789
171790
171791
171792
171793
171794
171795
171796
171797
171798
171799
171800
171801
171802
171803
171804
171805
171806
171807
171808
171809
171810
171811
171812
171813
171814
171815
171816
171817
171818
171819
171820
171821
171822
171823
171824
171825
171826
171827
171828
171829
171830
171831
171832
171833
171834
171835
171836
171837
171838
171839
171840
171841
171842
171843
171844
171845
171846
171847
171848
171849
171850
171851
171852
171853
171854
171855
171856
171857
171858
171859
171860
171861
171862
171863
171864
171865
171866
171867
171868
171869
171870
171871
171872
171873
171874
171875
171876
171877
171878
171879
171880
171881
171882
171883
171884
171885
171886
171887
171888
171889
171890
171891
171892
171893
171894
171895
171896
171897
171898
171899
171900
171901
171902
171903
171904
171905
171906
171907
171908
171909
171910
171911
171912
171913
171914
171915
171916
171917
171918
171919
171920
171921
171922
171923
171924
171925
171926
171927
171928
171929
171930
171931
171932
171933
171934
171935
171936
171937
171938
171939
171940
171941
171942
171943
171944
171945
171946
171947
171948
171949
171950
171951
171952
171953
171954
171955
171956
171957
171958
171959
171960
171961
171962
171963
171964
171965
171966
171967
171968
171969
171970
171971
171972
171973
171974
171975
171976
171977
171978
171979
171980
171981
171982
171983
171984
171985
171986
171987
171988
171989
171990
171991
171992
171993
171994
171995
171996
171997
171998
171999
172000
172001
172002
172003
172004
172005
172006
172007
172008
172009
172010
172011
172012
172013
172014
172015
172016
172017
172018
172019
172020
172021
172022
172023
172024
172025
172026
172027
172028
172029
172030
172031
172032
172033
172034
172035
172036
172037
172038
172039
172040
172041
172042
172043
172044
172045
172046
172047
172048
172049
172050
172051
172052
172053
172054
172055
172056
172057
172058
172059
172060
172061
172062
172063
172064
172065
172066
172067
172068
172069
172070
172071
172072
172073
172074
172075
172076
172077
172078
172079
172080
172081
172082
172083
172084
172085
172086
172087
172088
172089
172090
172091
172092
172093
172094
172095
172096
172097
172098
172099
172100
172101
172102
172103
172104
172105
172106
172107
172108
172109
172110
172111
172112
172113
172114
172115
172116
172117
172118
172119
172120
172121
172122
172123
172124
172125
172126
172127
172128
172129
172130
172131
172132
172133
172134
172135
172136
172137
172138
172139
172140
172141
172142
172143
172144
172145
172146
172147
172148
172149
172150
172151
172152
172153
172154
172155
172156
172157
172158
172159
172160
172161
172162
172163
172164
172165
172166
172167
172168
172169
172170
172171
172172
172173
172174
172175
172176
172177
172178
172179
172180
172181
172182
172183
172184
172185
172186
172187
172188
172189
172190
172191
172192
172193
172194
172195
172196
172197
172198
172199
172200
172201
172202
172203
172204
172205
172206
172207
172208
172209
172210
172211
172212
172213
172214
172215
172216
172217
172218
172219
172220
172221
172222
172223
172224
172225
172226
172227
172228
172229
172230
172231
172232
172233
172234
172235
172236
172237
172238
172239
172240
172241
172242
172243
172244
172245
172246
172247
172248
172249
172250
172251
172252
172253
172254
172255
172256
172257
172258
172259
172260
172261
172262
172263
172264
172265
172266
172267
172268
172269
172270
172271
172272
172273
172274
172275
172276
172277
172278
172279
172280
172281
172282
172283
172284
172285
172286
172287
172288
172289
172290
172291
172292
172293
172294
172295
172296
172297
172298
172299
172300
172301
172302
172303
172304
172305
172306
172307
172308
172309
172310
172311
172312
172313
172314
172315
172316
172317
172318
172319
172320
172321
172322
172323
172324
172325
172326
172327
172328
172329
172330
172331
172332
172333
172334
172335
172336
172337
172338
172339
172340
172341
172342
172343
172344
172345
172346
172347
172348
172349
172350
172351
172352
172353
172354
172355
172356
172357
172358
172359
172360
172361
172362
172363
172364
172365
172366
172367
172368
172369
172370
172371
172372
172373
172374
172375
172376
172377
172378
172379
172380
172381
172382
172383
172384
172385
172386
172387
172388
172389
172390
172391
172392
172393
172394
172395
172396
172397
172398
172399
172400
172401
172402
172403
172404
172405
172406
172407
172408
172409
172410
172411
172412
172413
172414
172415
172416
172417
172418
172419
172420
172421
172422
172423
172424
172425
172426
172427
172428
172429
172430
172431
172432
172433
172434
172435
172436
172437
172438
172439
172440
172441
172442
172443
172444
172445
172446
172447
172448
172449
172450
172451
172452
172453
172454
172455
172456
172457
172458
172459
172460
172461
172462
172463
172464
172465
172466
172467
172468
172469
172470
172471
172472
172473
172474
172475
172476
172477
172478
172479
172480
172481
172482
172483
172484
172485
172486
172487
172488
172489
172490
172491
172492
172493
172494
172495
172496
172497
172498
172499
172500
172501
172502
172503
172504
172505
172506
172507
172508
172509
172510
172511
172512
172513
172514
172515
172516
172517
172518
172519
172520
172521
172522
172523
172524
172525
172526
172527
172528
172529
172530
172531
172532
172533
172534
172535
172536
172537
172538
172539
172540
172541
172542
172543
172544
172545
172546
172547
172548
172549
172550
172551
172552
172553
172554
172555
172556
172557
172558
172559
172560
172561
172562
172563
172564
172565
172566
172567
172568
172569
172570
172571
172572
172573
172574
172575
172576
172577
172578
172579
172580
172581
172582
172583
172584
172585
172586
172587
172588
172589
172590
172591
172592
172593
172594
172595
172596
172597
172598
172599
172600
172601
172602
172603
172604
172605
172606
172607
172608
172609
172610
172611
172612
172613
172614
172615
172616
172617
172618
172619
172620
172621
172622
172623
172624
172625
172626
172627
172628
172629
172630
172631
172632
172633
172634
172635
172636
172637
172638
172639
172640
172641
172642
172643
172644
172645
172646
172647
172648
172649
172650
172651
172652
172653
172654
172655
172656
172657
172658
172659
172660
172661
172662
172663
172664
172665
172666
172667
172668
172669
172670
172671
172672
172673
172674
172675
172676
172677
172678
172679
172680
172681
172682
172683
172684
172685
172686
172687
172688
172689
172690
172691
172692
172693
172694
172695
172696
172697
172698
172699
172700
172701
172702
172703
172704
172705
172706
172707
172708
172709
172710
172711
172712
172713
172714
172715
172716
172717
172718
172719
172720
172721
172722
172723
172724
172725
172726
172727
172728
172729
172730
172731
172732
172733
172734
172735
172736
172737
172738
172739
172740
172741
172742
172743
172744
172745
172746
172747
172748
172749
172750
172751
172752
172753
172754
172755
172756
172757
172758
172759
172760
172761
172762
172763
172764
172765
172766
172767
172768
172769
172770
172771
172772
172773
172774
172775
172776
172777
172778
172779
172780
172781
172782
172783
172784
172785
172786
172787
172788
172789
172790
172791
172792
172793
172794
172795
172796
172797
172798
172799
172800
172801
172802
172803
172804
172805
172806
172807
172808
172809
172810
172811
172812
172813
172814
172815
172816
172817
172818
172819
172820
172821
172822
172823
172824
172825
172826
172827
172828
172829
172830
172831
172832
172833
172834
172835
172836
172837
172838
172839
172840
172841
172842
172843
172844
172845
172846
172847
172848
172849
172850
172851
172852
172853
172854
172855
172856
172857
172858
172859
172860
172861
172862
172863
172864
172865
172866
172867
172868
172869
172870
172871
172872
172873
172874
172875
172876
172877
172878
172879
172880
172881
172882
172883
172884
172885
172886
172887
172888
172889
172890
172891
172892
172893
172894
172895
172896
172897
172898
172899
172900
172901
172902
172903
172904
172905
172906
172907
172908
172909
172910
172911
172912
172913
172914
172915
172916
172917
172918
172919
172920
172921
172922
172923
172924
172925
172926
172927
172928
172929
172930
172931
172932
172933
172934
172935
172936
172937
172938
172939
172940
172941
172942
172943
172944
172945
172946
172947
172948
172949
172950
172951
172952
172953
172954
172955
172956
172957
172958
172959
172960
172961
172962
172963
172964
172965
172966
172967
172968
172969
172970
172971
172972
172973
172974
172975
172976
172977
172978
172979
172980
172981
172982
172983
172984
172985
172986
172987
172988
172989
172990
172991
172992
172993
172994
172995
172996
172997
172998
172999
173000
173001
173002
173003
173004
173005
173006
173007
173008
173009
173010
173011
173012
173013
173014
173015
173016
173017
173018
173019
173020
173021
173022
173023
173024
173025
173026
173027
173028
173029
173030
173031
173032
173033
173034
173035
173036
173037
173038
173039
173040
173041
173042
173043
173044
173045
173046
173047
173048
173049
173050
173051
173052
173053
173054
173055
173056
173057
173058
173059
173060
173061
173062
173063
173064
173065
173066
173067
173068
173069
173070
173071
173072
173073
173074
173075
173076
173077
173078
173079
173080
173081
173082
173083
173084
173085
173086
173087
173088
173089
173090
173091
173092
173093
173094
173095
173096
173097
173098
173099
173100
173101
173102
173103
173104
173105
173106
173107
173108
173109
173110
173111
173112
173113
173114
173115
173116
173117
173118
173119
173120
173121
173122
173123
173124
173125
173126
173127
173128
173129
173130
173131
173132
173133
173134
173135
173136
173137
173138
173139
173140
173141
173142
173143
173144
173145
173146
173147
173148
173149
173150
173151
173152
173153
173154
173155
173156
173157
173158
173159
173160
173161
173162
173163
173164
173165
173166
173167
173168
173169
173170
173171
173172
173173
173174
173175
173176
173177
173178
173179
173180
173181
173182
173183
173184
173185
173186
173187
173188
173189
173190
173191
173192
173193
173194
173195
173196
173197
173198
173199
173200
173201
173202
173203
173204
173205
173206
173207
173208
173209
173210
173211
173212
173213
173214
173215
173216
173217
173218
173219
173220
173221
173222
173223
173224
173225
173226
173227
173228
173229
173230
173231
173232
173233
173234
173235
173236
173237
173238
173239
173240
173241
173242
173243
173244
173245
173246
173247
173248
173249
173250
173251
173252
173253
173254
173255
173256
173257
173258
173259
173260
173261
173262
173263
173264
173265
173266
173267
173268
173269
173270
173271
173272
173273
173274
173275
173276
173277
173278
173279
173280
173281
173282
173283
173284
173285
173286
173287
173288
173289
173290
173291
173292
173293
173294
173295
173296
173297
173298
173299
173300
173301
173302
173303
173304
173305
173306
173307
173308
173309
173310
173311
173312
173313
173314
173315
173316
173317
173318
173319
173320
173321
173322
173323
173324
173325
173326
173327
173328
173329
173330
173331
173332
173333
173334
173335
173336
173337
173338
173339
173340
173341
173342
173343
173344
173345
173346
173347
173348
173349
173350
173351
173352
173353
173354
173355
173356
173357
173358
173359
173360
173361
173362
173363
173364
173365
173366
173367
173368
173369
173370
173371
173372
173373
173374
173375
173376
173377
173378
173379
173380
173381
173382
173383
173384
173385
173386
173387
173388
173389
173390
173391
173392
173393
173394
173395
173396
173397
173398
173399
173400
173401
173402
173403
173404
173405
173406
173407
173408
173409
173410
173411
173412
173413
173414
173415
173416
173417
173418
173419
173420
173421
173422
173423
173424
173425
173426
173427
173428
173429
173430
173431
173432
173433
173434
173435
173436
173437
173438
173439
173440
173441
173442
173443
173444
173445
173446
173447
173448
173449
173450
173451
173452
173453
173454
173455
173456
173457
173458
173459
173460
173461
173462
173463
173464
173465
173466
173467
173468
173469
173470
173471
173472
173473
173474
173475
173476
173477
173478
173479
173480
173481
173482
173483
173484
173485
173486
173487
173488
173489
173490
173491
173492
173493
173494
173495
173496
173497
173498
173499
173500
173501
173502
173503
173504
173505
173506
173507
173508
173509
173510
173511
173512
173513
173514
173515
173516
173517
173518
173519
173520
173521
173522
173523
173524
173525
173526
173527
173528
173529
173530
173531
173532
173533
173534
173535
173536
173537
173538
173539
173540
173541
173542
173543
173544
173545
173546
173547
173548
173549
173550
173551
173552
173553
173554
173555
173556
173557
173558
173559
173560
173561
173562
173563
173564
173565
173566
173567
173568
173569
173570
173571
173572
173573
173574
173575
173576
173577
173578
173579
173580
173581
173582
173583
173584
173585
173586
173587
173588
173589
173590
173591
173592
173593
173594
173595
173596
173597
173598
173599
173600
173601
173602
173603
173604
173605
173606
173607
173608
173609
173610
173611
173612
173613
173614
173615
173616
173617
173618
173619
173620
173621
173622
173623
173624
173625
173626
173627
173628
173629
173630
173631
173632
173633
173634
173635
173636
173637
173638
173639
173640
173641
173642
173643
173644
173645
173646
173647
173648
173649
173650
173651
173652
173653
173654
173655
173656
173657
173658
173659
173660
173661
173662
173663
173664
173665
173666
173667
173668
173669
173670
173671
173672
173673
173674
173675
173676
173677
173678
173679
173680
173681
173682
173683
173684
173685
173686
173687
173688
173689
173690
173691
173692
173693
173694
173695
173696
173697
173698
173699
173700
173701
173702
173703
173704
173705
173706
173707
173708
173709
173710
173711
173712
173713
173714
173715
173716
173717
173718
173719
173720
173721
173722
173723
173724
173725
173726
173727
173728
173729
173730
173731
173732
173733
173734
173735
173736
173737
173738
173739
173740
173741
173742
173743
173744
173745
173746
173747
173748
173749
173750
173751
173752
173753
173754
173755
173756
173757
173758
173759
173760
173761
173762
173763
173764
173765
173766
173767
173768
173769
173770
173771
173772
173773
173774
173775
173776
173777
173778
173779
173780
173781
173782
173783
173784
173785
173786
173787
173788
173789
173790
173791
173792
173793
173794
173795
173796
173797
173798
173799
173800
173801
173802
173803
173804
173805
173806
173807
173808
173809
173810
173811
173812
173813
173814
173815
173816
173817
173818
173819
173820
173821
173822
173823
173824
173825
173826
173827
173828
173829
173830
173831
173832
173833
173834
173835
173836
173837
173838
173839
173840
173841
173842
173843
173844
173845
173846
173847
173848
173849
173850
173851
173852
173853
173854
173855
173856
173857
173858
173859
173860
173861
173862
173863
173864
173865
173866
173867
173868
173869
173870
173871
173872
173873
173874
173875
173876
173877
173878
173879
173880
173881
173882
173883
173884
173885
173886
173887
173888
173889
173890
173891
173892
173893
173894
173895
173896
173897
173898
173899
173900
173901
173902
173903
173904
173905
173906
173907
173908
173909
173910
173911
173912
173913
173914
173915
173916
173917
173918
173919
173920
173921
173922
173923
173924
173925
173926
173927
173928
173929
173930
173931
173932
173933
173934
173935
173936
173937
173938
173939
173940
173941
173942
173943
173944
173945
173946
173947
173948
173949
173950
173951
173952
173953
173954
173955
173956
173957
173958
173959
173960
173961
173962
173963
173964
173965
173966
173967
173968
173969
173970
173971
173972
173973
173974
173975
173976
173977
173978
173979
173980
173981
173982
173983
173984
173985
173986
173987
173988
173989
173990
173991
173992
173993
173994
173995
173996
173997
173998
173999
174000
174001
174002
174003
174004
174005
174006
174007
174008
174009
174010
174011
174012
174013
174014
174015
174016
174017
174018
174019
174020
174021
174022
174023
174024
174025
174026
174027
174028
174029
174030
174031
174032
174033
174034
174035
174036
174037
174038
174039
174040
174041
174042
174043
174044
174045
174046
174047
174048
174049
174050
174051
174052
174053
174054
174055
174056
174057
174058
174059
174060
174061
174062
174063
174064
174065
174066
174067
174068
174069
174070
174071
174072
174073
174074
174075
174076
174077
174078
174079
174080
174081
174082
174083
174084
174085
174086
174087
174088
174089
174090
174091
174092
174093
174094
174095
174096
174097
174098
174099
174100
174101
174102
174103
174104
174105
174106
174107
174108
174109
174110
174111
174112
174113
174114
174115
174116
174117
174118
174119
174120
174121
174122
174123
174124
174125
174126
174127
174128
174129
174130
174131
174132
174133
174134
174135
174136
174137
174138
174139
174140
174141
174142
174143
174144
174145
174146
174147
174148
174149
174150
174151
174152
174153
174154
174155
174156
174157
174158
174159
174160
174161
174162
174163
174164
174165
174166
174167
174168
174169
174170
174171
174172
174173
174174
174175
174176
174177
174178
174179
174180
174181
174182
174183
174184
174185
174186
174187
174188
174189
174190
174191
174192
174193
174194
174195
174196
174197
174198
174199
174200
174201
174202
174203
174204
174205
174206
174207
174208
174209
174210
174211
174212
174213
174214
174215
174216
174217
174218
174219
174220
174221
174222
174223
174224
174225
174226
174227
174228
174229
174230
174231
174232
174233
174234
174235
174236
174237
174238
174239
174240
174241
174242
174243
174244
174245
174246
174247
174248
174249
174250
174251
174252
174253
174254
174255
174256
174257
174258
174259
174260
174261
174262
174263
174264
174265
174266
174267
174268
174269
174270
174271
174272
174273
174274
174275
174276
174277
174278
174279
174280
174281
174282
174283
174284
174285
174286
174287
174288
174289
174290
174291
174292
174293
174294
174295
174296
174297
174298
174299
174300
174301
174302
174303
174304
174305
174306
174307
174308
174309
174310
174311
174312
174313
174314
174315
174316
174317
174318
174319
174320
174321
174322
174323
174324
174325
174326
174327
174328
174329
174330
174331
174332
174333
174334
174335
174336
174337
174338
174339
174340
174341
174342
174343
174344
174345
174346
174347
174348
174349
174350
174351
174352
174353
174354
174355
174356
174357
174358
174359
174360
174361
174362
174363
174364
174365
174366
174367
174368
174369
174370
174371
174372
174373
174374
174375
174376
174377
174378
174379
174380
174381
174382
174383
174384
174385
174386
174387
174388
174389
174390
174391
174392
174393
174394
174395
174396
174397
174398
174399
174400
174401
174402
174403
174404
174405
174406
174407
174408
174409
174410
174411
174412
174413
174414
174415
174416
174417
174418
174419
174420
174421
174422
174423
174424
174425
174426
174427
174428
174429
174430
174431
174432
174433
174434
174435
174436
174437
174438
174439
174440
174441
174442
174443
174444
174445
174446
174447
174448
174449
174450
174451
174452
174453
174454
174455
174456
174457
174458
174459
174460
174461
174462
174463
174464
174465
174466
174467
174468
174469
174470
174471
174472
174473
174474
174475
174476
174477
174478
174479
174480
174481
174482
174483
174484
174485
174486
174487
174488
174489
174490
174491
174492
174493
174494
174495
174496
174497
174498
174499
174500
174501
174502
174503
174504
174505
174506
174507
174508
174509
174510
174511
174512
174513
174514
174515
174516
174517
174518
174519
174520
174521
174522
174523
174524
174525
174526
174527
174528
174529
174530
174531
174532
174533
174534
174535
174536
174537
174538
174539
174540
174541
174542
174543
174544
174545
174546
174547
174548
174549
174550
174551
174552
174553
174554
174555
174556
174557
174558
174559
174560
174561
174562
174563
174564
174565
174566
174567
174568
174569
174570
174571
174572
174573
174574
174575
174576
174577
174578
174579
174580
174581
174582
174583
174584
174585
174586
174587
174588
174589
174590
174591
174592
174593
174594
174595
174596
174597
174598
174599
174600
174601
174602
174603
174604
174605
174606
174607
174608
174609
174610
174611
174612
174613
174614
174615
174616
174617
174618
174619
174620
174621
174622
174623
174624
174625
174626
174627
174628
174629
174630
174631
174632
174633
174634
174635
174636
174637
174638
174639
174640
174641
174642
174643
174644
174645
174646
174647
174648
174649
174650
174651
174652
174653
174654
174655
174656
174657
174658
174659
174660
174661
174662
174663
174664
174665
174666
174667
174668
174669
174670
174671
174672
174673
174674
174675
174676
174677
174678
174679
174680
174681
174682
174683
174684
174685
174686
174687
174688
174689
174690
174691
174692
174693
174694
174695
174696
174697
174698
174699
174700
174701
174702
174703
174704
174705
174706
174707
174708
174709
174710
174711
174712
174713
174714
174715
174716
174717
174718
@misc{rfc1,
  author="S. Crocker",
  title="{Host Software}",
  howpublished="RFC 1",
  series="Internet Request for Comments",
  type="RFC",
  number="1",
  pages="1--11",
  year=1969,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1.txt",
  key="RFC 1",
  doi="10.17487/RFC0001",
  }

@misc{rfc2,
  author="B. Duvall",
  title="{Host software}",
  howpublished="RFC 2",
  series="Internet Request for Comments",
  type="RFC",
  number="2",
  pages="1--10",
  year=1969,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2.txt",
  key="RFC 2",
  doi="10.17487/RFC0002",
  }

@misc{rfc3,
  author="S.D. Crocker",
  title="{Documentation conventions}",
  howpublished="RFC 3",
  series="Internet Request for Comments",
  type="RFC",
  number="3",
  pages="1--2",
  year=1969,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 10",
url="https://www.rfc-editor.org/rfc/rfc3.txt",
  key="RFC 3",
  doi="10.17487/RFC0003",
  }

@misc{rfc4,
  author="E.B. Shapiro",
  title="{Network timetable}",
  howpublished="RFC 4",
  series="Internet Request for Comments",
  type="RFC",
  number="4",
  pages="1--6",
  year=1969,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4.txt",
  key="RFC 4",
  doi="10.17487/RFC0004",
  }

@misc{rfc5,
  author="J. Rulifson",
  title="{Decode Encode Language (DEL)}",
  howpublished="RFC 5",
  series="Internet Request for Comments",
  type="RFC",
  number="5",
  pages="1--17",
  year=1969,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5.txt",
  key="RFC 5",
  doi="10.17487/RFC0005",
  }

@misc{rfc6,
  author="S.D. Crocker",
  title="{Conversation with Bob Kahn}",
  howpublished="RFC 6",
  series="Internet Request for Comments",
  type="RFC",
  number="6",
  pages="1--1",
  year=1969,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6.txt",
  key="RFC 6",
  doi="10.17487/RFC0006",
  }

@misc{rfc7,
  author="G. Deloche",
  title="{Host-IMP interface}",
  howpublished="RFC 7",
  series="Internet Request for Comments",
  type="RFC",
  number="7",
  pages="1--7",
  year=1969,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7.txt",
  key="RFC 7",
  doi="10.17487/RFC0007",
  }

@misc{rfc8,
  author="G. Deloche",
  title="{ARPA Network Functional Specifications}",
  howpublished="RFC 8",
  series="Internet Request for Comments",
  type="RFC",
  number="8",
  year=1969,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8.txt",
  key="RFC 8",
  doi="10.17487/RFC0008",
  }

@misc{rfc9,
  author="G. Deloche",
  title="{Host Software}",
  howpublished="RFC 9",
  series="Internet Request for Comments",
  type="RFC",
  number="9",
  year=1969,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc9.txt",
  key="RFC 9",
  doi="10.17487/RFC0009",
  }

@misc{rfc10,
  author="S.D. Crocker",
  title="{Documentation conventions}",
  howpublished="RFC 10",
  series="Internet Request for Comments",
  type="RFC",
  number="10",
  pages="1--3",
  year=1969,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 16, updated by RFCs 24, 27, 30",
url="https://www.rfc-editor.org/rfc/rfc10.txt",
  key="RFC 10",
  doi="10.17487/RFC0010",
  }

@misc{rfc11,
  author="G. Deloche",
  title="{Implementation of the Host - Host Software Procedures in GORDO}",
  howpublished="RFC 11",
  series="Internet Request for Comments",
  type="RFC",
  number="11",
  pages="1--23",
  year=1969,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 33",
url="https://www.rfc-editor.org/rfc/rfc11.txt",
  key="RFC 11",
  doi="10.17487/RFC0011",
  }

@misc{rfc12,
  author="M. Wingfield",
  title="{IMP-Host interface flow diagrams}",
  howpublished="RFC 12",
  series="Internet Request for Comments",
  type="RFC",
  number="12",
  pages="1--1",
  year=1969,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc12.txt",
  key="RFC 12",
  doi="10.17487/RFC0012",
  }

@misc{rfc13,
  author="V. Cerf",
  title="{Zero Text Length EOF Message}",
  howpublished="RFC 13",
  series="Internet Request for Comments",
  type="RFC",
  number="13",
  pages="1--1",
  year=1969,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc13.txt",
  key="RFC 13",
  doi="10.17487/RFC0013",
  }

@misc{rfc15,
  author="C.S. Carr",
  title="{Network subsystem for time sharing hosts}",
  howpublished="RFC 15",
  series="Internet Request for Comments",
  type="RFC",
  number="15",
  pages="1--5",
  year=1969,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc15.txt",
  key="RFC 15",
  doi="10.17487/RFC0015",
  }

@misc{rfc16,
  author="S. Crocker",
  title="{M.I.T}",
  howpublished="RFC 16",
  series="Internet Request for Comments",
  type="RFC",
  number="16",
  pages="1--1",
  year=1969,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 24, updated by RFCs 24, 27, 30",
url="https://www.rfc-editor.org/rfc/rfc16.txt",
  key="RFC 16",
  doi="10.17487/RFC0016",
  }

@misc{rfc17,
  author="J.E. Kreznar",
  title="{Some questions re: Host-IMP Protocol}",
  howpublished="RFC 17",
  series="Internet Request for Comments",
  type="RFC",
  number="17",
  pages="1--4",
  year=1969,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc17.txt",
  key="RFC 17",
  doi="10.17487/RFC0017",
  }

@misc{rfc18,
  author="V. Cerf",
  title="{IMP-IMP and HOST-HOST Control Links}",
  howpublished="RFC 18",
  series="Internet Request for Comments",
  type="RFC",
  number="18",
  pages="1--1",
  year=1969,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc18.txt",
  key="RFC 18",
  doi="10.17487/RFC0018",
  }

@misc{rfc19,
  author="J.E. Kreznar",
  title="{Two protocol suggestions to reduce congestion at swap bound nodes}",
  howpublished="RFC 19",
  series="Internet Request for Comments",
  type="RFC",
  number="19",
  pages="1--2",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc19.txt",
  key="RFC 19",
  doi="10.17487/RFC0019",
  }

@misc{rfc20,
  author="V.G. Cerf",
  title="{ASCII format for network interchange}",
  howpublished="RFC 20 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="20",
  pages="1--9",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc20.txt",
  key="RFC 20",
  doi="10.17487/RFC0020",
  }

@misc{rfc21,
  author="V.G. Cerf",
  title="{Network meeting}",
  howpublished="RFC 21",
  series="Internet Request for Comments",
  type="RFC",
  number="21",
  pages="1--2",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc21.txt",
  key="RFC 21",
  doi="10.17487/RFC0021",
  }

@misc{rfc22,
  author="V.G. Cerf",
  title="{Host-host control message formats}",
  howpublished="RFC 22",
  series="Internet Request for Comments",
  type="RFC",
  number="22",
  pages="1--2",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc22.txt",
  key="RFC 22",
  doi="10.17487/RFC0022",
  }

@misc{rfc23,
  author="G. Gregg",
  title="{Transmission of Multiple Control Messages}",
  howpublished="RFC 23",
  series="Internet Request for Comments",
  type="RFC",
  number="23",
  pages="1--1",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc23.txt",
  key="RFC 23",
  doi="10.17487/RFC0023",
  }

@misc{rfc24,
  author="S.D. Crocker",
  title="{Documentation Conventions}",
  howpublished="RFC 24",
  series="Internet Request for Comments",
  type="RFC",
  number="24",
  pages="1--3",
  year=1969,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 27, 30",
url="https://www.rfc-editor.org/rfc/rfc24.txt",
  key="RFC 24",
  doi="10.17487/RFC0024",
  }

@misc{rfc25,
  author="S.D. Crocker",
  title="{No High Link Numbers}",
  howpublished="RFC 25",
  series="Internet Request for Comments",
  type="RFC",
  number="25",
  pages="1--1",
  year=1969,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc25.txt",
  key="RFC 25",
  doi="10.17487/RFC0025",
  }

@misc{rfc27,
  author="S.D. Crocker",
  title="{Documentation Conventions}",
  howpublished="RFC 27",
  series="Internet Request for Comments",
  type="RFC",
  number="27",
  pages="1--3",
  year=1969,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 30",
url="https://www.rfc-editor.org/rfc/rfc27.txt",
  key="RFC 27",
  doi="10.17487/RFC0027",
  }

@misc{rfc28,
  author="W.K. English",
  title="{Time Standards}",
  howpublished="RFC 28",
  series="Internet Request for Comments",
  type="RFC",
  number="28",
  pages="1--1",
  year=1970,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc28.txt",
  key="RFC 28",
  doi="10.17487/RFC0028",
  }

@misc{rfc29,
  author="R.E. Kahn",
  title="{Response to RFC 28}",
  howpublished="RFC 29",
  series="Internet Request for Comments",
  type="RFC",
  number="29",
  pages="1--1",
  year=1970,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc29.txt",
  key="RFC 29",
  doi="10.17487/RFC0029",
  }

@misc{rfc30,
  author="S.D. Crocker",
  title="{Documentation Conventions}",
  howpublished="RFC 30",
  series="Internet Request for Comments",
  type="RFC",
  number="30",
  pages="1--3",
  year=1970,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc30.txt",
  key="RFC 30",
  doi="10.17487/RFC0030",
  }

@misc{rfc31,
  author="D. Bobrow and W.R. Sutherland",
  title="{Binary Message Forms in Computer}",
  howpublished="RFC 31",
  series="Internet Request for Comments",
  type="RFC",
  number="31",
  pages="1--7",
  year=1968,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc31.txt",
  key="RFC 31",
  doi="10.17487/RFC0031",
  }

@misc{rfc32,
  author="J. Cole",
  title="{Some Thoughts on SRI's Proposed Real Time Clock}",
  howpublished="RFC 32",
  series="Internet Request for Comments",
  type="RFC",
  number="32",
  pages="1--1",
  year=1970,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc32.txt",
  key="RFC 32",
  doi="10.17487/RFC0032",
  }

@misc{rfc33,
  author="S.D. Crocker",
  title="{New Host-Host Protocol}",
  howpublished="RFC 33",
  series="Internet Request for Comments",
  type="RFC",
  number="33",
  pages="1--19",
  year=1970,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 36, 47",
url="https://www.rfc-editor.org/rfc/rfc33.txt",
  key="RFC 33",
  doi="10.17487/RFC0033",
  }

@misc{rfc34,
  author="W.K. English",
  title="{Some Brief Preliminary Notes on the Augmentation Research Center Clock}",
  howpublished="RFC 34",
  series="Internet Request for Comments",
  type="RFC",
  number="34",
  pages="1--2",
  year=1970,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc34.txt",
  key="RFC 34",
  doi="10.17487/RFC0034",
  }

@misc{rfc35,
  author="S.D. Crocker",
  title="{Network Meeting}",
  howpublished="RFC 35 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="35",
  pages="1--1",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc35.txt",
  key="RFC 35",
  doi="10.17487/RFC0035",
  }

@misc{rfc36,
  author="S.D. Crocker",
  title="{Protocol Notes}",
  howpublished="RFC 36",
  series="Internet Request for Comments",
  type="RFC",
  number="36",
  pages="1--8",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 39, 44",
url="https://www.rfc-editor.org/rfc/rfc36.txt",
  key="RFC 36",
  doi="10.17487/RFC0036",
  }

@misc{rfc37,
  author="S.D. Crocker",
  title="{Network Meeting Epilogue, etc}",
  howpublished="RFC 37",
  series="Internet Request for Comments",
  type="RFC",
  number="37",
  pages="1--5",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc37.txt",
  key="RFC 37",
  doi="10.17487/RFC0037",
  }

@misc{rfc38,
  author="S.M. Wolfe",
  title="{Comments on Network Protocol from NWG/RFC \#36}",
  howpublished="RFC 38",
  series="Internet Request for Comments",
  type="RFC",
  number="38",
  pages="1--1",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc38.txt",
  key="RFC 38",
  doi="10.17487/RFC0038",
  }

@misc{rfc39,
  author="E. Harslem and J.F. Heafner",
  title="{Comments on Protocol Re: NWG/RFC \#36}",
  howpublished="RFC 39",
  series="Internet Request for Comments",
  type="RFC",
  number="39",
  pages="1--3",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc39.txt",
  key="RFC 39",
  doi="10.17487/RFC0039",
  }

@misc{rfc40,
  author="E. Harslem and J.F. Heafner",
  title="{More Comments on the Forthcoming Protocol}",
  howpublished="RFC 40",
  series="Internet Request for Comments",
  type="RFC",
  number="40",
  pages="1--3",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc40.txt",
  key="RFC 40",
  doi="10.17487/RFC0040",
  }

@misc{rfc41,
  author="J.T. Melvin",
  title="{IMP-IMP Teletype Communication}",
  howpublished="RFC 41",
  series="Internet Request for Comments",
  type="RFC",
  number="41",
  pages="1--1",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc41.txt",
  key="RFC 41",
  doi="10.17487/RFC0041",
  }

@misc{rfc42,
  author="E. Ancona",
  title="{Message Data Types}",
  howpublished="RFC 42",
  series="Internet Request for Comments",
  type="RFC",
  number="42",
  pages="1--3",
  year=1970,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc42.txt",
  key="RFC 42",
  doi="10.17487/RFC0042",
  }

@misc{rfc43,
  author="A.G. Nemeth",
  title="{Proposed Meeting}",
  howpublished="RFC 43",
  series="Internet Request for Comments",
  type="RFC",
  number="43",
  pages="1--2",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc43.txt",
  key="RFC 43",
  doi="10.17487/RFC0043",
  }

@misc{rfc44,
  author="A. Shoshani and R. Long and A. Landsberg",
  title="{Comments on NWG/RFC 33 and 36}",
  howpublished="RFC 44",
  series="Internet Request for Comments",
  type="RFC",
  number="44",
  pages="1--3",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc44.txt",
  key="RFC 44",
  doi="10.17487/RFC0044",
  }

@misc{rfc45,
  author="J. Postel and S.D. Crocker",
  title="{New Protocol is Coming}",
  howpublished="RFC 45",
  series="Internet Request for Comments",
  type="RFC",
  number="45",
  pages="1--1",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc45.txt",
  key="RFC 45",
  doi="10.17487/RFC0045",
  }

@misc{rfc46,
  author="E. Meyer",
  title="{ARPA Network protocol notes}",
  howpublished="RFC 46",
  series="Internet Request for Comments",
  type="RFC",
  number="46",
  pages="1--17",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc46.txt",
  key="RFC 46",
  doi="10.17487/RFC0046",
  }

@misc{rfc47,
  author="J. Postel and S. Crocker",
  title="{BBN's Comments on NWG/RFC \#33}",
  howpublished="RFC 47",
  series="Internet Request for Comments",
  type="RFC",
  number="47",
  pages="1--4",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc47.txt",
  key="RFC 47",
  doi="10.17487/RFC0047",
  }

@misc{rfc48,
  author="J. Postel and S.D. Crocker",
  title="{Possible protocol plateau}",
  howpublished="RFC 48",
  series="Internet Request for Comments",
  type="RFC",
  number="48",
  pages="1--18",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc48.txt",
  key="RFC 48",
  doi="10.17487/RFC0048",
  }

@misc{rfc49,
  author="E. Meyer",
  title="{Conversations with S. Crocker (UCLA)}",
  howpublished="RFC 49",
  series="Internet Request for Comments",
  type="RFC",
  number="49",
  pages="1--5",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc49.txt",
  key="RFC 49",
  doi="10.17487/RFC0049",
  }

@misc{rfc50,
  author="E. Harslen and J. Heafner",
  title="{Comments on the Meyer Proposal}",
  howpublished="RFC 50",
  series="Internet Request for Comments",
  type="RFC",
  number="50",
  pages="1--2",
  year=1970,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc50.txt",
  key="RFC 50",
  doi="10.17487/RFC0050",
  }

@misc{rfc51,
  author="M. Elie",
  title="{Proposal for a Network Interchange Language}",
  howpublished="RFC 51",
  series="Internet Request for Comments",
  type="RFC",
  number="51",
  year=1970,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc51.txt",
  key="RFC 51",
  doi="10.17487/RFC0051",
  }

@misc{rfc52,
  author="J. Postel and S.D. Crocker",
  title="{Updated distribution list}",
  howpublished="RFC 52",
  series="Internet Request for Comments",
  type="RFC",
  number="52",
  pages="1--3",
  year=1970,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 69",
url="https://www.rfc-editor.org/rfc/rfc52.txt",
  key="RFC 52",
  doi="10.17487/RFC0052",
  }

@misc{rfc53,
  author="S.D. Crocker",
  title="{Official protocol mechanism}",
  howpublished="RFC 53",
  series="Internet Request for Comments",
  type="RFC",
  number="53",
  pages="1--1",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc53.txt",
  key="RFC 53",
  doi="10.17487/RFC0053",
  }

@misc{rfc54,
  author="S.D. Crocker and J. Postel and J. Newkirk and M. Kraley",
  title="{Official Protocol Proffering}",
  howpublished="RFC 54",
  series="Internet Request for Comments",
  type="RFC",
  number="54",
  pages="1--9",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 57",
url="https://www.rfc-editor.org/rfc/rfc54.txt",
  key="RFC 54",
  doi="10.17487/RFC0054",
  }

@misc{rfc55,
  author="J. Newkirk and M. Kraley and J. Postel and S.D. Crocker",
  title="{Prototypical implementation of the NCP}",
  howpublished="RFC 55",
  series="Internet Request for Comments",
  type="RFC",
  number="55",
  pages="1--23",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc55.txt",
  key="RFC 55",
  doi="10.17487/RFC0055",
  }

@misc{rfc56,
  author="E. Belove and D. Black and R. Flegal and L.G. Farquar",
  title="{Third Level Protocol: Logger Protocol}",
  howpublished="RFC 56",
  series="Internet Request for Comments",
  type="RFC",
  number="56",
  pages="1--6",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc56.txt",
  key="RFC 56",
  doi="10.17487/RFC0056",
  }

@misc{rfc57,
  author="M. Kraley and J. Newkirk",
  title="{Thoughts and Reflections on NWG/RFC 54}",
  howpublished="RFC 57",
  series="Internet Request for Comments",
  type="RFC",
  number="57",
  pages="1--5",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc57.txt",
  key="RFC 57",
  doi="10.17487/RFC0057",
  }

@misc{rfc58,
  author="T.P. Skinner",
  title="{Logical Message Synchronization}",
  howpublished="RFC 58",
  series="Internet Request for Comments",
  type="RFC",
  number="58",
  pages="1--2",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc58.txt",
  key="RFC 58",
  doi="10.17487/RFC0058",
  }

@misc{rfc59,
  author="E. Meyer",
  title="{Flow Control - Fixed Versus Demand Allocation}",
  howpublished="RFC 59",
  series="Internet Request for Comments",
  type="RFC",
  number="59",
  pages="1--7",
  year=1970,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc59.txt",
  key="RFC 59",
  doi="10.17487/RFC0059",
  }

@misc{rfc60,
  author="R. Kalin",
  title="{A Simplified NCP Protocol}",
  howpublished="RFC 60",
  series="Internet Request for Comments",
  type="RFC",
  number="60",
  pages="1--8",
  year=1970,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc60.txt",
  key="RFC 60",
  doi="10.17487/RFC0060",
  }

@misc{rfc61,
  author="D.C. Walden",
  title="{Note on Interprocess Communication in a Resource Sharing Computer Network}",
  howpublished="RFC 61",
  series="Internet Request for Comments",
  type="RFC",
  number="61",
  pages="1--18",
  year=1970,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 62",
url="https://www.rfc-editor.org/rfc/rfc61.txt",
  key="RFC 61",
  doi="10.17487/RFC0061",
  }

@misc{rfc62,
  author="D.C. Walden",
  title="{Systems for Interprocess Communication in a Resource Sharing Computer Network}",
  howpublished="RFC 62",
  series="Internet Request for Comments",
  type="RFC",
  number="62",
  pages="1--20",
  year=1970,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc62.txt",
  key="RFC 62",
  doi="10.17487/RFC0062",
  }

@misc{rfc63,
  author="V.G. Cerf",
  title="{Belated Network Meeting Report}",
  howpublished="RFC 63",
  series="Internet Request for Comments",
  type="RFC",
  number="63",
  pages="1--2",
  year=1970,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc63.txt",
  key="RFC 63",
  doi="10.17487/RFC0063",
  }

@misc{rfc64,
  author="M. Elie",
  title="{Getting rid of marking}",
  howpublished="RFC 64",
  series="Internet Request for Comments",
  type="RFC",
  number="64",
  pages="1--4",
  year=1970,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc64.txt",
  key="RFC 64",
  doi="10.17487/RFC0064",
  }

@misc{rfc65,
  author="D.C. Walden",
  title="{Comments on Host/Host Protocol document \#1}",
  howpublished="RFC 65",
  series="Internet Request for Comments",
  type="RFC",
  number="65",
  pages="1--2",
  year=1970,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc65.txt",
  key="RFC 65",
  doi="10.17487/RFC0065",
  }

@misc{rfc66,
  author="S.D. Crocker",
  title="{NIC - third level ideas and other noise}",
  howpublished="RFC 66",
  series="Internet Request for Comments",
  type="RFC",
  number="66",
  pages="1--3",
  year=1970,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 123, updated by RFCs 80, 93",
url="https://www.rfc-editor.org/rfc/rfc66.txt",
  key="RFC 66",
  doi="10.17487/RFC0066",
  }

@misc{rfc67,
  author="W.R. Crowther",
  title="{Proposed Change to Host/IMP Spec to Eliminate Marking}",
  howpublished="RFC 67",
  series="Internet Request for Comments",
  type="RFC",
  number="67",
  pages="1--1",
  year=1970,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc67.txt",
  key="RFC 67",
  doi="10.17487/RFC0067",
  }

@misc{rfc68,
  author="M. Elie",
  title="{Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM}",
  howpublished="RFC 68",
  series="Internet Request for Comments",
  type="RFC",
  number="68",
  pages="1--2",
  year=1970,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc68.txt",
  key="RFC 68",
  doi="10.17487/RFC0068",
  }

@misc{rfc69,
  author="A.K. Bhushan",
  title="{Distribution List Change for MIT}",
  howpublished="RFC 69",
  series="Internet Request for Comments",
  type="RFC",
  number="69",
  pages="1--1",
  year=1970,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc69.txt",
  key="RFC 69",
  doi="10.17487/RFC0069",
  }

@misc{rfc70,
  author="S.D. Crocker",
  title="{Note on Padding}",
  howpublished="RFC 70",
  series="Internet Request for Comments",
  type="RFC",
  number="70",
  pages="1--9",
  year=1970,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 228",
url="https://www.rfc-editor.org/rfc/rfc70.txt",
  key="RFC 70",
  doi="10.17487/RFC0070",
  }

@misc{rfc71,
  author="T. Schipper",
  title="{Reallocation in Case of Input Error}",
  howpublished="RFC 71",
  series="Internet Request for Comments",
  type="RFC",
  number="71",
  pages="1--1",
  year=1970,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc71.txt",
  key="RFC 71",
  doi="10.17487/RFC0071",
  }

@misc{rfc72,
  author="R.D. Bressler",
  title="{Proposed Moratorium on Changes to Network Protocol}",
  howpublished="RFC 72",
  series="Internet Request for Comments",
  type="RFC",
  number="72",
  pages="1--4",
  year=1970,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc72.txt",
  key="RFC 72",
  doi="10.17487/RFC0072",
  }

@misc{rfc73,
  author="S.D. Crocker",
  title="{Response to NWG/RFC 67}",
  howpublished="RFC 73",
  series="Internet Request for Comments",
  type="RFC",
  number="73",
  pages="1--1",
  year=1970,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc73.txt",
  key="RFC 73",
  doi="10.17487/RFC0073",
  }

@misc{rfc74,
  author="J.E. White",
  title="{Specifications for Network Use of the UCSB On-Line System}",
  howpublished="RFC 74",
  series="Internet Request for Comments",
  type="RFC",
  number="74",
  pages="1--9",
  year=1970,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 217, 225",
url="https://www.rfc-editor.org/rfc/rfc74.txt",
  key="RFC 74",
  doi="10.17487/RFC0074",
  }

@misc{rfc75,
  author="S.D. Crocker",
  title="{Network Meeting}",
  howpublished="RFC 75",
  series="Internet Request for Comments",
  type="RFC",
  number="75",
  pages="1--1",
  year=1970,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc75.txt",
  key="RFC 75",
  doi="10.17487/RFC0075",
  }

@misc{rfc76,
  author="J. Bouknight and J. Madden and G.R. Grossman",
  title="{Connection by name: User oriented protocol}",
  howpublished="RFC 76",
  series="Internet Request for Comments",
  type="RFC",
  number="76",
  pages="1--15",
  year=1970,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc76.txt",
  key="RFC 76",
  doi="10.17487/RFC0076",
  }

@misc{rfc77,
  author="J. Postel",
  title="{Network meeting report}",
  howpublished="RFC 77",
  series="Internet Request for Comments",
  type="RFC",
  number="77",
  pages="1--9",
  year=1970,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc77.txt",
  key="RFC 77",
  doi="10.17487/RFC0077",
  }

@misc{rfc78,
  author="E. Harslem and J.F. Heafner and J.E. White",
  title="{NCP Status Report: UCSB/Rand}",
  howpublished="RFC 78",
  series="Internet Request for Comments",
  type="RFC",
  number="78",
  pages="1--1",
  year=1970,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc78.txt",
  key="RFC 78",
  doi="10.17487/RFC0078",
  }

@misc{rfc79,
  author="E. Meyer",
  title="{Logger Protocol error}",
  howpublished="RFC 79",
  series="Internet Request for Comments",
  type="RFC",
  number="79",
  pages="1--1",
  year=1970,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc79.txt",
  key="RFC 79",
  doi="10.17487/RFC0079",
  }

@misc{rfc80,
  author="E. Harslem and J.F. Heafner",
  title="{Protocols and Data Formats}",
  howpublished="RFC 80",
  series="Internet Request for Comments",
  type="RFC",
  number="80",
  pages="1--9",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 123, updated by RFC 93",
url="https://www.rfc-editor.org/rfc/rfc80.txt",
  key="RFC 80",
  doi="10.17487/RFC0080",
  }

@misc{rfc81,
  author="J. Bouknight",
  title="{Request for Reference Information}",
  howpublished="RFC 81",
  series="Internet Request for Comments",
  type="RFC",
  number="81",
  pages="1--1",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc81.txt",
  key="RFC 81",
  doi="10.17487/RFC0081",
  }

@misc{rfc82,
  author="E. Meyer",
  title="{Network Meeting Notes}",
  howpublished="RFC 82",
  series="Internet Request for Comments",
  type="RFC",
  number="82",
  pages="1--18",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc82.txt",
  key="RFC 82",
  doi="10.17487/RFC0082",
  }

@misc{rfc83,
  author="R.H. Anderson and E. Harslem and J.F. Heafner",
  title="{Language-machine for data reconfiguration}",
  howpublished="RFC 83",
  series="Internet Request for Comments",
  type="RFC",
  number="83",
  pages="1--13",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc83.txt",
  key="RFC 83",
  doi="10.17487/RFC0083",
  }

@misc{rfc84,
  author="J.B. North",
  title="{List of NWG/RFC's 1-80}",
  howpublished="RFC 84",
  series="Internet Request for Comments",
  type="RFC",
  number="84",
  pages="1--8",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc84.txt",
  key="RFC 84",
  doi="10.17487/RFC0084",
  }

@misc{rfc85,
  author="S.D. Crocker",
  title="{Network Working Group meeting}",
  howpublished="RFC 85",
  series="Internet Request for Comments",
  type="RFC",
  number="85",
  pages="1--1",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc85.txt",
  key="RFC 85",
  doi="10.17487/RFC0085",
  }

@misc{rfc86,
  author="S.D. Crocker",
  title="{Proposal for a Network Standard Format for a Data Stream to Control Graphics Display}",
  howpublished="RFC 86",
  series="Internet Request for Comments",
  type="RFC",
  number="86",
  pages="1--6",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 125",
url="https://www.rfc-editor.org/rfc/rfc86.txt",
  key="RFC 86",
  doi="10.17487/RFC0086",
  }

@misc{rfc87,
  author="A. Vezza",
  title="{Topic for Discussion at the Next Network Working Group Meeting}",
  howpublished="RFC 87",
  series="Internet Request for Comments",
  type="RFC",
  number="87",
  pages="1--3",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc87.txt",
  key="RFC 87",
  doi="10.17487/RFC0087",
  }

@misc{rfc88,
  author="R.T. Braden and S.M. Wolfe",
  title="{NETRJS: A third level protocol for Remote Job Entry}",
  howpublished="RFC 88",
  series="Internet Request for Comments",
  type="RFC",
  number="88",
  pages="1--9",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 189",
url="https://www.rfc-editor.org/rfc/rfc88.txt",
  key="RFC 88",
  doi="10.17487/RFC0088",
  }

@misc{rfc89,
  author="R.M. Metcalfe",
  title="{Some historic moments in networking}",
  howpublished="RFC 89",
  series="Internet Request for Comments",
  type="RFC",
  number="89",
  pages="1--7",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc89.txt",
  key="RFC 89",
  doi="10.17487/RFC0089",
  }

@misc{rfc90,
  author="R.T. Braden",
  title="{CCN as a Network Service Center}",
  howpublished="RFC 90",
  series="Internet Request for Comments",
  type="RFC",
  number="90",
  pages="1--6",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc90.txt",
  key="RFC 90",
  doi="10.17487/RFC0090",
  }

@misc{rfc91,
  author="G.H. Mealy",
  title="{Proposed User-User Protocol}",
  howpublished="RFC 91",
  series="Internet Request for Comments",
  type="RFC",
  number="91",
  pages="1--12",
  year=1970,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc91.txt",
  key="RFC 91",
  doi="10.17487/RFC0091",
  }

@misc{rfc93,
  author="A.M. McKenzie",
  title="{Initial Connection Protocol}",
  howpublished="RFC 93",
  series="Internet Request for Comments",
  type="RFC",
  number="93",
  pages="1--1",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc93.txt",
  key="RFC 93",
  doi="10.17487/RFC0093",
  }

@misc{rfc94,
  author="E. Harslem and J.F. Heafner",
  title="{Some thoughts on Network Graphics}",
  howpublished="RFC 94",
  series="Internet Request for Comments",
  type="RFC",
  number="94",
  pages="1--6",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc94.txt",
  key="RFC 94",
  doi="10.17487/RFC0094",
  }

@misc{rfc95,
  author="S. Crocker",
  title="{Distribution of NWG/RFC's through the NIC}",
  howpublished="RFC 95",
  series="Internet Request for Comments",
  type="RFC",
  number="95",
  pages="1--5",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 155",
url="https://www.rfc-editor.org/rfc/rfc95.txt",
  key="RFC 95",
  doi="10.17487/RFC0095",
  }

@misc{rfc96,
  author="R.W. Watson",
  title="{An Interactive Network Experiment to Study Modes of Access the Network Information Center}",
  howpublished="RFC 96 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="96",
  pages="1--5",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc96.txt",
  key="RFC 96",
  doi="10.17487/RFC0096",
  }

@misc{rfc97,
  author="J.T. Melvin and R.W. Watson",
  title="{First Cut at a Proposed Telnet Protocol}",
  howpublished="RFC 97",
  series="Internet Request for Comments",
  type="RFC",
  number="97",
  pages="1--11",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc97.txt",
  key="RFC 97",
  doi="10.17487/RFC0097",
  }

@misc{rfc98,
  author="E. Meyer and T. Skinner",
  title="{Logger Protocol Proposal}",
  howpublished="RFC 98",
  series="Internet Request for Comments",
  type="RFC",
  number="98",
  pages="1--10",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 123",
url="https://www.rfc-editor.org/rfc/rfc98.txt",
  key="RFC 98",
  doi="10.17487/RFC0098",
  }

@misc{rfc99,
  author="P.M. Karp",
  title="{Network Meeting}",
  howpublished="RFC 99",
  series="Internet Request for Comments",
  type="RFC",
  number="99",
  pages="1--1",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 116",
url="https://www.rfc-editor.org/rfc/rfc99.txt",
  key="RFC 99",
  doi="10.17487/RFC0099",
  }

@misc{rfc100,
  author="P.M. Karp",
  title="{Categorization and guide to NWG/RFCs}",
  howpublished="RFC 100",
  series="Internet Request for Comments",
  type="RFC",
  number="100",
  pages="1--37",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc100.txt",
  key="RFC 100",
  doi="10.17487/RFC0100",
  }

@misc{rfc101,
  author="R.W. Watson",
  title="{Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971}",
  howpublished="RFC 101",
  series="Internet Request for Comments",
  type="RFC",
  number="101",
  pages="1--14",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 108, 123",
url="https://www.rfc-editor.org/rfc/rfc101.txt",
  key="RFC 101",
  doi="10.17487/RFC0101",
  }

@misc{rfc102,
  author="S.D. Crocker",
  title="{Output of the Host-Host Protocol glitch cleaning committee}",
  howpublished="RFC 102",
  series="Internet Request for Comments",
  type="RFC",
  number="102",
  pages="1--4",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 107",
url="https://www.rfc-editor.org/rfc/rfc102.txt",
  key="RFC 102",
  doi="10.17487/RFC0102",
  }

@misc{rfc103,
  author="R.B. Kalin",
  title="{Implementation of Interrupt Keys}",
  howpublished="RFC 103",
  series="Internet Request for Comments",
  type="RFC",
  number="103",
  pages="1--4",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc103.txt",
  key="RFC 103",
  doi="10.17487/RFC0103",
  }

@misc{rfc104,
  author="J.B. Postel and S.D. Crocker",
  title="{Link 191}",
  howpublished="RFC 104",
  series="Internet Request for Comments",
  type="RFC",
  number="104",
  pages="1--1",
  year=1971,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc104.txt",
  key="RFC 104",
  doi="10.17487/RFC0104",
  }

@misc{rfc105,
  author="J.E. White",
  title="{Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB}",
  howpublished="RFC 105",
  series="Internet Request for Comments",
  type="RFC",
  number="105",
  pages="1--9",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 217",
url="https://www.rfc-editor.org/rfc/rfc105.txt",
  key="RFC 105",
  doi="10.17487/RFC0105",
  }

@misc{rfc106,
  author="T.C. O'Sullivan",
  title="{User/Server Site Protocol Network Host Questionnaire}",
  howpublished="RFC 106",
  series="Internet Request for Comments",
  type="RFC",
  number="106",
  pages="1--5",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc106.txt",
  key="RFC 106",
  doi="10.17487/RFC0106",
  }

@misc{rfc107,
  author="R.D. Bressler and S.D. Crocker and W.R. Crowther and G.R. Grossman and R.S. Tomlinson and J.E. White",
  title="{Output of the Host-Host Protocol Glitch Cleaning Committee}",
  howpublished="RFC 107",
  series="Internet Request for Comments",
  type="RFC",
  number="107",
  pages="1--12",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 111, 124, 132, 154, 179",
url="https://www.rfc-editor.org/rfc/rfc107.txt",
  key="RFC 107",
  doi="10.17487/RFC0107",
  }

@misc{rfc108,
  author="R.W. Watson",
  title="{Attendance list at the Urbana NWG meeting, February 17-19, 1971}",
  howpublished="RFC 108",
  series="Internet Request for Comments",
  type="RFC",
  number="108",
  pages="1--2",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc108.txt",
  key="RFC 108",
  doi="10.17487/RFC0108",
  }

@misc{rfc109,
  author="J. Winett",
  title="{Level III Server Protocol for the Lincoln Laboratory 360/67 Host}",
  howpublished="RFC 109",
  series="Internet Request for Comments",
  type="RFC",
  number="109",
  pages="1--12",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc109.txt",
  key="RFC 109",
  doi="10.17487/RFC0109",
  }

@misc{rfc110,
  author="J. Winett",
  title="{Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts}",
  howpublished="RFC 110",
  series="Internet Request for Comments",
  type="RFC",
  number="110",
  pages="1--4",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 135",
url="https://www.rfc-editor.org/rfc/rfc110.txt",
  key="RFC 110",
  doi="10.17487/RFC0110",
  }

@misc{rfc111,
  author="S.D. Crocker",
  title="{Pressure from the Chairman}",
  howpublished="RFC 111",
  series="Internet Request for Comments",
  type="RFC",
  number="111",
  pages="1--2",
  year=1971,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 130",
url="https://www.rfc-editor.org/rfc/rfc111.txt",
  key="RFC 111",
  doi="10.17487/RFC0111",
  }

@misc{rfc112,
  author="T.C. O'Sullivan",
  title="{User/Server Site Protocol: Network Host Questionnaire}",
  howpublished="RFC 112",
  series="Internet Request for Comments",
  type="RFC",
  number="112",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc112.txt",
  key="RFC 112",
  doi="10.17487/RFC0112",
  }

@misc{rfc113,
  author="E. Harslem and J.F. Heafner and J.E. White",
  title="{Network activity report: UCSB Rand}",
  howpublished="RFC 113",
  series="Internet Request for Comments",
  type="RFC",
  number="113",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 227",
url="https://www.rfc-editor.org/rfc/rfc113.txt",
  key="RFC 113",
  doi="10.17487/RFC0113",
  }

@misc{rfc114,
  author="A.K. Bhushan",
  title="{File Transfer Protocol}",
  howpublished="RFC 114",
  series="Internet Request for Comments",
  type="RFC",
  number="114",
  pages="1--17",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 133, 141, 171, 172",
url="https://www.rfc-editor.org/rfc/rfc114.txt",
  key="RFC 114",
  keywords="FTP",
  doi="10.17487/RFC0114",
  }

@misc{rfc115,
  author="R.W. Watson and J.B. North",
  title="{Some Network Information Center policies on handling documents}",
  howpublished="RFC 115",
  series="Internet Request for Comments",
  type="RFC",
  number="115",
  pages="1--8",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc115.txt",
  key="RFC 115",
  doi="10.17487/RFC0115",
  }

@misc{rfc116,
  author="S.D. Crocker",
  title="{Structure of the May NWG Meeting}",
  howpublished="RFC 116",
  series="Internet Request for Comments",
  type="RFC",
  number="116",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 131, 156",
url="https://www.rfc-editor.org/rfc/rfc116.txt",
  key="RFC 116",
  doi="10.17487/RFC0116",
  }

@misc{rfc117,
  author="J. Wong",
  title="{Some comments on the official protocol}",
  howpublished="RFC 117",
  series="Internet Request for Comments",
  type="RFC",
  number="117",
  pages="1--5",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc117.txt",
  key="RFC 117",
  doi="10.17487/RFC0117",
  }

@misc{rfc118,
  author="R.W. Watson",
  title="{Recommendations for facility documentation}",
  howpublished="RFC 118",
  series="Internet Request for Comments",
  type="RFC",
  number="118",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc118.txt",
  key="RFC 118",
  doi="10.17487/RFC0118",
  }

@misc{rfc119,
  author="M. Krilanovich",
  title="{Network Fortran Subprograms}",
  howpublished="RFC 119",
  series="Internet Request for Comments",
  type="RFC",
  number="119",
  pages="1--19",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc119.txt",
  key="RFC 119",
  doi="10.17487/RFC0119",
  }

@misc{rfc120,
  author="M. Krilanovich",
  title="{Network PL1 subprograms}",
  howpublished="RFC 120",
  series="Internet Request for Comments",
  type="RFC",
  number="120",
  pages="1--16",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc120.txt",
  key="RFC 120",
  doi="10.17487/RFC0120",
  }

@misc{rfc121,
  author="M. Krilanovich",
  title="{Network on-line operators}",
  howpublished="RFC 121",
  series="Internet Request for Comments",
  type="RFC",
  number="121",
  pages="1--13",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc121.txt",
  key="RFC 121",
  doi="10.17487/RFC0121",
  }

@misc{rfc122,
  author="J.E. White",
  title="{Network specifications for UCSB's Simple-Minded File System}",
  howpublished="RFC 122",
  series="Internet Request for Comments",
  type="RFC",
  number="122",
  pages="1--21",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 217, 269, 399, 431",
url="https://www.rfc-editor.org/rfc/rfc122.txt",
  key="RFC 122",
  doi="10.17487/RFC0122",
  }

@misc{rfc123,
  author="S.D. Crocker",
  title="{Proffered Official ICP}",
  howpublished="RFC 123",
  series="Internet Request for Comments",
  type="RFC",
  number="123",
  pages="1--3",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 165, updated by RFCs 127, 143, 148",
url="https://www.rfc-editor.org/rfc/rfc123.txt",
  key="RFC 123",
  doi="10.17487/RFC0123",
  }

@misc{rfc124,
  author="J.T. Melvin",
  title="{Typographical error in RFC 107}",
  howpublished="RFC 124",
  series="Internet Request for Comments",
  type="RFC",
  number="124",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc124.txt",
  key="RFC 124",
  doi="10.17487/RFC0124",
  }

@misc{rfc125,
  author="J. McConnell",
  title="{Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream}",
  howpublished="RFC 125",
  series="Internet Request for Comments",
  type="RFC",
  number="125",
  pages="1--4",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 177",
url="https://www.rfc-editor.org/rfc/rfc125.txt",
  key="RFC 125",
  doi="10.17487/RFC0125",
  }

@misc{rfc126,
  author="J. McConnell",
  title="{Graphics Facilities at Ames Research Center}",
  howpublished="RFC 126",
  series="Internet Request for Comments",
  type="RFC",
  number="126",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc126.txt",
  key="RFC 126",
  doi="10.17487/RFC0126",
  }

@misc{rfc127,
  author="J. Postel",
  title="{Comments on RFC 123}",
  howpublished="RFC 127",
  series="Internet Request for Comments",
  type="RFC",
  number="127",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 145, updated by RFC 151",
url="https://www.rfc-editor.org/rfc/rfc127.txt",
  key="RFC 127",
  doi="10.17487/RFC0127",
  }

@misc{rfc128,
  author="J. Postel",
  title="{Bytes}",
  howpublished="RFC 128",
  series="Internet Request for Comments",
  type="RFC",
  number="128",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc128.txt",
  key="RFC 128",
  doi="10.17487/RFC0128",
  }

@misc{rfc129,
  author="E. Harslem and J. Heafner and E. Meyer",
  title="{Request for comments on socket name structure}",
  howpublished="RFC 129",
  series="Internet Request for Comments",
  type="RFC",
  number="129",
  pages="1--6",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 147",
url="https://www.rfc-editor.org/rfc/rfc129.txt",
  key="RFC 129",
  doi="10.17487/RFC0129",
  }

@misc{rfc130,
  author="J.F. Heafner",
  title="{Response to RFC 111: Pressure from the chairman}",
  howpublished="RFC 130",
  series="Internet Request for Comments",
  type="RFC",
  number="130",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc130.txt",
  key="RFC 130",
  doi="10.17487/RFC0130",
  }

@misc{rfc131,
  author="E. Harslem and J.F. Heafner",
  title="{Response to RFC 116: May NWG meeting}",
  howpublished="RFC 131",
  series="Internet Request for Comments",
  type="RFC",
  number="131",
  pages="1--3",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc131.txt",
  key="RFC 131",
  doi="10.17487/RFC0131",
  }

@misc{rfc132,
  author="J.E. White",
  title="{Typographical Error in RFC 107}",
  howpublished="RFC 132",
  series="Internet Request for Comments",
  type="RFC",
  number="132",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 154",
url="https://www.rfc-editor.org/rfc/rfc132.txt",
  key="RFC 132",
  doi="10.17487/RFC0132",
  }

@misc{rfc133,
  author="R.L. Sunberg",
  title="{File Transfer and Error Recovery}",
  howpublished="RFC 133",
  series="Internet Request for Comments",
  type="RFC",
  number="133",
  pages="1--4",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc133.txt",
  key="RFC 133",
  keywords="FTP",
  doi="10.17487/RFC0133",
  }

@misc{rfc134,
  author="A. Vezza",
  title="{Network Graphics meeting}",
  howpublished="RFC 134",
  series="Internet Request for Comments",
  type="RFC",
  number="134",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc134.txt",
  key="RFC 134",
  doi="10.17487/RFC0134",
  }

@misc{rfc135,
  author="W. Hathaway",
  title="{Response to NWG/RFC 110}",
  howpublished="RFC 135",
  series="Internet Request for Comments",
  type="RFC",
  number="135",
  pages="1--3",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc135.txt",
  key="RFC 135",
  doi="10.17487/RFC0135",
  }

@misc{rfc136,
  author="R.E. Kahn",
  title="{Host accounting and administrative procedures}",
  howpublished="RFC 136",
  series="Internet Request for Comments",
  type="RFC",
  number="136",
  pages="1--4",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc136.txt",
  key="RFC 136",
  doi="10.17487/RFC0136",
  }

@misc{rfc137,
  author="T.C. O'Sullivan",
  title="{Telnet Protocol - a proposed document}",
  howpublished="RFC 137",
  series="Internet Request for Comments",
  type="RFC",
  number="137",
  pages="1--11",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 139",
url="https://www.rfc-editor.org/rfc/rfc137.txt",
  key="RFC 137",
  doi="10.17487/RFC0137",
  }

@misc{rfc138,
  author="R.H. Anderson and V.G. Cerf and E. Harslem and J.F. Heafner and J. Madden and R.M. Metcalfe and A. Shoshani and J.E. White and D.C.M. Wood",
  title="{Status report on proposed Data Reconfiguration Service}",
  howpublished="RFC 138",
  series="Internet Request for Comments",
  type="RFC",
  number="138",
  pages="1--23",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc138.txt",
  key="RFC 138",
  doi="10.17487/RFC0138",
  }

@misc{rfc139,
  author="T.C. O'Sullivan",
  title="{Discussion of Telnet Protocol}",
  howpublished="RFC 139",
  series="Internet Request for Comments",
  type="RFC",
  number="139",
  pages="1--11",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 158",
url="https://www.rfc-editor.org/rfc/rfc139.txt",
  key="RFC 139",
  doi="10.17487/RFC0139",
  }

@misc{rfc140,
  author="S.D. Crocker",
  title="{Agenda for the May NWG meeting}",
  howpublished="RFC 140",
  series="Internet Request for Comments",
  type="RFC",
  number="140",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 149",
url="https://www.rfc-editor.org/rfc/rfc140.txt",
  key="RFC 140",
  doi="10.17487/RFC0140",
  }

@misc{rfc141,
  author="E. Harslem and J.F. Heafner",
  title="{Comments on RFC 114: A File Transfer Protocol}",
  howpublished="RFC 141",
  series="Internet Request for Comments",
  type="RFC",
  number="141",
  pages="1--2",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc141.txt",
  key="RFC 141",
  keywords="FTP",
  doi="10.17487/RFC0141",
  }

@misc{rfc142,
  author="C. Kline and J. Wong",
  title="{Time-Out Mechanism in the Host-Host Protocol}",
  howpublished="RFC 142",
  series="Internet Request for Comments",
  type="RFC",
  number="142",
  pages="1--2",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc142.txt",
  key="RFC 142",
  doi="10.17487/RFC0142",
  }

@misc{rfc143,
  author="W. Naylor and J. Wong and C. Kline and J. Postel",
  title="{Regarding proffered official ICP}",
  howpublished="RFC 143",
  series="Internet Request for Comments",
  type="RFC",
  number="143",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 165",
url="https://www.rfc-editor.org/rfc/rfc143.txt",
  key="RFC 143",
  doi="10.17487/RFC0143",
  }

@misc{rfc144,
  author="A. Shoshani",
  title="{Data sharing on computer networks}",
  howpublished="RFC 144",
  series="Internet Request for Comments",
  type="RFC",
  number="144",
  pages="1--6",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc144.txt",
  key="RFC 144",
  doi="10.17487/RFC0144",
  }

@misc{rfc145,
  author="J. Postel",
  title="{Initial Connection Protocol Control Commands}",
  howpublished="RFC 145",
  series="Internet Request for Comments",
  type="RFC",
  number="145",
  pages="1--2",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 165, updated by RFC 143",
url="https://www.rfc-editor.org/rfc/rfc145.txt",
  key="RFC 145",
  doi="10.17487/RFC0145",
  }

@misc{rfc146,
  author="P.M. Karp and D.B. McKay and D.C.M. Wood",
  title="{Views on issues relevant to data sharing on computer networks}",
  howpublished="RFC 146",
  series="Internet Request for Comments",
  type="RFC",
  number="146",
  pages="1--6",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc146.txt",
  key="RFC 146",
  doi="10.17487/RFC0146",
  }

@misc{rfc147,
  author="J.M. Winett",
  title="{Definition of a socket}",
  howpublished="RFC 147",
  series="Internet Request for Comments",
  type="RFC",
  number="147",
  pages="1--3",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc147.txt",
  key="RFC 147",
  doi="10.17487/RFC0147",
  }

@misc{rfc148,
  author="A.K. Bhushan",
  title="{Comments on RFC 123}",
  howpublished="RFC 148",
  series="Internet Request for Comments",
  type="RFC",
  number="148",
  pages="1--1",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc148.txt",
  key="RFC 148",
  doi="10.17487/RFC0148",
  }

@misc{rfc149,
  author="S.D. Crocker",
  title="{Best Laid Plans}",
  howpublished="RFC 149",
  series="Internet Request for Comments",
  type="RFC",
  number="149",
  pages="1--1",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc149.txt",
  key="RFC 149",
  doi="10.17487/RFC0149",
  }

@misc{rfc150,
  author="R.B. Kalin",
  title="{Use of IPC Facilities: A Working Paper}",
  howpublished="RFC 150",
  series="Internet Request for Comments",
  type="RFC",
  number="150",
  pages="1--11",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc150.txt",
  key="RFC 150",
  doi="10.17487/RFC0150",
  }

@misc{rfc151,
  author="A. Shoshani",
  title="{Comments on a proffered official ICP: RFCs 123, 127}",
  howpublished="RFC 151",
  series="Internet Request for Comments",
  type="RFC",
  number="151",
  pages="1--2",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc151.txt",
  key="RFC 151",
  doi="10.17487/RFC0151",
  }

@misc{rfc152,
  author="M. Wilber",
  title="{SRI Artificial Intelligence status report}",
  howpublished="RFC 152",
  series="Internet Request for Comments",
  type="RFC",
  number="152",
  pages="1--1",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc152.txt",
  key="RFC 152",
  doi="10.17487/RFC0152",
  }

@misc{rfc153,
  author="J.T. Melvin and R.W. Watson",
  title="{SRI ARC-NIC status}",
  howpublished="RFC 153",
  series="Internet Request for Comments",
  type="RFC",
  number="153",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc153.txt",
  key="RFC 153",
  doi="10.17487/RFC0153",
  }

@misc{rfc154,
  author="S.D. Crocker",
  title="{Exposition Style}",
  howpublished="RFC 154",
  series="Internet Request for Comments",
  type="RFC",
  number="154",
  pages="1--1",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc154.txt",
  key="RFC 154",
  doi="10.17487/RFC0154",
  }

@misc{rfc155,
  author="J.B. North",
  title="{ARPA Network mailing lists}",
  howpublished="RFC 155",
  series="Internet Request for Comments",
  type="RFC",
  number="155",
  pages="1--13",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 168",
url="https://www.rfc-editor.org/rfc/rfc155.txt",
  key="RFC 155",
  doi="10.17487/RFC0155",
  }

@misc{rfc156,
  author="J. Bouknight",
  title="{Status of the Illinois site: Response to RFC 116}",
  howpublished="RFC 156",
  series="Internet Request for Comments",
  type="RFC",
  number="156",
  pages="1--1",
  year=1971,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc156.txt",
  key="RFC 156",
  doi="10.17487/RFC0156",
  }

@misc{rfc157,
  author="V.G. Cerf",
  title="{Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems}",
  howpublished="RFC 157",
  series="Internet Request for Comments",
  type="RFC",
  number="157",
  pages="1--2",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc157.txt",
  key="RFC 157",
  doi="10.17487/RFC0157",
  }

@misc{rfc158,
  author="T.C. O'Sullivan",
  title="{Telnet Protocol: A Proposed Document}",
  howpublished="RFC 158",
  series="Internet Request for Comments",
  type="RFC",
  number="158",
  pages="1--11",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 495, updated by RFC 318",
url="https://www.rfc-editor.org/rfc/rfc158.txt",
  key="RFC 158",
  doi="10.17487/RFC0158",
  }

@misc{rfc160,
  author="Network Information Center. Stanford Research Institute",
  title="{RFC brief list}",
  howpublished="RFC 160",
  series="Internet Request for Comments",
  type="RFC",
  number="160",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 200, 999",
url="https://www.rfc-editor.org/rfc/rfc160.txt",
  key="RFC 160",
  doi="10.17487/RFC0160",
  }

@misc{rfc161,
  author="A. Shoshani",
  title="{Solution to the race condition in the ICP}",
  howpublished="RFC 161",
  series="Internet Request for Comments",
  type="RFC",
  number="161",
  pages="1--1",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc161.txt",
  key="RFC 161",
  doi="10.17487/RFC0161",
  }

@misc{rfc162,
  author="M. Kampe",
  title="{NETBUGGER3}",
  howpublished="RFC 162",
  series="Internet Request for Comments",
  type="RFC",
  number="162",
  pages="1--2",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc162.txt",
  key="RFC 162",
  doi="10.17487/RFC0162",
  }

@misc{rfc163,
  author="V.G. Cerf",
  title="{Data transfer protocols}",
  howpublished="RFC 163",
  series="Internet Request for Comments",
  type="RFC",
  number="163",
  pages="1--3",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc163.txt",
  key="RFC 163",
  keywords="FTP, DTP, data, manager",
  doi="10.17487/RFC0163",
  }

@misc{rfc164,
  author="J.F. Heafner",
  title="{Minutes of Network Working Group meeting, 5/16 through 5/19/71}",
  howpublished="RFC 164",
  series="Internet Request for Comments",
  type="RFC",
  number="164",
  pages="1--32",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc164.txt",
  key="RFC 164",
  doi="10.17487/RFC0164",
  }

@misc{rfc165,
  author="J. Postel",
  title="{Proffered Official Initial Connection Protocol}",
  howpublished="RFC 165",
  series="Internet Request for Comments",
  type="RFC",
  number="165",
  pages="1--5",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC NaN",
url="https://www.rfc-editor.org/rfc/rfc165.txt",
  key="RFC 165",
  doi="10.17487/RFC0165",
  }

@misc{rfc166,
  author="R.H. Anderson and V.G. Cerf and E. Harslem and J.F. Heafner and J. Madden and R.M. Metcalfe and A. Shoshani and J.E. White and D.C.M. Wood",
  title="{Data Reconfiguration Service: An implementation specification}",
  howpublished="RFC 166",
  series="Internet Request for Comments",
  type="RFC",
  number="166",
  pages="1--20",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc166.txt",
  key="RFC 166",
  doi="10.17487/RFC0166",
  }

@misc{rfc167,
  author="A.K. Bhushan and R.M. Metcalfe and J.M. Winett",
  title="{Socket conventions reconsidered}",
  howpublished="RFC 167",
  series="Internet Request for Comments",
  type="RFC",
  number="167",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc167.txt",
  key="RFC 167",
  doi="10.17487/RFC0167",
  }

@misc{rfc168,
  author="J.B. North",
  title="{ARPA Network mailing lists}",
  howpublished="RFC 168",
  series="Internet Request for Comments",
  type="RFC",
  number="168",
  pages="1--7",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 211",
url="https://www.rfc-editor.org/rfc/rfc168.txt",
  key="RFC 168",
  doi="10.17487/RFC0168",
  }

@misc{rfc169,
  author="S.D. Crocker",
  title="{COMPUTER NETWORKS}",
  howpublished="RFC 169",
  series="Internet Request for Comments",
  type="RFC",
  number="169",
  pages="1--4",
  year=1971,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc169.txt",
  key="RFC 169",
  doi="10.17487/RFC0169",
  }

@misc{rfc170,
  author="Network Information Center. Stanford Research Institute",
  title="{RFC List by Number}",
  howpublished="RFC 170",
  series="Internet Request for Comments",
  type="RFC",
  number="170",
  pages="1--6",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 200",
url="https://www.rfc-editor.org/rfc/rfc170.txt",
  key="RFC 170",
  doi="10.17487/RFC0170",
  }

@misc{rfc171,
  author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenize and J. Melvin and B. Sundberg and D. Watson and J. White",
  title="{The Data Transfer Protocol}",
  howpublished="RFC 171",
  series="Internet Request for Comments",
  type="RFC",
  number="171",
  pages="1--9",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 264, updated by RFC 238",
url="https://www.rfc-editor.org/rfc/rfc171.txt",
  key="RFC 171",
  keywords="FTP, DTP",
  doi="10.17487/RFC0171",
  }

@misc{rfc172,
  author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenzie and J. Melvin and B. Sundberg and D. Watson and J. White",
  title="{The File Transfer Protocol}",
  howpublished="RFC 172",
  series="Internet Request for Comments",
  type="RFC",
  number="172",
  pages="1--12",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 265, updated by RFC 238",
url="https://www.rfc-editor.org/rfc/rfc172.txt",
  key="RFC 172",
  keywords="FTP",
  doi="10.17487/RFC0172",
  }

@misc{rfc173,
  author="P.M. Karp and D.B. McKay",
  title="{Network Data Management Committee Meeting Announcement}",
  howpublished="RFC 173",
  series="Internet Request for Comments",
  type="RFC",
  number="173",
  pages="1--2",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc173.txt",
  key="RFC 173",
  doi="10.17487/RFC0173",
  }

@misc{rfc174,
  author="J. Postel and V.G. Cerf",
  title="{UCLA - Computer Science Graphics Overview}",
  howpublished="RFC 174",
  series="Internet Request for Comments",
  type="RFC",
  number="174",
  pages="1--3",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc174.txt",
  key="RFC 174",
  doi="10.17487/RFC0174",
  }

@misc{rfc175,
  author="E. Harslem and J.F. Heafner",
  title="{Comments on ``Socket Conventions Reconsidered''}",
  howpublished="RFC 175",
  series="Internet Request for Comments",
  type="RFC",
  number="175",
  pages="1--1",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc175.txt",
  key="RFC 175",
  doi="10.17487/RFC0175",
  }

@misc{rfc176,
  author="A.K. Bhushan and R. Kanodia and R.M. Metcalfe and J. Postel",
  title="{Comments on ``Byte size for connections''}",
  howpublished="RFC 176",
  series="Internet Request for Comments",
  type="RFC",
  number="176",
  pages="1--5",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc176.txt",
  key="RFC 176",
  doi="10.17487/RFC0176",
  }

@misc{rfc177,
  author="J. McConnell",
  title="{Device independent graphical display description}",
  howpublished="RFC 177",
  series="Internet Request for Comments",
  type="RFC",
  number="177",
  pages="1--9",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 181",
url="https://www.rfc-editor.org/rfc/rfc177.txt",
  key="RFC 177",
  doi="10.17487/RFC0177",
  }

@misc{rfc178,
  author="I.W. Cotton",
  title="{Network graphic attention handling}",
  howpublished="RFC 178",
  series="Internet Request for Comments",
  type="RFC",
  number="178",
  pages="1--11",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc178.txt",
  key="RFC 178",
  doi="10.17487/RFC0178",
  }

@misc{rfc179,
  author="A.M. McKenzie",
  title="{Link Number Assignments}",
  howpublished="RFC 179",
  series="Internet Request for Comments",
  type="RFC",
  number="179",
  pages="1--1",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc179.txt",
  key="RFC 179",
  doi="10.17487/RFC0179",
  }

@misc{rfc180,
  author="A.M. McKenzie",
  title="{File system questionnaire}",
  howpublished="RFC 180",
  series="Internet Request for Comments",
  type="RFC",
  number="180",
  pages="1--4",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc180.txt",
  key="RFC 180",
  doi="10.17487/RFC0180",
  }

@misc{rfc181,
  author="J. McConnell",
  title="{Modifications to RFC 177}",
  howpublished="RFC 181",
  series="Internet Request for Comments",
  type="RFC",
  number="181",
  pages="1--3",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc181.txt",
  key="RFC 181",
  doi="10.17487/RFC0181",
  }

@misc{rfc182,
  author="J.B. North",
  title="{Compilation of list of relevant site reports}",
  howpublished="RFC 182",
  series="Internet Request for Comments",
  type="RFC",
  number="182",
  pages="1--1",
  year=1971,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc182.txt",
  key="RFC 182",
  doi="10.17487/RFC0182",
  }

@misc{rfc183,
  author="J.M. Winett",
  title="{EBCDIC Codes and Their Mapping to ASCII}",
  howpublished="RFC 183",
  series="Internet Request for Comments",
  type="RFC",
  number="183",
  pages="1--12",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc183.txt",
  key="RFC 183",
  doi="10.17487/RFC0183",
  }

@misc{rfc184,
  author="K.C. Kelley",
  title="{Proposed graphic display modes}",
  howpublished="RFC 184",
  series="Internet Request for Comments",
  type="RFC",
  number="184",
  pages="1--7",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc184.txt",
  key="RFC 184",
  doi="10.17487/RFC0184",
  }

@misc{rfc185,
  author="J.B. North",
  title="{NIC distribution of manuals and handbooks}",
  howpublished="RFC 185",
  series="Internet Request for Comments",
  type="RFC",
  number="185",
  pages="1--1",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc185.txt",
  key="RFC 185",
  doi="10.17487/RFC0185",
  }

@misc{rfc186,
  author="J.C. Michener",
  title="{Network graphics loader}",
  howpublished="RFC 186",
  series="Internet Request for Comments",
  type="RFC",
  number="186",
  pages="1--17",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc186.txt",
  key="RFC 186",
  doi="10.17487/RFC0186",
  }

@misc{rfc187,
  author="D.B. McKay and D.P. Karp",
  title="{Network/440 Protocol Concept}",
  howpublished="RFC 187",
  series="Internet Request for Comments",
  type="RFC",
  number="187",
  pages="1--11",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc187.txt",
  key="RFC 187",
  doi="10.17487/RFC0187",
  }

@misc{rfc188,
  author="P.M. Karp and D.B. McKay",
  title="{Data management meeting announcement}",
  howpublished="RFC 188",
  series="Internet Request for Comments",
  type="RFC",
  number="188",
  pages="1--2",
  year=1971,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc188.txt",
  key="RFC 188",
  doi="10.17487/RFC0188",
  }

@misc{rfc189,
  author="R.T. Braden",
  title="{Interim NETRJS specifications}",
  howpublished="RFC 189",
  series="Internet Request for Comments",
  type="RFC",
  number="189",
  pages="1--19",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 599, updated by RFC 283",
url="https://www.rfc-editor.org/rfc/rfc189.txt",
  key="RFC 189",
  doi="10.17487/RFC0189",
  }

@misc{rfc190,
  author="L.P. Deutsch",
  title="{DEC PDP-10-IMLAC communications system}",
  howpublished="RFC 190",
  series="Internet Request for Comments",
  type="RFC",
  number="190",
  pages="1--16",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc190.txt",
  key="RFC 190",
  doi="10.17487/RFC0190",
  }

@misc{rfc191,
  author="C.H. Irby",
  title="{Graphics implementation and conceptualization at Augmentation Research Center}",
  howpublished="RFC 191",
  series="Internet Request for Comments",
  type="RFC",
  number="191",
  pages="1--4",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc191.txt",
  key="RFC 191",
  doi="10.17487/RFC0191",
  }

@misc{rfc192,
  author="R.W. Watson",
  title="{Some factors which a Network Graphics Protocol must consider}",
  howpublished="RFC 192",
  series="Internet Request for Comments",
  type="RFC",
  number="192",
  pages="1--19",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc192.txt",
  key="RFC 192",
  doi="10.17487/RFC0192",
  }

@misc{rfc193,
  author="E. Harslem and J.F. Heafner",
  title="{NETWORK CHECKOUT}",
  howpublished="RFC 193",
  series="Internet Request for Comments",
  type="RFC",
  number="193",
  pages="1--2",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 198, updated by RFC 198",
url="https://www.rfc-editor.org/rfc/rfc193.txt",
  key="RFC 193",
  doi="10.17487/RFC0193",
  }

@misc{rfc194,
  author="V. Cerf and E. Harslem and J. Heafner and B. Metcalfe and J. White",
  title="{The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes}",
  howpublished="RFC 194",
  series="Internet Request for Comments",
  type="RFC",
  number="194",
  pages="1--18",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc194.txt",
  key="RFC 194",
  doi="10.17487/RFC0194",
  }

@misc{rfc195,
  author="G.H. Mealy",
  title="{Data computers-data descriptions and access language}",
  howpublished="RFC 195",
  series="Internet Request for Comments",
  type="RFC",
  number="195",
  pages="1--4",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc195.txt",
  key="RFC 195",
  doi="10.17487/RFC0195",
  }

@misc{rfc196,
  author="R.W. Watson",
  title="{Mail Box Protocol}",
  howpublished="RFC 196",
  series="Internet Request for Comments",
  type="RFC",
  number="196",
  pages="1--4",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 221",
url="https://www.rfc-editor.org/rfc/rfc196.txt",
  key="RFC 196",
  doi="10.17487/RFC0196",
  }

@misc{rfc197,
  author="A. Shoshani and E. Harslem",
  title="{Initial Connection Protocol - Reviewed}",
  howpublished="RFC 197",
  series="Internet Request for Comments",
  type="RFC",
  number="197",
  pages="1--5",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc197.txt",
  key="RFC 197",
  doi="10.17487/RFC0197",
  }

@misc{rfc198,
  author="J.F. Heafner",
  title="{Site Certification - Lincoln Labs 360/67}",
  howpublished="RFC 198",
  series="Internet Request for Comments",
  type="RFC",
  number="198",
  pages="1--1",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 214",
url="https://www.rfc-editor.org/rfc/rfc198.txt",
  key="RFC 198",
  doi="10.17487/RFC0198",
  }

@misc{rfc199,
  author="T. Williams",
  title="{Suggestions for a Network Data-Tablet Graphics Protocol}",
  howpublished="RFC 199",
  series="Internet Request for Comments",
  type="RFC",
  number="199",
  pages="1--10",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc199.txt",
  key="RFC 199",
  doi="10.17487/RFC0199",
  }

@misc{rfc200,
  author="J.B. North",
  title="{RFC list by number}",
  howpublished="RFC 200",
  series="Internet Request for Comments",
  type="RFC",
  number="200",
  pages="1--7",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC NaN",
url="https://www.rfc-editor.org/rfc/rfc200.txt",
  key="RFC 200",
  doi="10.17487/RFC0200",
  }

@misc{rfc202,
  author="S.M. Wolfe and J. Postel",
  title="{Possible Deadlock in ICP}",
  howpublished="RFC 202",
  series="Internet Request for Comments",
  type="RFC",
  number="202",
  pages="1--2",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc202.txt",
  key="RFC 202",
  doi="10.17487/RFC0202",
  }

@misc{rfc203,
  author="R.B. Kalin",
  title="{Achieving reliable communication}",
  howpublished="RFC 203",
  series="Internet Request for Comments",
  type="RFC",
  number="203",
  pages="1--4",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc203.txt",
  key="RFC 203",
  doi="10.17487/RFC0203",
  }

@misc{rfc204,
  author="J. Postel",
  title="{Sockets in use}",
  howpublished="RFC 204",
  series="Internet Request for Comments",
  type="RFC",
  number="204",
  pages="1--1",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 234",
url="https://www.rfc-editor.org/rfc/rfc204.txt",
  key="RFC 204",
  doi="10.17487/RFC0204",
  }

@misc{rfc205,
  author="R.T. Braden",
  title="{NETCRT - a character display protocol}",
  howpublished="RFC 205",
  series="Internet Request for Comments",
  type="RFC",
  number="205",
  pages="1--13",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc205.txt",
  key="RFC 205",
  doi="10.17487/RFC0205",
  }

@misc{rfc206,
  author="J. White",
  title="{A User TELNET Description of an Initial Implementation}",
  howpublished="RFC 206",
  series="Internet Request for Comments",
  type="RFC",
  number="206",
  pages="1--14",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc206.txt",
  key="RFC 206",
  doi="10.17487/RFC0206",
  }

@misc{rfc207,
  author="A. Vezza",
  title="{September Network Working Group meeting}",
  howpublished="RFC 207",
  series="Internet Request for Comments",
  type="RFC",
  number="207",
  pages="1--2",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 212",
url="https://www.rfc-editor.org/rfc/rfc207.txt",
  key="RFC 207",
  doi="10.17487/RFC0207",
  }

@misc{rfc208,
  author="A.M. McKenzie",
  title="{Address tables}",
  howpublished="RFC 208",
  series="Internet Request for Comments",
  type="RFC",
  number="208",
  pages="1--3",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc208.txt",
  key="RFC 208",
  doi="10.17487/RFC0208",
  }

@misc{rfc209,
  author="B. Cosell",
  title="{Host/IMP interface documentation}",
  howpublished="RFC 209",
  series="Internet Request for Comments",
  type="RFC",
  number="209",
  pages="1--1",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc209.txt",
  key="RFC 209",
  doi="10.17487/RFC0209",
  }

@misc{rfc210,
  author="W. Conrad",
  title="{Improvement of Flow Control}",
  howpublished="RFC 210",
  series="Internet Request for Comments",
  type="RFC",
  number="210",
  pages="1--2",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc210.txt",
  key="RFC 210",
  doi="10.17487/RFC0210",
  }

@misc{rfc211,
  author="J.B. North",
  title="{ARPA Network Mailing Lists}",
  howpublished="RFC 211",
  series="Internet Request for Comments",
  type="RFC",
  number="211",
  pages="1--13",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 300",
url="https://www.rfc-editor.org/rfc/rfc211.txt",
  key="RFC 211",
  doi="10.17487/RFC0211",
  }

@misc{rfc212,
  author="Information Sciences Institute University of Southern California",
  title="{NWG meeting on network usage}",
  howpublished="RFC 212",
  series="Internet Request for Comments",
  type="RFC",
  number="212",
  pages="1--2",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 222",
url="https://www.rfc-editor.org/rfc/rfc212.txt",
  key="RFC 212",
  doi="10.17487/RFC0212",
  }

@misc{rfc213,
  author="B. Cosell",
  title="{IMP System change notification}",
  howpublished="RFC 213",
  series="Internet Request for Comments",
  type="RFC",
  number="213",
  pages="1--1",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc213.txt",
  key="RFC 213",
  doi="10.17487/RFC0213",
  }

@misc{rfc214,
  author="E. Harslem",
  title="{Network checkpoint}",
  howpublished="RFC 214",
  series="Internet Request for Comments",
  type="RFC",
  number="214",
  pages="1--2",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc214.txt",
  key="RFC 214",
  doi="10.17487/RFC0214",
  }

@misc{rfc215,
  author="A.M. McKenzie",
  title="{NCP, ICP, and Telnet: The Terminal IMP implementation}",
  howpublished="RFC 215",
  series="Internet Request for Comments",
  type="RFC",
  number="215",
  pages="1--7",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc215.txt",
  key="RFC 215",
  doi="10.17487/RFC0215",
  }

@misc{rfc216,
  author="J.E. White",
  title="{Telnet Access to UCSB's On-Line System}",
  howpublished="RFC 216",
  series="Internet Request for Comments",
  type="RFC",
  number="216",
  pages="1--16",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc216.txt",
  key="RFC 216",
  doi="10.17487/RFC0216",
  }

@misc{rfc217,
  author="J.E. White",
  title="{Specifications changes for OLS, RJE/RJOR, and SMFS}",
  howpublished="RFC 217",
  series="Internet Request for Comments",
  type="RFC",
  number="217",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc217.txt",
  key="RFC 217",
  doi="10.17487/RFC0217",
  }

@misc{rfc218,
  author="B. Cosell",
  title="{Changing the IMP status reporting facility}",
  howpublished="RFC 218",
  series="Internet Request for Comments",
  type="RFC",
  number="218",
  pages="1--1",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc218.txt",
  key="RFC 218",
  doi="10.17487/RFC0218",
  }

@misc{rfc219,
  author="R. Winter",
  title="{User's View of the Datacomputer}",
  howpublished="RFC 219",
  series="Internet Request for Comments",
  type="RFC",
  number="219",
  pages="1--7",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc219.txt",
  key="RFC 219",
  doi="10.17487/RFC0219",
  }

@misc{rfc221,
  author="R.W. Watson",
  title="{Mail Box Protocol: Version 2}",
  howpublished="RFC 221",
  series="Internet Request for Comments",
  type="RFC",
  number="221",
  pages="1--5",
  year=1971,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 278",
url="https://www.rfc-editor.org/rfc/rfc221.txt",
  key="RFC 221",
  doi="10.17487/RFC0221",
  }

@misc{rfc222,
  author="R.M. Metcalfe",
  title="{Subject: System programmer's workshop}",
  howpublished="RFC 222",
  series="Internet Request for Comments",
  type="RFC",
  number="222",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 234",
url="https://www.rfc-editor.org/rfc/rfc222.txt",
  key="RFC 222",
  doi="10.17487/RFC0222",
  }

@misc{rfc223,
  author="J.T. Melvin and R.W. Watson",
  title="{Network Information Center schedule for network users}",
  howpublished="RFC 223",
  series="Internet Request for Comments",
  type="RFC",
  number="223",
  pages="1--4",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc223.txt",
  key="RFC 223",
  doi="10.17487/RFC0223",
  }

@misc{rfc224,
  author="A.M. McKenzie",
  title="{Comments on Mailbox Protocol}",
  howpublished="RFC 224",
  series="Internet Request for Comments",
  type="RFC",
  number="224",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc224.txt",
  key="RFC 224",
  doi="10.17487/RFC0224",
  }

@misc{rfc225,
  author="E. Harslem and R. Stoughton",
  title="{Rand/UCSB network graphics experiment}",
  howpublished="RFC 225",
  series="Internet Request for Comments",
  type="RFC",
  number="225",
  pages="1--5",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc225.txt",
  key="RFC 225",
  doi="10.17487/RFC0225",
  }

@misc{rfc226,
  author="P.M. Karp",
  title="{Standardization of host mnemonics}",
  howpublished="RFC 226",
  series="Internet Request for Comments",
  type="RFC",
  number="226",
  pages="1--1",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 247",
url="https://www.rfc-editor.org/rfc/rfc226.txt",
  key="RFC 226",
  doi="10.17487/RFC0226",
  }

@misc{rfc227,
  author="J.F. Heafner and E. Harslem",
  title="{Data transfer rates (Rand/UCLA)}",
  howpublished="RFC 227",
  series="Internet Request for Comments",
  type="RFC",
  number="227",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc227.txt",
  key="RFC 227",
  doi="10.17487/RFC0227",
  }

@misc{rfc228,
  author="D.C. Walden",
  title="{Clarification}",
  howpublished="RFC 228",
  series="Internet Request for Comments",
  type="RFC",
  number="228",
  pages="1--1",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc228.txt",
  key="RFC 228",
  doi="10.17487/RFC0228",
  }

@misc{rfc229,
  author="J. Postel",
  title="{Standard host names}",
  howpublished="RFC 229",
  series="Internet Request for Comments",
  type="RFC",
  number="229",
  pages="1--3",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 236",
url="https://www.rfc-editor.org/rfc/rfc229.txt",
  key="RFC 229",
  doi="10.17487/RFC0229",
  }

@misc{rfc230,
  author="T. Pyke",
  title="{Toward reliable operation of minicomputer-based terminals on a TIP}",
  howpublished="RFC 230",
  series="Internet Request for Comments",
  type="RFC",
  number="230",
  pages="1--3",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc230.txt",
  key="RFC 230",
  doi="10.17487/RFC0230",
  }

@misc{rfc231,
  author="J.F. Heafner and E. Harslem",
  title="{Service center standards for remote usage: A user's view}",
  howpublished="RFC 231",
  series="Internet Request for Comments",
  type="RFC",
  number="231",
  pages="1--4",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc231.txt",
  key="RFC 231",
  doi="10.17487/RFC0231",
  }

@misc{rfc232,
  author="A. Vezza",
  title="{Postponement of network graphics meeting}",
  howpublished="RFC 232",
  series="Internet Request for Comments",
  type="RFC",
  number="232",
  pages="1--1",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc232.txt",
  key="RFC 232",
  doi="10.17487/RFC0232",
  }

@misc{rfc233,
  author="A. Bhushan and R. Metcalfe",
  title="{Standardization of host call letters}",
  howpublished="RFC 233",
  series="Internet Request for Comments",
  type="RFC",
  number="233",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc233.txt",
  key="RFC 233",
  doi="10.17487/RFC0233",
  }

@misc{rfc234,
  author="A. Vezza",
  title="{Network Working Group meeting schedule}",
  howpublished="RFC 234",
  series="Internet Request for Comments",
  type="RFC",
  number="234",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc234.txt",
  key="RFC 234",
  doi="10.17487/RFC0234",
  }

@misc{rfc235,
  author="E. Westheimer",
  title="{Site status}",
  howpublished="RFC 235",
  series="Internet Request for Comments",
  type="RFC",
  number="235",
  pages="1--5",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 240",
url="https://www.rfc-editor.org/rfc/rfc235.txt",
  key="RFC 235",
  doi="10.17487/RFC0235",
  }

@misc{rfc236,
  author="J. Postel",
  title="{Standard host names}",
  howpublished="RFC 236",
  series="Internet Request for Comments",
  type="RFC",
  number="236",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc236.txt",
  key="RFC 236",
  doi="10.17487/RFC0236",
  }

@misc{rfc237,
  author="R.W. Watson",
  title="{NIC view of standard host names}",
  howpublished="RFC 237",
  series="Internet Request for Comments",
  type="RFC",
  number="237",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 273",
url="https://www.rfc-editor.org/rfc/rfc237.txt",
  key="RFC 237",
  doi="10.17487/RFC0237",
  }

@misc{rfc238,
  author="R.T. Braden",
  title="{Comments on DTP and FTP proposals}",
  howpublished="RFC 238",
  series="Internet Request for Comments",
  type="RFC",
  number="238",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc238.txt",
  key="RFC 238",
  keywords="FTP",
  doi="10.17487/RFC0238",
  }

@misc{rfc239,
  author="R.T. Braden",
  title="{Host mnemonics proposed in RFC 226 (NIC 7625)}",
  howpublished="RFC 239",
  series="Internet Request for Comments",
  type="RFC",
  number="239",
  pages="1--1",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc239.txt",
  key="RFC 239",
  doi="10.17487/RFC0239",
  }

@misc{rfc240,
  author="A.M. McKenzie",
  title="{Site Status}",
  howpublished="RFC 240",
  series="Internet Request for Comments",
  type="RFC",
  number="240",
  pages="1--4",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 252",
url="https://www.rfc-editor.org/rfc/rfc240.txt",
  key="RFC 240",
  doi="10.17487/RFC0240",
  }

@misc{rfc241,
  author="A.M. McKenzie",
  title="{Connecting computers to MLC ports}",
  howpublished="RFC 241",
  series="Internet Request for Comments",
  type="RFC",
  number="241",
  pages="1--2",
  year=1971,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc241.txt",
  key="RFC 241",
  doi="10.17487/RFC0241",
  }

@misc{rfc242,
  author="L. Haibt and A.P. Mullery",
  title="{Data Descriptive Language for Shared Data}",
  howpublished="RFC 242",
  series="Internet Request for Comments",
  type="RFC",
  number="242",
  pages="1--10",
  year=1971,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc242.txt",
  key="RFC 242",
  doi="10.17487/RFC0242",
  }

@misc{rfc243,
  author="A.P. Mullery",
  title="{Network and data sharing bibliography}",
  howpublished="RFC 243",
  series="Internet Request for Comments",
  type="RFC",
  number="243",
  pages="1--7",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 290",
url="https://www.rfc-editor.org/rfc/rfc243.txt",
  key="RFC 243",
  doi="10.17487/RFC0243",
  }

@misc{rfc245,
  author="C. Falls",
  title="{Reservations for Network Group meeting}",
  howpublished="RFC 245",
  series="Internet Request for Comments",
  type="RFC",
  number="245",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc245.txt",
  key="RFC 245",
  doi="10.17487/RFC0245",
  }

@misc{rfc246,
  author="A. Vezza",
  title="{Network Graphics meeting}",
  howpublished="RFC 246",
  series="Internet Request for Comments",
  type="RFC",
  number="246",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc246.txt",
  key="RFC 246",
  doi="10.17487/RFC0246",
  }

@misc{rfc247,
  author="P.M. Karp",
  title="{Proffered set of standard host names}",
  howpublished="RFC 247",
  series="Internet Request for Comments",
  type="RFC",
  number="247",
  pages="1--4",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc247.txt",
  key="RFC 247",
  doi="10.17487/RFC0247",
  }

@misc{rfc249,
  author="R.F. Borelli",
  title="{Coordination of equipment and supplies purchase}",
  howpublished="RFC 249",
  series="Internet Request for Comments",
  type="RFC",
  number="249",
  pages="1--2",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc249.txt",
  key="RFC 249",
  doi="10.17487/RFC0249",
  }

@misc{rfc250,
  author="H. Brodie",
  title="{Some thoughts on file transfer}",
  howpublished="RFC 250",
  series="Internet Request for Comments",
  type="RFC",
  number="250",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc250.txt",
  key="RFC 250",
  doi="10.17487/RFC0250",
  }

@misc{rfc251,
  author="D. Stern",
  title="{Weather data}",
  howpublished="RFC 251",
  series="Internet Request for Comments",
  type="RFC",
  number="251",
  pages="1--2",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc251.txt",
  key="RFC 251",
  doi="10.17487/RFC0251",
  }

@misc{rfc252,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 252",
  series="Internet Request for Comments",
  type="RFC",
  number="252",
  pages="1--3",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 255",
url="https://www.rfc-editor.org/rfc/rfc252.txt",
  key="RFC 252",
  doi="10.17487/RFC0252",
  }

@misc{rfc253,
  author="J.A. Moorer",
  title="{Second Network Graphics meeting details}",
  howpublished="RFC 253",
  series="Internet Request for Comments",
  type="RFC",
  number="253",
  pages="1--1",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc253.txt",
  key="RFC 253",
  doi="10.17487/RFC0253",
  }

@misc{rfc254,
  author="A. Bhushan",
  title="{Scenarios for using ARPANET computers}",
  howpublished="RFC 254",
  series="Internet Request for Comments",
  type="RFC",
  number="254",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc254.txt",
  key="RFC 254",
  doi="10.17487/RFC0254",
  }

@misc{rfc255,
  author="E. Westheimer",
  title="{Status of network hosts}",
  howpublished="RFC 255",
  series="Internet Request for Comments",
  type="RFC",
  number="255",
  pages="1--2",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 266",
url="https://www.rfc-editor.org/rfc/rfc255.txt",
  key="RFC 255",
  doi="10.17487/RFC0255",
  }

@misc{rfc256,
  author="B. Cosell",
  title="{IMPSYS change notification}",
  howpublished="RFC 256",
  series="Internet Request for Comments",
  type="RFC",
  number="256",
  pages="1--1",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc256.txt",
  key="RFC 256",
  doi="10.17487/RFC0256",
  }

@misc{rfc263,
  author="A.M. McKenzie",
  title="{``Very Distant'' Host interface}",
  howpublished="RFC 263",
  series="Internet Request for Comments",
  type="RFC",
  number="263",
  pages="1--2",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc263.txt",
  key="RFC 263",
  doi="10.17487/RFC0263",
  }

@misc{rfc264,
  author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenize and B. Sundberg and D. Watson and J. White",
  title="{The Data Transfer Protocol}",
  howpublished="RFC 264",
  series="Internet Request for Comments",
  type="RFC",
  number="264",
  pages="1--9",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 354, updated by RFC 310",
url="https://www.rfc-editor.org/rfc/rfc264.txt",
  key="RFC 264",
  keywords="FTP, DTP",
  doi="10.17487/RFC0264",
  }

@misc{rfc265,
  author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenzie and J. Melvin and B. Sundberg and D. Watson and J. White",
  title="{The File Transfer Protocol}",
  howpublished="RFC 265",
  series="Internet Request for Comments",
  type="RFC",
  number="265",
  pages="1--12",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 354, updated by RFCs 281, 294, 310",
url="https://www.rfc-editor.org/rfc/rfc265.txt",
  key="RFC 265",
  keywords="FTP",
  doi="10.17487/RFC0265",
  }

@misc{rfc266,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 266",
  series="Internet Request for Comments",
  type="RFC",
  number="266",
  pages="1--2",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 267",
url="https://www.rfc-editor.org/rfc/rfc266.txt",
  key="RFC 266",
  doi="10.17487/RFC0266",
  }

@misc{rfc267,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 267",
  series="Internet Request for Comments",
  type="RFC",
  number="267",
  pages="1--4",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 287",
url="https://www.rfc-editor.org/rfc/rfc267.txt",
  key="RFC 267",
  doi="10.17487/RFC0267",
  }

@misc{rfc268,
  author="J. Postel",
  title="{Graphics facilities information}",
  howpublished="RFC 268",
  series="Internet Request for Comments",
  type="RFC",
  number="268",
  pages="1--1",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc268.txt",
  key="RFC 268",
  doi="10.17487/RFC0268",
  }

@misc{rfc269,
  author="H. Brodie",
  title="{Some Experience with File Transfer}",
  howpublished="RFC 269",
  series="Internet Request for Comments",
  type="RFC",
  number="269",
  pages="1--3",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc269.txt",
  key="RFC 269",
  doi="10.17487/RFC0269",
  }

@misc{rfc270,
  author="A.M. McKenzie",
  title="{Correction to BBN Report No. 1822 (NIC NO 7958)}",
  howpublished="RFC 270",
  series="Internet Request for Comments",
  type="RFC",
  number="270",
  pages="1--1",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc270.txt",
  key="RFC 270",
  doi="10.17487/RFC0270",
  }

@misc{rfc271,
  author="B. Cosell",
  title="{IMP System change notifications}",
  howpublished="RFC 271",
  series="Internet Request for Comments",
  type="RFC",
  number="271",
  pages="1--2",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc271.txt",
  key="RFC 271",
  doi="10.17487/RFC0271",
  }

@misc{rfc273,
  author="R.W. Watson",
  title="{More on standard host names}",
  howpublished="RFC 273",
  series="Internet Request for Comments",
  type="RFC",
  number="273",
  pages="1--3",
  year=1971,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc273.txt",
  key="RFC 273",
  doi="10.17487/RFC0273",
  }

@misc{rfc274,
  author="E. Forman",
  title="{Establishing a local guide for network usage}",
  howpublished="RFC 274",
  series="Internet Request for Comments",
  type="RFC",
  number="274",
  pages="1--5",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc274.txt",
  key="RFC 274",
  doi="10.17487/RFC0274",
  }

@misc{rfc276,
  author="R.W. Watson",
  title="{NIC course}",
  howpublished="RFC 276",
  series="Internet Request for Comments",
  type="RFC",
  number="276",
  pages="1--1",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc276.txt",
  key="RFC 276",
  doi="10.17487/RFC0276",
  }

@misc{rfc278,
  author="A.K. Bhushan and R.T. Braden and E. Harslem and J.F. Heafner and A.M. McKenzie and J.T. Melvin and R.L. Sundberg and R.W. Watson and J.E. White",
  title="{Revision of the Mail Box Protocol}",
  howpublished="RFC 278",
  series="Internet Request for Comments",
  type="RFC",
  number="278",
  pages="1--4",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc278.txt",
  key="RFC 278",
  doi="10.17487/RFC0278",
  }

@misc{rfc280,
  author="R.W. Watson",
  title="{A Draft of Host Names}",
  howpublished="RFC 280",
  series="Internet Request for Comments",
  type="RFC",
  number="280",
  pages="1--3",
  year=1971,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc280.txt",
  key="RFC 280",
  doi="10.17487/RFC0280",
  }

@misc{rfc281,
  author="A.M. McKenzie",
  title="{Suggested addition to File Transfer Protocol}",
  howpublished="RFC 281",
  series="Internet Request for Comments",
  type="RFC",
  number="281",
  pages="1--8",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc281.txt",
  key="RFC 281",
  keywords="FTP",
  doi="10.17487/RFC0281",
  }

@misc{rfc282,
  author="M.A. Padlipsky",
  title="{Graphics meeting report}",
  howpublished="RFC 282",
  series="Internet Request for Comments",
  type="RFC",
  number="282",
  pages="1--8",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc282.txt",
  key="RFC 282",
  doi="10.17487/RFC0282",
  }

@misc{rfc283,
  author="R.T. Braden",
  title="{NETRJT: Remote Job Service Protocol for TIPS}",
  howpublished="RFC 283",
  series="Internet Request for Comments",
  type="RFC",
  number="283",
  pages="1--9",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc283.txt",
  key="RFC 283",
  doi="10.17487/RFC0283",
  }

@misc{rfc285,
  author="D. Huff",
  title="{Network graphics}",
  howpublished="RFC 285",
  series="Internet Request for Comments",
  type="RFC",
  number="285",
  pages="1--8",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc285.txt",
  key="RFC 285",
  doi="10.17487/RFC0285",
  }

@misc{rfc286,
  author="E. Forman",
  title="{Network Library Information System}",
  howpublished="RFC 286",
  series="Internet Request for Comments",
  type="RFC",
  number="286",
  pages="1--1",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc286.txt",
  key="RFC 286",
  doi="10.17487/RFC0286",
  }

@misc{rfc287,
  author="E. Westheimer",
  title="{Status of Network Hosts}",
  howpublished="RFC 287",
  series="Internet Request for Comments",
  type="RFC",
  number="287",
  pages="1--5",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 288",
url="https://www.rfc-editor.org/rfc/rfc287.txt",
  key="RFC 287",
  doi="10.17487/RFC0287",
  }

@misc{rfc288,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 288",
  series="Internet Request for Comments",
  type="RFC",
  number="288",
  pages="1--4",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 293, updated by RFC 293",
url="https://www.rfc-editor.org/rfc/rfc288.txt",
  key="RFC 288",
  doi="10.17487/RFC0288",
  }

@misc{rfc289,
  author="R.W. Watson",
  title="{What we hope is an official list of host names}",
  howpublished="RFC 289",
  series="Internet Request for Comments",
  type="RFC",
  number="289",
  pages="1--3",
  year=1971,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 384",
url="https://www.rfc-editor.org/rfc/rfc289.txt",
  key="RFC 289",
  doi="10.17487/RFC0289",
  }

@misc{rfc290,
  author="A.P. Mullery",
  title="{Computer networks and data sharing: A bibliography}",
  howpublished="RFC 290",
  series="Internet Request for Comments",
  type="RFC",
  number="290",
  pages="1--15",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc290.txt",
  key="RFC 290",
  doi="10.17487/RFC0290",
  }

@misc{rfc291,
  author="D.B. McKay",
  title="{Data Management Meeting Announcement}",
  howpublished="RFC 291",
  series="Internet Request for Comments",
  type="RFC",
  number="291",
  pages="1--2",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc291.txt",
  key="RFC 291",
  doi="10.17487/RFC0291",
  }

@misc{rfc292,
  author="J.C. Michener and I.W. Cotton and K.C. Kelley and D.E. Liddle and E. Meyer",
  title="{Graphics Protocol: Level 0 only}",
  howpublished="RFC 292",
  series="Internet Request for Comments",
  type="RFC",
  number="292",
  pages="1--10",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 493",
url="https://www.rfc-editor.org/rfc/rfc292.txt",
  key="RFC 292",
  doi="10.17487/RFC0292",
  }

@misc{rfc293,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 293",
  series="Internet Request for Comments",
  type="RFC",
  number="293",
  pages="1--4",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 298",
url="https://www.rfc-editor.org/rfc/rfc293.txt",
  key="RFC 293",
  doi="10.17487/RFC0293",
  }

@misc{rfc294,
  author="A.K. Bhushan",
  title="{The Use of ``Set Data Type'' Transaction in File Transfer Protocol}",
  howpublished="RFC 294",
  series="Internet Request for Comments",
  type="RFC",
  number="294",
  pages="1--2",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc294.txt",
  key="RFC 294",
  keywords="FTP",
  doi="10.17487/RFC0294",
  }

@misc{rfc295,
  author="J. Postel",
  title="{Report of the Protocol Workshop, 12 October 1971}",
  howpublished="RFC 295",
  series="Internet Request for Comments",
  type="RFC",
  number="295",
  pages="1--4",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc295.txt",
  key="RFC 295",
  doi="10.17487/RFC0295",
  }

@misc{rfc296,
  author="D.E. Liddle",
  title="{DS-1 Display System}",
  howpublished="RFC 296",
  series="Internet Request for Comments",
  type="RFC",
  number="296",
  pages="1--17",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc296.txt",
  key="RFC 296",
  doi="10.17487/RFC0296",
  }

@misc{rfc297,
  author="D.C. Walden",
  title="{TIP Message Buffers}",
  howpublished="RFC 297",
  series="Internet Request for Comments",
  type="RFC",
  number="297",
  pages="1--2",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc297.txt",
  key="RFC 297",
  doi="10.17487/RFC0297",
  }

@misc{rfc298,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 298",
  series="Internet Request for Comments",
  type="RFC",
  number="298",
  pages="1--4",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 306",
url="https://www.rfc-editor.org/rfc/rfc298.txt",
  key="RFC 298",
  doi="10.17487/RFC0298",
  }

@misc{rfc299,
  author="D. Hopkin",
  title="{Information Management System}",
  howpublished="RFC 299",
  series="Internet Request for Comments",
  type="RFC",
  number="299",
  pages="1--1",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc299.txt",
  key="RFC 299",
  doi="10.17487/RFC0299",
  }

@misc{rfc300,
  author="J.B. North",
  title="{ARPA Network mailing lists}",
  howpublished="RFC 300",
  series="Internet Request for Comments",
  type="RFC",
  number="300",
  pages="1--9",
  year=1972,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 303",
url="https://www.rfc-editor.org/rfc/rfc300.txt",
  key="RFC 300",
  doi="10.17487/RFC0300",
  }

@misc{rfc301,
  author="R. Alter",
  title="{BBN IMP (\#5) and NCC Schedule March 4, 1971}",
  howpublished="RFC 301",
  series="Internet Request for Comments",
  type="RFC",
  number="301",
  pages="1--1",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc301.txt",
  key="RFC 301",
  doi="10.17487/RFC0301",
  }

@misc{rfc302,
  author="R.F. Bryan",
  title="{Exercising The ARPANET}",
  howpublished="RFC 302",
  series="Internet Request for Comments",
  type="RFC",
  number="302",
  pages="1--3",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc302.txt",
  key="RFC 302",
  doi="10.17487/RFC0302",
  }

@misc{rfc303,
  author="Network Information Center. Stanford Research Institute",
  title="{ARPA Network mailing lists}",
  howpublished="RFC 303",
  series="Internet Request for Comments",
  type="RFC",
  number="303",
  pages="1--11",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 329",
url="https://www.rfc-editor.org/rfc/rfc303.txt",
  key="RFC 303",
  doi="10.17487/RFC0303",
  }

@misc{rfc304,
  author="D.B. McKay",
  title="{Data Management System Proposal for the ARPA Network}",
  howpublished="RFC 304",
  series="Internet Request for Comments",
  type="RFC",
  number="304",
  pages="1--8",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc304.txt",
  key="RFC 304",
  doi="10.17487/RFC0304",
  }

@misc{rfc305,
  author="R. Alter",
  title="{Unknown Host Numbers}",
  howpublished="RFC 305",
  series="Internet Request for Comments",
  type="RFC",
  number="305",
  pages="1--1",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc305.txt",
  key="RFC 305",
  doi="10.17487/RFC0305",
  }

@misc{rfc306,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 306",
  series="Internet Request for Comments",
  type="RFC",
  number="306",
  pages="1--4",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 315",
url="https://www.rfc-editor.org/rfc/rfc306.txt",
  key="RFC 306",
  doi="10.17487/RFC0306",
  }

@misc{rfc307,
  author="E. Harslem",
  title="{Using network Remote Job Entry}",
  howpublished="RFC 307",
  series="Internet Request for Comments",
  type="RFC",
  number="307",
  pages="1--6",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc307.txt",
  key="RFC 307",
  doi="10.17487/RFC0307",
  }

@misc{rfc308,
  author="M. Seriff",
  title="{ARPANET host availability data}",
  howpublished="RFC 308",
  series="Internet Request for Comments",
  type="RFC",
  number="308",
  pages="1--4",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc308.txt",
  key="RFC 308",
  doi="10.17487/RFC0308",
  }

@misc{rfc309,
  author="A.K. Bhushan",
  title="{Data and File Transfer Workshop Announcement}",
  howpublished="RFC 309",
  series="Internet Request for Comments",
  type="RFC",
  number="309",
  pages="1--6",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc309.txt",
  key="RFC 309",
  keywords="FTP, DTP",
  doi="10.17487/RFC0309",
  }

@misc{rfc310,
  author="A.K. Bhushan",
  title="{Another Look at Data and File Transfer Protocols}",
  howpublished="RFC 310",
  series="Internet Request for Comments",
  type="RFC",
  number="310",
  pages="1--7",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc310.txt",
  key="RFC 310",
  keywords="FTP",
  doi="10.17487/RFC0310",
  }

@misc{rfc311,
  author="R.F. Bryan",
  title="{New Console Attachments to the USCB Host}",
  howpublished="RFC 311",
  series="Internet Request for Comments",
  type="RFC",
  number="311",
  pages="1--2",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc311.txt",
  key="RFC 311",
  doi="10.17487/RFC0311",
  }

@misc{rfc312,
  author="A.M. McKenzie",
  title="{Proposed Change in IMP-to-Host Protocol}",
  howpublished="RFC 312",
  series="Internet Request for Comments",
  type="RFC",
  number="312",
  pages="1--2",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc312.txt",
  key="RFC 312",
  doi="10.17487/RFC0312",
  }

@misc{rfc313,
  author="T.C. O'Sullivan",
  title="{Computer based instruction}",
  howpublished="RFC 313",
  series="Internet Request for Comments",
  type="RFC",
  number="313",
  pages="1--8",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc313.txt",
  key="RFC 313",
  doi="10.17487/RFC0313",
  }

@misc{rfc314,
  author="I.W. Cotton",
  title="{Network Graphics Working Group Meeting}",
  howpublished="RFC 314",
  series="Internet Request for Comments",
  type="RFC",
  number="314",
  pages="1--1",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc314.txt",
  key="RFC 314",
  doi="10.17487/RFC0314",
  }

@misc{rfc315,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 315",
  series="Internet Request for Comments",
  type="RFC",
  number="315",
  pages="1--4",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 319",
url="https://www.rfc-editor.org/rfc/rfc315.txt",
  key="RFC 315",
  doi="10.17487/RFC0315",
  }

@misc{rfc316,
  author="D.B. McKay and A.P. Mullery",
  title="{ARPA Network Data Management Working Group}",
  howpublished="RFC 316",
  series="Internet Request for Comments",
  type="RFC",
  number="316",
  pages="1--7",
  year=1972,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc316.txt",
  key="RFC 316",
  doi="10.17487/RFC0316",
  }

@misc{rfc317,
  author="J. Postel",
  title="{Official Host-Host Protocol Modification: Assigned Link Numbers}",
  howpublished="RFC 317",
  series="Internet Request for Comments",
  type="RFC",
  number="317",
  pages="1--1",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 604",
url="https://www.rfc-editor.org/rfc/rfc317.txt",
  key="RFC 317",
  doi="10.17487/RFC0317",
  }

@misc{rfc318,
  author="J. Postel",
  title="{Telnet Protocols}",
  howpublished="RFC 318",
  series="Internet Request for Comments",
  type="RFC",
  number="318",
  pages="1--16",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 435",
url="https://www.rfc-editor.org/rfc/rfc318.txt",
  key="RFC 318",
  doi="10.17487/RFC0318",
  }

@misc{rfc319,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 319",
  series="Internet Request for Comments",
  type="RFC",
  number="319",
  pages="1--4",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 326",
url="https://www.rfc-editor.org/rfc/rfc319.txt",
  key="RFC 319",
  doi="10.17487/RFC0319",
  }

@misc{rfc320,
  author="R. Reddy",
  title="{Workshop on Hard Copy Line Graphics}",
  howpublished="RFC 320",
  series="Internet Request for Comments",
  type="RFC",
  number="320",
  pages="1--3",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc320.txt",
  key="RFC 320",
  doi="10.17487/RFC0320",
  }

@misc{rfc321,
  author="P.M. Karp",
  title="{CBI Networking Activity at MITRE}",
  howpublished="RFC 321",
  series="Internet Request for Comments",
  type="RFC",
  number="321",
  pages="1--13",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc321.txt",
  key="RFC 321",
  doi="10.17487/RFC0321",
  }

@misc{rfc322,
  author="V. Cerf and J. Postel",
  title="{Well known socket numbers}",
  howpublished="RFC 322",
  series="Internet Request for Comments",
  type="RFC",
  number="322",
  pages="1--1",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc322.txt",
  key="RFC 322",
  doi="10.17487/RFC0322",
  }

@misc{rfc323,
  author="V. Cerf",
  title="{Formation of Network Measurement Group (NMG)}",
  howpublished="RFC 323",
  series="Internet Request for Comments",
  type="RFC",
  number="323",
  pages="1--9",
  year=1972,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 388",
url="https://www.rfc-editor.org/rfc/rfc323.txt",
  key="RFC 323",
  doi="10.17487/RFC0323",
  }

@misc{rfc324,
  author="J. Postel",
  title="{RJE Protocol meeting}",
  howpublished="RFC 324",
  series="Internet Request for Comments",
  type="RFC",
  number="324",
  pages="1--1",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc324.txt",
  key="RFC 324",
  doi="10.17487/RFC0324",
  }

@misc{rfc325,
  author="G. Hicks",
  title="{Network Remote Job Entry program - NETRJS}",
  howpublished="RFC 325",
  series="Internet Request for Comments",
  type="RFC",
  number="325",
  pages="1--9",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc325.txt",
  key="RFC 325",
  doi="10.17487/RFC0325",
  }

@misc{rfc326,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 326",
  series="Internet Request for Comments",
  type="RFC",
  number="326",
  pages="1--4",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 330",
url="https://www.rfc-editor.org/rfc/rfc326.txt",
  key="RFC 326",
  doi="10.17487/RFC0326",
  }

@misc{rfc327,
  author="A.K. Bhushan",
  title="{Data and File Transfer workshop notes}",
  howpublished="RFC 327",
  series="Internet Request for Comments",
  type="RFC",
  number="327",
  pages="1--5",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc327.txt",
  key="RFC 327",
  doi="10.17487/RFC0327",
  }

@misc{rfc328,
  author="J. Postel",
  title="{Suggested Telnet Protocol Changes}",
  howpublished="RFC 328",
  series="Internet Request for Comments",
  type="RFC",
  number="328",
  pages="1--2",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc328.txt",
  key="RFC 328",
  doi="10.17487/RFC0328",
  }

@misc{rfc329,
  author="Network Information Center. Stanford Research Institute",
  title="{ARPA Network Mailing Lists}",
  howpublished="RFC 329",
  series="Internet Request for Comments",
  type="RFC",
  number="329",
  pages="1--13",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 363",
url="https://www.rfc-editor.org/rfc/rfc329.txt",
  key="RFC 329",
  doi="10.17487/RFC0329",
  }

@misc{rfc330,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 330",
  series="Internet Request for Comments",
  type="RFC",
  number="330",
  pages="1--3",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 332",
url="https://www.rfc-editor.org/rfc/rfc330.txt",
  key="RFC 330",
  doi="10.17487/RFC0330",
  }

@misc{rfc331,
  author="J.M. McQuillan",
  title="{IMP System Change Notification}",
  howpublished="RFC 331",
  series="Internet Request for Comments",
  type="RFC",
  number="331",
  pages="1--1",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 343",
url="https://www.rfc-editor.org/rfc/rfc331.txt",
  key="RFC 331",
  doi="10.17487/RFC0331",
  }

@misc{rfc332,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 332",
  series="Internet Request for Comments",
  type="RFC",
  number="332",
  pages="1--4",
  year=1972,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 342",
url="https://www.rfc-editor.org/rfc/rfc332.txt",
  key="RFC 332",
  doi="10.17487/RFC0332",
  }

@misc{rfc333,
  author="R.D. Bressler and D. Murphy and D.C. Walden",
  title="{Proposed experiment with a Message Switching Protocol}",
  howpublished="RFC 333",
  series="Internet Request for Comments",
  type="RFC",
  number="333",
  pages="1--26",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc333.txt",
  key="RFC 333",
  doi="10.17487/RFC0333",
  }

@misc{rfc334,
  author="A.M. McKenzie",
  title="{Network Use on May 8}",
  howpublished="RFC 334",
  series="Internet Request for Comments",
  type="RFC",
  number="334",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc334.txt",
  key="RFC 334",
  doi="10.17487/RFC0334",
  }

@misc{rfc335,
  author="R.F. Bryan",
  title="{New Interface - IMP/360}",
  howpublished="RFC 335",
  series="Internet Request for Comments",
  type="RFC",
  number="335",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc335.txt",
  key="RFC 335",
  doi="10.17487/RFC0335",
  }

@misc{rfc336,
  author="I.W. Cotton",
  title="{Level 0 Graphic Input Protocol}",
  howpublished="RFC 336",
  series="Internet Request for Comments",
  type="RFC",
  number="336",
  pages="1--2",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc336.txt",
  key="RFC 336",
  doi="10.17487/RFC0336",
  }

@misc{rfc338,
  author="R.T. Braden",
  title="{EBCDIC/ASCII Mapping for Network RJE}",
  howpublished="RFC 338",
  series="Internet Request for Comments",
  type="RFC",
  number="338",
  pages="1--6",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc338.txt",
  key="RFC 338",
  doi="10.17487/RFC0338",
  }

@misc{rfc339,
  author="R. Thomas",
  title="{MLTNET: A ``Multi Telnet'' Subsystem for Tenex}",
  howpublished="RFC 339",
  series="Internet Request for Comments",
  type="RFC",
  number="339",
  pages="1--4",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc339.txt",
  key="RFC 339",
  doi="10.17487/RFC0339",
  }

@misc{rfc340,
  author="T.C. O'Sullivan",
  title="{Proposed Telnet Changes}",
  howpublished="RFC 340",
  series="Internet Request for Comments",
  type="RFC",
  number="340",
  pages="1--2",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc340.txt",
  key="RFC 340",
  doi="10.17487/RFC0340",
  }

@misc{rfc342,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 342",
  series="Internet Request for Comments",
  type="RFC",
  number="342",
  pages="1--4",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 344",
url="https://www.rfc-editor.org/rfc/rfc342.txt",
  key="RFC 342",
  doi="10.17487/RFC0342",
  }

@misc{rfc343,
  author="A.M. McKenzie",
  title="{IMP System change notification}",
  howpublished="RFC 343",
  series="Internet Request for Comments",
  type="RFC",
  number="343",
  pages="1--2",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 359",
url="https://www.rfc-editor.org/rfc/rfc343.txt",
  key="RFC 343",
  doi="10.17487/RFC0343",
  }

@misc{rfc344,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 344",
  series="Internet Request for Comments",
  type="RFC",
  number="344",
  pages="1--4",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 353",
url="https://www.rfc-editor.org/rfc/rfc344.txt",
  key="RFC 344",
  doi="10.17487/RFC0344",
  }

@misc{rfc345,
  author="K.C. Kelley",
  title="{Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)}",
  howpublished="RFC 345",
  series="Internet Request for Comments",
  type="RFC",
  number="345",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc345.txt",
  key="RFC 345",
  keywords="MIP",
  doi="10.17487/RFC0345",
  }

@misc{rfc346,
  author="J. Postel",
  title="{Satellite Considerations}",
  howpublished="RFC 346",
  series="Internet Request for Comments",
  type="RFC",
  number="346",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc346.txt",
  key="RFC 346",
  doi="10.17487/RFC0346",
  }

@misc{rfc347,
  author="J. Postel",
  title="{Echo process}",
  howpublished="RFC 347",
  series="Internet Request for Comments",
  type="RFC",
  number="347",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc347.txt",
  key="RFC 347",
  doi="10.17487/RFC0347",
  }

@misc{rfc348,
  author="J. Postel",
  title="{Discard Process}",
  howpublished="RFC 348",
  series="Internet Request for Comments",
  type="RFC",
  number="348",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc348.txt",
  key="RFC 348",
  doi="10.17487/RFC0348",
  }

@misc{rfc349,
  author="J. Postel",
  title="{Proposed Standard Socket Numbers}",
  howpublished="RFC 349",
  series="Internet Request for Comments",
  type="RFC",
  number="349",
  pages="1--1",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 433",
url="https://www.rfc-editor.org/rfc/rfc349.txt",
  key="RFC 349",
  doi="10.17487/RFC0349",
  }

@misc{rfc350,
  author="R. Stoughton",
  title="{User Accounts for UCSB On-Line System}",
  howpublished="RFC 350",
  series="Internet Request for Comments",
  type="RFC",
  number="350",
  pages="1--3",
  year=1972,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc350.txt",
  key="RFC 350",
  doi="10.17487/RFC0350",
  }

@misc{rfc351,
  author="D. Crocker",
  title="{Graphics information form for the ARPANET graphics resources notebook}",
  howpublished="RFC 351",
  series="Internet Request for Comments",
  type="RFC",
  number="351",
  pages="1--2",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc351.txt",
  key="RFC 351",
  doi="10.17487/RFC0351",
  }

@misc{rfc352,
  author="D. Crocker",
  title="{TIP Site Information Form}",
  howpublished="RFC 352",
  series="Internet Request for Comments",
  type="RFC",
  number="352",
  pages="1--3",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc352.txt",
  key="RFC 352",
  doi="10.17487/RFC0352",
  }

@misc{rfc353,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 353",
  series="Internet Request for Comments",
  type="RFC",
  number="353",
  pages="1--5",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 362",
url="https://www.rfc-editor.org/rfc/rfc353.txt",
  key="RFC 353",
  doi="10.17487/RFC0353",
  }

@misc{rfc354,
  author="A.K. Bhushan",
  title="{File Transfer Protocol}",
  howpublished="RFC 354",
  series="Internet Request for Comments",
  type="RFC",
  number="354",
  pages="1--25",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 542, updated by RFCs 385, 454, 683",
url="https://www.rfc-editor.org/rfc/rfc354.txt",
  key="RFC 354",
  keywords="FTP",
  doi="10.17487/RFC0354",
  }

@misc{rfc355,
  author="J. Davidson",
  title="{Response to NWG/RFC 346}",
  howpublished="RFC 355",
  series="Internet Request for Comments",
  type="RFC",
  number="355",
  pages="1--3",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc355.txt",
  key="RFC 355",
  doi="10.17487/RFC0355",
  }

@misc{rfc356,
  author="R. Alter",
  title="{ARPA Network Control Center}",
  howpublished="RFC 356",
  series="Internet Request for Comments",
  type="RFC",
  number="356",
  pages="1--1",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc356.txt",
  key="RFC 356",
  doi="10.17487/RFC0356",
  }

@misc{rfc357,
  author="J. Davidson",
  title="{Echoing strategy for satellite links}",
  howpublished="RFC 357",
  series="Internet Request for Comments",
  type="RFC",
  number="357",
  pages="1--13",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc357.txt",
  key="RFC 357",
  doi="10.17487/RFC0357",
  }

@misc{rfc359,
  author="D.C. Walden",
  title="{Status of the Release of the New IMP System (2600)}",
  howpublished="RFC 359",
  series="Internet Request for Comments",
  type="RFC",
  number="359",
  pages="1--1",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc359.txt",
  key="RFC 359",
  doi="10.17487/RFC0359",
  }

@misc{rfc360,
  author="C. Holland",
  title="{Proposed Remote Job Entry Protocol}",
  howpublished="RFC 360",
  series="Internet Request for Comments",
  type="RFC",
  number="360",
  pages="1--18",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 407",
url="https://www.rfc-editor.org/rfc/rfc360.txt",
  key="RFC 360",
  doi="10.17487/RFC0360",
  }

@misc{rfc361,
  author="R.D. Bressler",
  title="{Deamon Processes on Host 106}",
  howpublished="RFC 361",
  series="Internet Request for Comments",
  type="RFC",
  number="361",
  pages="1--1",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc361.txt",
  key="RFC 361",
  doi="10.17487/RFC0361",
  }

@misc{rfc362,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 362",
  series="Internet Request for Comments",
  type="RFC",
  number="362",
  pages="1--4",
  year=1972,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 366",
url="https://www.rfc-editor.org/rfc/rfc362.txt",
  key="RFC 362",
  doi="10.17487/RFC0362",
  }

@misc{rfc363,
  author="Network Information Center. Stanford Research Institute",
  title="{ARPA Network mailing lists}",
  howpublished="RFC 363",
  series="Internet Request for Comments",
  type="RFC",
  number="363",
  pages="1--13",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 402",
url="https://www.rfc-editor.org/rfc/rfc363.txt",
  key="RFC 363",
  doi="10.17487/RFC0363",
  }

@misc{rfc364,
  author="M.D. Abrams",
  title="{Serving remote users on the ARPANET}",
  howpublished="RFC 364",
  series="Internet Request for Comments",
  type="RFC",
  number="364",
  pages="1--6",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc364.txt",
  key="RFC 364",
  doi="10.17487/RFC0364",
  }

@misc{rfc365,
  author="D.C. Walden",
  title="{Letter to All TIP Users}",
  howpublished="RFC 365",
  series="Internet Request for Comments",
  type="RFC",
  number="365",
  pages="1--5",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc365.txt",
  key="RFC 365",
  doi="10.17487/RFC0365",
  }

@misc{rfc366,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 366",
  series="Internet Request for Comments",
  type="RFC",
  number="366",
  pages="1--4",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 367",
url="https://www.rfc-editor.org/rfc/rfc366.txt",
  key="RFC 366",
  doi="10.17487/RFC0366",
  }

@misc{rfc367,
  author="E. Westheimer",
  title="{Network host status}",
  howpublished="RFC 367",
  series="Internet Request for Comments",
  type="RFC",
  number="367",
  pages="1--4",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 370",
url="https://www.rfc-editor.org/rfc/rfc367.txt",
  key="RFC 367",
  doi="10.17487/RFC0367",
  }

@misc{rfc368,
  author="R.T. Braden",
  title="{Comments on ``Proposed Remote Job Entry Protocol''}",
  howpublished="RFC 368",
  series="Internet Request for Comments",
  type="RFC",
  number="368",
  pages="1--2",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc368.txt",
  key="RFC 368",
  doi="10.17487/RFC0368",
  }

@misc{rfc369,
  author="J.R. Pickens",
  title="{Evaluation of ARPANET services January-March, 1972}",
  howpublished="RFC 369",
  series="Internet Request for Comments",
  type="RFC",
  number="369",
  pages="1--11",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc369.txt",
  key="RFC 369",
  doi="10.17487/RFC0369",
  }

@misc{rfc370,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 370",
  series="Internet Request for Comments",
  type="RFC",
  number="370",
  pages="1--5",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 376",
url="https://www.rfc-editor.org/rfc/rfc370.txt",
  key="RFC 370",
  doi="10.17487/RFC0370",
  }

@misc{rfc371,
  author="R.E. Kahn",
  title="{Demonstration at International Computer Communications Conference}",
  howpublished="RFC 371",
  series="Internet Request for Comments",
  type="RFC",
  number="371",
  pages="1--2",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc371.txt",
  key="RFC 371",
  doi="10.17487/RFC0371",
  }

@misc{rfc372,
  author="R.W. Watson",
  title="{Notes on a Conversation with Bob Kahn on the ICCC}",
  howpublished="RFC 372",
  series="Internet Request for Comments",
  type="RFC",
  number="372",
  pages="1--4",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc372.txt",
  key="RFC 372",
  doi="10.17487/RFC0372",
  }

@misc{rfc373,
  author="J. McCarthy",
  title="{Arbitrary Character Sets}",
  howpublished="RFC 373",
  series="Internet Request for Comments",
  type="RFC",
  number="373",
  pages="1--4",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc373.txt",
  key="RFC 373",
  doi="10.17487/RFC0373",
  }

@misc{rfc374,
  author="A.M. McKenzie",
  title="{IMP System Announcement}",
  howpublished="RFC 374",
  series="Internet Request for Comments",
  type="RFC",
  number="374",
  pages="1--2",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc374.txt",
  key="RFC 374",
  doi="10.17487/RFC0374",
  }

@misc{rfc376,
  author="E. Westheimer",
  title="{Network Host Status}",
  howpublished="RFC 376",
  series="Internet Request for Comments",
  type="RFC",
  number="376",
  pages="1--5",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc376.txt",
  key="RFC 376",
  doi="10.17487/RFC0376",
  }

@misc{rfc377,
  author="R.T. Braden",
  title="{Using TSO via ARPA Network Virtual Terminal}",
  howpublished="RFC 377",
  series="Internet Request for Comments",
  type="RFC",
  number="377",
  pages="1--4",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc377.txt",
  key="RFC 377",
  doi="10.17487/RFC0377",
  }

@misc{rfc378,
  author="A.M. McKenzie",
  title="{Traffic statistics (July 1972)}",
  howpublished="RFC 378",
  series="Internet Request for Comments",
  type="RFC",
  number="378",
  pages="1--3",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 391",
url="https://www.rfc-editor.org/rfc/rfc378.txt",
  key="RFC 378",
  doi="10.17487/RFC0378",
  }

@misc{rfc379,
  author="R. Braden",
  title="{Using TSO at CCN}",
  howpublished="RFC 379",
  series="Internet Request for Comments",
  type="RFC",
  number="379",
  pages="1--5",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc379.txt",
  key="RFC 379",
  doi="10.17487/RFC0379",
  }

@misc{rfc381,
  author="J.M. McQuillan",
  title="{Three aids to improved network operation}",
  howpublished="RFC 381",
  series="Internet Request for Comments",
  type="RFC",
  number="381",
  pages="1--4",
  year=1972,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 394",
url="https://www.rfc-editor.org/rfc/rfc381.txt",
  key="RFC 381",
  doi="10.17487/RFC0381",
  }

@misc{rfc382,
  author="L. McDaniel",
  title="{Mathematical Software on the ARPA Network}",
  howpublished="RFC 382",
  series="Internet Request for Comments",
  type="RFC",
  number="382",
  pages="1--1",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc382.txt",
  key="RFC 382",
  doi="10.17487/RFC0382",
  }

@misc{rfc384,
  author="J.B. North",
  title="{Official site idents for organizations in the ARPA Network}",
  howpublished="RFC 384",
  series="Internet Request for Comments",
  type="RFC",
  number="384",
  pages="1--4",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc384.txt",
  key="RFC 384",
  doi="10.17487/RFC0384",
  }

@misc{rfc385,
  author="A.K. Bhushan",
  title="{Comments on the File Transfer Protocol}",
  howpublished="RFC 385",
  series="Internet Request for Comments",
  type="RFC",
  number="385",
  pages="1--6",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 414",
url="https://www.rfc-editor.org/rfc/rfc385.txt",
  key="RFC 385",
  keywords="FTP",
  doi="10.17487/RFC0385",
  }

@misc{rfc386,
  author="B. Cosell and D.C. Walden",
  title="{Letter to TIP users-2}",
  howpublished="RFC 386",
  series="Internet Request for Comments",
  type="RFC",
  number="386",
  pages="1--5",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc386.txt",
  key="RFC 386",
  doi="10.17487/RFC0386",
  }

@misc{rfc387,
  author="K.C. Kelley and J. Meir",
  title="{Some experiences in implementing Network Graphics Protocol Level 0}",
  howpublished="RFC 387",
  series="Internet Request for Comments",
  type="RFC",
  number="387",
  pages="1--5",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 401",
url="https://www.rfc-editor.org/rfc/rfc387.txt",
  key="RFC 387",
  doi="10.17487/RFC0387",
  }

@misc{rfc388,
  author="V. Cerf",
  title="{NCP statistics}",
  howpublished="RFC 388",
  series="Internet Request for Comments",
  type="RFC",
  number="388",
  pages="1--5",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc388.txt",
  key="RFC 388",
  doi="10.17487/RFC0388",
  }

@misc{rfc389,
  author="B. Noble",
  title="{UCLA Campus Computing Network Liaison Staff for ARPA Network}",
  howpublished="RFC 389",
  series="Internet Request for Comments",
  type="RFC",
  number="389",
  pages="1--2",
  year=1972,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 423",
url="https://www.rfc-editor.org/rfc/rfc389.txt",
  key="RFC 389",
  doi="10.17487/RFC0389",
  }

@misc{rfc390,
  author="R.T. Braden",
  title="{TSO Scenario}",
  howpublished="RFC 390",
  series="Internet Request for Comments",
  type="RFC",
  number="390",
  pages="1--4",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc390.txt",
  key="RFC 390",
  doi="10.17487/RFC0390",
  }

@misc{rfc391,
  author="A.M. McKenzie",
  title="{Traffic statistics (August 1972)}",
  howpublished="RFC 391",
  series="Internet Request for Comments",
  type="RFC",
  number="391",
  pages="1--3",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc391.txt",
  key="RFC 391",
  doi="10.17487/RFC0391",
  }

@misc{rfc392,
  author="G. Hicks and B.D. Wessler",
  title="{Measurement of host costs for transmitting network data}",
  howpublished="RFC 392",
  series="Internet Request for Comments",
  type="RFC",
  number="392",
  pages="1--6",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc392.txt",
  key="RFC 392",
  doi="10.17487/RFC0392",
  }

@misc{rfc393,
  author="J.M. Winett",
  title="{Comments on Telnet Protocol Changes}",
  howpublished="RFC 393",
  series="Internet Request for Comments",
  type="RFC",
  number="393",
  pages="1--4",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc393.txt",
  key="RFC 393",
  doi="10.17487/RFC0393",
  }

@misc{rfc394,
  author="J.M. McQuillan",
  title="{Two Proposed Changes to the IMP-Host Protocol}",
  howpublished="RFC 394",
  series="Internet Request for Comments",
  type="RFC",
  number="394",
  pages="1--3",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc394.txt",
  key="RFC 394",
  doi="10.17487/RFC0394",
  }

@misc{rfc395,
  author="J.M. McQuillan",
  title="{Switch Settings on IMPs and TIPs}",
  howpublished="RFC 395",
  series="Internet Request for Comments",
  type="RFC",
  number="395",
  pages="1--1",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc395.txt",
  key="RFC 395",
  doi="10.17487/RFC0395",
  }

@misc{rfc396,
  author="S. Bunch",
  title="{Network Graphics Working Group Meeting - Second Iteration}",
  howpublished="RFC 396",
  series="Internet Request for Comments",
  type="RFC",
  number="396",
  pages="1--1",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 474",
url="https://www.rfc-editor.org/rfc/rfc396.txt",
  key="RFC 396",
  doi="10.17487/RFC0396",
  }

@misc{rfc398,
  author="J.R. Pickens and E. Faeh",
  title="{UCSB Online Graphics}",
  howpublished="RFC 398",
  series="Internet Request for Comments",
  type="RFC",
  number="398",
  pages="1--2",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc398.txt",
  key="RFC 398",
  doi="10.17487/RFC0398",
  }

@misc{rfc399,
  author="M. Krilanovich",
  title="{SMFS Login and Logout}",
  howpublished="RFC 399",
  series="Internet Request for Comments",
  type="RFC",
  number="399",
  pages="1--2",
  year=1972,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 431",
url="https://www.rfc-editor.org/rfc/rfc399.txt",
  key="RFC 399",
  doi="10.17487/RFC0399",
  }

@misc{rfc400,
  author="A.M. McKenzie",
  title="{Traffic Statistics (September 1972)}",
  howpublished="RFC 400",
  series="Internet Request for Comments",
  type="RFC",
  number="400",
  pages="1--3",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc400.txt",
  key="RFC 400",
  doi="10.17487/RFC0400",
  }

@misc{rfc401,
  author="J. Hansen",
  title="{Conversion of NGP-0 Coordinates to Device Specific Coordinates}",
  howpublished="RFC 401",
  series="Internet Request for Comments",
  type="RFC",
  number="401",
  pages="1--2",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc401.txt",
  key="RFC 401",
  doi="10.17487/RFC0401",
  }

@misc{rfc402,
  author="J.B. North",
  title="{ARPA Network Mailing Lists}",
  howpublished="RFC 402",
  series="Internet Request for Comments",
  type="RFC",
  number="402",
  pages="1--16",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc402.txt",
  key="RFC 402",
  doi="10.17487/RFC0402",
  }

@misc{rfc403,
  author="G. Hicks",
  title="{Desirability of a Network 1108 Service}",
  howpublished="RFC 403",
  series="Internet Request for Comments",
  type="RFC",
  number="403",
  pages="1--5",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc403.txt",
  key="RFC 403",
  doi="10.17487/RFC0403",
  }

@misc{rfc404,
  author="A.M. McKenzie",
  title="{Host Address Changes Involving Rand and ISI}",
  howpublished="RFC 404",
  series="Internet Request for Comments",
  type="RFC",
  number="404",
  pages="1--1",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 405",
url="https://www.rfc-editor.org/rfc/rfc404.txt",
  key="RFC 404",
  doi="10.17487/RFC0404",
  }

@misc{rfc405,
  author="A.M. McKenzie",
  title="{Correction to RFC 404}",
  howpublished="RFC 405",
  series="Internet Request for Comments",
  type="RFC",
  number="405",
  pages="1--1",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc405.txt",
  key="RFC 405",
  doi="10.17487/RFC0405",
  }

@misc{rfc406,
  author="J.M. McQuillan",
  title="{Scheduled IMP Software Releases}",
  howpublished="RFC 406",
  series="Internet Request for Comments",
  type="RFC",
  number="406",
  pages="1--2",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc406.txt",
  key="RFC 406",
  doi="10.17487/RFC0406",
  }

@misc{rfc407,
  author="R.D. Bressler and R. Guida and A.M. McKenzie",
  title="{Remote Job Entry Protocol}",
  howpublished="RFC 407 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="407",
  pages="1--21",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc407.txt",
  key="RFC 407",
  keywords="RJE",
  doi="10.17487/RFC0407",
  }

@misc{rfc408,
  author="A.D. Owen and J. Postel",
  title="{NETBANK}",
  howpublished="RFC 408",
  series="Internet Request for Comments",
  type="RFC",
  number="408",
  pages="1--1",
  year=1972,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc408.txt",
  key="RFC 408",
  doi="10.17487/RFC0408",
  }

@misc{rfc409,
  author="J.E. White",
  title="{Tenex interface to UCSB's Simple-Minded File System}",
  howpublished="RFC 409",
  series="Internet Request for Comments",
  type="RFC",
  number="409",
  pages="1--8",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc409.txt",
  key="RFC 409",
  doi="10.17487/RFC0409",
  }

@misc{rfc410,
  author="J.M. McQuillan",
  title="{Removal of the 30-Second Delay When Hosts Come Up}",
  howpublished="RFC 410",
  series="Internet Request for Comments",
  type="RFC",
  number="410",
  pages="1--2",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc410.txt",
  key="RFC 410",
  doi="10.17487/RFC0410",
  }

@misc{rfc411,
  author="M.A. Padlipsky",
  title="{New MULTICS Network Software Features}",
  howpublished="RFC 411",
  series="Internet Request for Comments",
  type="RFC",
  number="411",
  pages="1--2",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc411.txt",
  key="RFC 411",
  doi="10.17487/RFC0411",
  }

@misc{rfc412,
  author="G. Hicks",
  title="{User FTP Documentation}",
  howpublished="RFC 412",
  series="Internet Request for Comments",
  type="RFC",
  number="412",
  pages="1--10",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc412.txt",
  key="RFC 412",
  doi="10.17487/RFC0412",
  }

@misc{rfc413,
  author="A.M. McKenzie",
  title="{Traffic statistics (October 1972)}",
  howpublished="RFC 413",
  series="Internet Request for Comments",
  type="RFC",
  number="413",
  pages="1--10",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc413.txt",
  key="RFC 413",
  doi="10.17487/RFC0413",
  }

@misc{rfc414,
  author="A.K. Bhushan",
  title="{File Transfer Protocol (FTP) status and further comments}",
  howpublished="RFC 414",
  series="Internet Request for Comments",
  type="RFC",
  number="414",
  pages="1--5",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc414.txt",
  key="RFC 414",
  doi="10.17487/RFC0414",
  }

@misc{rfc415,
  author="H. Murray",
  title="{Tenex bandwidth}",
  howpublished="RFC 415",
  series="Internet Request for Comments",
  type="RFC",
  number="415",
  pages="1--2",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc415.txt",
  key="RFC 415",
  doi="10.17487/RFC0415",
  }

@misc{rfc416,
  author="J.C. Norton",
  title="{ARC System Will Be Unavailable for Use During Thanksgiving Week}",
  howpublished="RFC 416",
  series="Internet Request for Comments",
  type="RFC",
  number="416",
  pages="1--2",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc416.txt",
  key="RFC 416",
  doi="10.17487/RFC0416",
  }

@misc{rfc417,
  author="J. Postel and C. Kline",
  title="{Link usage violation}",
  howpublished="RFC 417",
  series="Internet Request for Comments",
  type="RFC",
  number="417",
  pages="1--1",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc417.txt",
  key="RFC 417",
  doi="10.17487/RFC0417",
  }

@misc{rfc418,
  author="W. Hathaway",
  title="{Server File Transfer Under TSS/360 At NASA-Ames Research Center}",
  howpublished="RFC 418",
  series="Internet Request for Comments",
  type="RFC",
  number="418",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc418.txt",
  key="RFC 418",
  doi="10.17487/RFC0418",
  }

@misc{rfc419,
  author="A. Vezza",
  title="{To: Network liaisons and station agents}",
  howpublished="RFC 419",
  series="Internet Request for Comments",
  type="RFC",
  number="419",
  pages="1--1",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc419.txt",
  key="RFC 419",
  doi="10.17487/RFC0419",
  }

@misc{rfc420,
  author="H. Murray",
  title="{CCA ICCC weather demo}",
  howpublished="RFC 420",
  series="Internet Request for Comments",
  type="RFC",
  number="420",
  pages="1--8",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc420.txt",
  key="RFC 420",
  doi="10.17487/RFC0420",
  }

@misc{rfc421,
  author="A.M. McKenzie",
  title="{Software Consulting Service for Network Users}",
  howpublished="RFC 421",
  series="Internet Request for Comments",
  type="RFC",
  number="421",
  pages="1--2",
  year=1972,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc421.txt",
  key="RFC 421",
  doi="10.17487/RFC0421",
  }

@misc{rfc422,
  author="A.M. McKenzie",
  title="{Traffic statistics (November 1972)}",
  howpublished="RFC 422",
  series="Internet Request for Comments",
  type="RFC",
  number="422",
  pages="1--4",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc422.txt",
  key="RFC 422",
  doi="10.17487/RFC0422",
  }

@misc{rfc423,
  author="B. Noble",
  title="{UCLA Campus Computing Network Liaison Staff for ARPANET}",
  howpublished="RFC 423",
  series="Internet Request for Comments",
  type="RFC",
  number="423",
  pages="1--2",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc423.txt",
  key="RFC 423",
  doi="10.17487/RFC0423",
  }

@misc{rfc425,
  author="R.D. Bressler",
  title="{``But my NCP costs \$500 a day''}",
  howpublished="RFC 425",
  series="Internet Request for Comments",
  type="RFC",
  number="425",
  pages="1--1",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc425.txt",
  key="RFC 425",
  doi="10.17487/RFC0425",
  }

@misc{rfc426,
  author="R. Thomas",
  title="{Reconnection Protocol}",
  howpublished="RFC 426",
  series="Internet Request for Comments",
  type="RFC",
  number="426",
  pages="1--12",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc426.txt",
  key="RFC 426",
  doi="10.17487/RFC0426",
  }

@misc{rfc429,
  author="J. Postel",
  title="{Character Generator Process}",
  howpublished="RFC 429",
  series="Internet Request for Comments",
  type="RFC",
  number="429",
  pages="1--1",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc429.txt",
  key="RFC 429",
  doi="10.17487/RFC0429",
  }

@misc{rfc430,
  author="R.T. Braden",
  title="{Comments on File Transfer Protocol}",
  howpublished="RFC 430",
  series="Internet Request for Comments",
  type="RFC",
  number="430",
  pages="1--8",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc430.txt",
  key="RFC 430",
  doi="10.17487/RFC0430",
  }

@misc{rfc431,
  author="M. Krilanovich",
  title="{Update on SMFS Login and Logout}",
  howpublished="RFC 431",
  series="Internet Request for Comments",
  type="RFC",
  number="431",
  pages="1--3",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc431.txt",
  key="RFC 431",
  doi="10.17487/RFC0431",
  }

@misc{rfc432,
  author="N. Neigus",
  title="{Network logical map}",
  howpublished="RFC 432",
  series="Internet Request for Comments",
  type="RFC",
  number="432",
  pages="1--1",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc432.txt",
  key="RFC 432",
  doi="10.17487/RFC0432",
  }

@misc{rfc433,
  author="J. Postel",
  title="{Socket number list}",
  howpublished="RFC 433",
  series="Internet Request for Comments",
  type="RFC",
  number="433",
  pages="1--5",
  year=1972,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 503",
url="https://www.rfc-editor.org/rfc/rfc433.txt",
  key="RFC 433",
  doi="10.17487/RFC0433",
  }

@misc{rfc434,
  author="A.M. McKenzie",
  title="{IMP/TIP memory retrofit schedule}",
  howpublished="RFC 434",
  series="Internet Request for Comments",
  type="RFC",
  number="434",
  pages="1--2",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 447",
url="https://www.rfc-editor.org/rfc/rfc434.txt",
  key="RFC 434",
  doi="10.17487/RFC0434",
  }

@misc{rfc435,
  author="B. Cosell and D.C. Walden",
  title="{Telnet issues}",
  howpublished="RFC 435",
  series="Internet Request for Comments",
  type="RFC",
  number="435",
  pages="1--10",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc435.txt",
  key="RFC 435",
  doi="10.17487/RFC0435",
  }

@misc{rfc436,
  author="M. Krilanovich",
  title="{Announcement of RJS at UCSB}",
  howpublished="RFC 436",
  series="Internet Request for Comments",
  type="RFC",
  number="436",
  pages="1--1",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc436.txt",
  key="RFC 436",
  doi="10.17487/RFC0436",
  }

@misc{rfc437,
  author="E. Faeh",
  title="{Data Reconfiguration Service at UCSB}",
  howpublished="RFC 437",
  series="Internet Request for Comments",
  type="RFC",
  number="437",
  pages="1--10",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc437.txt",
  key="RFC 437",
  doi="10.17487/RFC0437",
  }

@misc{rfc438,
  author="R. Thomas and R. Clements",
  title="{FTP server-server interaction}",
  howpublished="RFC 438",
  series="Internet Request for Comments",
  type="RFC",
  number="438",
  pages="1--3",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc438.txt",
  key="RFC 438",
  doi="10.17487/RFC0438",
  }

@misc{rfc439,
  author="V. Cerf",
  title="{PARRY encounters the DOCTOR}",
  howpublished="RFC 439",
  series="Internet Request for Comments",
  type="RFC",
  number="439",
  pages="1--7",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc439.txt",
  key="RFC 439",
  doi="10.17487/RFC0439",
  }

@misc{rfc440,
  author="D.C. Walden",
  title="{Scheduled network software maintenance}",
  howpublished="RFC 440",
  series="Internet Request for Comments",
  type="RFC",
  number="440",
  pages="1--1",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc440.txt",
  key="RFC 440",
  doi="10.17487/RFC0440",
  }

@misc{rfc441,
  author="R.D. Bressler and R. Thomas",
  title="{Inter-Entity Communication - an experiment}",
  howpublished="RFC 441",
  series="Internet Request for Comments",
  type="RFC",
  number="441",
  pages="1--7",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc441.txt",
  key="RFC 441",
  doi="10.17487/RFC0441",
  }

@misc{rfc442,
  author="V. Cerf",
  title="{Current flow-control scheme for IMPSYS}",
  howpublished="RFC 442",
  series="Internet Request for Comments",
  type="RFC",
  number="442",
  pages="1--7",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 449",
url="https://www.rfc-editor.org/rfc/rfc442.txt",
  key="RFC 442",
  doi="10.17487/RFC0442",
  }

@misc{rfc443,
  author="A.M. McKenzie",
  title="{Traffic statistics (December 1972)}",
  howpublished="RFC 443",
  series="Internet Request for Comments",
  type="RFC",
  number="443",
  pages="1--3",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc443.txt",
  key="RFC 443",
  doi="10.17487/RFC0443",
  }

@misc{rfc445,
  author="A.M. McKenzie",
  title="{IMP/TIP preventive maintenance schedule}",
  howpublished="RFC 445",
  series="Internet Request for Comments",
  type="RFC",
  number="445",
  pages="1--2",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc445.txt",
  key="RFC 445",
  doi="10.17487/RFC0445",
  }

@misc{rfc446,
  author="L.P. Deutsch",
  title="{Proposal to consider a network program resource notebook}",
  howpublished="RFC 446",
  series="Internet Request for Comments",
  type="RFC",
  number="446",
  pages="1--2",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc446.txt",
  key="RFC 446",
  doi="10.17487/RFC0446",
  }

@misc{rfc447,
  author="A.M. McKenzie",
  title="{IMP/TIP memory retrofit schedule}",
  howpublished="RFC 447",
  series="Internet Request for Comments",
  type="RFC",
  number="447",
  pages="1--2",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 476",
url="https://www.rfc-editor.org/rfc/rfc447.txt",
  key="RFC 447",
  doi="10.17487/RFC0447",
  }

@misc{rfc448,
  author="R.T. Braden",
  title="{Print files in FTP}",
  howpublished="RFC 448",
  series="Internet Request for Comments",
  type="RFC",
  number="448",
  pages="1--3",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc448.txt",
  key="RFC 448",
  doi="10.17487/RFC0448",
  }

@misc{rfc449,
  author="D.C. Walden",
  title="{Current flow-control scheme for IMPSYS}",
  howpublished="RFC 449",
  series="Internet Request for Comments",
  type="RFC",
  number="449",
  pages="1--1",
  year=1973,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc449.txt",
  key="RFC 449",
  doi="10.17487/RFC0449",
  }

@misc{rfc450,
  author="M.A. Padlipsky",
  title="{MULTICS sampling timeout change}",
  howpublished="RFC 450",
  series="Internet Request for Comments",
  type="RFC",
  number="450",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc450.txt",
  key="RFC 450",
  doi="10.17487/RFC0450",
  }

@misc{rfc451,
  author="M.A. Padlipsky",
  title="{Tentative proposal for a Unified User Level Protocol}",
  howpublished="RFC 451",
  series="Internet Request for Comments",
  type="RFC",
  number="451",
  pages="1--3",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc451.txt",
  key="RFC 451",
  doi="10.17487/RFC0451",
  }

@misc{rfc452,
  author="J. Winett",
  title="{TELNET Command at Host LL}",
  howpublished="RFC 452",
  series="Internet Request for Comments",
  type="RFC",
  number="452",
  pages="1--14",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc452.txt",
  key="RFC 452",
  doi="10.17487/RFC0452",
  }

@misc{rfc453,
  author="M.D. Kudlick",
  title="{Meeting announcement to discuss a network mail system}",
  howpublished="RFC 453",
  series="Internet Request for Comments",
  type="RFC",
  number="453",
  pages="1--3",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc453.txt",
  key="RFC 453",
  doi="10.17487/RFC0453",
  }

@misc{rfc454,
  author="A.M. McKenzie",
  title="{File Transfer Protocol - meeting announcement and a new proposed document}",
  howpublished="RFC 454",
  series="Internet Request for Comments",
  type="RFC",
  number="454",
  pages="1--35",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc454.txt",
  key="RFC 454",
  keywords="FTP",
  doi="10.17487/RFC0454",
  }

@misc{rfc455,
  author="A.M. McKenzie",
  title="{Traffic statistics (January 1973)}",
  howpublished="RFC 455",
  series="Internet Request for Comments",
  type="RFC",
  number="455",
  pages="1--3",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc455.txt",
  key="RFC 455",
  doi="10.17487/RFC0455",
  }

@misc{rfc456,
  author="M.D. Kudlick",
  title="{Memorandum: Date change of mail meeting}",
  howpublished="RFC 456",
  series="Internet Request for Comments",
  type="RFC",
  number="456",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc456.txt",
  key="RFC 456",
  doi="10.17487/RFC0456",
  }

@misc{rfc457,
  author="D.C. Walden",
  title="{TIPUG}",
  howpublished="RFC 457",
  series="Internet Request for Comments",
  type="RFC",
  number="457",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc457.txt",
  key="RFC 457",
  doi="10.17487/RFC0457",
  }

@misc{rfc458,
  author="R.D. Bressler and R. Thomas",
  title="{Mail retrieval via FTP}",
  howpublished="RFC 458",
  series="Internet Request for Comments",
  type="RFC",
  number="458",
  pages="1--2",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc458.txt",
  key="RFC 458",
  doi="10.17487/RFC0458",
  }

@misc{rfc459,
  author="W. Kantrowitz",
  title="{Network questionnaires}",
  howpublished="RFC 459",
  series="Internet Request for Comments",
  type="RFC",
  number="459",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc459.txt",
  key="RFC 459",
  doi="10.17487/RFC0459",
  }

@misc{rfc460,
  author="C. Kline",
  title="{NCP survey}",
  howpublished="RFC 460",
  series="Internet Request for Comments",
  type="RFC",
  number="460",
  pages="1--7",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc460.txt",
  key="RFC 460",
  doi="10.17487/RFC0460",
  }

@misc{rfc461,
  author="A.M. McKenzie",
  title="{Telnet Protocol meeting announcement}",
  howpublished="RFC 461",
  series="Internet Request for Comments",
  type="RFC",
  number="461",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc461.txt",
  key="RFC 461",
  doi="10.17487/RFC0461",
  }

@misc{rfc462,
  author="J. Iseli and D. Crocker",
  title="{Responding to user needs}",
  howpublished="RFC 462",
  series="Internet Request for Comments",
  type="RFC",
  number="462",
  pages="1--2",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc462.txt",
  key="RFC 462",
  doi="10.17487/RFC0462",
  }

@misc{rfc463,
  author="A.K. Bhushan",
  title="{FTP comments and response to RFC 430}",
  howpublished="RFC 463",
  series="Internet Request for Comments",
  type="RFC",
  number="463",
  pages="1--3",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc463.txt",
  key="RFC 463",
  doi="10.17487/RFC0463",
  }

@misc{rfc464,
  author="M.D. Kudlick",
  title="{Resource notebook framework}",
  howpublished="RFC 464",
  series="Internet Request for Comments",
  type="RFC",
  number="464",
  pages="1--2",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc464.txt",
  key="RFC 464",
  doi="10.17487/RFC0464",
  }

@misc{rfc466,
  author="J.M. Winett",
  title="{Telnet logger/server for host LL-67}",
  howpublished="RFC 466",
  series="Internet Request for Comments",
  type="RFC",
  number="466",
  pages="1--9",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc466.txt",
  key="RFC 466",
  doi="10.17487/RFC0466",
  }

@misc{rfc467,
  author="J.D. Burchfiel and R.S. Tomlinson",
  title="{Proposed change to Host-Host Protocol: Resynchronization of connection status}",
  howpublished="RFC 467",
  series="Internet Request for Comments",
  type="RFC",
  number="467",
  pages="1--7",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 492",
url="https://www.rfc-editor.org/rfc/rfc467.txt",
  key="RFC 467",
  doi="10.17487/RFC0467",
  }

@misc{rfc468,
  author="R.T. Braden",
  title="{FTP data compression}",
  howpublished="RFC 468",
  series="Internet Request for Comments",
  type="RFC",
  number="468",
  pages="1--7",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc468.txt",
  key="RFC 468",
  doi="10.17487/RFC0468",
  }

@misc{rfc469,
  author="M.D. Kudlick",
  title="{Network mail meeting summary}",
  howpublished="RFC 469",
  series="Internet Request for Comments",
  type="RFC",
  number="469",
  pages="1--10",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc469.txt",
  key="RFC 469",
  keywords="network, mail, meeting",
  doi="10.17487/RFC0469",
  }

@misc{rfc470,
  author="R. Thomas",
  title="{Change in socket for TIP news facility}",
  howpublished="RFC 470",
  series="Internet Request for Comments",
  type="RFC",
  number="470",
  pages="1--1",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc470.txt",
  key="RFC 470",
  doi="10.17487/RFC0470",
  }

@misc{rfc471,
  author="R. Thomas",
  title="{Workshop on multi-site executive programs}",
  howpublished="RFC 471",
  series="Internet Request for Comments",
  type="RFC",
  number="471",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc471.txt",
  key="RFC 471",
  doi="10.17487/RFC0471",
  }

@misc{rfc472,
  author="S. Bunch",
  title="{Illinois' reply to Maxwell's request for graphics information (NIC 14925)}",
  howpublished="RFC 472",
  series="Internet Request for Comments",
  type="RFC",
  number="472",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc472.txt",
  key="RFC 472",
  doi="10.17487/RFC0472",
  }

@misc{rfc473,
  author="D.C. Walden",
  title="{MIX and MIXAL?}",
  howpublished="RFC 473",
  series="Internet Request for Comments",
  type="RFC",
  number="473",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc473.txt",
  key="RFC 473",
  doi="10.17487/RFC0473",
  }

@misc{rfc474,
  author="S. Bunch",
  title="{Announcement of NGWG meeting: Call for papers}",
  howpublished="RFC 474",
  series="Internet Request for Comments",
  type="RFC",
  number="474",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc474.txt",
  key="RFC 474",
  doi="10.17487/RFC0474",
  }

@misc{rfc475,
  author="A.K. Bhushan",
  title="{FTP and Network Mail System}",
  howpublished="RFC 475",
  series="Internet Request for Comments",
  type="RFC",
  number="475",
  pages="1--5",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc475.txt",
  key="RFC 475",
  doi="10.17487/RFC0475",
  }

@misc{rfc476,
  author="A.M. McKenzie",
  title="{IMP/TIP memory retrofit schedule (rev 2)}",
  howpublished="RFC 476",
  series="Internet Request for Comments",
  type="RFC",
  number="476",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc476.txt",
  key="RFC 476",
  doi="10.17487/RFC0476",
  }

@misc{rfc477,
  author="M. Krilanovich",
  title="{Remote Job Service at UCSB}",
  howpublished="RFC 477",
  series="Internet Request for Comments",
  type="RFC",
  number="477",
  pages="1--19",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc477.txt",
  key="RFC 477",
  doi="10.17487/RFC0477",
  }

@misc{rfc478,
  author="R.D. Bressler and R. Thomas",
  title="{FTP server-server interaction - II}",
  howpublished="RFC 478",
  series="Internet Request for Comments",
  type="RFC",
  number="478",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc478.txt",
  key="RFC 478",
  doi="10.17487/RFC0478",
  }

@misc{rfc479,
  author="J.E. White",
  title="{Use of FTP by the NIC Journal}",
  howpublished="RFC 479",
  series="Internet Request for Comments",
  type="RFC",
  number="479",
  pages="1--5",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc479.txt",
  key="RFC 479",
  doi="10.17487/RFC0479",
  }

@misc{rfc480,
  author="J.E. White",
  title="{Host-dependent FTP parameters}",
  howpublished="RFC 480",
  series="Internet Request for Comments",
  type="RFC",
  number="480",
  pages="1--1",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc480.txt",
  key="RFC 480",
  doi="10.17487/RFC0480",
  }

@misc{rfc482,
  author="A.M. McKenzie",
  title="{Traffic statistics (February 1973)}",
  howpublished="RFC 482",
  series="Internet Request for Comments",
  type="RFC",
  number="482",
  pages="1--4",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 497",
url="https://www.rfc-editor.org/rfc/rfc482.txt",
  key="RFC 482",
  doi="10.17487/RFC0482",
  }

@misc{rfc483,
  author="M.D. Kudlick",
  title="{Cancellation of the resource notebook framework meeting}",
  howpublished="RFC 483",
  series="Internet Request for Comments",
  type="RFC",
  number="483",
  pages="1--1",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc483.txt",
  key="RFC 483",
  doi="10.17487/RFC0483",
  }

@misc{rfc485,
  author="J.R. Pickens",
  title="{MIX and MIXAL at UCSB}",
  howpublished="RFC 485",
  series="Internet Request for Comments",
  type="RFC",
  number="485",
  pages="1--1",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc485.txt",
  key="RFC 485",
  doi="10.17487/RFC0485",
  }

@misc{rfc486,
  author="R.D. Bressler",
  title="{Data transfer revisited}",
  howpublished="RFC 486",
  series="Internet Request for Comments",
  type="RFC",
  number="486",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc486.txt",
  key="RFC 486",
  keywords="RJE, FTP",
  doi="10.17487/RFC0486",
  }

@misc{rfc487,
  author="R.D. Bressler",
  title="{Free file transfer}",
  howpublished="RFC 487",
  series="Internet Request for Comments",
  type="RFC",
  number="487",
  pages="1--2",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc487.txt",
  key="RFC 487",
  keywords="FTP",
  doi="10.17487/RFC0487",
  }

@misc{rfc488,
  author="M.F. Auerbach",
  title="{NLS classes at network sites}",
  howpublished="RFC 488",
  series="Internet Request for Comments",
  type="RFC",
  number="488",
  pages="1--2",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc488.txt",
  key="RFC 488",
  doi="10.17487/RFC0488",
  }

@misc{rfc489,
  author="J. Postel",
  title="{Comment on resynchronization of connection status proposal}",
  howpublished="RFC 489",
  series="Internet Request for Comments",
  type="RFC",
  number="489",
  pages="1--1",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc489.txt",
  key="RFC 489",
  doi="10.17487/RFC0489",
  }

@misc{rfc490,
  author="J.R. Pickens",
  title="{Surrogate RJS for UCLA-CCN}",
  howpublished="RFC 490",
  series="Internet Request for Comments",
  type="RFC",
  number="490",
  pages="1--6",
  year=1973,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc490.txt",
  key="RFC 490",
  doi="10.17487/RFC0490",
  }

@misc{rfc491,
  author="M.A. Padlipsky",
  title="{What is ``Free''?}",
  howpublished="RFC 491",
  series="Internet Request for Comments",
  type="RFC",
  number="491",
  pages="1--2",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc491.txt",
  key="RFC 491",
  doi="10.17487/RFC0491",
  }

@misc{rfc492,
  author="E. Meyer",
  title="{Response to RFC 467}",
  howpublished="RFC 492",
  series="Internet Request for Comments",
  type="RFC",
  number="492",
  pages="1--7",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc492.txt",
  key="RFC 492",
  doi="10.17487/RFC0492",
  }

@misc{rfc493,
  author="J.C. Michener and I.W. Cotton and K.C. Kelley and D.E. Liddle and E. Meyer",
  title="{GRAPHICS PROTOCOL}",
  howpublished="RFC 493",
  series="Internet Request for Comments",
  type="RFC",
  number="493",
  pages="1--28",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc493.txt",
  key="RFC 493",
  doi="10.17487/RFC0493",
  }

@misc{rfc494,
  author="D.C. Walden",
  title="{Availability of MIX and MIXAL in the Network}",
  howpublished="RFC 494",
  series="Internet Request for Comments",
  type="RFC",
  number="494",
  pages="1--1",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc494.txt",
  key="RFC 494",
  doi="10.17487/RFC0494",
  }

@misc{rfc495,
  author="A.M. McKenzie",
  title="{Telnet Protocol specifications}",
  howpublished="RFC 495",
  series="Internet Request for Comments",
  type="RFC",
  number="495",
  pages="1--2",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 562",
url="https://www.rfc-editor.org/rfc/rfc495.txt",
  key="RFC 495",
  doi="10.17487/RFC0495",
  }

@misc{rfc496,
  author="M.F. Auerbach",
  title="{TNLS quick reference card is available}",
  howpublished="RFC 496",
  series="Internet Request for Comments",
  type="RFC",
  number="496",
  pages="1--1",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc496.txt",
  key="RFC 496",
  doi="10.17487/RFC0496",
  }

@misc{rfc497,
  author="A.M. McKenzie",
  title="{Traffic Statistics (March 1973)}",
  howpublished="RFC 497",
  series="Internet Request for Comments",
  type="RFC",
  number="497",
  pages="1--4",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc497.txt",
  key="RFC 497",
  doi="10.17487/RFC0497",
  }

@misc{rfc498,
  author="R.T. Braden",
  title="{On mail service to CCN}",
  howpublished="RFC 498",
  series="Internet Request for Comments",
  type="RFC",
  number="498",
  pages="1--3",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc498.txt",
  key="RFC 498",
  doi="10.17487/RFC0498",
  }

@misc{rfc499,
  author="B.R. Reussow",
  title="{Harvard's network RJE}",
  howpublished="RFC 499",
  series="Internet Request for Comments",
  type="RFC",
  number="499",
  pages="1--6",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc499.txt",
  key="RFC 499",
  doi="10.17487/RFC0499",
  }

@misc{rfc500,
  author="A. Shoshani and I. Spiegler",
  title="{Integration of data management systems on a computer network}",
  howpublished="RFC 500",
  series="Internet Request for Comments",
  type="RFC",
  number="500",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc500.txt",
  key="RFC 500",
  doi="10.17487/RFC0500",
  }

@misc{rfc501,
  author="K.T. Pogran",
  title="{Un-muddling ``free file transfer''}",
  howpublished="RFC 501",
  series="Internet Request for Comments",
  type="RFC",
  number="501",
  pages="1--5",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc501.txt",
  key="RFC 501",
  keywords="FTP",
  doi="10.17487/RFC0501",
  }

@misc{rfc503,
  author="N. Neigus and J. Postel",
  title="{Socket number list}",
  howpublished="RFC 503",
  series="Internet Request for Comments",
  type="RFC",
  number="503",
  pages="1--8",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 739",
url="https://www.rfc-editor.org/rfc/rfc503.txt",
  key="RFC 503",
  doi="10.17487/RFC0503",
  }

@misc{rfc504,
  author="R. Thomas",
  title="{Distributed resources workshop announcement}",
  howpublished="RFC 504",
  series="Internet Request for Comments",
  type="RFC",
  number="504",
  pages="1--5",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc504.txt",
  key="RFC 504",
  doi="10.17487/RFC0504",
  }

@misc{rfc505,
  author="M.A. Padlipsky",
  title="{Two solutions to a file transfer access problem}",
  howpublished="RFC 505",
  series="Internet Request for Comments",
  type="RFC",
  number="505",
  pages="1--3",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc505.txt",
  key="RFC 505",
  keywords="FTP, free",
  doi="10.17487/RFC0505",
  }

@misc{rfc506,
  author="M.A. Padlipsky",
  title="{FTP command naming problem}",
  howpublished="RFC 506",
  series="Internet Request for Comments",
  type="RFC",
  number="506",
  pages="1--1",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc506.txt",
  key="RFC 506",
  doi="10.17487/RFC0506",
  }

@misc{rfc508,
  author="L. Pfeifer and J. McAfee",
  title="{Real-time data transmission on the ARPANET}",
  howpublished="RFC 508",
  series="Internet Request for Comments",
  type="RFC",
  number="508",
  pages="1--10",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc508.txt",
  key="RFC 508",
  doi="10.17487/RFC0508",
  }

@misc{rfc509,
  author="A.M. McKenzie",
  title="{Traffic statistics (April 1973)}",
  howpublished="RFC 509",
  series="Internet Request for Comments",
  type="RFC",
  number="509",
  pages="1--4",
  year=1973,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc509.txt",
  key="RFC 509",
  doi="10.17487/RFC0509",
  }

@misc{rfc510,
  author="J.E. White",
  title="{Request for network mailbox addresses}",
  howpublished="RFC 510",
  series="Internet Request for Comments",
  type="RFC",
  number="510",
  pages="1--2",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc510.txt",
  key="RFC 510",
  doi="10.17487/RFC0510",
  }

@misc{rfc511,
  author="J.B. North",
  title="{Enterprise phone service to NIC from ARPANET sites}",
  howpublished="RFC 511",
  series="Internet Request for Comments",
  type="RFC",
  number="511",
  pages="1--4",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc511.txt",
  key="RFC 511",
  doi="10.17487/RFC0511",
  }

@misc{rfc512,
  author="W. Hathaway",
  title="{More on lost message detection}",
  howpublished="RFC 512",
  series="Internet Request for Comments",
  type="RFC",
  number="512",
  pages="1--2",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc512.txt",
  key="RFC 512",
  doi="10.17487/RFC0512",
  }

@misc{rfc513,
  author="W. Hathaway",
  title="{Comments on the new Telnet specifications}",
  howpublished="RFC 513",
  series="Internet Request for Comments",
  type="RFC",
  number="513",
  pages="1--3",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc513.txt",
  key="RFC 513",
  doi="10.17487/RFC0513",
  }

@misc{rfc514,
  author="W. Kantrowitz",
  title="{Network make-work}",
  howpublished="RFC 514",
  series="Internet Request for Comments",
  type="RFC",
  number="514",
  pages="1--4",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc514.txt",
  key="RFC 514",
  doi="10.17487/RFC0514",
  }

@misc{rfc515,
  author="R. Winter",
  title="{Specifications for Datalanguage, Version 0/9}",
  howpublished="RFC 515",
  series="Internet Request for Comments",
  type="RFC",
  number="515",
  pages="1--31",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc515.txt",
  key="RFC 515",
  doi="10.17487/RFC0515",
  }

@misc{rfc516,
  author="J. Postel",
  title="{Lost message detection}",
  howpublished="RFC 516",
  series="Internet Request for Comments",
  type="RFC",
  number="516",
  pages="1--2",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc516.txt",
  key="RFC 516",
  doi="10.17487/RFC0516",
  }

@misc{rfc518,
  author="N. Vaughan and E.J. Feinler",
  title="{ARPANET accounts}",
  howpublished="RFC 518",
  series="Internet Request for Comments",
  type="RFC",
  number="518",
  pages="1--9",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc518.txt",
  key="RFC 518",
  doi="10.17487/RFC0518",
  }

@misc{rfc519,
  author="J.R. Pickens",
  title="{Resource Evaluation}",
  howpublished="RFC 519",
  series="Internet Request for Comments",
  type="RFC",
  number="519",
  pages="1--4",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc519.txt",
  key="RFC 519",
  doi="10.17487/RFC0519",
  }

@misc{rfc520,
  author="J.D. Day",
  title="{Memo to FTP group: Proposal for File Access Protocol}",
  howpublished="RFC 520",
  series="Internet Request for Comments",
  type="RFC",
  number="520",
  pages="1--8",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc520.txt",
  key="RFC 520",
  doi="10.17487/RFC0520",
  }

@misc{rfc521,
  author="A.M. McKenzie",
  title="{Restricted use of IMP DDT}",
  howpublished="RFC 521",
  series="Internet Request for Comments",
  type="RFC",
  number="521",
  pages="1--2",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc521.txt",
  key="RFC 521",
  doi="10.17487/RFC0521",
  }

@misc{rfc522,
  author="A.M. McKenzie",
  title="{Traffic Statistics (May 1973)}",
  howpublished="RFC 522",
  series="Internet Request for Comments",
  type="RFC",
  number="522",
  pages="1--4",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc522.txt",
  key="RFC 522",
  doi="10.17487/RFC0522",
  }

@misc{rfc523,
  author="A.K. Bhushan",
  title="{SURVEY is in operation again}",
  howpublished="RFC 523",
  series="Internet Request for Comments",
  type="RFC",
  number="523",
  pages="1--2",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc523.txt",
  key="RFC 523",
  doi="10.17487/RFC0523",
  }

@misc{rfc524,
  author="J.E. White",
  title="{Proposed Mail Protocol}",
  howpublished="RFC 524",
  series="Internet Request for Comments",
  type="RFC",
  number="524",
  pages="1--40",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc524.txt",
  key="RFC 524",
  doi="10.17487/RFC0524",
  }

@misc{rfc525,
  author="W. Parrish and J.R. Pickens",
  title="{MIT-MATHLAB meets UCSB-OLS -an example of resource sharing}",
  howpublished="RFC 525",
  series="Internet Request for Comments",
  type="RFC",
  number="525",
  pages="1--9",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc525.txt",
  key="RFC 525",
  doi="10.17487/RFC0525",
  }

@misc{rfc526,
  author="W.K. Pratt",
  title="{Technical meeting: Digital image processing software systems}",
  howpublished="RFC 526",
  series="Internet Request for Comments",
  type="RFC",
  number="526",
  pages="1--3",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc526.txt",
  key="RFC 526",
  doi="10.17487/RFC0526",
  }

@misc{rfc527,
  author="R. Merryman",
  title="{ARPAWOCKY}",
  howpublished="RFC 527",
  series="Internet Request for Comments",
  type="RFC",
  number="527",
  pages="1--1",
  year=1973,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc527.txt",
  key="RFC 527",
  doi="10.17487/RFC0527",
  }

@misc{rfc528,
  author="J.M. McQuillan",
  title="{Software checksumming in the IMP and network reliability}",
  howpublished="RFC 528",
  series="Internet Request for Comments",
  type="RFC",
  number="528",
  pages="1--9",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc528.txt",
  key="RFC 528",
  doi="10.17487/RFC0528",
  }

@misc{rfc529,
  author="A.M. McKenzie and R. Thomas and R.S. Tomlinson and K.T. Pogran",
  title="{Note on protocol synch sequences}",
  howpublished="RFC 529",
  series="Internet Request for Comments",
  type="RFC",
  number="529",
  pages="1--4",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc529.txt",
  key="RFC 529",
  doi="10.17487/RFC0529",
  }

@misc{rfc530,
  author="A.K. Bhushan",
  title="{Report on the Survey Project}",
  howpublished="RFC 530",
  series="Internet Request for Comments",
  type="RFC",
  number="530",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc530.txt",
  key="RFC 530",
  doi="10.17487/RFC0530",
  }

@misc{rfc531,
  author="M.A. Padlipsky",
  title="{Feast or famine? A response to two recent RFC's about network information}",
  howpublished="RFC 531",
  series="Internet Request for Comments",
  type="RFC",
  number="531",
  pages="1--2",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc531.txt",
  key="RFC 531",
  doi="10.17487/RFC0531",
  }

@misc{rfc532,
  author="R.G. Merryman",
  title="{UCSD-CC Server-FTP facility}",
  howpublished="RFC 532",
  series="Internet Request for Comments",
  type="RFC",
  number="532",
  pages="1--4",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc532.txt",
  key="RFC 532",
  keywords="FTP, server",
  doi="10.17487/RFC0532",
  }

@misc{rfc533,
  author="D.C. Walden",
  title="{Message-ID numbers}",
  howpublished="RFC 533",
  series="Internet Request for Comments",
  type="RFC",
  number="533",
  pages="1--1",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc533.txt",
  key="RFC 533",
  doi="10.17487/RFC0533",
  }

@misc{rfc534,
  author="D.C. Walden",
  title="{Lost message detection}",
  howpublished="RFC 534",
  series="Internet Request for Comments",
  type="RFC",
  number="534",
  pages="1--2",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc534.txt",
  key="RFC 534",
  doi="10.17487/RFC0534",
  }

@misc{rfc535,
  author="R. Thomas",
  title="{Comments on File Access Protocol}",
  howpublished="RFC 535",
  series="Internet Request for Comments",
  type="RFC",
  number="535",
  pages="1--4",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc535.txt",
  key="RFC 535",
  doi="10.17487/RFC0535",
  }

@misc{rfc537,
  author="S. Bunch",
  title="{Announcement of NGG meeting July 16-17}",
  howpublished="RFC 537",
  series="Internet Request for Comments",
  type="RFC",
  number="537",
  pages="1--2",
  year=1973,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc537.txt",
  key="RFC 537",
  doi="10.17487/RFC0537",
  }

@misc{rfc538,
  author="A.M. McKenzie",
  title="{Traffic statistics (June 1973)}",
  howpublished="RFC 538",
  series="Internet Request for Comments",
  type="RFC",
  number="538",
  pages="1--4",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 556",
url="https://www.rfc-editor.org/rfc/rfc538.txt",
  key="RFC 538",
  doi="10.17487/RFC0538",
  }

@misc{rfc539,
  author="D. Crocker and J. Postel",
  title="{Thoughts on the mail protocol proposed in RFC 524}",
  howpublished="RFC 539",
  series="Internet Request for Comments",
  type="RFC",
  number="539",
  pages="1--3",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc539.txt",
  key="RFC 539",
  doi="10.17487/RFC0539",
  }

@misc{rfc542,
  author="N. Neigus",
  title="{File Transfer Protocol}",
  howpublished="RFC 542",
  series="Internet Request for Comments",
  type="RFC",
  number="542",
  pages="1--40",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 765, updated by RFCs 614, 640",
url="https://www.rfc-editor.org/rfc/rfc542.txt",
  key="RFC 542",
  keywords="FTP",
  doi="10.17487/RFC0542",
  }

@misc{rfc543,
  author="N.D. Meyer",
  title="{Network journal submission and delivery}",
  howpublished="RFC 543",
  series="Internet Request for Comments",
  type="RFC",
  number="543",
  pages="1--8",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc543.txt",
  key="RFC 543",
  doi="10.17487/RFC0543",
  }

@misc{rfc544,
  author="N.D. Meyer and K. Kelley",
  title="{Locating on-line documentation at SRI-ARC}",
  howpublished="RFC 544",
  series="Internet Request for Comments",
  type="RFC",
  number="544",
  pages="1--1",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc544.txt",
  key="RFC 544",
  doi="10.17487/RFC0544",
  }

@misc{rfc545,
  author="J.R. Pickens",
  title="{Of what quality be the UCSB resources evaluators?}",
  howpublished="RFC 545",
  series="Internet Request for Comments",
  type="RFC",
  number="545",
  pages="1--2",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc545.txt",
  key="RFC 545",
  doi="10.17487/RFC0545",
  }

@misc{rfc546,
  author="R. Thomas",
  title="{Tenex load averages for July 1973}",
  howpublished="RFC 546",
  series="Internet Request for Comments",
  type="RFC",
  number="546",
  pages="1--4",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc546.txt",
  key="RFC 546",
  doi="10.17487/RFC0546",
  }

@misc{rfc547,
  author="D.C. Walden",
  title="{Change to the Very Distant Host specification}",
  howpublished="RFC 547",
  series="Internet Request for Comments",
  type="RFC",
  number="547",
  pages="1--3",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc547.txt",
  key="RFC 547",
  doi="10.17487/RFC0547",
  }

@misc{rfc548,
  author="D.C. Walden",
  title="{Hosts using the IMP Going Down message}",
  howpublished="RFC 548",
  series="Internet Request for Comments",
  type="RFC",
  number="548",
  pages="1--1",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc548.txt",
  key="RFC 548",
  doi="10.17487/RFC0548",
  }

@misc{rfc549,
  author="J.C. Michener",
  title="{Minutes of Network Graphics Group meeting, 15-17 July 1973}",
  howpublished="RFC 549",
  series="Internet Request for Comments",
  type="RFC",
  number="549",
  pages="1--12",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc549.txt",
  key="RFC 549",
  doi="10.17487/RFC0549",
  }

@misc{rfc550,
  author="L.P. Deutsch",
  title="{NIC NCP experiment}",
  howpublished="RFC 550",
  series="Internet Request for Comments",
  type="RFC",
  number="550",
  pages="1--2",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc550.txt",
  key="RFC 550",
  doi="10.17487/RFC0550",
  }

@misc{rfc551,
  author="Y. Feinroth and R. Fink",
  title="{NYU, ANL, and LBL Joining the Net}",
  howpublished="RFC 551",
  series="Internet Request for Comments",
  type="RFC",
  number="551",
  pages="1--2",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc551.txt",
  key="RFC 551",
  doi="10.17487/RFC0551",
  }

@misc{rfc552,
  author="A.D. Owen",
  title="{Single access to standard protocols}",
  howpublished="RFC 552",
  series="Internet Request for Comments",
  type="RFC",
  number="552",
  pages="1--1",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc552.txt",
  key="RFC 552",
  doi="10.17487/RFC0552",
  }

@misc{rfc553,
  author="C.H. Irby and K. Victor",
  title="{Draft design for a text/graphics protocol}",
  howpublished="RFC 553",
  series="Internet Request for Comments",
  type="RFC",
  number="553",
  pages="1--19",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc553.txt",
  key="RFC 553",
  doi="10.17487/RFC0553",
  }

@misc{rfc555,
  author="J.E. White",
  title="{Responses to critiques of the proposed mail protocol}",
  howpublished="RFC 555",
  series="Internet Request for Comments",
  type="RFC",
  number="555",
  pages="1--11",
  year=1973,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc555.txt",
  key="RFC 555",
  doi="10.17487/RFC0555",
  }

@misc{rfc556,
  author="A.M. McKenzie",
  title="{Traffic Statistics (July 1973)}",
  howpublished="RFC 556",
  series="Internet Request for Comments",
  type="RFC",
  number="556",
  pages="1--4",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc556.txt",
  key="RFC 556",
  doi="10.17487/RFC0556",
  }

@misc{rfc557,
  author="B.D. Wessler",
  title="{REVELATIONS IN NETWORK HOST MEASUREMENTS}",
  howpublished="RFC 557",
  series="Internet Request for Comments",
  type="RFC",
  number="557",
  pages="1--2",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc557.txt",
  key="RFC 557",
  doi="10.17487/RFC0557",
  }

@misc{rfc559,
  author="A.K. Bushan",
  title="{Comments on The New Telnet Protocol and its Implementation}",
  howpublished="RFC 559",
  series="Internet Request for Comments",
  type="RFC",
  number="559",
  pages="1--5",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc559.txt",
  key="RFC 559",
  doi="10.17487/RFC0559",
  }

@misc{rfc560,
  author="D. Crocker and J. Postel",
  title="{Remote Controlled Transmission and Echoing Telnet option}",
  howpublished="RFC 560",
  series="Internet Request for Comments",
  type="RFC",
  number="560",
  pages="1--12",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 581",
url="https://www.rfc-editor.org/rfc/rfc560.txt",
  key="RFC 560",
  doi="10.17487/RFC0560",
  }

@misc{rfc561,
  author="A.K. Bhushan and K.T. Pogran and R.S. Tomlinson and J.E. White",
  title="{Standardizing Network Mail Headers}",
  howpublished="RFC 561",
  series="Internet Request for Comments",
  type="RFC",
  number="561",
  pages="1--3",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 680",
url="https://www.rfc-editor.org/rfc/rfc561.txt",
  key="RFC 561",
  doi="10.17487/RFC0561",
  }

@misc{rfc562,
  author="A.M. McKenzie",
  title="{Modifications to the TELNET Specification}",
  howpublished="RFC 562",
  series="Internet Request for Comments",
  type="RFC",
  number="562",
  pages="1--2",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc562.txt",
  key="RFC 562",
  doi="10.17487/RFC0562",
  }

@misc{rfc563,
  author="J. Davidson",
  title="{Comments on the RCTE Telnet option}",
  howpublished="RFC 563",
  series="Internet Request for Comments",
  type="RFC",
  number="563",
  pages="1--5",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc563.txt",
  key="RFC 563",
  doi="10.17487/RFC0563",
  }

@misc{rfc565,
  author="D. Cantor",
  title="{Storing network survey data at the datacomputer}",
  howpublished="RFC 565",
  series="Internet Request for Comments",
  type="RFC",
  number="565",
  pages="1--5",
  year=1973,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc565.txt",
  key="RFC 565",
  doi="10.17487/RFC0565",
  }

@misc{rfc566,
  author="A.M. McKenzie",
  title="{Traffic statistics (August 1973)}",
  howpublished="RFC 566",
  series="Internet Request for Comments",
  type="RFC",
  number="566",
  pages="1--4",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 579",
url="https://www.rfc-editor.org/rfc/rfc566.txt",
  key="RFC 566",
  doi="10.17487/RFC0566",
  }

@misc{rfc567,
  author="L.P. Deutsch",
  title="{Cross Country Network Bandwidth}",
  howpublished="RFC 567",
  series="Internet Request for Comments",
  type="RFC",
  number="567",
  pages="1--1",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 568",
url="https://www.rfc-editor.org/rfc/rfc567.txt",
  key="RFC 567",
  doi="10.17487/RFC0567",
  }

@misc{rfc568,
  author="J.M. McQuillan",
  title="{Response to RFC 567 - cross country network bandwidth}",
  howpublished="RFC 568",
  series="Internet Request for Comments",
  type="RFC",
  number="568",
  pages="1--3",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc568.txt",
  key="RFC 568",
  doi="10.17487/RFC0568",
  }

@misc{rfc569,
  author="M.A. Padlipsky",
  title="{NETED: A Common Editor for the ARPA Network}",
  howpublished="RFC 569 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="569",
  pages="1--6",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc569.txt",
  key="RFC 569",
  keywords="NETED",
  doi="10.17487/RFC0569",
  }

@misc{rfc570,
  author="J.R. Pickens",
  title="{Experimental input mapping between NVT ASCII and UCSB On Line System}",
  howpublished="RFC 570",
  series="Internet Request for Comments",
  type="RFC",
  number="570",
  pages="1--1",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc570.txt",
  key="RFC 570",
  doi="10.17487/RFC0570",
  }

@misc{rfc571,
  author="R. Braden",
  title="{TENEX FTP PROBLEM}",
  howpublished="RFC 571",
  series="Internet Request for Comments",
  type="RFC",
  number="571",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc571.txt",
  key="RFC 571",
  doi="10.17487/RFC0571",
  }

@misc{rfc573,
  author="A. Bhushan",
  title="{DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS}",
  howpublished="RFC 573",
  series="Internet Request for Comments",
  type="RFC",
  number="573",
  pages="1--8",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc573.txt",
  key="RFC 573",
  doi="10.17487/RFC0573",
  }

@misc{rfc574,
  author="M. Krilanovich",
  title="{Announcement of a Mail Facility at UCSB}",
  howpublished="RFC 574",
  series="Internet Request for Comments",
  type="RFC",
  number="574",
  pages="1--1",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc574.txt",
  key="RFC 574",
  doi="10.17487/RFC0574",
  }

@misc{rfc576,
  author="K. Victor",
  title="{Proposal for modifying linking}",
  howpublished="RFC 576",
  series="Internet Request for Comments",
  type="RFC",
  number="576",
  pages="1--2",
  year=1973,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc576.txt",
  key="RFC 576",
  doi="10.17487/RFC0576",
  }

@misc{rfc577,
  author="D. Crocker",
  title="{Mail priority}",
  howpublished="RFC 577",
  series="Internet Request for Comments",
  type="RFC",
  number="577",
  pages="1--2",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc577.txt",
  key="RFC 577",
  doi="10.17487/RFC0577",
  }

@misc{rfc578,
  author="A.K. Bhushan and N.D. Ryan",
  title="{Using MIT-Mathlab MACSYMA from MIT-DMS Muddle}",
  howpublished="RFC 578",
  series="Internet Request for Comments",
  type="RFC",
  number="578",
  pages="1--9",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc578.txt",
  key="RFC 578",
  doi="10.17487/RFC0578",
  }

@misc{rfc579,
  author="A.M. McKenzie",
  title="{Traffic statistics (September 1973)}",
  howpublished="RFC 579",
  series="Internet Request for Comments",
  type="RFC",
  number="579",
  pages="1--5",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 586",
url="https://www.rfc-editor.org/rfc/rfc579.txt",
  key="RFC 579",
  doi="10.17487/RFC0579",
  }

@misc{rfc580,
  author="J. Postel",
  title="{Note to Protocol Designers and Implementers}",
  howpublished="RFC 580",
  series="Internet Request for Comments",
  type="RFC",
  number="580",
  pages="1--1",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 582",
url="https://www.rfc-editor.org/rfc/rfc580.txt",
  key="RFC 580",
  doi="10.17487/RFC0580",
  }

@misc{rfc581,
  author="D. Crocker and J. Postel",
  title="{Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option}",
  howpublished="RFC 581",
  series="Internet Request for Comments",
  type="RFC",
  number="581",
  pages="1--5",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc581.txt",
  key="RFC 581",
  doi="10.17487/RFC0581",
  }

@misc{rfc582,
  author="R. Clements",
  title="{Comments on RFC 580: Machine readable protocols}",
  howpublished="RFC 582",
  series="Internet Request for Comments",
  type="RFC",
  number="582",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc582.txt",
  key="RFC 582",
  doi="10.17487/RFC0582",
  }

@misc{rfc584,
  author="J. Iseli and D. Crocker and N. Neigus",
  title="{Charter for ARPANET Users Interest Working Group}",
  howpublished="RFC 584",
  series="Internet Request for Comments",
  type="RFC",
  number="584",
  pages="1--3",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc584.txt",
  key="RFC 584",
  doi="10.17487/RFC0584",
  }

@misc{rfc585,
  author="D. Crocker and N. Neigus and E.J. Feinler and J. Iseli",
  title="{ARPANET users interest working group meeting}",
  howpublished="RFC 585",
  series="Internet Request for Comments",
  type="RFC",
  number="585",
  pages="1--9",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc585.txt",
  key="RFC 585",
  doi="10.17487/RFC0585",
  }

@misc{rfc586,
  author="A.M. McKenzie",
  title="{Traffic statistics (October 1973)}",
  howpublished="RFC 586",
  series="Internet Request for Comments",
  type="RFC",
  number="586",
  pages="1--5",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc586.txt",
  key="RFC 586",
  doi="10.17487/RFC0586",
  }

@misc{rfc587,
  author="J. Postel",
  title="{Announcing New Telnet Options}",
  howpublished="RFC 587",
  series="Internet Request for Comments",
  type="RFC",
  number="587",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc587.txt",
  key="RFC 587",
  doi="10.17487/RFC0587",
  }

@misc{rfc588,
  author="A. Stokes",
  title="{London Node Is Now Up}",
  howpublished="RFC 588",
  series="Internet Request for Comments",
  type="RFC",
  number="588",
  pages="1--3",
  year=1973,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc588.txt",
  key="RFC 588",
  doi="10.17487/RFC0588",
  }

@misc{rfc589,
  author="R.T. Braden",
  title="{CCN NETRJS server messages to remote user}",
  howpublished="RFC 589",
  series="Internet Request for Comments",
  type="RFC",
  number="589",
  pages="1--5",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc589.txt",
  key="RFC 589",
  doi="10.17487/RFC0589",
  }

@misc{rfc590,
  author="M.A. Padlipsky",
  title="{MULTICS address change}",
  howpublished="RFC 590",
  series="Internet Request for Comments",
  type="RFC",
  number="590",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc590.txt",
  key="RFC 590",
  doi="10.17487/RFC0590",
  }

@misc{rfc591,
  author="D.C. Walden",
  title="{Addition to the Very Distant Host specifications}",
  howpublished="RFC 591",
  series="Internet Request for Comments",
  type="RFC",
  number="591",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc591.txt",
  key="RFC 591",
  doi="10.17487/RFC0591",
  }

@misc{rfc592,
  author="R.W. Watson",
  title="{Some thoughts on system design to facilitate resource sharing}",
  howpublished="RFC 592",
  series="Internet Request for Comments",
  type="RFC",
  number="592",
  pages="1--5",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc592.txt",
  key="RFC 592",
  doi="10.17487/RFC0592",
  }

@misc{rfc593,
  author="A.M. McKenzie and J. Postel",
  title="{Telnet and FTP implementation schedule change}",
  howpublished="RFC 593",
  series="Internet Request for Comments",
  type="RFC",
  number="593",
  pages="1--1",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc593.txt",
  key="RFC 593",
  doi="10.17487/RFC0593",
  }

@misc{rfc594,
  author="J.D. Burchfiel",
  title="{Speedup of Host-IMP interface}",
  howpublished="RFC 594",
  series="Internet Request for Comments",
  type="RFC",
  number="594",
  pages="1--3",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc594.txt",
  key="RFC 594",
  doi="10.17487/RFC0594",
  }

@misc{rfc595,
  author="W. Hathaway",
  title="{Second thoughts in defense of the Telnet Go-Ahead}",
  howpublished="RFC 595",
  series="Internet Request for Comments",
  type="RFC",
  number="595",
  pages="1--5",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc595.txt",
  key="RFC 595",
  doi="10.17487/RFC0595",
  }

@misc{rfc596,
  author="E.A. Taft",
  title="{Second thoughts on Telnet Go-Ahead}",
  howpublished="RFC 596",
  series="Internet Request for Comments",
  type="RFC",
  number="596",
  pages="1--5",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc596.txt",
  key="RFC 596",
  doi="10.17487/RFC0596",
  }

@misc{rfc597,
  author="N. Neigus and E.J. Feinler",
  title="{Host status}",
  howpublished="RFC 597",
  series="Internet Request for Comments",
  type="RFC",
  number="597",
  pages="1--6",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 603",
url="https://www.rfc-editor.org/rfc/rfc597.txt",
  key="RFC 597",
  doi="10.17487/RFC0597",
  }

@misc{rfc598,
  author="Network Information Center. Stanford Research Institute",
  title="{RFC index - December 5, 1973}",
  howpublished="RFC 598",
  series="Internet Request for Comments",
  type="RFC",
  number="598",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc598.txt",
  key="RFC 598",
  doi="10.17487/RFC0598",
  }

@misc{rfc599,
  author="R.T. Braden",
  title="{Update on NETRJS}",
  howpublished="RFC 599",
  series="Internet Request for Comments",
  type="RFC",
  number="599",
  pages="1--9",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 740",
url="https://www.rfc-editor.org/rfc/rfc599.txt",
  key="RFC 599",
  doi="10.17487/RFC0599",
  }

@misc{rfc600,
  author="A. Berggreen",
  title="{Interfacing an Illinois plasma terminal to the ARPANET}",
  howpublished="RFC 600",
  series="Internet Request for Comments",
  type="RFC",
  number="600",
  pages="1--3",
  year=1973,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc600.txt",
  key="RFC 600",
  abstract={Discusses some unusual interface issues for the Plato terminal.},
  doi="10.17487/RFC0600",
  }

@misc{rfc601,
  author="A.M. McKenzie",
  title="{Traffic statistics (November 1973)}",
  howpublished="RFC 601",
  series="Internet Request for Comments",
  type="RFC",
  number="601",
  pages="1--5",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc601.txt",
  key="RFC 601",
  doi="10.17487/RFC0601",
  }

@misc{rfc602,
  author="R.M. Metcalfe",
  title="{``The stockings were hung by the chimney with care''}",
  howpublished="RFC 602",
  series="Internet Request for Comments",
  type="RFC",
  number="602",
  pages="1--1",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc602.txt",
  key="RFC 602",
  abstract={Susceptibility of ARPANET to security violations.},
  keywords="security, violations, TIP, arpanet",
  doi="10.17487/RFC0602",
  }

@misc{rfc603,
  author="J.D. Burchfiel",
  title="{Response to RFC 597: Host status}",
  howpublished="RFC 603",
  series="Internet Request for Comments",
  type="RFC",
  number="603",
  pages="1--1",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 613",
url="https://www.rfc-editor.org/rfc/rfc603.txt",
  key="RFC 603",
  abstract={Questions about the ARPANET topology described in RFC 597.},
  doi="10.17487/RFC0603",
  }

@misc{rfc604,
  author="J. Postel",
  title="{Assigned link numbers}",
  howpublished="RFC 604",
  series="Internet Request for Comments",
  type="RFC",
  number="604",
  pages="1--2",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 739",
url="https://www.rfc-editor.org/rfc/rfc604.txt",
  key="RFC 604",
  abstract={Modifies official host-host protocol.  Replaces RFC 377.},
  doi="10.17487/RFC0604",
  }

@misc{rfc606,
  author="L.P. Deutsch",
  title="{Host names on-line}",
  howpublished="RFC 606",
  series="Internet Request for Comments",
  type="RFC",
  number="606",
  pages="1--3",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc606.txt",
  key="RFC 606",
  abstract={Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.},
  keywords="lists, names, host, addresses",
  doi="10.17487/RFC0606",
  }

@misc{rfc607,
  author="M. Krilanovich and G. Gregg",
  title="{Comments on the File Transfer Protocol}",
  howpublished="RFC 607",
  series="Internet Request for Comments",
  type="RFC",
  number="607",
  pages="1--3",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 624, updated by RFC 614",
url="https://www.rfc-editor.org/rfc/rfc607.txt",
  key="RFC 607",
  abstract={An old version; see RFC 624; see also RFCs 614, 542 and 640.},
  keywords="solutions, weakness, ftp",
  doi="10.17487/RFC0607",
  }

@misc{rfc608,
  author="M.D. Kudlick",
  title="{Host names on-line}",
  howpublished="RFC 608",
  series="Internet Request for Comments",
  type="RFC",
  number="608",
  pages="1--4",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 810",
url="https://www.rfc-editor.org/rfc/rfc608.txt",
  key="RFC 608",
  abstract={Response to RFC 606; see also RFCs 627, 625 and 623.},
  doi="10.17487/RFC0608",
  }

@misc{rfc609,
  author="B. Ferguson",
  title="{Statement of upcoming move of NIC/NLS service}",
  howpublished="RFC 609",
  series="Internet Request for Comments",
  type="RFC",
  number="609",
  pages="1--2",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc609.txt",
  key="RFC 609",
  abstract={See also RFCs 621 and 620.},
  doi="10.17487/RFC0609",
  }

@misc{rfc610,
  author="R. Winter and J. Hill and W. Greiff",
  title="{Further datalanguage design concepts}",
  howpublished="RFC 610",
  series="Internet Request for Comments",
  type="RFC",
  number="610",
  pages="1--88",
  year=1973,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc610.txt",
  key="RFC 610",
  abstract={Preliminary results of the language design; a model for data languagea semantics; future considerations.},
  doi="10.17487/RFC0610",
  }

@misc{rfc611,
  author="D.C. Walden",
  title="{Two changes to the IMP/Host Protocol to improve user/network communications}",
  howpublished="RFC 611",
  series="Internet Request for Comments",
  type="RFC",
  number="611",
  pages="1--4",
  year=1974,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc611.txt",
  key="RFC 611",
  abstract={Expansion of Host-Going-Down and addition of Dead-Host-Status Message.},
  doi="10.17487/RFC0611",
  }

@misc{rfc612,
  author="A.M. McKenzie",
  title="{Traffic statistics (December 1973)}",
  howpublished="RFC 612",
  series="Internet Request for Comments",
  type="RFC",
  number="612",
  pages="1--6",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc612.txt",
  key="RFC 612",
  doi="10.17487/RFC0612",
  }

@misc{rfc613,
  author="A.M. McKenzie",
  title="{Network connectivity: A response to RFC 603}",
  howpublished="RFC 613",
  series="Internet Request for Comments",
  type="RFC",
  number="613",
  pages="1--1",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc613.txt",
  key="RFC 613",
  doi="10.17487/RFC0613",
  }

@misc{rfc614,
  author="K.T. Pogran and N. Neigus",
  title="{Response to RFC 607: ``Comments on the File Transfer Protocol''}",
  howpublished="RFC 614",
  series="Internet Request for Comments",
  type="RFC",
  number="614",
  pages="1--3",
  year=1974,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc614.txt",
  key="RFC 614",
  abstract={See also RFCs 624, 542 and 640.},
  keywords="ftp, weakness, solutions",
  doi="10.17487/RFC0614",
  }

@misc{rfc615,
  author="D. Crocker",
  title="{Proposed Network Standard Data Pathname syntax}",
  howpublished="RFC 615",
  series="Internet Request for Comments",
  type="RFC",
  number="615",
  pages="1--4",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 645",
url="https://www.rfc-editor.org/rfc/rfc615.txt",
  key="RFC 615",
  doi="10.17487/RFC0615",
  }

@misc{rfc616,
  author="D. Walden",
  title="{LATEST NETWORK MAPS}",
  howpublished="RFC 616",
  series="Internet Request for Comments",
  type="RFC",
  number="616",
  pages="1--1",
  year=1973,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc616.txt",
  key="RFC 616",
  keywords="Network, maps",
  doi="10.17487/RFC0616",
  }

@misc{rfc617,
  author="E.A. Taft",
  title="{Note on socket number assignment}",
  howpublished="RFC 617",
  series="Internet Request for Comments",
  type="RFC",
  number="617",
  pages="1--3",
  year=1974,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc617.txt",
  key="RFC 617",
  abstract={Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.},
  keywords="telnet",
  doi="10.17487/RFC0617",
  }

@misc{rfc618,
  author="E.A. Taft",
  title="{Few observations on NCP statistics}",
  howpublished="RFC 618",
  series="Internet Request for Comments",
  type="RFC",
  number="618",
  pages="1--3",
  year=1974,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc618.txt",
  key="RFC 618",
  abstract={Distribution of NCP and IMP message types by actual measurement.},
  doi="10.17487/RFC0618",
  }

@misc{rfc619,
  author="W. Naylor and H. Opderbeck",
  title="{Mean round-trip times in the ARPANET}",
  howpublished="RFC 619",
  series="Internet Request for Comments",
  type="RFC",
  number="619",
  pages="1--14",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc619.txt",
  key="RFC 619",
  abstract={Actual measurements of round-trip times.},
  doi="10.17487/RFC0619",
  }

@misc{rfc620,
  author="B. Ferguson",
  title="{Request for monitor host table updates}",
  howpublished="RFC 620",
  series="Internet Request for Comments",
  type="RFC",
  number="620",
  pages="1--1",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc620.txt",
  key="RFC 620",
  abstract={In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.},
  keywords="tenex",
  doi="10.17487/RFC0620",
  }

@misc{rfc621,
  author="M.D. Kudlick",
  title="{NIC user directories at SRI ARC}",
  howpublished="RFC 621",
  series="Internet Request for Comments",
  type="RFC",
  number="621",
  pages="1--1",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc621.txt",
  key="RFC 621",
  abstract={See also RFCs 620 and 609.},
  doi="10.17487/RFC0621",
  }

@misc{rfc622,
  author="A.M. McKenzie",
  title="{Scheduling IMP/TIP down time}",
  howpublished="RFC 622",
  series="Internet Request for Comments",
  type="RFC",
  number="622",
  pages="1--3",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc622.txt",
  key="RFC 622",
  abstract={Modification of previous policy.},
  doi="10.17487/RFC0622",
  }

@misc{rfc623,
  author="M. Krilanovich",
  title="{Comments on on-line host name service}",
  howpublished="RFC 623",
  series="Internet Request for Comments",
  type="RFC",
  number="623",
  pages="1--2",
  year=1974,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc623.txt",
  key="RFC 623",
  abstract={See also RFCs 627, 625, 608 and 606.},
  doi="10.17487/RFC0623",
  }

@misc{rfc624,
  author="M. Krilanovich and G. Gregg and W. Hathaway and J.E. White",
  title="{Comments on the File Transfer Protocol}",
  howpublished="RFC 624",
  series="Internet Request for Comments",
  type="RFC",
  number="624",
  pages="1--3",
  year=1974,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc624.txt",
  key="RFC 624",
  abstract={Design changes and slight modifications.  Replaces RFC 607; see also RFCs 614, 542 and 640.},
  keywords="ftp, telnet",
  doi="10.17487/RFC0624",
  }

@misc{rfc625,
  author="M.D. Kudlick and E.J. Feinler",
  title="{On-line hostnames service}",
  howpublished="RFC 625",
  series="Internet Request for Comments",
  type="RFC",
  number="625",
  pages="1--1",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc625.txt",
  key="RFC 625",
  abstract={See also RFCs 606, 608, 623 and 627.},
  doi="10.17487/RFC0625",
  }

@misc{rfc626,
  author="L. Kleinrock and H. Opderbeck",
  title="{On a possible lockup condition in IMP subnet due to message sequencing}",
  howpublished="RFC 626",
  series="Internet Request for Comments",
  type="RFC",
  number="626",
  pages="1--5",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc626.txt",
  key="RFC 626",
  doi="10.17487/RFC0626",
  }

@misc{rfc627,
  author="M.D. Kudlick and E.J. Feinler",
  title="{ASCII text file of hostnames}",
  howpublished="RFC 627",
  series="Internet Request for Comments",
  type="RFC",
  number="627",
  pages="1--1",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc627.txt",
  key="RFC 627",
  abstract={See also RFCs 606, 608, 623 and 625.},
  doi="10.17487/RFC0627",
  }

@misc{rfc628,
  author="M.L. Keeney",
  title="{Status of RFC numbers and a note on pre-assigned journal numbers}",
  howpublished="RFC 628",
  series="Internet Request for Comments",
  type="RFC",
  number="628",
  pages="1--1",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc628.txt",
  key="RFC 628",
  doi="10.17487/RFC0628",
  }

@misc{rfc629,
  author="J.B. North",
  title="{Scenario for using the Network Journal}",
  howpublished="RFC 629",
  series="Internet Request for Comments",
  type="RFC",
  number="629",
  pages="1--3",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc629.txt",
  key="RFC 629",
  doi="10.17487/RFC0629",
  }

@misc{rfc630,
  author="J. Sussman",
  title="{FTP error code usage for more reliable mail service}",
  howpublished="RFC 630",
  series="Internet Request for Comments",
  type="RFC",
  number="630",
  pages="1--3",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc630.txt",
  key="RFC 630",
  abstract={Describes FTP reply-code usage in TENEX mail processing.},
  doi="10.17487/RFC0630",
  }

@misc{rfc631,
  author="A. Danthine",
  title="{International meeting on minicomputers and data communication: Call for papers}",
  howpublished="RFC 631",
  series="Internet Request for Comments",
  type="RFC",
  number="631",
  pages="1--2",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc631.txt",
  key="RFC 631",
  doi="10.17487/RFC0631",
  }

@misc{rfc632,
  author="H. Opderbeck",
  title="{Throughput degradations for single packet messages}",
  howpublished="RFC 632",
  series="Internet Request for Comments",
  type="RFC",
  number="632",
  pages="1--6",
  year=1974,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc632.txt",
  key="RFC 632",
  doi="10.17487/RFC0632",
  }

@misc{rfc633,
  author="A.M. McKenzie",
  title="{IMP/TIP preventive maintenance schedule}",
  howpublished="RFC 633",
  series="Internet Request for Comments",
  type="RFC",
  number="633",
  pages="1--4",
  year=1974,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 638",
url="https://www.rfc-editor.org/rfc/rfc633.txt",
  key="RFC 633",
  abstract={An old version; see RFC 638.},
  doi="10.17487/RFC0633",
  }

@misc{rfc634,
  author="A.M. McKenzie",
  title="{Change in network address for Haskins Lab}",
  howpublished="RFC 634",
  series="Internet Request for Comments",
  type="RFC",
  number="634",
  pages="1--1",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc634.txt",
  key="RFC 634",
  doi="10.17487/RFC0634",
  }

@misc{rfc635,
  author="V. Cerf",
  title="{Assessment of ARPANET protocols}",
  howpublished="RFC 635",
  series="Internet Request for Comments",
  type="RFC",
  number="635",
  pages="1--1",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc635.txt",
  key="RFC 635",
  abstract={Theoretical and practical motivation for redesign.  Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.},
  doi="10.17487/RFC0635",
  }

@misc{rfc636,
  author="J.D. Burchfiel and B. Cosell and R.S. Tomlinson and D.C. Walden",
  title="{TIP/Tenex reliability improvements}",
  howpublished="RFC 636",
  series="Internet Request for Comments",
  type="RFC",
  number="636",
  pages="1--8",
  year=1974,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc636.txt",
  key="RFC 636",
  abstract={Obtaining/maintaining connections; recovery from lost connections; connection-state changes.},
  doi="10.17487/RFC0636",
  }

@misc{rfc637,
  author="A.M. McKenzie",
  title="{Change of network address for SU-DSL}",
  howpublished="RFC 637",
  series="Internet Request for Comments",
  type="RFC",
  number="637",
  pages="1--1",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc637.txt",
  key="RFC 637",
  doi="10.17487/RFC0637",
  }

@misc{rfc638,
  author="A.M. McKenzie",
  title="{IMP/TIP preventive maintenance schedule}",
  howpublished="RFC 638",
  series="Internet Request for Comments",
  type="RFC",
  number="638",
  pages="1--4",
  year=1974,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc638.txt",
  key="RFC 638",
  abstract={Corrects RFC 633.},
  doi="10.17487/RFC0638",
  }

@misc{rfc640,
  author="J. Postel",
  title="{Revised FTP reply codes}",
  howpublished="RFC 640",
  series="Internet Request for Comments",
  type="RFC",
  number="640",
  pages="1--17",
  year=1974,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc640.txt",
  key="RFC 640",
  abstract={Updates RFC 542.},
  doi="10.17487/RFC0640",
  }

@misc{rfc642,
  author="J.D. Burchfiel",
  title="{Ready line philosophy and implementation}",
  howpublished="RFC 642",
  series="Internet Request for Comments",
  type="RFC",
  number="642",
  pages="1--4",
  year=1974,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc642.txt",
  key="RFC 642",
  doi="10.17487/RFC0642",
  }

@misc{rfc643,
  author="E. Mader",
  title="{Network Debugging Protocol}",
  howpublished="RFC 643",
  series="Internet Request for Comments",
  type="RFC",
  number="643",
  pages="1--7",
  year=1974,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc643.txt",
  key="RFC 643",
  abstract={To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.},
  doi="10.17487/RFC0643",
  }

@misc{rfc644,
  author="R. Thomas",
  title="{On the problem of signature authentication for network mail}",
  howpublished="RFC 644",
  series="Internet Request for Comments",
  type="RFC",
  number="644",
  pages="1--3",
  year=1974,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc644.txt",
  key="RFC 644",
  doi="10.17487/RFC0644",
  }

@misc{rfc645,
  author="D. Crocker",
  title="{Network Standard Data Specification syntax}",
  howpublished="RFC 645",
  series="Internet Request for Comments",
  type="RFC",
  number="645",
  pages="1--9",
  year=1974,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc645.txt",
  key="RFC 645",
  abstract={Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.},
  doi="10.17487/RFC0645",
  }

@misc{rfc647,
  author="M.A. Padlipsky",
  title="{Proposed protocol for connecting host computers to ARPA-like networks via front end processors}",
  howpublished="RFC 647",
  series="Internet Request for Comments",
  type="RFC",
  number="647",
  pages="1--20",
  year=1974,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc647.txt",
  key="RFC 647",
  abstract={Approaches to Front-End protocol processing using available hardware and software.},
  doi="10.17487/RFC0647",
  }

@misc{rfc651,
  author="D. Crocker",
  title="{Revised Telnet status option}",
  howpublished="RFC 651",
  series="Internet Request for Comments",
  type="RFC",
  number="651",
  pages="1--2",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 859",
url="https://www.rfc-editor.org/rfc/rfc651.txt",
  key="RFC 651",
  doi="10.17487/RFC0651",
  }

@misc{rfc652,
  author="D. Crocker",
  title="{Telnet output carriage-return disposition option}",
  howpublished="RFC 652 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="652",
  pages="1--4",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc652.txt",
  key="RFC 652",
  keywords="TOPT-OCRD",
  doi="10.17487/RFC0652",
  }

@misc{rfc653,
  author="D. Crocker",
  title="{Telnet output horizontal tabstops option}",
  howpublished="RFC 653 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="653",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc653.txt",
  key="RFC 653",
  keywords="TOPT-OHT",
  doi="10.17487/RFC0653",
  }

@misc{rfc654,
  author="D. Crocker",
  title="{Telnet output horizontal tab disposition option}",
  howpublished="RFC 654 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="654",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc654.txt",
  key="RFC 654",
  keywords="TOPT-OHTD",
  doi="10.17487/RFC0654",
  }

@misc{rfc655,
  author="D. Crocker",
  title="{Telnet output formfeed disposition option}",
  howpublished="RFC 655 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="655",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc655.txt",
  key="RFC 655",
  keywords="TOPT-OFD",
  doi="10.17487/RFC0655",
  }

@misc{rfc656,
  author="D. Crocker",
  title="{Telnet output vertical tabstops option}",
  howpublished="RFC 656 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="656",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc656.txt",
  key="RFC 656",
  keywords="TOPT-OVT",
  doi="10.17487/RFC0656",
  }

@misc{rfc657,
  author="D. Crocker",
  title="{Telnet output vertical tab disposition option}",
  howpublished="RFC 657 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="657",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc657.txt",
  key="RFC 657",
  keywords="TOPT-OVTD",
  doi="10.17487/RFC0657",
  }

@misc{rfc658,
  author="D. Crocker",
  title="{Telnet output linefeed disposition}",
  howpublished="RFC 658 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="658",
  pages="1--2",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc658.txt",
  key="RFC 658",
  keywords="TOPT-OLD",
  doi="10.17487/RFC0658",
  }

@misc{rfc659,
  author="J. Postel",
  title="{Announcing additional Telnet options}",
  howpublished="RFC 659",
  series="Internet Request for Comments",
  type="RFC",
  number="659",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc659.txt",
  key="RFC 659",
  abstract={Options defined in RFCs 651-658.},
  doi="10.17487/RFC0659",
  }

@misc{rfc660,
  author="D.C. Walden",
  title="{Some changes to the IMP and the IMP/Host interface}",
  howpublished="RFC 660",
  series="Internet Request for Comments",
  type="RFC",
  number="660",
  pages="1--1",
  year=1974,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc660.txt",
  key="RFC 660",
  abstract={Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.},
  doi="10.17487/RFC0660",
  }

@misc{rfc661,
  author="J. Postel",
  title="{Protocol information}",
  howpublished="RFC 661",
  series="Internet Request for Comments",
  type="RFC",
  number="661",
  pages="1--21",
  year=1974,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 694",
url="https://www.rfc-editor.org/rfc/rfc661.txt",
  key="RFC 661",
  abstract={An old version; see RFC 694.},
  doi="10.17487/RFC0661",
  }

@misc{rfc662,
  author="R. Kanodia",
  title="{Performance improvement in ARPANET file transfers from Multics}",
  howpublished="RFC 662",
  series="Internet Request for Comments",
  type="RFC",
  number="662",
  pages="1--2",
  year=1974,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc662.txt",
  key="RFC 662",
  abstract={Experimenting with host output buffers to improve throughput.},
  doi="10.17487/RFC0662",
  }

@misc{rfc663,
  author="R. Kanodia",
  title="{Lost message detection and recovery protocol}",
  howpublished="RFC 663",
  series="Internet Request for Comments",
  type="RFC",
  number="663",
  pages="1--22",
  year=1974,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc663.txt",
  key="RFC 663",
  abstract={Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.},
  keywords="ARPANET, Host",
  doi="10.17487/RFC0663",
  }

@misc{rfc666,
  author="M.A. Padlipsky",
  title="{Specification of the Unified User-Level Protocol}",
  howpublished="RFC 666",
  series="Internet Request for Comments",
  type="RFC",
  number="666",
  pages="1--19",
  year=1974,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc666.txt",
  key="RFC 666",
  abstract={Discusses and proposes a common command language.},
  doi="10.17487/RFC0666",
  }

@misc{rfc667,
  author="S.G. Chipman",
  title="{Host Ports}",
  howpublished="RFC 667",
  series="Internet Request for Comments",
  type="RFC",
  number="667",
  pages="1--2",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc667.txt",
  key="RFC 667",
  abstract={Approved scheme to connect host ports to the network.},
  doi="10.17487/RFC0667",
  }

@misc{rfc669,
  author="D.W. Dodds",
  title="{November, 1974, survey of New-Protocol Telnet servers}",
  howpublished="RFC 669",
  series="Internet Request for Comments",
  type="RFC",
  number="669",
  pages="1--3",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 679",
url="https://www.rfc-editor.org/rfc/rfc669.txt",
  key="RFC 669",
  abstract={An earlier poll of Telnet server implementation status.  Updates RFC 702; see also RFCs 703 and 679.},
  doi="10.17487/RFC0669",
  }

@misc{rfc671,
  author="R. Schantz",
  title="{Note on Reconnection Protocol}",
  howpublished="RFC 671",
  series="Internet Request for Comments",
  type="RFC",
  number="671",
  pages="1--9",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc671.txt",
  key="RFC 671",
  abstract={Experience with implementation in RSEXEC context.},
  doi="10.17487/RFC0671",
  }

@misc{rfc672,
  author="R. Schantz",
  title="{Multi-site data collection facility}",
  howpublished="RFC 672",
  series="Internet Request for Comments",
  type="RFC",
  number="672",
  pages="1--9",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc672.txt",
  key="RFC 672",
  abstract={Applicability of TIP/TENEX protocols beyond TIP accounting.},
  doi="10.17487/RFC0672",
  }

@misc{rfc674,
  author="J. Postel and J.E. White",
  title="{Procedure call documents: Version 2}",
  howpublished="RFC 674",
  series="Internet Request for Comments",
  type="RFC",
  number="674",
  pages="1--6",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc674.txt",
  key="RFC 674",
  abstract={Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.},
  doi="10.17487/RFC0674",
  }

@misc{rfc675,
  author="V. Cerf and Y. Dalal and C. Sunshine",
  title="{Specification of Internet Transmission Control Program}",
  howpublished="RFC 675 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="675",
  pages="1--70",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc675.txt",
  key="RFC 675",
  abstract={The first detailed specification of TCP; see RFC 793.},
  doi="10.17487/RFC0675",
  }

@misc{rfc677,
  author="P.R. Johnson and R. Thomas",
  title="{Maintenance of duplicate databases}",
  howpublished="RFC 677",
  series="Internet Request for Comments",
  type="RFC",
  number="677",
  pages="1--10",
  year=1975,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc677.txt",
  key="RFC 677",
  doi="10.17487/RFC0677",
  }

@misc{rfc678,
  author="J. Postel",
  title="{Standard file formats}",
  howpublished="RFC 678",
  series="Internet Request for Comments",
  type="RFC",
  number="678",
  pages="1--9",
  year=1974,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc678.txt",
  key="RFC 678",
  abstract={For transmission of documents across different environments.},
  doi="10.17487/RFC0678",
  }

@misc{rfc679,
  author="D.W. Dodds",
  title="{February, 1975, survey of New-Protocol Telnet servers}",
  howpublished="RFC 679",
  series="Internet Request for Comments",
  type="RFC",
  number="679",
  pages="1--3",
  year=1975,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 703",
url="https://www.rfc-editor.org/rfc/rfc679.txt",
  key="RFC 679",
  abstract={An earlier poll of Telnet server implementation status.  Updates RFCs 701, 702 and 669; see also RFC 703.},
  doi="10.17487/RFC0679",
  }

@misc{rfc680,
  author="T.H. Myer and D.A. Henderson",
  title="{Message Transmission Protocol}",
  howpublished="RFC 680",
  series="Internet Request for Comments",
  type="RFC",
  number="680",
  pages="1--6",
  year=1975,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc680.txt",
  key="RFC 680",
  abstract={Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.},
  doi="10.17487/RFC0680",
  }

@misc{rfc681,
  author="S. Holmgren",
  title="{Network UNIX}",
  howpublished="RFC 681",
  series="Internet Request for Comments",
  type="RFC",
  number="681",
  pages="1--8",
  year=1975,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc681.txt",
  key="RFC 681",
  abstract={Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.},
  doi="10.17487/RFC0681",
  }

@misc{rfc683,
  author="R. Clements",
  title="{FTPSRV - Tenex extension for paged files}",
  howpublished="RFC 683",
  series="Internet Request for Comments",
  type="RFC",
  number="683",
  pages="1--3",
  year=1975,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc683.txt",
  key="RFC 683",
  abstract={Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.},
  keywords="FTP, paged, file, transfer, Tenex",
  doi="10.17487/RFC0683",
  }

@misc{rfc684,
  author="R. Schantz",
  title="{Commentary on procedure calling as a network protocol}",
  howpublished="RFC 684",
  series="Internet Request for Comments",
  type="RFC",
  number="684",
  pages="1--9",
  year=1975,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc684.txt",
  key="RFC 684",
  abstract={Issues in designing distributed computing systems.  Shortcomings of RFC 674; see also RFCs 542 and 354.},
  doi="10.17487/RFC0684",
  }

@misc{rfc685,
  author="M. Beeler",
  title="{Response time in cross network debugging}",
  howpublished="RFC 685",
  series="Internet Request for Comments",
  type="RFC",
  number="685",
  pages="1--3",
  year=1975,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc685.txt",
  key="RFC 685",
  abstract={The contribution of ARPANET communication to response time.},
  doi="10.17487/RFC0685",
  }

@misc{rfc686,
  author="B. Harvey",
  title="{Leaving well enough alone}",
  howpublished="RFC 686",
  series="Internet Request for Comments",
  type="RFC",
  number="686",
  pages="1--9",
  year=1975,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc686.txt",
  key="RFC 686",
  abstract={Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.},
  doi="10.17487/RFC0686",
  }

@misc{rfc687,
  author="D.C. Walden",
  title="{IMP/Host and Host/IMP Protocol changes}",
  howpublished="RFC 687",
  series="Internet Request for Comments",
  type="RFC",
  number="687",
  pages="1--2",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 704, updated by RFC 690",
url="https://www.rfc-editor.org/rfc/rfc687.txt",
  key="RFC 687",
  abstract={Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.},
  doi="10.17487/RFC0687",
  }

@misc{rfc688,
  author="D.C. Walden",
  title="{Tentative schedule for the new Telnet implementation for the TIP}",
  howpublished="RFC 688",
  series="Internet Request for Comments",
  type="RFC",
  number="688",
  pages="1--1",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc688.txt",
  key="RFC 688",
  doi="10.17487/RFC0688",
  }

@misc{rfc689,
  author="R. Clements",
  title="{Tenex NCP finite state machine for connections}",
  howpublished="RFC 689",
  series="Internet Request for Comments",
  type="RFC",
  number="689",
  pages="1--5",
  year=1975,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc689.txt",
  key="RFC 689",
  abstract={Describes the internal states of an NCP connection in the TENEX implementation.},
  doi="10.17487/RFC0689",
  }

@misc{rfc690,
  author="J. Postel",
  title="{Comments on the proposed Host/IMP Protocol changes}",
  howpublished="RFC 690",
  series="Internet Request for Comments",
  type="RFC",
  number="690",
  pages="1--3",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 692",
url="https://www.rfc-editor.org/rfc/rfc690.txt",
  key="RFC 690",
  abstract={Comments on suggestions in RFC 687; see also RFCs 692 and 696.},
  doi="10.17487/RFC0690",
  }

@misc{rfc691,
  author="B. Harvey",
  title="{One more try on the FTP}",
  howpublished="RFC 691",
  series="Internet Request for Comments",
  type="RFC",
  number="691",
  pages="1--14",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc691.txt",
  key="RFC 691",
  abstract={Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.},
  doi="10.17487/RFC0691",
  }

@misc{rfc692,
  author="S.M. Wolfe",
  title="{Comments on IMP/Host Protocol changes (RFCs 687 and 690)}",
  howpublished="RFC 692",
  series="Internet Request for Comments",
  type="RFC",
  number="692",
  pages="1--2",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc692.txt",
  key="RFC 692",
  abstract={A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.},
  doi="10.17487/RFC0692",
  }

@misc{rfc694,
  author="J. Postel",
  title="{Protocol information}",
  howpublished="RFC 694",
  series="Internet Request for Comments",
  type="RFC",
  number="694",
  pages="1--36",
  year=1975,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc694.txt",
  key="RFC 694",
  abstract={References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.},
  doi="10.17487/RFC0694",
  }

@misc{rfc695,
  author="M. Krilanovich",
  title="{Official change in Host-Host Protocol}",
  howpublished="RFC 695",
  series="Internet Request for Comments",
  type="RFC",
  number="695",
  pages="1--3",
  year=1975,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc695.txt",
  key="RFC 695",
  abstract={Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.},
  doi="10.17487/RFC0695",
  }

@misc{rfc696,
  author="V.G. Cerf",
  title="{Comments on the IMP/Host and Host/IMP Protocol changes}",
  howpublished="RFC 696",
  series="Internet Request for Comments",
  type="RFC",
  number="696",
  pages="1--2",
  year=1975,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc696.txt",
  key="RFC 696",
  abstract={Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.},
  doi="10.17487/RFC0696",
  }

@misc{rfc697,
  author="J. Lieb",
  title="{CWD command of FTP}",
  howpublished="RFC 697",
  series="Internet Request for Comments",
  type="RFC",
  number="697",
  pages="1--2",
  year=1975,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc697.txt",
  key="RFC 697",
  abstract={Discusses FTP login access to ``files only'' directories.},
  doi="10.17487/RFC0697",
  }

@misc{rfc698,
  author="T. Mock",
  title="{Telnet extended ASCII option}",
  howpublished="RFC 698 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="698",
  pages="1--3",
  year=1975,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5198",
url="https://www.rfc-editor.org/rfc/rfc698.txt",
  key="RFC 698",
  abstract={Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.},
  keywords="TOPT-EXT",
  doi="10.17487/RFC0698",
  }

@misc{rfc699,
  author="J. Postel and J. Vernon",
  title="{Request For Comments summary notes: 600-699}",
  howpublished="RFC 699 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="699",
  pages="1--9",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc699.txt",
  key="RFC 699",
  doi="10.17487/RFC0699",
  }

@misc{rfc700,
  author="E. Mader and W.W. Plummer and R.S. Tomlinson",
  title="{Protocol experiment}",
  howpublished="RFC 700 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="700",
  pages="1--7",
  year=1974,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc700.txt",
  key="RFC 700",
  doi="10.17487/RFC0700",
  }

@misc{rfc701,
  author="D.W. Dodds",
  title="{August, 1974, survey of New-Protocol Telnet servers}",
  howpublished="RFC 701",
  series="Internet Request for Comments",
  type="RFC",
  number="701",
  pages="1--1",
  year=1974,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 702",
url="https://www.rfc-editor.org/rfc/rfc701.txt",
  key="RFC 701",
  doi="10.17487/RFC0701",
  }

@misc{rfc702,
  author="D.W. Dodds",
  title="{September, 1974, survey of New-Protocol Telnet servers}",
  howpublished="RFC 702",
  series="Internet Request for Comments",
  type="RFC",
  number="702",
  pages="1--3",
  year=1974,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 669",
url="https://www.rfc-editor.org/rfc/rfc702.txt",
  key="RFC 702",
  doi="10.17487/RFC0702",
  }

@misc{rfc703,
  author="D.W. Dodds",
  title="{July, 1975, survey of New-Protocol Telnet Servers}",
  howpublished="RFC 703",
  series="Internet Request for Comments",
  type="RFC",
  number="703",
  pages="1--3",
  year=1975,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc703.txt",
  key="RFC 703",
  doi="10.17487/RFC0703",
  }

@misc{rfc704,
  author="P.J. Santos",
  title="{IMP/Host and Host/IMP Protocol change}",
  howpublished="RFC 704",
  series="Internet Request for Comments",
  type="RFC",
  number="704",
  pages="1--2",
  year=1975,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc704.txt",
  key="RFC 704",
  doi="10.17487/RFC0704",
  }

@misc{rfc705,
  author="R.F. Bryan",
  title="{Front-end Protocol B6700 version}",
  howpublished="RFC 705",
  series="Internet Request for Comments",
  type="RFC",
  number="705",
  pages="1--39",
  year=1975,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc705.txt",
  key="RFC 705",
  doi="10.17487/RFC0705",
  }

@misc{rfc706,
  author="J. Postel",
  title="{On the junk mail problem}",
  howpublished="RFC 706",
  series="Internet Request for Comments",
  type="RFC",
  number="706",
  pages="1--1",
  year=1975,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc706.txt",
  key="RFC 706",
  doi="10.17487/RFC0706",
  }

@misc{rfc707,
  author="J.E. White",
  title="{High-level framework for network-based resource sharing}",
  howpublished="RFC 707",
  series="Internet Request for Comments",
  type="RFC",
  number="707",
  pages="1--29",
  year=1975,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc707.txt",
  key="RFC 707",
  doi="10.17487/RFC0707",
  }

@misc{rfc708,
  author="J.E. White",
  title="{Elements of a Distributed Programming System}",
  howpublished="RFC 708",
  series="Internet Request for Comments",
  type="RFC",
  number="708",
  pages="1--30",
  year=1976,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc708.txt",
  key="RFC 708",
  doi="10.17487/RFC0708",
  }

@misc{rfc712,
  author="J.E. Donnelley",
  title="{Distributed Capability Computing System (DCCS)}",
  howpublished="RFC 712",
  series="Internet Request for Comments",
  type="RFC",
  number="712",
  pages="1--17",
  year=1976,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc712.txt",
  key="RFC 712",
  doi="10.17487/RFC0712",
  }

@misc{rfc713,
  author="J. Haverty",
  title="{MSDTP-Message Services Data Transmission Protocol}",
  howpublished="RFC 713",
  series="Internet Request for Comments",
  type="RFC",
  number="713",
  pages="1--21",
  year=1976,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc713.txt",
  key="RFC 713",
  doi="10.17487/RFC0713",
  }

@misc{rfc714,
  author="A.M. McKenzie",
  title="{Host-Host Protocol for an ARPANET-Type Network}",
  howpublished="RFC 714",
  series="Internet Request for Comments",
  type="RFC",
  number="714",
  pages="1--22",
  year=1976,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc714.txt",
  key="RFC 714",
  doi="10.17487/RFC0714",
  }

@misc{rfc716,
  author="D.C. Walden and J. Levin",
  title="{Interim Revision to Appendix F of BBN 1822}",
  howpublished="RFC 716",
  series="Internet Request for Comments",
  type="RFC",
  number="716",
  pages="1--1",
  year=1976,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc716.txt",
  key="RFC 716",
  doi="10.17487/RFC0716",
  }

@misc{rfc717,
  author="J. Postel",
  title="{Assigned Network Numbers}",
  howpublished="RFC 717 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="717",
  pages="1--1",
  year=1976,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc717.txt",
  key="RFC 717",
  doi="10.17487/RFC0717",
  }

@misc{rfc718,
  author="J. Postel",
  title="{Comments on RCTE from the Tenex Implementation Experience}",
  howpublished="RFC 718",
  series="Internet Request for Comments",
  type="RFC",
  number="718",
  pages="1--1",
  year=1976,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc718.txt",
  key="RFC 718",
  doi="10.17487/RFC0718",
  }

@misc{rfc719,
  author="J. Postel",
  title="{Discussion on RCTE}",
  howpublished="RFC 719",
  series="Internet Request for Comments",
  type="RFC",
  number="719",
  pages="1--1",
  year=1976,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc719.txt",
  key="RFC 719",
  doi="10.17487/RFC0719",
  }

@misc{rfc720,
  author="D. Crocker",
  title="{Address Specification Syntax for Network Mail}",
  howpublished="RFC 720",
  series="Internet Request for Comments",
  type="RFC",
  number="720",
  pages="1--3",
  year=1976,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc720.txt",
  key="RFC 720",
  doi="10.17487/RFC0720",
  }

@misc{rfc721,
  author="L.L. Garlick",
  title="{Out-of-Band Control Signals in a Host-to-Host Protocol}",
  howpublished="RFC 721 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="721",
  pages="1--7",
  year=1976,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc721.txt",
  key="RFC 721",
  doi="10.17487/RFC0721",
  }

@misc{rfc722,
  author="J. Haverty",
  title="{Thoughts on Interactions in Distributed Services}",
  howpublished="RFC 722",
  series="Internet Request for Comments",
  type="RFC",
  number="722",
  pages="1--13",
  year=1976,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc722.txt",
  key="RFC 722",
  doi="10.17487/RFC0722",
  }

@misc{rfc724,
  author="D. Crocker and K.T. Pogran and J. Vittal and D.A. Henderson",
  title="{Proposed official standard for the format of ARPA Network messages}",
  howpublished="RFC 724",
  series="Internet Request for Comments",
  type="RFC",
  number="724",
  pages="1--36",
  year=1977,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 733",
url="https://www.rfc-editor.org/rfc/rfc724.txt",
  key="RFC 724",
  doi="10.17487/RFC0724",
  }

@misc{rfc725,
  author="J.D. Day and G.R. Grossman",
  title="{RJE protocol for a resource sharing network}",
  howpublished="RFC 725",
  series="Internet Request for Comments",
  type="RFC",
  number="725",
  pages="1--27",
  year=1977,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc725.txt",
  key="RFC 725",
  doi="10.17487/RFC0725",
  }

@misc{rfc726,
  author="J. Postel and D. Crocker",
  title="{Remote Controlled Transmission and Echoing Telnet option}",
  howpublished="RFC 726 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="726",
  pages="1--16",
  year=1977,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc726.txt",
  key="RFC 726",
  keywords="TOPT-REM",
  doi="10.17487/RFC0726",
  }

@misc{rfc727,
  author="M.R. Crispin",
  title="{Telnet logout option}",
  howpublished="RFC 727 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="727",
  pages="1--3",
  year=1977,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc727.txt",
  key="RFC 727",
  keywords="TOPT-LOGO",
  doi="10.17487/RFC0727",
  }

@misc{rfc728,
  author="J.D. Day",
  title="{Minor pitfall in the Telnet Protocol}",
  howpublished="RFC 728",
  series="Internet Request for Comments",
  type="RFC",
  number="728",
  pages="1--1",
  year=1977,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc728.txt",
  key="RFC 728",
  doi="10.17487/RFC0728",
  }

@misc{rfc729,
  author="D. Crocker",
  title="{Telnet byte macro option}",
  howpublished="RFC 729",
  series="Internet Request for Comments",
  type="RFC",
  number="729",
  pages="1--3",
  year=1977,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 735",
url="https://www.rfc-editor.org/rfc/rfc729.txt",
  key="RFC 729",
  doi="10.17487/RFC0729",
  }

@misc{rfc730,
  author="J. Postel",
  title="{Extensible field addressing}",
  howpublished="RFC 730",
  series="Internet Request for Comments",
  type="RFC",
  number="730",
  pages="1--5",
  year=1977,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc730.txt",
  key="RFC 730",
  doi="10.17487/RFC0730",
  }

@misc{rfc731,
  author="J.D. Day",
  title="{Telnet Data Entry Terminal option}",
  howpublished="RFC 731",
  series="Internet Request for Comments",
  type="RFC",
  number="731",
  pages="1--28",
  year=1977,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 732",
url="https://www.rfc-editor.org/rfc/rfc731.txt",
  key="RFC 731",
  doi="10.17487/RFC0731",
  }

@misc{rfc732,
  author="J.D. Day",
  title="{Telnet Data Entry Terminal option}",
  howpublished="RFC 732",
  series="Internet Request for Comments",
  type="RFC",
  number="732",
  pages="1--30",
  year=1977,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1043",
url="https://www.rfc-editor.org/rfc/rfc732.txt",
  key="RFC 732",
  doi="10.17487/RFC0732",
  }

@misc{rfc733,
  author="D. Crocker and J. Vittal and K.T. Pogran and D.A. Henderson",
  title="{Standard for the format of ARPA network text messages}",
  howpublished="RFC 733",
  series="Internet Request for Comments",
  type="RFC",
  number="733",
  pages="1--38",
  year=1977,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 822",
url="https://www.rfc-editor.org/rfc/rfc733.txt",
  key="RFC 733",
  doi="10.17487/RFC0733",
  }

@misc{rfc734,
  author="M.R. Crispin",
  title="{SUPDUP Protocol}",
  howpublished="RFC 734 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="734",
  pages="1--13",
  year=1977,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc734.txt",
  key="RFC 734",
  keywords="SUPDUP",
  doi="10.17487/RFC0734",
  }

@misc{rfc735,
  author="D. Crocker and R.H. Gumpertz",
  title="{Revised Telnet byte macro option}",
  howpublished="RFC 735 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="735",
  pages="1--5",
  year=1977,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc735.txt",
  key="RFC 735",
  keywords="TOPT-BYTE",
  doi="10.17487/RFC0735",
  }

@misc{rfc736,
  author="M.R. Crispin",
  title="{Telnet SUPDUP option}",
  howpublished="RFC 736 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="736",
  pages="1--1",
  year=1977,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc736.txt",
  key="RFC 736",
  keywords="TOPT-SUP",
  doi="10.17487/RFC0736",
  }

@misc{rfc737,
  author="K. Harrenstien",
  title="{FTP extension: XSEN}",
  howpublished="RFC 737",
  series="Internet Request for Comments",
  type="RFC",
  number="737",
  pages="1--1",
  year=1977,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc737.txt",
  key="RFC 737",
  doi="10.17487/RFC0737",
  }

@misc{rfc738,
  author="K. Harrenstien",
  title="{Time server}",
  howpublished="RFC 738",
  series="Internet Request for Comments",
  type="RFC",
  number="738",
  pages="1--1",
  year=1977,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc738.txt",
  key="RFC 738",
  doi="10.17487/RFC0738",
  }

@misc{rfc739,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 739 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="739",
  pages="1--11",
  year=1977,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 750",
url="https://www.rfc-editor.org/rfc/rfc739.txt",
  key="RFC 739",
  doi="10.17487/RFC0739",
  }

@misc{rfc740,
  author="R.T. Braden",
  title="{NETRJS Protocol}",
  howpublished="RFC 740 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="740",
  pages="1--19",
  year=1977,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc740.txt",
  key="RFC 740",
  keywords="NETRJS",
  doi="10.17487/RFC0740",
  }

@misc{rfc741,
  author="D. Cohen",
  title="{Specifications for the Network Voice Protocol (NVP)}",
  howpublished="RFC 741",
  series="Internet Request for Comments",
  type="RFC",
  number="741",
  pages="1--34",
  year=1977,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc741.txt",
  key="RFC 741",
  doi="10.17487/RFC0741",
  }

@misc{rfc742,
  author="K. Harrenstien",
  title="{NAME/FINGER Protocol}",
  howpublished="RFC 742",
  series="Internet Request for Comments",
  type="RFC",
  number="742",
  pages="1--7",
  year=1977,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1288, 1196, 1194",
url="https://www.rfc-editor.org/rfc/rfc742.txt",
  key="RFC 742",
  doi="10.17487/RFC0742",
  }

@misc{rfc743,
  author="K. Harrenstien",
  title="{FTP extension: XRSQ/XRCP}",
  howpublished="RFC 743",
  series="Internet Request for Comments",
  type="RFC",
  number="743",
  pages="1--8",
  year=1977,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc743.txt",
  key="RFC 743",
  doi="10.17487/RFC0743",
  }

@misc{rfc744,
  author="J. Sattley",
  title="{MARS - a Message Archiving and Retrieval Service}",
  howpublished="RFC 744",
  series="Internet Request for Comments",
  type="RFC",
  number="744",
  pages="1--6",
  year=1978,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc744.txt",
  key="RFC 744",
  doi="10.17487/RFC0744",
  }

@misc{rfc745,
  author="M. Beeler",
  title="{JANUS interface specifications}",
  howpublished="RFC 745",
  series="Internet Request for Comments",
  type="RFC",
  number="745",
  pages="1--10",
  year=1978,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc745.txt",
  key="RFC 745",
  keywords="JANUS, interface, specifications",
  doi="10.17487/RFC0745",
  }

@misc{rfc746,
  author="R. Stallman",
  title="{SUPDUP graphics extension}",
  howpublished="RFC 746",
  series="Internet Request for Comments",
  type="RFC",
  number="746",
  pages="1--15",
  year=1978,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc746.txt",
  key="RFC 746",
  doi="10.17487/RFC0746",
  }

@misc{rfc747,
  author="M.R. Crispin",
  title="{Recent extensions to the SUPDUP Protocol}",
  howpublished="RFC 747",
  series="Internet Request for Comments",
  type="RFC",
  number="747",
  pages="1--1",
  year=1978,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc747.txt",
  key="RFC 747",
  doi="10.17487/RFC0747",
  }

@misc{rfc748,
  author="M.R. Crispin",
  title="{Telnet randomly-lose option}",
  howpublished="RFC 748",
  series="Internet Request for Comments",
  type="RFC",
  number="748",
  pages="1--2",
  year=1978,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc748.txt",
  key="RFC 748",
  doi="10.17487/RFC0748",
  }

@misc{rfc749,
  author="B. Greenberg",
  title="{Telnet SUPDUP-Output option}",
  howpublished="RFC 749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="749",
  pages="1--4",
  year=1978,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc749.txt",
  key="RFC 749",
  keywords="TOPT-SUPO",
  doi="10.17487/RFC0749",
  }

@misc{rfc750,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 750 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="750",
  pages="1--12",
  year=1978,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 755",
url="https://www.rfc-editor.org/rfc/rfc750.txt",
  key="RFC 750",
  doi="10.17487/RFC0750",
  }

@misc{rfc751,
  author="P.D. Lebling",
  title="{Survey of FTP mail and MLFL}",
  howpublished="RFC 751",
  series="Internet Request for Comments",
  type="RFC",
  number="751",
  pages="1--5",
  year=1978,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc751.txt",
  key="RFC 751",
  doi="10.17487/RFC0751",
  }

@misc{rfc752,
  author="M.R. Crispin",
  title="{Universal host table}",
  howpublished="RFC 752",
  series="Internet Request for Comments",
  type="RFC",
  number="752",
  pages="1--12",
  year=1979,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc752.txt",
  key="RFC 752",
  doi="10.17487/RFC0752",
  }

@misc{rfc753,
  author="J. Postel",
  title="{Internet Message Protocol}",
  howpublished="RFC 753",
  series="Internet Request for Comments",
  type="RFC",
  number="753",
  pages="1--62",
  year=1979,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc753.txt",
  key="RFC 753",
  doi="10.17487/RFC0753",
  }

@misc{rfc754,
  author="J. Postel",
  title="{Out-of-net host addresses for mail}",
  howpublished="RFC 754",
  series="Internet Request for Comments",
  type="RFC",
  number="754",
  pages="1--10",
  year=1979,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc754.txt",
  key="RFC 754",
  doi="10.17487/RFC0754",
  }

@misc{rfc755,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 755 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="755",
  pages="1--12",
  year=1979,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 758",
url="https://www.rfc-editor.org/rfc/rfc755.txt",
  key="RFC 755",
  doi="10.17487/RFC0755",
  }

@misc{rfc756,
  author="J.R. Pickens and E.J. Feinler and J.E. Mathis",
  title="{NIC name server - a datagram-based information utility}",
  howpublished="RFC 756",
  series="Internet Request for Comments",
  type="RFC",
  number="756",
  pages="1--12",
  year=1979,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc756.txt",
  key="RFC 756",
  doi="10.17487/RFC0756",
  }

@misc{rfc757,
  author="D.P. Deutsch",
  title="{Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems}",
  howpublished="RFC 757",
  series="Internet Request for Comments",
  type="RFC",
  number="757",
  pages="1--19",
  year=1979,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc757.txt",
  key="RFC 757",
  doi="10.17487/RFC0757",
  }

@misc{rfc758,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 758 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="758",
  pages="1--12",
  year=1979,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 762",
url="https://www.rfc-editor.org/rfc/rfc758.txt",
  key="RFC 758",
  doi="10.17487/RFC0758",
  }

@misc{rfc759,
  author="J. Postel",
  title="{Internet Message Protocol}",
  howpublished="RFC 759 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="759",
  pages="1--77",
  year=1980,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc759.txt",
  key="RFC 759",
  keywords="MPM",
  doi="10.17487/RFC0759",
  }

@misc{rfc760,
  author="J. Postel",
  title="{DoD standard Internet Protocol}",
  howpublished="RFC 760",
  series="Internet Request for Comments",
  type="RFC",
  number="760",
  pages="1--46",
  year=1980,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 791, updated by RFC 777",
url="https://www.rfc-editor.org/rfc/rfc760.txt",
  key="RFC 760",
  doi="10.17487/RFC0760",
  }

@misc{rfc761,
  author="J. Postel",
  title="{DoD standard Transmission Control Protocol}",
  howpublished="RFC 761 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="761",
  pages="1--88",
  year=1980,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 793, 7805",
url="https://www.rfc-editor.org/rfc/rfc761.txt",
  key="RFC 761",
  keywords="TCP",
  doi="10.17487/RFC0761",
  }

@misc{rfc762,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 762 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="762",
  pages="1--13",
  year=1980,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 770",
url="https://www.rfc-editor.org/rfc/rfc762.txt",
  key="RFC 762",
  doi="10.17487/RFC0762",
  }

@misc{rfc763,
  author="M.D. Abrams",
  title="{Role mailboxes}",
  howpublished="RFC 763",
  series="Internet Request for Comments",
  type="RFC",
  number="763",
  pages="1--1",
  year=1980,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc763.txt",
  key="RFC 763",
  doi="10.17487/RFC0763",
  }

@misc{rfc764,
  author="J. Postel",
  title="{Telnet Protocol specification}",
  howpublished="RFC 764",
  series="Internet Request for Comments",
  type="RFC",
  number="764",
  pages="1--15",
  year=1980,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 854",
url="https://www.rfc-editor.org/rfc/rfc764.txt",
  key="RFC 764",
  doi="10.17487/RFC0764",
  }

@misc{rfc765,
  author="J. Postel",
  title="{File Transfer Protocol specification}",
  howpublished="RFC 765",
  series="Internet Request for Comments",
  type="RFC",
  number="765",
  pages="1--70",
  year=1980,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 959",
url="https://www.rfc-editor.org/rfc/rfc765.txt",
  key="RFC 765",
  doi="10.17487/RFC0765",
  }

@misc{rfc766,
  author="J. Postel",
  title="{Internet Protocol Handbook: Table of contents}",
  howpublished="RFC 766",
  series="Internet Request for Comments",
  type="RFC",
  number="766",
  pages="1--2",
  year=1980,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 774",
url="https://www.rfc-editor.org/rfc/rfc766.txt",
  key="RFC 766",
  doi="10.17487/RFC0766",
  }

@misc{rfc767,
  author="J. Postel",
  title="{Structured format for transmission of multi-media documents}",
  howpublished="RFC 767",
  series="Internet Request for Comments",
  type="RFC",
  number="767",
  pages="1--40",
  year=1980,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc767.txt",
  key="RFC 767",
  doi="10.17487/RFC0767",
  }

@misc{rfc768,
  author="J. Postel",
  title="{User Datagram Protocol}",
  howpublished="RFC 768 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="768",
  pages="1--3",
  year=1980,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc768.txt",
  key="RFC 768",
  keywords="UDP, UDP",
  doi="10.17487/RFC0768",
  }

@misc{rfc769,
  author="J. Postel",
  title="{Rapicom 450 facsimile file format}",
  howpublished="RFC 769",
  series="Internet Request for Comments",
  type="RFC",
  number="769",
  pages="1--2",
  year=1980,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc769.txt",
  key="RFC 769",
  doi="10.17487/RFC0769",
  }

@misc{rfc770,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 770 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="770",
  pages="1--15",
  year=1980,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 776",
url="https://www.rfc-editor.org/rfc/rfc770.txt",
  key="RFC 770",
  doi="10.17487/RFC0770",
  }

@misc{rfc771,
  author="V.G. Cerf and J. Postel",
  title="{Mail transition plan}",
  howpublished="RFC 771",
  series="Internet Request for Comments",
  type="RFC",
  number="771",
  pages="1--9",
  year=1980,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc771.txt",
  key="RFC 771",
  doi="10.17487/RFC0771",
  }

@misc{rfc772,
  author="S. Sluizer and J. Postel",
  title="{Mail Transfer Protocol}",
  howpublished="RFC 772",
  series="Internet Request for Comments",
  type="RFC",
  number="772",
  pages="1--31",
  year=1980,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 780",
url="https://www.rfc-editor.org/rfc/rfc772.txt",
  key="RFC 772",
  keywords="MTP, email",
  doi="10.17487/RFC0772",
  }

@misc{rfc773,
  author="V.G. Cerf",
  title="{Comments on NCP/TCP mail service transition strategy}",
  howpublished="RFC 773",
  series="Internet Request for Comments",
  type="RFC",
  number="773",
  pages="1--11",
  year=1980,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc773.txt",
  key="RFC 773",
  doi="10.17487/RFC0773",
  }

@misc{rfc774,
  author="J. Postel",
  title="{Internet Protocol Handbook: Table of contents}",
  howpublished="RFC 774",
  series="Internet Request for Comments",
  type="RFC",
  number="774",
  pages="1--3",
  year=1980,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc774.txt",
  key="RFC 774",
  doi="10.17487/RFC0774",
  }

@misc{rfc775,
  author="D. Mankins and D. Franklin and A.D. Owen",
  title="{Directory oriented FTP commands}",
  howpublished="RFC 775",
  series="Internet Request for Comments",
  type="RFC",
  number="775",
  pages="1--6",
  year=1980,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc775.txt",
  key="RFC 775",
  doi="10.17487/RFC0775",
  }

@misc{rfc776,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 776 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="776",
  pages="1--13",
  year=1981,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 790",
url="https://www.rfc-editor.org/rfc/rfc776.txt",
  key="RFC 776",
  doi="10.17487/RFC0776",
  }

@misc{rfc777,
  author="J. Postel",
  title="{Internet Control Message Protocol}",
  howpublished="RFC 777",
  series="Internet Request for Comments",
  type="RFC",
  number="777",
  pages="1--14",
  year=1981,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 792",
url="https://www.rfc-editor.org/rfc/rfc777.txt",
  key="RFC 777",
  doi="10.17487/RFC0777",
  }

@misc{rfc778,
  author="D.L. Mills",
  title="{DCNET Internet Clock Service}",
  howpublished="RFC 778 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="778",
  pages="1--4",
  year=1981,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc778.txt",
  key="RFC 778",
  keywords="CLOCK",
  doi="10.17487/RFC0778",
  }

@misc{rfc779,
  author="E. Killian",
  title="{Telnet send-location option}",
  howpublished="RFC 779 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="779",
  pages="1--2",
  year=1981,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc779.txt",
  key="RFC 779",
  keywords="TOPT-SNDL",
  doi="10.17487/RFC0779",
  }

@misc{rfc780,
  author="S. Sluizer and J. Postel",
  title="{Mail Transfer Protocol}",
  howpublished="RFC 780",
  series="Internet Request for Comments",
  type="RFC",
  number="780",
  pages="1--47",
  year=1981,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 788",
url="https://www.rfc-editor.org/rfc/rfc780.txt",
  key="RFC 780",
  keywords="MTP, email",
  doi="10.17487/RFC0780",
  }

@misc{rfc781,
  author="Z. Su",
  title="{Specification of the Internet Protocol (IP) timestamp option}",
  howpublished="RFC 781",
  series="Internet Request for Comments",
  type="RFC",
  number="781",
  pages="1--1",
  year=1981,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc781.txt",
  key="RFC 781",
  doi="10.17487/RFC0781",
  }

@misc{rfc782,
  author="J. Nabielsky and A.P. Skelton",
  title="{Virtual Terminal management model}",
  howpublished="RFC 782",
  series="Internet Request for Comments",
  type="RFC",
  number="782",
  pages="1--23",
  year=1981,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc782.txt",
  key="RFC 782",
  doi="10.17487/RFC0782",
  }

@misc{rfc783,
  author="K.R. Sollins",
  title="{TFTP Protocol (revision 2)}",
  howpublished="RFC 783",
  series="Internet Request for Comments",
  type="RFC",
  number="783",
  pages="1--18",
  year=1981,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1350",
url="https://www.rfc-editor.org/rfc/rfc783.txt",
  key="RFC 783",
  doi="10.17487/RFC0783",
  }

@misc{rfc784,
  author="S. Sluizer and J. Postel",
  title="{Mail Transfer Protocol: ISI TOPS20 implementation}",
  howpublished="RFC 784",
  series="Internet Request for Comments",
  type="RFC",
  number="784",
  pages="1--3",
  year=1981,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc784.txt",
  key="RFC 784",
  keywords="MTP, email",
  doi="10.17487/RFC0784",
  }

@misc{rfc785,
  author="S. Sluizer and J. Postel",
  title="{Mail Transfer Protocol: ISI TOPS20 file definitions}",
  howpublished="RFC 785",
  series="Internet Request for Comments",
  type="RFC",
  number="785",
  pages="1--3",
  year=1981,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc785.txt",
  key="RFC 785",
  keywords="MTP, email",
  doi="10.17487/RFC0785",
  }

@misc{rfc786,
  author="S. Sluizer and J. Postel",
  title="{Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface}",
  howpublished="RFC 786",
  series="Internet Request for Comments",
  type="RFC",
  number="786",
  pages="1--2",
  year=1981,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc786.txt",
  key="RFC 786",
  keywords="MTP, NIMAIL, TOPS20",
  doi="10.17487/RFC0786",
  }

@misc{rfc787,
  author="A.L. Chapin",
  title="{Connectionless data transmission survey/tutorial}",
  howpublished="RFC 787",
  series="Internet Request for Comments",
  type="RFC",
  number="787",
  pages="1--40",
  year=1981,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc787.txt",
  key="RFC 787",
  doi="10.17487/RFC0787",
  }

@misc{rfc788,
  author="J. Postel",
  title="{Simple Mail Transfer Protocol}",
  howpublished="RFC 788",
  series="Internet Request for Comments",
  type="RFC",
  number="788",
  pages="1--64",
  year=1981,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 821",
url="https://www.rfc-editor.org/rfc/rfc788.txt",
  key="RFC 788",
  keywords="SMTP, email",
  doi="10.17487/RFC0788",
  }

@misc{rfc789,
  author="E.C. Rosen",
  title="{Vulnerabilities of network control protocols: An example}",
  howpublished="RFC 789",
  series="Internet Request for Comments",
  type="RFC",
  number="789",
  pages="1--16",
  year=1981,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc789.txt",
  key="RFC 789",
  doi="10.17487/RFC0789",
  }

@misc{rfc790,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 790 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="790",
  pages="1--15",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 820",
url="https://www.rfc-editor.org/rfc/rfc790.txt",
  key="RFC 790",
  doi="10.17487/RFC0790",
  }

@misc{rfc791,
  author="J. Postel",
  title="{Internet Protocol}",
  howpublished="RFC 791 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="791",
  pages="1--51",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1349, 2474, 6864",
url="https://www.rfc-editor.org/rfc/rfc791.txt",
  key="RFC 791",
  keywords="IP, IPv4",
  doi="10.17487/RFC0791",
  }

@misc{rfc792,
  author="J. Postel",
  title="{Internet Control Message Protocol}",
  howpublished="RFC 792 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="792",
  pages="1--21",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 950, 4884, 6633, 6918",
url="https://www.rfc-editor.org/rfc/rfc792.txt",
  key="RFC 792",
  keywords="ICMP",
  doi="10.17487/RFC0792",
  }

@misc{rfc793,
  author="J. Postel",
  title="{Transmission Control Protocol}",
  howpublished="RFC 793 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="793",
  pages="1--91",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1122, 3168, 6093, 6528",
url="https://www.rfc-editor.org/rfc/rfc793.txt",
  key="RFC 793",
  keywords="TCP, TCP",
  doi="10.17487/RFC0793",
  }

@misc{rfc794,
  author="V.G. Cerf",
  title="{Pre-emption}",
  howpublished="RFC 794 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="794",
  pages="1--2",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc794.txt",
  key="RFC 794",
  doi="10.17487/RFC0794",
  }

@misc{rfc795,
  author="J. Postel",
  title="{Service mappings}",
  howpublished="RFC 795",
  series="Internet Request for Comments",
  type="RFC",
  number="795",
  pages="1--4",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc795.txt",
  key="RFC 795",
  doi="10.17487/RFC0795",
  }

@misc{rfc796,
  author="J. Postel",
  title="{Address mappings}",
  howpublished="RFC 796 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="796",
  pages="1--7",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc796.txt",
  key="RFC 796",
  doi="10.17487/RFC0796",
  }

@misc{rfc797,
  author="A.R. Katz",
  title="{Format for Bitmap files}",
  howpublished="RFC 797",
  series="Internet Request for Comments",
  type="RFC",
  number="797",
  pages="1--2",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc797.txt",
  key="RFC 797",
  doi="10.17487/RFC0797",
  }

@misc{rfc798,
  author="A.R. Katz",
  title="{Decoding facsimile data from the Rapicom 450}",
  howpublished="RFC 798",
  series="Internet Request for Comments",
  type="RFC",
  number="798",
  pages="1--17",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc798.txt",
  key="RFC 798",
  doi="10.17487/RFC0798",
  }

@misc{rfc799,
  author="D.L. Mills",
  title="{Internet name domains}",
  howpublished="RFC 799",
  series="Internet Request for Comments",
  type="RFC",
  number="799",
  pages="1--5",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc799.txt",
  key="RFC 799",
  doi="10.17487/RFC0799",
  }

@misc{rfc800,
  author="J. Postel and J. Vernon",
  title="{Request For Comments summary notes: 700-799}",
  howpublished="RFC 800 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="800",
  pages="1--10",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc800.txt",
  key="RFC 800",
  abstract={This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799.  This is a status report on these RFCs.},
  doi="10.17487/RFC0800",
  }

@misc{rfc801,
  author="J. Postel",
  title="{NCP/TCP transition plan}",
  howpublished="RFC 801",
  series="Internet Request for Comments",
  type="RFC",
  number="801",
  pages="1--21",
  year=1981,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc801.txt",
  key="RFC 801",
  abstract={This RFC discusses the conversion of hosts from NCP to TCP.  And making available the principle services: Telnet, File Transfer, and Mail.  These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.},
  doi="10.17487/RFC0801",
  }

@misc{rfc802,
  author="A.G. Malis",
  title="{ARPANET 1822L Host Access Protocol}",
  howpublished="RFC 802",
  series="Internet Request for Comments",
  type="RFC",
  number="802",
  pages="1--45",
  year=1981,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 851",
url="https://www.rfc-editor.org/rfc/rfc802.txt",
  key="RFC 802",
  abstract={This document proposed two major changes to the current ARPANET host access protocol.  The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds).  See RFCs 852 and 851.},
  doi="10.17487/RFC0802",
  }

@misc{rfc803,
  author="A. Agarwal and M.J. O'Connor and D.L. Mills",
  title="{Dacom 450/500 facsimile data transcoding}",
  howpublished="RFC 803",
  series="Internet Request for Comments",
  type="RFC",
  number="803",
  pages="1--14",
  year=1981,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc803.txt",
  key="RFC 803",
  abstract={The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum.  The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.},
  doi="10.17487/RFC0803",
  }

@misc{rfc804,
  author="International Telegraph and Telephone Consultative Committee of the International Telecommunication Union",
  title="{CCITT draft recommendation T.4}",
  howpublished="RFC 804",
  series="Internet Request for Comments",
  type="RFC",
  number="804",
  pages="1--12",
  year=1981,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc804.txt",
  key="RFC 804",
  abstract={This is the CCITT standard for group 3 facsimile encoding.  This is useful for data compression of bit map data.},
  doi="10.17487/RFC0804",
  }

@misc{rfc805,
  author="J. Postel",
  title="{Computer mail meeting notes}",
  howpublished="RFC 805",
  series="Internet Request for Comments",
  type="RFC",
  number="805",
  pages="1--6",
  year=1982,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc805.txt",
  key="RFC 805",
  abstract={This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail.  The major conclusion reached at the meeting is to extend the ``username@hostname'' mailbox format to ``username@host.domain'', where the domain itself can be further strutured.},
  doi="10.17487/RFC0805",
  }

@misc{rfc806,
  author="National Bureau of Standards",
  title="{Proposed Federal Information Processing Standard: Specification for message format for computer based message systems}",
  howpublished="RFC 806",
  series="Internet Request for Comments",
  type="RFC",
  number="806",
  pages="1--107",
  year=1981,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 841",
url="https://www.rfc-editor.org/rfc/rfc806.txt",
  key="RFC 806",
  abstract={This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them.  This RFC is replaced by RFC 841.},
  doi="10.17487/RFC0806",
  }

@misc{rfc807,
  author="J. Postel",
  title="{Multimedia mail meeting notes}",
  howpublished="RFC 807",
  series="Internet Request for Comments",
  type="RFC",
  number="807",
  pages="1--6",
  year=1982,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc807.txt",
  key="RFC 807",
  abstract={This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.},
  doi="10.17487/RFC0807",
  }

@misc{rfc808,
  author="J. Postel",
  title="{Summary of computer mail services meeting held at BBN on 10 January 1979}",
  howpublished="RFC 808",
  series="Internet Request for Comments",
  type="RFC",
  number="808",
  pages="1--8",
  year=1982,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc808.txt",
  key="RFC 808",
  abstract={This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.},
  doi="10.17487/RFC0808",
  }

@misc{rfc809,
  author="T. Chang",
  title="{UCL facsimile system}",
  howpublished="RFC 809",
  series="Internet Request for Comments",
  type="RFC",
  number="809",
  pages="1--99",
  year=1982,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc809.txt",
  key="RFC 809",
  abstract={This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL.  First its functions are considered and the related experimental work are reported.  Then the disciplines for system design are discussed.  Finally, the implementation of the system are described, while detailed description are given as appendices.},
  doi="10.17487/RFC0809",
  }

@misc{rfc810,
  author="E.J. Feinler and K. Harrenstien and Z. Su and V. White",
  title="{DoD Internet host table specification}",
  howpublished="RFC 810",
  series="Internet Request for Comments",
  type="RFC",
  number="810",
  pages="1--8",
  year=1982,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 952",
url="https://www.rfc-editor.org/rfc/rfc810.txt",
  key="RFC 810",
  abstract={This RFC specifies a new host table format applicable to both ARPANET and Internet needs.  In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information.  This RFC obsoletes the host table described in RFC 608.},
  doi="10.17487/RFC0810",
  }

@misc{rfc811,
  author="K. Harrenstien and V. White and E.J. Feinler",
  title="{Hostnames Server}",
  howpublished="RFC 811",
  series="Internet Request for Comments",
  type="RFC",
  number="811",
  pages="1--4",
  year=1982,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 953",
url="https://www.rfc-editor.org/rfc/rfc811.txt",
  key="RFC 811",
  abstract={This RFC gives a description of what the Hostnames Server is and how to access it.  The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.},
  doi="10.17487/RFC0811",
  }

@misc{rfc812,
  author="K. Harrenstien and V. White",
  title="{NICNAME/WHOIS}",
  howpublished="RFC 812",
  series="Internet Request for Comments",
  type="RFC",
  number="812",
  pages="1--2",
  year=1982,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 954, 3912",
url="https://www.rfc-editor.org/rfc/rfc812.txt",
  key="RFC 812",
  abstract={This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it.  This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.},
  doi="10.17487/RFC0812",
  }

@misc{rfc813,
  author="D.D. Clark",
  title="{Window and Acknowledgement Strategy in TCP}",
  howpublished="RFC 813 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="813",
  pages="1--21",
  year=1982,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc813.txt",
  key="RFC 813",
  abstract={This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement.  It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other.  With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.},
  doi="10.17487/RFC0813",
  }

@misc{rfc814,
  author="D.D. Clark",
  title="{Name, addresses, ports, and routes}",
  howpublished="RFC 814 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="814",
  pages="1--13",
  year=1982,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc814.txt",
  key="RFC 814",
  abstract={This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.},
  doi="10.17487/RFC0814",
  }

@misc{rfc815,
  author="D.D. Clark",
  title="{IP datagram reassembly algorithms}",
  howpublished="RFC 815",
  series="Internet Request for Comments",
  type="RFC",
  number="815",
  pages="1--8",
  year=1982,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc815.txt",
  key="RFC 815",
  abstract={This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.},
  doi="10.17487/RFC0815",
  }

@misc{rfc816,
  author="D.D. Clark",
  title="{Fault isolation and recovery}",
  howpublished="RFC 816 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="816",
  pages="1--11",
  year=1982,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc816.txt",
  key="RFC 816",
  abstract={This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.},
  doi="10.17487/RFC0816",
  }

@misc{rfc817,
  author="D.D. Clark",
  title="{Modularity and efficiency in protocol implementation}",
  howpublished="RFC 817 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="817",
  pages="1--25",
  year=1982,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc817.txt",
  key="RFC 817",
  abstract={This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.},
  doi="10.17487/RFC0817",
  }

@misc{rfc818,
  author="J. Postel",
  title="{Remote User Telnet service}",
  howpublished="RFC 818 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="818",
  pages="1--2",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc818.txt",
  key="RFC 818",
  abstract={This RFC is the specification of an application protocol.  Any host that implements this application level service must follow this protocol.},
  keywords="RTELNET",
  doi="10.17487/RFC0818",
  }

@misc{rfc819,
  author="Z. Su and J. Postel",
  title="{The Domain Naming Convention for Internet User Applications}",
  howpublished="RFC 819",
  series="Internet Request for Comments",
  type="RFC",
  number="819",
  pages="1--18",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc819.txt",
  key="RFC 819",
  abstract={This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.},
  doi="10.17487/RFC0819",
  }

@misc{rfc820,
  author="J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 820 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="820",
  pages="1--22",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 870",
url="https://www.rfc-editor.org/rfc/rfc820.txt",
  key="RFC 820",
  abstract={This RFC is an old version, see RFC 870.},
  doi="10.17487/RFC0820",
  }

@misc{rfc821,
  author="J. Postel",
  title="{Simple Mail Transfer Protocol}",
  howpublished="RFC 821 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="821",
  pages="1--72",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2821",
url="https://www.rfc-editor.org/rfc/rfc821.txt",
  key="RFC 821",
  abstract={The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.  SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel.  Obsoletes RFC 788, 780, and 772.},
  keywords="SMTP",
  doi="10.17487/RFC0821",
  }

@misc{rfc822,
  author="D. Crocker",
  title="{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES}",
  howpublished="RFC 822 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="822",
  pages="1--49",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2822, updated by RFCs 1123, 2156, 1327, 1138, 1148",
url="https://www.rfc-editor.org/rfc/rfc822.txt",
  key="RFC 822",
  abstract={This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet.  Some of RFC 733's features failed to gain adequate acceptance.  In order to simplify the standard and the software that follows it, these features have been removed.  A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced.  Obsoletes RFC 733, NIC 41952.},
  keywords="MAIL",
  doi="10.17487/RFC0822",
  }

@misc{rfc823,
  author="R.M. Hinden and A. Sheltzer",
  title="{DARPA Internet gateway}",
  howpublished="RFC 823 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="823",
  pages="1--45",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc823.txt",
  key="RFC 823",
  abstract={This RFC is a status report on the Internet Gateway developed by BBN.  It describes the Internet Gateway as of September 1982.  This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.},
  keywords="GGP",
  doi="10.17487/RFC0823",
  }

@misc{rfc824,
  author="W.I. MacGregor and D.C. Tappan",
  title="{CRONUS Virtual Local Network}",
  howpublished="RFC 824",
  series="Internet Request for Comments",
  type="RFC",
  number="824",
  pages="1--41",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc824.txt",
  key="RFC 824",
  abstract={The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features.  These features include a method for mapping between Internet Addresses and Local Network addresses.  This is a topic of current concern in the ARPA Internet community.  This note is intended to stimulate discussion.  This is not a specification of an Internet Standard.},
  doi="10.17487/RFC0824",
  }

@misc{rfc825,
  author="J. Postel",
  title="{Request for comments on Requests For Comments}",
  howpublished="RFC 825",
  series="Internet Request for Comments",
  type="RFC",
  number="825",
  pages="1--2",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1111, 1543, 2223",
url="https://www.rfc-editor.org/rfc/rfc825.txt",
  key="RFC 825",
  abstract={This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future.  It is in a sense a specification for RFCs.},
  doi="10.17487/RFC0825",
  }

@misc{rfc826,
  author="D. Plummer",
  title="{Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware}",
  howpublished="RFC 826 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="826",
  pages="1--10",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5227, 5494",
url="https://www.rfc-editor.org/rfc/rfc826.txt",
  key="RFC 826",
  abstract={The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses).  This is an issue of general concern in the ARPA Internet Community at this time.  The method proposed here is presented for your consideration and comment.  This is not the specification of an Internet Standard.},
  keywords="ARP",
  doi="10.17487/RFC0826",
  }

@misc{rfc827,
  author="E.C. Rosen",
  title="{Exterior Gateway Protocol (EGP)}",
  howpublished="RFC 827",
  series="Internet Request for Comments",
  type="RFC",
  number="827",
  pages="1--46",
  year=1982,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 904",
url="https://www.rfc-editor.org/rfc/rfc827.txt",
  key="RFC 827",
  abstract={This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious.  This document is a DRAFT for that standard.  Your comments are strongly encouraged.},
  doi="10.17487/RFC0827",
  }

@misc{rfc828,
  author="K. Owen",
  title="{Data communications: IFIP's international ``network'' of experts}",
  howpublished="RFC 828",
  series="Internet Request for Comments",
  type="RFC",
  number="828",
  pages="1--11",
  year=1982,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc828.txt",
  key="RFC 828",
  abstract={This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.},
  doi="10.17487/RFC0828",
  }

@misc{rfc829,
  author="V.G. Cerf",
  title="{Packet satellite technology reference sources}",
  howpublished="RFC 829",
  series="Internet Request for Comments",
  type="RFC",
  number="829",
  pages="1--5",
  year=1982,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc829.txt",
  key="RFC 829",
  abstract={This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K.  and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.},
  doi="10.17487/RFC0829",
  }

@misc{rfc830,
  author="Z. Su",
  title="{Distributed system for Internet name service}",
  howpublished="RFC 830",
  series="Internet Request for Comments",
  type="RFC",
  number="830",
  pages="1--18",
  year=1982,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc830.txt",
  key="RFC 830",
  abstract={This RFC proposes a distributed name service for DARPA Internet.  Its purpose is to focus discussion on the subject.  It is hoped that a general consensus will emerge leading eventually to the adoption of standards.},
  doi="10.17487/RFC0830",
  }

@misc{rfc831,
  author="R.T. Braden",
  title="{Backup access to the European side of SATNET}",
  howpublished="RFC 831",
  series="Internet Request for Comments",
  type="RFC",
  number="831",
  pages="1--6",
  year=1982,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc831.txt",
  key="RFC 831",
  abstract={The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned.  We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL.  This proposal is not intended as a standard at this time.},
  doi="10.17487/RFC0831",
  }

@misc{rfc832,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 832",
  series="Internet Request for Comments",
  type="RFC",
  number="832",
  pages="1--13",
  year=1982,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 833",
url="https://www.rfc-editor.org/rfc/rfc832.txt",
  key="RFC 832",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 2-Dec-82.  The tests were run on 7-Dec-82.},
  doi="10.17487/RFC0832",
  }

@misc{rfc833,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 833",
  series="Internet Request for Comments",
  type="RFC",
  number="833",
  pages="1--13",
  year=1982,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 834",
url="https://www.rfc-editor.org/rfc/rfc833.txt",
  key="RFC 833",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 2-Dec-82.  The tests were run on 14-Dec-82.},
  doi="10.17487/RFC0833",
  }

@misc{rfc834,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 834",
  series="Internet Request for Comments",
  type="RFC",
  number="834",
  pages="1--13",
  year=1982,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 835",
url="https://www.rfc-editor.org/rfc/rfc834.txt",
  key="RFC 834",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 2-Dec-82.  The tests were run on 22-Dec-82.},
  doi="10.17487/RFC0834",
  }

@misc{rfc835,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 835",
  series="Internet Request for Comments",
  type="RFC",
  number="835",
  pages="1--13",
  year=1982,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 836",
url="https://www.rfc-editor.org/rfc/rfc835.txt",
  key="RFC 835",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 2-Dec-82.  The tests were run on 28-Dec-82 through 5-Jan-83.},
  doi="10.17487/RFC0835",
  }

@misc{rfc836,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 836",
  series="Internet Request for Comments",
  type="RFC",
  number="836",
  pages="1--13",
  year=1983,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 837",
url="https://www.rfc-editor.org/rfc/rfc836.txt",
  key="RFC 836",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 20-Dec-82.  The tests were run on 4-Jan-83 through 5-Jan-83.},
  doi="10.17487/RFC0836",
  }

@misc{rfc837,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 837",
  series="Internet Request for Comments",
  type="RFC",
  number="837",
  pages="1--13",
  year=1983,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 838",
url="https://www.rfc-editor.org/rfc/rfc837.txt",
  key="RFC 837",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 31-Dec-82.  The tests were run on 11-Jan-83.},
  doi="10.17487/RFC0837",
  }

@misc{rfc838,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 838",
  series="Internet Request for Comments",
  type="RFC",
  number="838",
  pages="1--13",
  year=1983,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 839",
url="https://www.rfc-editor.org/rfc/rfc838.txt",
  key="RFC 838",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 31-Dec-82.  The tests were run on 18-Jan-83.},
  doi="10.17487/RFC0838",
  }

@misc{rfc839,
  author="D. Smallberg",
  title="{Who talks TCP?}",
  howpublished="RFC 839",
  series="Internet Request for Comments",
  type="RFC",
  number="839",
  pages="1--14",
  year=1983,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 842",
url="https://www.rfc-editor.org/rfc/rfc839.txt",
  key="RFC 839",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 31-Dec-82.  The tests were run on 25-Jan-83.},
  doi="10.17487/RFC0839",
  }

@misc{rfc840,
  author="J. Postel",
  title="{Official protocols}",
  howpublished="RFC 840 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="840",
  pages="1--23",
  year=1983,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 880",
url="https://www.rfc-editor.org/rfc/rfc840.txt",
  key="RFC 840",
  abstract={This RFC has been revised, see RFC 880.},
  doi="10.17487/RFC0840",
  }

@misc{rfc841,
  author="National Bureau of Standards",
  title="{Specification for message format for Computer Based Message Systems}",
  howpublished="RFC 841",
  series="Internet Request for Comments",
  type="RFC",
  number="841",
  pages="1--117",
  year=1983,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc841.txt",
  key="RFC 841",
  abstract={This RFC is FIPS 98.  The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community.  This RFC does not specify a standard for the ARPA Internet.  Obsoletes RFC 806.},
  doi="10.17487/RFC0841",
  }

@misc{rfc842,
  author="D. Smallberg",
  title="{Who talks TCP? - survey of 1 February 83}",
  howpublished="RFC 842",
  series="Internet Request for Comments",
  type="RFC",
  number="842",
  pages="1--12",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 843",
url="https://www.rfc-editor.org/rfc/rfc842.txt",
  key="RFC 842",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 28-Jan-83.  The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.},
  doi="10.17487/RFC0842",
  }

@misc{rfc843,
  author="D. Smallberg",
  title="{Who talks TCP? - survey of 8 February 83}",
  howpublished="RFC 843",
  series="Internet Request for Comments",
  type="RFC",
  number="843",
  pages="1--13",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 845, updated by RFC 844",
url="https://www.rfc-editor.org/rfc/rfc843.txt",
  key="RFC 843",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 3-Feb-83.  The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.},
  doi="10.17487/RFC0843",
  }

@misc{rfc844,
  author="R. Clements",
  title="{Who talks ICMP, too? - Survey of 18 February 1983}",
  howpublished="RFC 844",
  series="Internet Request for Comments",
  type="RFC",
  number="844",
  pages="1--5",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc844.txt",
  key="RFC 844",
  abstract={This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site.  This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses.  The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection.  The tests were run on 18-Feb-83.},
  doi="10.17487/RFC0844",
  }

@misc{rfc845,
  author="D. Smallberg",
  title="{Who talks TCP? - survey of 15 February 1983}",
  howpublished="RFC 845",
  series="Internet Request for Comments",
  type="RFC",
  number="845",
  pages="1--14",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 846",
url="https://www.rfc-editor.org/rfc/rfc845.txt",
  key="RFC 845",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 3-Feb-83.  The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.},
  doi="10.17487/RFC0845",
  }

@misc{rfc846,
  author="D. Smallberg",
  title="{Who talks TCP? - survey of 22 February 1983}",
  howpublished="RFC 846",
  series="Internet Request for Comments",
  type="RFC",
  number="846",
  pages="1--14",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 847",
url="https://www.rfc-editor.org/rfc/rfc846.txt",
  key="RFC 846",
  abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from the NIC hostname table of 18-Feb-83.  The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.},
  doi="10.17487/RFC0846",
  }

@misc{rfc847,
  author="A. Westine and D. Smallberg and J. Postel",
  title="{Summary of Smallberg surveys}",
  howpublished="RFC 847",
  series="Internet Request for Comments",
  type="RFC",
  number="847",
  pages="1--2",
  year=1983,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc847.txt",
  key="RFC 847",
  abstract={This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846.  This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).},
  doi="10.17487/RFC0847",
  }

@misc{rfc848,
  author="D. Smallberg",
  title="{Who provides the ``little'' TCP services?}",
  howpublished="RFC 848",
  series="Internet Request for Comments",
  type="RFC",
  number="848",
  pages="1--5",
  year=1983,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc848.txt",
  key="RFC 848",
  abstract={This RFC lists those hosts which provide any of these ``little'' TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83.  The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.},
  doi="10.17487/RFC0848",
  }

@misc{rfc849,
  author="M.R. Crispin",
  title="{Suggestions for improved host table distribution}",
  howpublished="RFC 849",
  series="Internet Request for Comments",
  type="RFC",
  number="849",
  pages="1--2",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc849.txt",
  key="RFC 849",
  abstract={This RFC actually is a request for comments.  The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future.  None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.},
  doi="10.17487/RFC0849",
  }

@misc{rfc850,
  author="M.R. Horton",
  title="{Standard for interchange of USENET messages}",
  howpublished="RFC 850",
  series="Internet Request for Comments",
  type="RFC",
  number="850",
  pages="1--17",
  year=1983,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1036",
url="https://www.rfc-editor.org/rfc/rfc850.txt",
  key="RFC 850",
  abstract={This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community.  It does not specify an Internet standard.  This RFC defines the standard format for interchange of Network News articles among USENET sites.  It describes the format for articles themselves, and gives partial standards for transmission of news.  The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.},
  doi="10.17487/RFC0850",
  }

@misc{rfc851,
  author="A.G. Malis",
  title="{ARPANET 1822L Host Access Protocol}",
  howpublished="RFC 851",
  series="Internet Request for Comments",
  type="RFC",
  number="851",
  pages="1--47",
  year=1983,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 878",
url="https://www.rfc-editor.org/rfc/rfc851.txt",
  key="RFC 851",
  abstract={This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol.  1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other.  This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers.  Obsoletes RFC 802.},
  doi="10.17487/RFC0851",
  }

@misc{rfc852,
  author="A.G. Malis",
  title="{ARPANET short blocking feature}",
  howpublished="RFC 852",
  series="Internet Request for Comments",
  type="RFC",
  number="852",
  pages="1--13",
  year=1983,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc852.txt",
  key="RFC 852",
  abstract={This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer.  This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol.  This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.},
  doi="10.17487/RFC0852",
  }

@misc{rfc854,
  author="J. Postel and J.K. Reynolds",
  title="{Telnet Protocol Specification}",
  howpublished="RFC 854 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="854",
  pages="1--15",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5198",
url="https://www.rfc-editor.org/rfc/rfc854.txt",
  key="RFC 854",
  abstract={This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet.  The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility.  Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other.  It is envisioned that the protocol may also be used for terminal-terminal communication (``linking'') and process-process communication (distributed computation).  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 18639.},
  keywords="TELNET",
  doi="10.17487/RFC0854",
  }

@misc{rfc855,
  author="J. Postel and J.K. Reynolds",
  title="{Telnet Option Specifications}",
  howpublished="RFC 855 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="855",
  pages="1--3",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc855.txt",
  key="RFC 855",
  abstract={This memo specifies the general form for Telnet options and the directions for their specification.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes RFC 651, NIC 18640.},
  keywords="TELNET",
  doi="10.17487/RFC0855",
  }

@misc{rfc856,
  author="J. Postel and J. Reynolds",
  title="{Telnet Binary Transmission}",
  howpublished="RFC 856 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="856",
  pages="1--4",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc856.txt",
  key="RFC 856",
  abstract={This Telnet Option enables a binary data mode between the Telnet modules.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 15389.},
  keywords="TOPT-BIN",
  doi="10.17487/RFC0856",
  }

@misc{rfc857,
  author="J. Postel and J. Reynolds",
  title="{Telnet Echo Option}",
  howpublished="RFC 857 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="857",
  pages="1--5",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc857.txt",
  key="RFC 857",
  abstract={This Telnet Option enables remote echoing by the other Telnet module.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 15390.},
  keywords="TOPT-ECHO",
  doi="10.17487/RFC0857",
  }

@misc{rfc858,
  author="J. Postel and J. Reynolds",
  title="{Telnet Suppress Go Ahead Option}",
  howpublished="RFC 858 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="858",
  pages="1--2",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc858.txt",
  key="RFC 858",
  abstract={This Telnet Option disables the exchange of go-ahead signals between the Telnet modules.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 15392.},
  keywords="TOPT-SUPP",
  doi="10.17487/RFC0858",
  }

@misc{rfc859,
  author="J. Postel and J. Reynolds",
  title="{Telnet Status Option}",
  howpublished="RFC 859 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="859",
  pages="1--3",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc859.txt",
  key="RFC 859",
  abstract={This Telnet Option provides a way to determine the other Telnet module's view of the status of options.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes RFC 651 (NIC 31154).},
  keywords="TOPT-STAT",
  doi="10.17487/RFC0859",
  }

@misc{rfc860,
  author="J. Postel and J. Reynolds",
  title="{Telnet Timing Mark Option}",
  howpublished="RFC 860 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="860",
  pages="1--4",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc860.txt",
  key="RFC 860",
  abstract={This Telnet Option provides a way to check the roundtrip path between two Telnet modules.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 16238.},
  keywords="TOPT-TIM",
  doi="10.17487/RFC0860",
  }

@misc{rfc861,
  author="J. Postel and J. Reynolds",
  title="{Telnet Extended Options: List Option}",
  howpublished="RFC 861 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="861",
  pages="1--2",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc861.txt",
  key="RFC 861",
  abstract={This Telnet Option provides a mechanism for extending the set of possible options.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.  Obsoletes NIC 16239.},
  keywords="TOPT-EXTOP",
  doi="10.17487/RFC0861",
  }

@misc{rfc862,
  author="J. Postel",
  title="{Echo Protocol}",
  howpublished="RFC 862 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="862",
  pages="1--1",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc862.txt",
  key="RFC 862",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard.  The Echo service simply sends back to the originating source any data it receives.},
  keywords="ECHO",
  doi="10.17487/RFC0862",
  }

@misc{rfc863,
  author="J. Postel",
  title="{Discard Protocol}",
  howpublished="RFC 863 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="863",
  pages="1--1",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc863.txt",
  key="RFC 863",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard.  The Discard service simply throws away any data it receives.},
  keywords="DISCARD",
  doi="10.17487/RFC0863",
  }

@misc{rfc864,
  author="J. Postel",
  title="{Character Generator Protocol}",
  howpublished="RFC 864 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="864",
  pages="1--3",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc864.txt",
  key="RFC 864",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard.  The Character Generator service simply sends data without regard to the input.},
  keywords="CHARGEN",
  doi="10.17487/RFC0864",
  }

@misc{rfc865,
  author="J. Postel",
  title="{Quote of the Day Protocol}",
  howpublished="RFC 865 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="865",
  pages="1--1",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc865.txt",
  key="RFC 865",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard.  The Quote of the Day service simply sends a short message without regard to the input.},
  keywords="QUOTE",
  doi="10.17487/RFC0865",
  }

@misc{rfc866,
  author="J. Postel",
  title="{Active users}",
  howpublished="RFC 866 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="866",
  pages="1--1",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc866.txt",
  key="RFC 866",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard.  The Active Users service simply sends a list of the currently active users on the host without regard to the input.},
  keywords="USERS",
  doi="10.17487/RFC0866",
  }

@misc{rfc867,
  author="J. Postel",
  title="{Daytime Protocol}",
  howpublished="RFC 867 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="867",
  pages="1--2",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc867.txt",
  key="RFC 867",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard.  The Daytime service simply sends the current date and time as a character string without regard to the input.},
  keywords="DAYTIME",
  doi="10.17487/RFC0867",
  }

@misc{rfc868,
  author="J. Postel and K. Harrenstien",
  title="{Time Protocol}",
  howpublished="RFC 868 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="868",
  pages="1--2",
  year=1983,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc868.txt",
  key="RFC 868",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard.  This protocol provides a site-independent, machine readable date and time.  The Time service sends back to the originating source the time in seconds since midnight on January first 1900.},
  keywords="TIME",
  doi="10.17487/RFC0868",
  }

@misc{rfc869,
  author="R. Hinden",
  title="{Host Monitoring Protocol}",
  howpublished="RFC 869 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="869",
  pages="1--72",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc869.txt",
  key="RFC 869",
  abstract={This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet.  Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.},
  keywords="HMP, HMP",
  doi="10.17487/RFC0869",
  }

@misc{rfc870,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 870 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="870",
  pages="1--26",
  year=1983,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 900",
url="https://www.rfc-editor.org/rfc/rfc870.txt",
  key="RFC 870",
  abstract={This RFC documents the list of numbers assigned for networks, protocols, etc.  Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.},
  doi="10.17487/RFC0870",
  }

@misc{rfc871,
  author="M.A. Padlipsky",
  title="{Perspective on the ARPANET reference model}",
  howpublished="RFC 871",
  series="Internet Request for Comments",
  type="RFC",
  number="871",
  pages="1--29",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc871.txt",
  key="RFC 871",
  abstract={This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years.  Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.},
  doi="10.17487/RFC0871",
  }

@misc{rfc872,
  author="M.A. Padlipsky",
  title="{TCP-on-a-LAN}",
  howpublished="RFC 872 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="872",
  pages="1--10",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc872.txt",
  key="RFC 872",
  abstract={This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network.  Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.},
  keywords="TCP LAN",
  doi="10.17487/RFC0872",
  }

@misc{rfc873,
  author="M.A. Padlipsky",
  title="{Illusion of vendor support}",
  howpublished="RFC 873",
  series="Internet Request for Comments",
  type="RFC",
  number="873",
  pages="1--12",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc873.txt",
  key="RFC 873",
  abstract={This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations.  Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.},
  doi="10.17487/RFC0873",
  }

@misc{rfc874,
  author="M.A. Padlipsky",
  title="{Critique of X.25}",
  howpublished="RFC 874",
  series="Internet Request for Comments",
  type="RFC",
  number="874",
  pages="1--17",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc874.txt",
  key="RFC 874",
  abstract={This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects.  The memo also touches on security, and implementation issues.  Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.},
  doi="10.17487/RFC0874",
  }

@misc{rfc875,
  author="M.A. Padlipsky",
  title="{Gateways, architectures, and heffalumps}",
  howpublished="RFC 875",
  series="Internet Request for Comments",
  type="RFC",
  number="875",
  pages="1--10",
  year=1982,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc875.txt",
  key="RFC 875",
  abstract={This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites.  The discussion notes possible functionality mis-matches, undesirable routing ``singularity points'', flow control issues, and high cost of translating gateways.  Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.},
  doi="10.17487/RFC0875",
  }

@misc{rfc876,
  author="D. Smallberg",
  title="{Survey of SMTP implementations}",
  howpublished="RFC 876",
  series="Internet Request for Comments",
  type="RFC",
  number="876",
  pages="1--13",
  year=1983,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc876.txt",
  key="RFC 876",
  abstract={This RFC is a survey of implementation status.  It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol.  It is expected that the status of the hosts reported on will change.  This information must be treated as a snapshot of the state of these implemetations.},
  doi="10.17487/RFC0876",
  }

@misc{rfc877,
  author="J.T. Korb",
  title="{Standard for the transmission of IP datagrams over public data networks}",
  howpublished="RFC 877",
  series="Internet Request for Comments",
  type="RFC",
  number="877",
  pages="1--2",
  year=1983,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1356",
url="https://www.rfc-editor.org/rfc/rfc877.txt",
  key="RFC 877",
  abstract={This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.},
  doi="10.17487/RFC0877",
  }

@misc{rfc878,
  author="A.G. Malis",
  title="{ARPANET 1822L Host Access Protocol}",
  howpublished="RFC 878",
  series="Internet Request for Comments",
  type="RFC",
  number="878",
  pages="1--51",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc878.txt",
  key="RFC 878",
  abstract={This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol.  The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.},
  doi="10.17487/RFC0878",
  }

@misc{rfc879,
  author="J. Postel",
  title="{The TCP Maximum Segment Size and Related Topics}",
  howpublished="RFC 879 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="879",
  pages="1--11",
  year=1983,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805, updated by RFC 6691",
url="https://www.rfc-editor.org/rfc/rfc879.txt",
  key="RFC 879",
  abstract={This RFC discusses the TCP Maximum Segment Size Option and related topics.  The purposes is to clarify some aspects of TCP and its interaction with IP.  This memo is a clarification to the TCP specification, and contains information that may be considered as ``advice to implementers''.},
  doi="10.17487/RFC0879",
  }

@misc{rfc880,
  author="J.K. Reynolds and J. Postel",
  title="{Official protocols}",
  howpublished="RFC 880 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="880",
  pages="1--26",
  year=1983,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 901",
url="https://www.rfc-editor.org/rfc/rfc880.txt",
  key="RFC 880",
  abstract={This RFC identifies the documents specifying the official protocols used in the ARPA Internet.  Annotations identify any revisions or changes planned.  Obsoletes RFC 840.},
  doi="10.17487/RFC0880",
  }

@misc{rfc881,
  author="J. Postel",
  title="{Domain names plan and schedule}",
  howpublished="RFC 881",
  series="Internet Request for Comments",
  type="RFC",
  number="881",
  pages="1--10",
  year=1983,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 897",
url="https://www.rfc-editor.org/rfc/rfc881.txt",
  key="RFC 881",
  abstract={This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community.  The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.},
  doi="10.17487/RFC0881",
  }

@misc{rfc882,
  author="P.V. Mockapetris",
  title="{Domain names: Concepts and facilities}",
  howpublished="RFC 882",
  series="Internet Request for Comments",
  type="RFC",
  number="882",
  pages="1--31",
  year=1983,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1034, 1035, updated by RFC 973",
url="https://www.rfc-editor.org/rfc/rfc882.txt",
  key="RFC 882",
  abstract={This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.},
  doi="10.17487/RFC0882",
  }

@misc{rfc883,
  author="P.V. Mockapetris",
  title="{Domain names: Implementation specification}",
  howpublished="RFC 883",
  series="Internet Request for Comments",
  type="RFC",
  number="883",
  pages="1--74",
  year=1983,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1034, 1035, updated by RFC 973",
url="https://www.rfc-editor.org/rfc/rfc883.txt",
  key="RFC 883",
  abstract={This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.},
  doi="10.17487/RFC0883",
  }

@misc{rfc884,
  author="M. Solomon and E. Wimmers",
  title="{Telnet terminal type option}",
  howpublished="RFC 884",
  series="Internet Request for Comments",
  type="RFC",
  number="884",
  pages="1--5",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 930",
url="https://www.rfc-editor.org/rfc/rfc884.txt",
  key="RFC 884",
  abstract={This RFC specifies a standard for the ARPA Internet community.  It specifies a method for exchanging terminal type information in the Telnet protocol.},
  doi="10.17487/RFC0884",
  }

@misc{rfc885,
  author="J. Postel",
  title="{Telnet end of record option}",
  howpublished="RFC 885 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="885",
  pages="1--2",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc885.txt",
  key="RFC 885",
  abstract={This RFC specifies a standard for the ARPA Internet community.  It specifies a method for marking the end of records in data transmitted on Telnet connections.},
  keywords="TOPT-EOR",
  doi="10.17487/RFC0885",
  }

@misc{rfc886,
  author="M.T. Rose",
  title="{Proposed standard for message header munging}",
  howpublished="RFC 886",
  series="Internet Request for Comments",
  type="RFC",
  number="886",
  pages="1--16",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc886.txt",
  key="RFC 886",
  abstract={This RFC specifies a draft standard for the ARPA Internet community.  It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system.  In particular, the treatment of header fields, and recipient addresses is specified.},
  doi="10.17487/RFC0886",
  }

@misc{rfc887,
  author="M. Accetta",
  title="{Resource Location Protocol}",
  howpublished="RFC 887 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="887",
  pages="1--16",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc887.txt",
  key="RFC 887",
  abstract={This RFC specifies a draft standard for the ARPA Internet community.  It describes a resource location protocol for use in the ARPA Internet.  It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks.  For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol.  Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.},
  keywords="RLP",
  doi="10.17487/RFC0887",
  }

@misc{rfc888,
  author="L. Seamonson and E.C. Rosen",
  title="{``STUB'' Exterior Gateway Protocol}",
  howpublished="RFC 888",
  series="Internet Request for Comments",
  type="RFC",
  number="888",
  pages="1--39",
  year=1984,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 904",
url="https://www.rfc-editor.org/rfc/rfc888.txt",
  key="RFC 888",
  abstract={This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways.  This document specifies the working protocol, and defines an ARPA official protocol.  All implementers of Gateways should carefully review this document.},
  doi="10.17487/RFC0888",
  }

@misc{rfc889,
  author="D.L. Mills",
  title="{Internet Delay Experiments}",
  howpublished="RFC 889 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="889",
  pages="1--12",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc889.txt",
  key="RFC 889",
  abstract={This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation.  This memo is both a status report on the Internet and advice to TCP implementers.},
  doi="10.17487/RFC0889",
  }

@misc{rfc890,
  author="J. Postel",
  title="{Exterior Gateway Protocol implementation schedule}",
  howpublished="RFC 890",
  series="Internet Request for Comments",
  type="RFC",
  number="890",
  pages="1--3",
  year=1984,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc890.txt",
  key="RFC 890",
  abstract={This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet.  This is an official policy statement of ICCB and DARPA.  After 1-Aug-84 there shall be no dumb gateways in the Internet.  Every gateway must be a member of some autonomous system.  Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.},
  keywords="EGP",
  doi="10.17487/RFC0890",
  }

@misc{rfc891,
  author="D.L. Mills",
  title="{DCN Local-Network Protocols}",
  howpublished="RFC 891 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="891",
  pages="1--26",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc891.txt",
  key="RFC 891",
  abstract={This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network.  These procedures may be of interest to the designers and implementers of other local networks.},
  keywords="IP-DC",
  doi="10.17487/RFC0891",
  }

@misc{rfc892,
  author="International Organization for Standardization",
  title="{ISO Transport Protocol specification}",
  howpublished="RFC 892",
  series="Internet Request for Comments",
  type="RFC",
  number="892",
  pages="1--82",
  year=1983,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 905",
url="https://www.rfc-editor.org/rfc/rfc892.txt",
  key="RFC 892",
  abstract={This is a draft version of the transport protocol being standardized by the ISO.  This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982.  This version is now out of date.},
  doi="10.17487/RFC0892",
  }

@misc{rfc893,
  author="S. Leffler and M.J. Karels",
  title="{Trailer encapsulations}",
  howpublished="RFC 893",
  series="Internet Request for Comments",
  type="RFC",
  number="893",
  pages="1--6",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc893.txt",
  key="RFC 893",
  abstract={This RFC discusses the motivation for use of ``trailer encapsulations'' on local-area networks and describes the implementation of such an encapsulation on various media.  This document is for information only.  This is NOT an official protocol for the ARPA Internet community.},
  doi="10.17487/RFC0893",
  }

@misc{rfc894,
  author="C. Hornig",
  title="{A Standard for the Transmission of IP Datagrams over Ethernet Networks}",
  howpublished="RFC 894 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="894",
  pages="1--3",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc894.txt",
  key="RFC 894",
  abstract={This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet.  This RFC specifies a standard protocol for the ARPA-Internet community.},
  keywords="IP-E",
  doi="10.17487/RFC0894",
  }

@misc{rfc895,
  author="J. Postel",
  title="{Standard for the transmission of IP datagrams over experimental Ethernet networks}",
  howpublished="RFC 895 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="895",
  pages="1--3",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc895.txt",
  key="RFC 895",
  abstract={This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet.  This RFC specifies a standard protocol for the ARPA Internet community.},
  keywords="IP-EE",
  doi="10.17487/RFC0895",
  }

@misc{rfc896,
  author="J. Nagle",
  title="{Congestion Control in IP/TCP Internetworks}",
  howpublished="RFC 896 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="896",
  pages="1--9",
  year=1984,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc896.txt",
  key="RFC 896",
  abstract={This memo discusses some aspects of congestion control in IP/TCP Internetworks.  It is intended to stimulate thought and further discussion of this topic.  While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.},
  doi="10.17487/RFC0896",
  }

@misc{rfc897,
  author="J. Postel",
  title="{Domain name system implementation schedule}",
  howpublished="RFC 897",
  series="Internet Request for Comments",
  type="RFC",
  number="897",
  pages="1--8",
  year=1984,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 921",
url="https://www.rfc-editor.org/rfc/rfc897.txt",
  key="RFC 897",
  abstract={This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet.  This memo is a partial update of RFC 881.  The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System.  The names of hosts will be changed to domain style names.  Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84.  This applies to both the ARPA research hosts and the DDN operational hosts.  This is an official policy statement of the ICCB and the DARPA.},
  doi="10.17487/RFC0897",
  }

@misc{rfc898,
  author="R.M. Hinden and J. Postel and M. Muuss and J.K. Reynolds",
  title="{Gateway special interest group meeting notes}",
  howpublished="RFC 898",
  series="Internet Request for Comments",
  type="RFC",
  number="898",
  pages="1--24",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc898.txt",
  key="RFC 898",
  abstract={This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984.  Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting.  Approximately 35 gateway designers and implementors attended.  These notes are based on the recollections of Jon Postel and Mike Muuss.  Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss.  This memo is a report on a meeting.  No conclusions, decisions, or policy statements are documented in this note.},
  doi="10.17487/RFC0898",
  }

@misc{rfc899,
  author="J. Postel and A. Westine",
  title="{Request For Comments summary notes: 800-899}",
  howpublished="RFC 899 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="899",
  pages="1--18",
  year=1984,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc899.txt",
  key="RFC 899",
  doi="10.17487/RFC0899",
  }

@misc{rfc900,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned Numbers}",
  howpublished="RFC 900 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="900",
  pages="1--43",
  year=1984,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 923",
url="https://www.rfc-editor.org/rfc/rfc900.txt",
  key="RFC 900",
  abstract={This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers.  This memo is an official status report on the protocol parameters used in the Internet protocol system.  See RFC-990 and 997.},
  doi="10.17487/RFC0900",
  }

@misc{rfc901,
  author="J.K. Reynolds and J. Postel",
  title="{Official ARPA-Internet protocols}",
  howpublished="RFC 901",
  series="Internet Request for Comments",
  type="RFC",
  number="901",
  pages="1--28",
  year=1984,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 924",
url="https://www.rfc-editor.org/rfc/rfc901.txt",
  key="RFC 901",
  abstract={This RFC identifies the documents specifying the official protocols used in the ARPA-Internet.  Annotations identify any revisions or changes planned.  This memo is an official status report on the protocols used in the DARPA research community.  See RFC-991.},
  doi="10.17487/RFC0901",
  }

@misc{rfc902,
  author="J.K. Reynolds and J. Postel",
  title="{ARPA Internet Protocol policy}",
  howpublished="RFC 902",
  series="Internet Request for Comments",
  type="RFC",
  number="902",
  pages="1--5",
  year=1984,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc902.txt",
  key="RFC 902",
  abstract={The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community.  There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community.  This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community.  This is an official policy statement of the ICCB and the DARPA.},
  doi="10.17487/RFC0902",
  }

@misc{rfc903,
  author="R. Finlayson and T. Mann and J.C. Mogul and M. Theimer",
  title="{A Reverse Address Resolution Protocol}",
  howpublished="RFC 903 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="903",
  pages="1--4",
  year=1984,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc903.txt",
  key="RFC 903",
  abstract={This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address).  This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.},
  keywords="RARP",
  doi="10.17487/RFC0903",
  }

@misc{rfc904,
  author="D.L. Mills",
  title="{Exterior Gateway Protocol formal specification}",
  howpublished="RFC 904 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="904",
  pages="1--30",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc904.txt",
  key="RFC 904",
  abstract={RFC-904 is the specification of the Exterior Gateway Protocol (EGP).  This memo updates portions of RFC-888 and RFC-827.  This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.},
  keywords="EGP",
  doi="10.17487/RFC0904",
  }

@misc{rfc905,
  author="ISO",
  title="{ISO Transport Protocol specification ISO DP 8073}",
  howpublished="RFC 905",
  series="Internet Request for Comments",
  type="RFC",
  number="905",
  pages="1--164",
  year=1984,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc905.txt",
  key="RFC 905",
  abstract={This is the current specification of the ISO Transport Protocol.  This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695.  This is the specification currently being voted on in ISO as a Draft International Standard (DIS).  This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community.  Our thanks to Alex McKenzie of BBN for making this online version available.  Please note the size of this document, the file contains 258,729 characters.},
  doi="10.17487/RFC0905",
  }

@misc{rfc906,
  author="R. Finlayson",
  title="{Bootstrap loading using TFTP}",
  howpublished="RFC 906",
  series="Internet Request for Comments",
  type="RFC",
  number="906",
  pages="1--4",
  year=1984,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc906.txt",
  key="RFC 906",
  abstract={It is often convenient to be able to bootstrap a computer system from a communications network.  This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.},
  doi="10.17487/RFC0906",
  }

@misc{rfc907,
  author="Bolt Beranek and Newman Laboratories",
  title="{Host Access Protocol specification}",
  howpublished="RFC 907 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="907",
  pages="1--75",
  year=1984,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1221",
url="https://www.rfc-editor.org/rfc/rfc907.txt",
  key="RFC 907",
  abstract={This document specifies the Host Access Protocol (HAP).  Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network.  HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported.  Implementations of HAP should be performed in coordination with satellite network development and operations personnel.},
  keywords="IP-WB",
  doi="10.17487/RFC0907",
  }

@misc{rfc908,
  author="D. Velten and R.M. Hinden and J. Sax",
  title="{Reliable Data Protocol}",
  howpublished="RFC 908 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="908",
  pages="1--62",
  year=1984,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1151",
url="https://www.rfc-editor.org/rfc/rfc908.txt",
  key="RFC 908",
  abstract={The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications.  This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.},
  keywords="RDP",
  doi="10.17487/RFC0908",
  }

@misc{rfc909,
  author="C. Welles and W. Milliken",
  title="{Loader Debugger Protocol}",
  howpublished="RFC 909 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="909",
  pages="1--135",
  year=1984,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc909.txt",
  key="RFC 909",
  abstract={The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment.  This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.},
  keywords="LDP",
  doi="10.17487/RFC0909",
  }

@misc{rfc910,
  author="H.C. Forsdick",
  title="{Multimedia mail meeting notes}",
  howpublished="RFC 910",
  series="Internet Request for Comments",
  type="RFC",
  number="910",
  pages="1--11",
  year=1984,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc910.txt",
  key="RFC 910",
  abstract={This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment).  The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems.  Representatives were present from BBN, ISI, SRI and Linkabit.},
  doi="10.17487/RFC0910",
  }

@misc{rfc911,
  author="P. Kirton",
  title="{EGP Gateway under Berkeley UNIX 4.2}",
  howpublished="RFC 911",
  series="Internet Request for Comments",
  type="RFC",
  number="911",
  pages="1--23",
  year=1984,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc911.txt",
  key="RFC 911",
  abstract={This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report).  The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).},
  doi="10.17487/RFC0911",
  }

@misc{rfc912,
  author="M. St. Johns",
  title="{Authentication service}",
  howpublished="RFC 912",
  series="Internet Request for Comments",
  type="RFC",
  number="912",
  pages="1--3",
  year=1984,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 931",
url="https://www.rfc-editor.org/rfc/rfc912.txt",
  key="RFC 912",
  abstract={This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection.  Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system.  Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.},
  doi="10.17487/RFC0912",
  }

@misc{rfc913,
  author="M. Lottor",
  title="{Simple File Transfer Protocol}",
  howpublished="RFC 913 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="913",
  pages="1--15",
  year=1984,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc913.txt",
  key="RFC 913",
  abstract={This memo describes a proposed Simple File Transfer Protocol (SFTP).  It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP.  SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting.  Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.},
  keywords="SFTP, FTP",
  doi="10.17487/RFC0913",
  }

@misc{rfc914,
  author="D.J. Farber and G. Delp and T.M. Conte",
  title="{Thinwire protocol for connecting personal computers to the Internet}",
  howpublished="RFC 914 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="914",
  pages="1--22",
  year=1984,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc914.txt",
  key="RFC 914",
  abstract={This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution.  None of the proposed solutions in this document are intended as standards for the ARPA-Internet.  Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.},
  keywords="THINWIRE",
  doi="10.17487/RFC0914",
  }

@misc{rfc915,
  author="M.A. Elvy and R. Nedved",
  title="{Network mail path service}",
  howpublished="RFC 915",
  series="Internet Request for Comments",
  type="RFC",
  number="915",
  pages="1--11",
  year=1984,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc915.txt",
  key="RFC 915",
  abstract={This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements.  The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc.  Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.},
  doi="10.17487/RFC0915",
  }

@misc{rfc916,
  author="G.G. Finn",
  title="{Reliable Asynchronous Transfer Protocol (RATP)}",
  howpublished="RFC 916 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="916",
  pages="1--54",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc916.txt",
  key="RFC 916",
  abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.  This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link.  It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered.  The protocol, named RATP, is designed to operate over a full duplex point-to-point connection.  It contains some features which tailor it to the RS-232 links now in common use.},
  keywords="RATP",
  doi="10.17487/RFC0916",
  }

@misc{rfc917,
  author="J.C. Mogul",
  title="{Internet subnets}",
  howpublished="RFC 917",
  series="Internet Request for Comments",
  type="RFC",
  number="917",
  pages="1--22",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc917.txt",
  key="RFC 917",
  abstract={This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing.  A subnet of an Internet network is a logically visible sub-section of a single Internet network.  For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0917",
  }

@misc{rfc918,
  author="J.K. Reynolds",
  title="{Post Office Protocol}",
  howpublished="RFC 918",
  series="Internet Request for Comments",
  type="RFC",
  number="918",
  pages="1--5",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 937",
url="https://www.rfc-editor.org/rfc/rfc918.txt",
  key="RFC 918",
  abstract={This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server.  The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server.  It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP).  This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement.  The status of this protocol is experimental, and this protocol is dependent upon TCP.},
  doi="10.17487/RFC0918",
  }

@misc{rfc919,
  author="J.C. Mogul",
  title="{Broadcasting Internet Datagrams}",
  howpublished="RFC 919 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="919",
  pages="1--8",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc919.txt",
  key="RFC 919",
  abstract={This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC0919",
  }

@misc{rfc920,
  author="J. Postel and J.K. Reynolds",
  title="{Domain requirements}",
  howpublished="RFC 920",
  series="Internet Request for Comments",
  type="RFC",
  number="920",
  pages="1--14",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc920.txt",
  key="RFC 920",
  abstract={This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains.  This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community.  This is an official policy statement of the IAB and the DARPA.},
  doi="10.17487/RFC0920",
  }

@misc{rfc921,
  author="J. Postel",
  title="{Domain name system implementation schedule - revised}",
  howpublished="RFC 921",
  series="Internet Request for Comments",
  type="RFC",
  number="921",
  pages="1--13",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc921.txt",
  key="RFC 921",
  abstract={This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet.  This memo is an update of RFC-881, and RFC-897.  This is an official policy statement of the IAB and the DARPA.  The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System.  The explanation of how this system works is to be found in the references.},
  doi="10.17487/RFC0921",
  }

@misc{rfc922,
  author="J.C. Mogul",
  title="{Broadcasting Internet datagrams in the presence of subnets}",
  howpublished="RFC 922 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="922",
  pages="1--12",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc922.txt",
  key="RFC 922",
  abstract={We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC0922",
  }

@misc{rfc923,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 923 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="923",
  pages="1--47",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 943",
url="https://www.rfc-editor.org/rfc/rfc923.txt",
  key="RFC 923",
  abstract={This RFC documents the currently assigned values from several series of numbers used in network protocol implementations.  This edition of Assigned Numbers obsoletes RFC-900 and earlier editions.  This memo is an official status report on the numbers used in protocols in the ARPA-Internet community.  See RFC-990, and 997.},
  doi="10.17487/RFC0923",
  }

@misc{rfc924,
  author="J.K. Reynolds and J. Postel",
  title="{Official ARPA-Internet protocols for connecting personal computers to the Internet}",
  howpublished="RFC 924",
  series="Internet Request for Comments",
  type="RFC",
  number="924",
  pages="1--35",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 944",
url="https://www.rfc-editor.org/rfc/rfc924.txt",
  key="RFC 924",
  abstract={This RFC identifies the documents specifying the official protocols used in the Internet.  This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions.  This memo is an official status report on the protocols used in the ARPA-Internet community.  See RFC-991.},
  doi="10.17487/RFC0924",
  }

@misc{rfc925,
  author="J. Postel",
  title="{Multi-LAN address resolution}",
  howpublished="RFC 925",
  series="Internet Request for Comments",
  type="RFC",
  number="925",
  pages="1--15",
  year=1984,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc925.txt",
  key="RFC 925",
  abstract={The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern.  It is inappropriate to give each LAN within an site a distinct Internet network number.  It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site.  The question arises on how to best do this, and even how to do it at all.  In RFC-917 Jeffery Mogul makes a case for the use of ``explicit subnets'' in a multi-LAN environment.  The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network.  In this note I urge another approach: the use of ``transparent subnets'' supported by a multi-LAN extension of the Address Resolution Protocol.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0925",
  }

@misc{rfc926,
  author="International Organization for Standardization",
  title="{Protocol for providing the connectionless mode network services}",
  howpublished="RFC 926",
  series="Internet Request for Comments",
  type="RFC",
  number="926",
  pages="1--107",
  year=1984,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 994",
url="https://www.rfc-editor.org/rfc/rfc926.txt",
  key="RFC 926",
  abstract={This note is the draft ISO protocol roughly similar to the DOD Internet Protocol.  This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS).  This document is distributred as an RFC for information only.  It does not specify a standard for the ARPA-Internet.},
  doi="10.17487/RFC0926",
  }

@misc{rfc927,
  author="B.A. Anderson",
  title="{TACACS user identification Telnet option}",
  howpublished="RFC 927 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="927",
  pages="1--4",
  year=1984,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc927.txt",
  key="RFC 927",
  abstract={The following is the description of a TELNET option designed to facilitate double login avoidance.  It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts.  For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="TOPT-TACACS",
  doi="10.17487/RFC0927",
  }

@misc{rfc928,
  author="M.A. Padlipsky",
  title="{Introduction to proposed DoD standard H-FP}",
  howpublished="RFC 928",
  series="Internet Request for Comments",
  type="RFC",
  number="928",
  pages="1--21",
  year=1984,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc928.txt",
  key="RFC 928",
  abstract={The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel.  It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of ``standard''.  Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0928",
  }

@misc{rfc929,
  author="J. Lilienkamp and R. Mandell and M.A. Padlipsky",
  title="{Proposed Host-Front End Protocol}",
  howpublished="RFC 929 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="929",
  pages="1--56",
  year=1984,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc929.txt",
  key="RFC 929",
  abstract={The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo.  The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="HFEP",
  doi="10.17487/RFC0929",
  }

@misc{rfc930,
  author="M. Solomon and E. Wimmers",
  title="{Telnet terminal type option}",
  howpublished="RFC 930",
  series="Internet Request for Comments",
  type="RFC",
  number="930",
  pages="1--4",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1091",
url="https://www.rfc-editor.org/rfc/rfc930.txt",
  key="RFC 930",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard.  This standard supersedes RFC-884.  The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.},
  doi="10.17487/RFC0930",
  }

@misc{rfc931,
  author="M. St. Johns",
  title="{Authentication server}",
  howpublished="RFC 931",
  series="Internet Request for Comments",
  type="RFC",
  number="931",
  pages="1--5",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1413",
url="https://www.rfc-editor.org/rfc/rfc931.txt",
  key="RFC 931",
  abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.  This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.},
  doi="10.17487/RFC0931",
  }

@misc{rfc932,
  author="D.D. Clark",
  title="{Subnetwork addressing scheme}",
  howpublished="RFC 932",
  series="Internet Request for Comments",
  type="RFC",
  number="932",
  pages="1--4",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc932.txt",
  key="RFC 932",
  abstract={This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever.  The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.},
  doi="10.17487/RFC0932",
  }

@misc{rfc933,
  author="S. Silverman",
  title="{Output marking Telnet option}",
  howpublished="RFC 933 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="933",
  pages="1--4",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc933.txt",
  key="RFC 933",
  abstract={This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.},
  keywords="TOPT-OM",
  doi="10.17487/RFC0933",
  }

@misc{rfc934,
  author="M.T. Rose and E.A. Stefferud",
  title="{Proposed standard for message encapsulation}",
  howpublished="RFC 934",
  series="Internet Request for Comments",
  type="RFC",
  number="934",
  pages="1--10",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc934.txt",
  key="RFC 934",
  abstract={This memo concerns itself with message forwarding.  Forwarding can be thought of as encapsulating one or more messages inside another.  Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms ``bursting''), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages.  In order to burst a message it is necessary to know how the component messages were encapsulated in the draft.  At present there is no unambiguous standard for interest group digests.  This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0934",
  }

@misc{rfc935,
  author="J.G. Robinson",
  title="{Reliable link layer protocols}",
  howpublished="RFC 935",
  series="Internet Request for Comments",
  type="RFC",
  number="935",
  pages="1--12",
  year=1985,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc935.txt",
  key="RFC 935",
  abstract={This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos.  The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds.  The suggested protocol uses the methods of existing national and international data link layer standards.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0935",
  }

@misc{rfc936,
  author="M.J. Karels",
  title="{Another Internet subnet addressing scheme}",
  howpublished="RFC 936",
  series="Internet Request for Comments",
  type="RFC",
  number="936",
  pages="1--4",
  year=1985,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc936.txt",
  key="RFC 936",
  abstract={There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route.  Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection.  They allow the complexity of the number and type of these networks, and routing to them, to be localized.  Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment.  These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed.  This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0936",
  }

@misc{rfc937,
  author="M. Butler and J. Postel and D. Chase and J. Goldberger and J.K. Reynolds",
  title="{Post Office Protocol: Version 2}",
  howpublished="RFC 937 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="937",
  pages="1--24",
  year=1985,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc937.txt",
  key="RFC 937",
  abstract={This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server.  This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement.  This memo is a revision of RFC-918.},
  keywords="POP2, Post Office Protocol, Version 2",
  doi="10.17487/RFC0937",
  }

@misc{rfc938,
  author="T. Miller",
  title="{Internet Reliable Transaction Protocol functional and interface specification}",
  howpublished="RFC 938 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="938",
  pages="1--19",
  year=1985,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc938.txt",
  key="RFC 938",
  abstract={This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it.  While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="IRTP",
  doi="10.17487/RFC0938",
  }

@misc{rfc939,
  author="National Research Council",
  title="{Executive summary of the NRC report on transport protocols for Department of Defense data networks}",
  howpublished="RFC 939",
  series="Internet Request for Comments",
  type="RFC",
  number="939",
  pages="1--20",
  year=1985,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc939.txt",
  key="RFC 939",
  abstract={This RFC reproduces the material from the ``front pages'' of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).  The point of this RFC is to make the text of the Executive Summary widely available in a timely way.  The order of presentation has been altered, and the pagination changed.  This RFC is distributed for information only.  This RFC does not establish any policy for the DARPA research community or the DDN operational community.},
  doi="10.17487/RFC0939",
  }

@misc{rfc940,
  author="Gateway Algorithms and Data Structures Task Force",
  title="{Toward an Internet standard scheme for subnetting}",
  howpublished="RFC 940",
  series="Internet Request for Comments",
  type="RFC",
  number="940",
  pages="1--3",
  year=1985,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc940.txt",
  key="RFC 940",
  abstract={Several sites now contain a complex of local links connected to the Internet via a gateway.  The details of the internal connectivity are of little interest to the rest of the Internet.  One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways).  This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways).  This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.},
  doi="10.17487/RFC0940",
  }

@misc{rfc941,
  author="International Organization for Standardization",
  title="{Addendum to the network service definition covering network layer addressing}",
  howpublished="RFC 941",
  series="Internet Request for Comments",
  type="RFC",
  number="941",
  pages="1--34",
  year=1985,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc941.txt",
  key="RFC 941",
  abstract={This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address).  The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters.  This document is distributed as an RFC for information only.  It does not specify a standard for the ARPA-Internet.},
  doi="10.17487/RFC0941",
  }

@misc{rfc942,
  author="National Research Council",
  title="{Transport protocols for Department of Defense data networks}",
  howpublished="RFC 942",
  series="Internet Request for Comments",
  type="RFC",
  number="942",
  pages="1--88",
  year=1985,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc942.txt",
  key="RFC 942",
  abstract={This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).},
  doi="10.17487/RFC0942",
  }

@misc{rfc943,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 943 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="943",
  pages="1--50",
  year=1985,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 960",
url="https://www.rfc-editor.org/rfc/rfc943.txt",
  key="RFC 943",
  abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.  This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds.  The assignment of numbers is also handled by Joyce.  If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment.  This memo is an official status report on the numbers used in protocols in the ARPA-Internet community.  See RFC-990 and 997.},
  doi="10.17487/RFC0943",
  }

@misc{rfc944,
  author="J.K. Reynolds and J. Postel",
  title="{Official ARPA-Internet protocols}",
  howpublished="RFC 944",
  series="Internet Request for Comments",
  type="RFC",
  number="944",
  pages="1--40",
  year=1985,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 961",
url="https://www.rfc-editor.org/rfc/rfc944.txt",
  key="RFC 944",
  abstract={This RFC identifies the documents specifying the official protocols used in the Internet.  This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions.  This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds.  This memo is an official status report on the protocols used in the ARPA-Internet community.  See RFC-991.},
  doi="10.17487/RFC0944",
  }

@misc{rfc945,
  author="J. Postel",
  title="{DoD statement on the NRC report}",
  howpublished="RFC 945",
  series="Internet Request for Comments",
  type="RFC",
  number="945",
  pages="1--2",
  year=1985,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1039",
url="https://www.rfc-editor.org/rfc/rfc945.txt",
  key="RFC 945",
  abstract={In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action.  The final report of the NRC committee was published in February 1985 (see RFC-942).  The enclosed letter is from Donald C.  Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report.  This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA).  This letter is distributed for information only.},
  doi="10.17487/RFC0945",
  }

@misc{rfc946,
  author="R. Nedved",
  title="{Telnet terminal location number option}",
  howpublished="RFC 946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="946",
  pages="1--4",
  year=1985,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc946.txt",
  key="RFC 946",
  abstract={Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names.  The information is useful for physically locating people and/or calling them on the phone.  In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC).  It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family.  The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community.  This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="TOPT-TLN",
  doi="10.17487/RFC0946",
  }

@misc{rfc947,
  author="K. Lebowitz and D. Mankins",
  title="{Multi-network broadcasting within the Internet}",
  howpublished="RFC 947",
  series="Internet Request for Comments",
  type="RFC",
  number="947",
  pages="1--5",
  year=1985,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc947.txt",
  key="RFC 947",
  abstract={This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.},
  doi="10.17487/RFC0947",
  }

@misc{rfc948,
  author="I. Winston",
  title="{Two methods for the transmission of IP datagrams over IEEE 802.3 networks}",
  howpublished="RFC 948",
  series="Internet Request for Comments",
  type="RFC",
  number="948",
  pages="1--7",
  year=1985,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1042",
url="https://www.rfc-editor.org/rfc/rfc948.txt",
  key="RFC 948",
  abstract={This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0948",
  }

@misc{rfc949,
  author="M.A. Padlipsky",
  title="{FTP unique-named store command}",
  howpublished="RFC 949",
  series="Internet Request for Comments",
  type="RFC",
  number="949",
  pages="1--2",
  year=1985,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc949.txt",
  key="RFC 949",
  abstract={There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory.  This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.  See RFC-959.},
  doi="10.17487/RFC0949",
  }

@misc{rfc950,
  author="J.C. Mogul and J. Postel",
  title="{Internet Standard Subnetting Procedure}",
  howpublished="RFC 950 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="950",
  pages="1--18",
  year=1985,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6918",
url="https://www.rfc-editor.org/rfc/rfc950.txt",
  key="RFC 950",
  abstract={This memo discusses the utility of ``subnets'' of Internet networks, which are logically visible sub-sections of a single Internet network.  For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers.  This memo specifies procedures for the use of subnets.  These procedures are for hosts (e.g., workstations).  The procedures used in and between subnet gateways are not fully described.  Important motivation and background information for a subnetting standard is provided in RFC-940.  This RFC specifies a protocol for the ARPA-Internet community.  If subnetting is implemented it is strongly recommended that these procedures be followed.},
  keywords="Address",
  doi="10.17487/RFC0950",
  }

@misc{rfc951,
  author="W.J. Croft and J. Gilmore",
  title="{Bootstrap Protocol}",
  howpublished="RFC 951 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="951",
  pages="1--12",
  year=1985,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1395, 1497, 1532, 1542, 5494",
url="https://www.rfc-editor.org/rfc/rfc951.txt",
  key="RFC 951",
  abstract={This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed.  The bootstrap operation can be thought of as consisting of TWO PHASES.  This RFC describes the first phase, which could be labeled `address determination and bootfile selection'.  After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs.  The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client.  However BOOTP could also work with other protocols such as SFTP or FTP.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="BOOTP",
  doi="10.17487/RFC0951",
  }

@misc{rfc952,
  author="K. Harrenstien and M.K. Stahl and E.J. Feinler",
  title="{DoD Internet host table specification}",
  howpublished="RFC 952",
  series="Internet Request for Comments",
  type="RFC",
  number="952",
  pages="1--6",
  year=1985,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1123",
url="https://www.rfc-editor.org/rfc/rfc952.txt",
  key="RFC 952",
  abstract={This RFC is the official specification of the format of the Internet Host Table.  This edition of the specification includes minor revisions to RFC-810 which brings it up to date.},
  doi="10.17487/RFC0952",
  }

@misc{rfc953,
  author="K. Harrenstien and M.K. Stahl and E.J. Feinler",
  title="{Hostname Server}",
  howpublished="RFC 953 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="953",
  pages="1--5",
  year=1985,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc953.txt",
  key="RFC 953",
  abstract={This RFC is the official specification of the Hostname Server Protocol.  This edition of the specification includes minor revisions to RFC-811 which brings it up to date.},
  keywords="HOSTNAME",
  doi="10.17487/RFC0953",
  }

@misc{rfc954,
  author="K. Harrenstien and M.K. Stahl and E.J. Feinler",
  title="{NICNAME/WHOIS}",
  howpublished="RFC 954 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="954",
  pages="1--4",
  year=1985,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3912",
url="https://www.rfc-editor.org/rfc/rfc954.txt",
  key="RFC 954",
  abstract={This RFC is the official specification of the NICNAME/WHOIS protocol.  This memo describes the protocol and the service.  This is an update of RFC-812.},
  keywords="NICNAME",
  doi="10.17487/RFC0954",
  }

@misc{rfc955,
  author="R.T. Braden",
  title="{Towards a transport service for transaction processing applications}",
  howpublished="RFC 955",
  series="Internet Request for Comments",
  type="RFC",
  number="955",
  pages="1--10",
  year=1985,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc955.txt",
  key="RFC 955",
  abstract={The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively.  These two protocols represent points in the space of possible transport service attributes which are quite ``far apart''.  We want to examine an important class of applications, those which perform what is often called ``transaction processing''.  We will see that the communication needs for these applications fall into the gap ``between'' TCP and UDP -- neither protocol is very appropriate.  This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present.  The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements.  It does not represent a standard, nor even a concrete protocol proposal.},
  doi="10.17487/RFC0955",
  }

@misc{rfc956,
  author="D.L. Mills",
  title="{Algorithms for synchronizing network clocks}",
  howpublished="RFC 956",
  series="Internet Request for Comments",
  type="RFC",
  number="956",
  pages="1--26",
  year=1985,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc956.txt",
  key="RFC 956",
  abstract={This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements.  The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply.  To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks.  This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links.  Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.},
  doi="10.17487/RFC0956",
  }

@misc{rfc957,
  author="D.L. Mills",
  title="{Experiments in network clock synchronization}",
  howpublished="RFC 957",
  series="Internet Request for Comments",
  type="RFC",
  number="957",
  pages="1--27",
  year=1985,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc957.txt",
  key="RFC 957",
  abstract={This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements.  One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays.  Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems.  In this memo one such clock service design will be described and its performance assessed.  This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.},
  doi="10.17487/RFC0957",
  }

@misc{rfc958,
  author="D.L. Mills",
  title="{Network Time Protocol (NTP)}",
  howpublished="RFC 958",
  series="Internet Request for Comments",
  type="RFC",
  number="958",
  pages="1--14",
  year=1985,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1059, 1119, 1305",
url="https://www.rfc-editor.org/rfc/rfc958.txt",
  key="RFC 958",
  abstract={This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers.  NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism.  It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="NTP, time, clock, synchronization",
  doi="10.17487/RFC0958",
  }

@misc{rfc959,
  author="J. Postel and J. Reynolds",
  title="{File Transfer Protocol}",
  howpublished="RFC 959 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="959",
  pages="1--69",
  year=1985,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2228, 2640, 2773, 3659, 5797, 7151",
url="https://www.rfc-editor.org/rfc/rfc959.txt",
  key="RFC 959",
  abstract={This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community.  The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol.  The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST).  Note that this specification is compatible with the previous edition.},
  keywords="FTP",
  doi="10.17487/RFC0959",
  }

@misc{rfc960,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 960 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="960",
  pages="1--60",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 990",
url="https://www.rfc-editor.org/rfc/rfc960.txt",
  key="RFC 960",
  abstract={This memo documents the currently assigned values from several series of numbers used in network protocol implementations.  This edition of Assigned Numbers updates and obsoletes RFC-943.  This memo is an official status report on the numbers used in protocols in the ARPA-Internet community.  See RFC-990 and 997.},
  doi="10.17487/RFC0960",
  }

@misc{rfc961,
  author="J.K. Reynolds and J. Postel",
  title="{Official ARPA-Internet protocols}",
  howpublished="RFC 961",
  series="Internet Request for Comments",
  type="RFC",
  number="961",
  pages="1--38",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 991",
url="https://www.rfc-editor.org/rfc/rfc961.txt",
  key="RFC 961",
  abstract={This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned.  This edition of the Official Protocols updates and obsoletes RFC-944.  This memo is an official status report on the protocols used in the ARPA-Internet community.  See RFC-991.},
  doi="10.17487/RFC0961",
  }

@misc{rfc962,
  author="M.A. Padlipsky",
  title="{TCP-4 prime}",
  howpublished="RFC 962",
  series="Internet Request for Comments",
  type="RFC",
  number="962",
  pages="1--2",
  year=1985,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc962.txt",
  key="RFC 962",
  abstract={This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol.  This memo does not propose a standard.},
  doi="10.17487/RFC0962",
  }

@misc{rfc963,
  author="D.P. Sidhu",
  title="{Some problems with the specification of the Military Standard Internet Protocol}",
  howpublished="RFC 963",
  series="Internet Request for Comments",
  type="RFC",
  number="963",
  pages="1--19",
  year=1985,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc963.txt",
  key="RFC 963",
  abstract={The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol.  This paper points out several problems in this specification.  This note also proposes solutions to these problems.},
  doi="10.17487/RFC0963",
  }

@misc{rfc964,
  author="D.P. Sidhu and T. Blumer",
  title="{Some problems with the specification of the Military Standard Transmission Control Protocol}",
  howpublished="RFC 964 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="964",
  pages="1--10",
  year=1985,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc964.txt",
  key="RFC 964",
  abstract={The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard.  This note points out three errors with this specification.  This note also proposes solutions to these problems.},
  doi="10.17487/RFC0964",
  }

@misc{rfc965,
  author="L. Aguilar",
  title="{Format for a graphical communication protocol}",
  howpublished="RFC 965",
  series="Internet Request for Comments",
  type="RFC",
  number="965",
  pages="1--51",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc965.txt",
  key="RFC 965",
  abstract={This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile.  We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.},
  doi="10.17487/RFC0965",
  }

@misc{rfc966,
  author="S.E. Deering and D.R. Cheriton",
  title="{Host groups: A multicast extension to the Internet Protocol}",
  howpublished="RFC 966",
  series="Internet Request for Comments",
  type="RFC",
  number="966",
  pages="1--27",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 988",
url="https://www.rfc-editor.org/rfc/rfc966.txt",
  key="RFC 966",
  abstract={This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service.  Discussion and suggestions for improvements are requested.  See RFC-988.},
  doi="10.17487/RFC0966",
  }

@misc{rfc967,
  author="M.A. Padlipsky",
  title="{All victims together}",
  howpublished="RFC 967",
  series="Internet Request for Comments",
  type="RFC",
  number="967",
  pages="1--2",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc967.txt",
  key="RFC 967",
  abstract={This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems.  It appears that this topic has not received enough exposure in the literature.  Comments and suggestions are encouraged.},
  doi="10.17487/RFC0967",
  }

@misc{rfc968,
  author="V.G. Cerf",
  title="{Twas the night before start-up}",
  howpublished="RFC 968",
  series="Internet Request for Comments",
  type="RFC",
  number="968",
  pages="1--2",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc968.txt",
  key="RFC 968",
  abstract={This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.},
  doi="10.17487/RFC0968",
  }

@misc{rfc969,
  author="D.D. Clark and M.L. Lambert and L. Zhang",
  title="{NETBLT: A bulk data transfer protocol}",
  howpublished="RFC 969",
  series="Internet Request for Comments",
  type="RFC",
  number="969",
  pages="1--15",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 998",
url="https://www.rfc-editor.org/rfc/rfc969.txt",
  key="RFC 969",
  abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.  This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol.  NETBLT is intended for the rapid transfer of a large quantity of data between computers.  It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks.  This description is published for discussion and comment, and does not constitute a standard.  As the proposal may change, implementation of this document is not advised.  See RFC-998.},
  doi="10.17487/RFC0969",
  }

@misc{rfc970,
  author="J. Nagle",
  title="{On Packet Switches With Infinite Storage}",
  howpublished="RFC 970",
  series="Internet Request for Comments",
  type="RFC",
  number="970",
  pages="1--9",
  year=1985,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc970.txt",
  key="RFC 970",
  abstract={The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution.  Most prior work on congestion in datagram systems focuses on buffer management.  In this memo the case of a packet switch with infinite storage is considered.  Such a packet switch can never run out of buffers.  It can, however, still become congested.  The meaning of congestion in an infinite-storage system is explored.  An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets.  By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found.  No proposed solutions this document are intended as standards for the ARPA-Internet at this time.},
  doi="10.17487/RFC0970",
  }

@misc{rfc971,
  author="A.L. DeSchon",
  title="{Survey of data representation standards}",
  howpublished="RFC 971",
  series="Internet Request for Comments",
  type="RFC",
  number="971",
  pages="1--9",
  year=1986,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc971.txt",
  key="RFC 971",
  abstract={This RFC is a comparison of several data representation standards that are currently in use.  The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package.  No proposals in this document are intended as standards for the ARPA-Internet at this time.  Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.},
  doi="10.17487/RFC0971",
  }

@misc{rfc972,
  author="F.J. Wancho",
  title="{Password Generator Protocol}",
  howpublished="RFC 972",
  series="Internet Request for Comments",
  type="RFC",
  number="972",
  pages="1--2",
  year=1986,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc972.txt",
  key="RFC 972",
  abstract={This RFC specifies a standard for the ARPA Internet community.  The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character ``words'' with a reasonable level of pronounceability, using a multi-level algorithm.  Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.},
  doi="10.17487/RFC0972",
  }

@misc{rfc973,
  author="P.V. Mockapetris",
  title="{Domain system changes and observations}",
  howpublished="RFC 973",
  series="Internet Request for Comments",
  type="RFC",
  number="973",
  pages="1--10",
  year=1986,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1034, 1035",
url="https://www.rfc-editor.org/rfc/rfc973.txt",
  key="RFC 973",
  abstract={This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.},
  doi="10.17487/RFC0973",
  }

@misc{rfc974,
  author="C. Partridge",
  title="{Mail routing and the domain system}",
  howpublished="RFC 974 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="974",
  pages="1--7",
  year=1986,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2821",
url="https://www.rfc-editor.org/rfc/rfc974.txt",
  key="RFC 974",
  abstract={This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system.  This involves a discussion of how mailers interpret MX RRs, which are used for message routing.},
  keywords="DNS-MX",
  doi="10.17487/RFC0974",
  }

@misc{rfc975,
  author="D.L. Mills",
  title="{Autonomous confederations}",
  howpublished="RFC 975",
  series="Internet Request for Comments",
  type="RFC",
  number="975",
  pages="1--10",
  year=1986,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc975.txt",
  key="RFC 975",
  abstract={This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model.  The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations.  Discussion and suggestions for improvement are requested.},
  doi="10.17487/RFC0975",
  }

@misc{rfc976,
  author="M.R. Horton",
  title="{UUCP mail interchange format standard}",
  howpublished="RFC 976",
  series="Internet Request for Comments",
  type="RFC",
  number="976",
  pages="1--12",
  year=1986,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1137",
url="https://www.rfc-editor.org/rfc/rfc976.txt",
  key="RFC 976",
  abstract={This document defines the standard format for the transmission of mail messages between computers in the UUCP Project.  It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next.  It represents a standard for conformance by hosts in the UUCP zone.},
  doi="10.17487/RFC0976",
  }

@misc{rfc977,
  author="B. Kantor and P. Lapsley",
  title="{Network News Transfer Protocol}",
  howpublished="RFC 977 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="977",
  pages="1--27",
  year=1986,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3977",
url="https://www.rfc-editor.org/rfc/rfc977.txt",
  key="RFC 977",
  abstract={NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community.  NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read.  Indexing, cross-referencing, and expiration of aged messages are also provided.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  keywords="NNTP]",
  doi="10.17487/RFC0977",
  }

@misc{rfc978,
  author="J.K. Reynolds and R. Gillman and W.A. Brackenridge and A. Witkowski and J. Postel",
  title="{Voice File Interchange Protocol (VFIP)}",
  howpublished="RFC 978",
  series="Internet Request for Comments",
  type="RFC",
  number="978",
  pages="1--5",
  year=1986,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc978.txt",
  key="RFC 978",
  abstract={The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community.  Suggestions for improvement are encouraged.},
  doi="10.17487/RFC0978",
  }

@misc{rfc979,
  author="A.G. Malis",
  title="{PSN End-to-End functional specification}",
  howpublished="RFC 979",
  series="Internet Request for Comments",
  type="RFC",
  number="979",
  pages="1--15",
  year=1986,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc979.txt",
  key="RFC 979",
  abstract={This memo is an updated version of BBN Report 5775, ``End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET''.  The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.},
  doi="10.17487/RFC0979",
  }

@misc{rfc980,
  author="O.J. Jacobsen and J. Postel",
  title="{Protocol document order information}",
  howpublished="RFC 980",
  series="Internet Request for Comments",
  type="RFC",
  number="980",
  pages="1--12",
  year=1986,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc980.txt",
  key="RFC 980",
  abstract={This RFC indicates how to obtain various protocol documents used in the DARPA research community.  Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).},
  doi="10.17487/RFC0980",
  }

@misc{rfc981,
  author="D.L. Mills",
  title="{Experimental multiple-path routing algorithm}",
  howpublished="RFC 981",
  series="Internet Request for Comments",
  type="RFC",
  number="981",
  pages="1--22",
  year=1986,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc981.txt",
  key="RFC 981",
  abstract={This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel.  The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed.  This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community.  Discussions and suggestions for improvements are welcomed.},
  doi="10.17487/RFC0981",
  }

@misc{rfc982,
  author="H.W. Braun",
  title="{Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address}",
  howpublished="RFC 982",
  series="Internet Request for Comments",
  type="RFC",
  number="982",
  pages="1--11",
  year=1986,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc982.txt",
  key="RFC 982",
  abstract={This RFC is a draft working document of the ANSI ``Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address''.  It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address.  This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment.  This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.},
  doi="10.17487/RFC0982",
  }

@misc{rfc983,
  author="D.E. Cass and M.T. Rose",
  title="{ISO transport arrives on top of the TCP}",
  howpublished="RFC 983",
  series="Internet Request for Comments",
  type="RFC",
  number="983",
  pages="1--27",
  year=1986,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1006",
url="https://www.rfc-editor.org/rfc/rfc983.txt",
  key="RFC 983",
  abstract={This memo describes a proposed protocol standard for the ARPA Internet community.  The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors.  To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities.  This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet.  The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard.  Suggestions for improvement are encouraged.},
  doi="10.17487/RFC0983",
  }

@misc{rfc984,
  author="D.D. Clark and M.L. Lambert",
  title="{PCMAIL: A distributed mail system for personal computers}",
  howpublished="RFC 984",
  series="Internet Request for Comments",
  type="RFC",
  number="984",
  pages="1--31",
  year=1986,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 993",
url="https://www.rfc-editor.org/rfc/rfc984.txt",
  key="RFC 984",
  abstract={This document is a preliminary discussion of the design of a personal-computer-based distributed mail system.  Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs).  The system is divided into two halves.  The first consists of a single entity called the ``repository''.  The repository is a storage center for incoming mail.  Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users.  The repository also maintains a stable copy of each user's mail state.  The repository is therefore typically a computer with a large amount of disk storage.  It is published for discussion and comment, and does not constitute a standard.  As the proposal may change, implementation of this document is not advised.  See RFC-993.},
  doi="10.17487/RFC0984",
  }

@misc{rfc985,
  author="National Science Foundation and Network Technical Advisory Group",
  title="{Requirements for Internet gateways - draft}",
  howpublished="RFC 985",
  series="Internet Request for Comments",
  type="RFC",
  number="985",
  pages="1--23",
  year=1986,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1009",
url="https://www.rfc-editor.org/rfc/rfc985.txt",
  key="RFC 985",
  abstract={This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols.  While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community.  The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application.  It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.},
  keywords="Requirements, Internet, gateways",
  doi="10.17487/RFC0985",
  }

@misc{rfc986,
  author="R.W. Callon and H.W. Braun",
  title="{Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol}",
  howpublished="RFC 986",
  series="Internet Request for Comments",
  type="RFC",
  number="986",
  pages="1--7",
  year=1986,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1069",
url="https://www.rfc-editor.org/rfc/rfc986.txt",
  key="RFC 986",
  abstract={This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP).  This is a draft solution to one of the problems inherent in the use of ``ISO-grams'' in the DOD Internet.  Related issues will be discussed in subsequent RFCs.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0986",
  }

@misc{rfc987,
  author="S.E. Kille",
  title="{Mapping between X.400 and RFC 822}",
  howpublished="RFC 987",
  series="Internet Request for Comments",
  type="RFC",
  number="987",
  pages="1--69",
  year=1986,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2156, 1327, updated by RFCs 1026, 1138, 1148",
url="https://www.rfc-editor.org/rfc/rfc987.txt",
  key="RFC 987",
  abstract={The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service.  It is expected that this standard will be implemented very widely.  This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822.  This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC0987",
  }

@misc{rfc988,
  author="S.E. Deering",
  title="{Host extensions for IP multicasting}",
  howpublished="RFC 988",
  series="Internet Request for Comments",
  type="RFC",
  number="988",
  pages="1--20",
  year=1986,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1054, 1112",
url="https://www.rfc-editor.org/rfc/rfc988.txt",
  key="RFC 988",
  abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting.  This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet.  The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.},
  keywords="multicast, Internet",
  doi="10.17487/RFC0988",
  }

@misc{rfc989,
  author="J. Linn",
  title="{Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures}",
  howpublished="RFC 989",
  series="Internet Request for Comments",
  type="RFC",
  number="989",
  pages="1--23",
  year=1987,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1040, 1113",
url="https://www.rfc-editor.org/rfc/rfc989.txt",
  key="RFC 989",
  abstract={This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements.  This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings.  This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet.  It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys.  Use of conventional cryptography for message text encryption and/or authentication is anticipated.},
  doi="10.17487/RFC0989",
  }

@misc{rfc990,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 990 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="990",
  pages="1--75",
  year=1986,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1010, updated by RFC 997",
url="https://www.rfc-editor.org/rfc/rfc990.txt",
  key="RFC 990",
  abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.  This memo is an official status report on the numbers used in protocols in the ARPA-Internet community.  See RFC-997.  Obsoletes RFC-960, 943, 923 and 900.},
  doi="10.17487/RFC0990",
  }

@misc{rfc991,
  author="J.K. Reynolds and J. Postel",
  title="{Official ARPA-Internet protocols}",
  howpublished="RFC 991",
  series="Internet Request for Comments",
  type="RFC",
  number="991",
  pages="1--46",
  year=1986,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1011",
url="https://www.rfc-editor.org/rfc/rfc991.txt",
  key="RFC 991",
  abstract={This RFC identifies the documents specifying the official protocols used in the Internet.  Comments indicate any revisions or changes planned.  This memo is an official status report on the numbers used in protocols in the ARPA-Internet community.  Obsoletes RFC-961, 944 and 924.},
  doi="10.17487/RFC0991",
  }

@misc{rfc992,
  author="K.P. Birman and T.A. Joseph",
  title="{On communication support for fault tolerant process groups}",
  howpublished="RFC 992",
  series="Internet Request for Comments",
  type="RFC",
  number="992",
  pages="1--18",
  year=1986,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc992.txt",
  key="RFC 992",
  abstract={This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery.  These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.},
  doi="10.17487/RFC0992",
  }

@misc{rfc993,
  author="D.D. Clark and M.L. Lambert",
  title="{PCMAIL: A distributed mail system for personal computers}",
  howpublished="RFC 993",
  series="Internet Request for Comments",
  type="RFC",
  number="993",
  pages="1--28",
  year=1986,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1056",
url="https://www.rfc-editor.org/rfc/rfc993.txt",
  key="RFC 993",
  abstract={This document is a discussion of the Pcmail workstation-based distributed mail system.  It is a revision of the design published in NIC RFC-984.  The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs.  As this design may change, implementation of this document is not advised.  Obsoletes RFC-984.},
  doi="10.17487/RFC0993",
  }

@misc{rfc994,
  author="International Organization for Standardization",
  title="{Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service}",
  howpublished="RFC 994",
  series="Internet Request for Comments",
  type="RFC",
  number="994",
  pages="1--52",
  year=1986,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc994.txt",
  key="RFC 994",
  abstract={This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems.  The set of standards covers the services and protocols required to achieve such interconnection.  This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498).  In particular, it is a protocol of the Network Layer.  This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both).  It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).},
  doi="10.17487/RFC0994",
  }

@misc{rfc995,
  author="International Organization for Standardization",
  title="{End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473}",
  howpublished="RFC 995",
  series="Internet Request for Comments",
  type="RFC",
  number="995",
  pages="1--41",
  year=1986,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc995.txt",
  key="RFC 995",
  abstract={This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems.  The set of standards covers the services and protocols required to achieve such interconnection.  This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648).  In particular, it is a protocol of the Network Layer.  This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.},
  doi="10.17487/RFC0995",
  }

@misc{rfc996,
  author="D.L. Mills",
  title="{Statistics server}",
  howpublished="RFC 996 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="996",
  pages="1--3",
  year=1987,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc996.txt",
  key="RFC 996",
  abstract={This RFC specifies a standard for the ARPA Internet community.  Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.},
  keywords="STATSRV",
  doi="10.17487/RFC0996",
  }

@misc{rfc997,
  author="J.K. Reynolds and J. Postel",
  title="{Internet numbers}",
  howpublished="RFC 997",
  series="Internet Request for Comments",
  type="RFC",
  number="997",
  pages="1--42",
  year=1987,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1020, 1117",
url="https://www.rfc-editor.org/rfc/rfc997.txt",
  key="RFC 997",
  abstract={This memo is an official status report on the network numbers used in the Internet community.  As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers.  This RFC documents the current assignments of these numbers at the time of this transfer of responsibility.  Obsoletes RFC-990, 960, 943, 923 and 900.},
  doi="10.17487/RFC0997",
  }

@misc{rfc998,
  author="D.D. Clark and M.L. Lambert and L. Zhang",
  title="{NETBLT: A bulk data transfer protocol}",
  howpublished="RFC 998 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="998",
  pages="1--21",
  year=1987,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc998.txt",
  key="RFC 998",
  abstract={This document is a description of, and a specification for, the NETBLT protocol.  It is a revision of the specification published in RFC-969.  NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers.  It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks.  Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP.  This document is published for discussion and comment, and does not constitute a standard.  The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised.  Obsoletes RFC-969.},
  keywords="NETBLT",
  doi="10.17487/RFC0998",
  }

@misc{rfc999,
  author="A. Westine and J. Postel",
  title="{Requests For Comments summary notes: 900-999}",
  howpublished="RFC 999",
  series="Internet Request for Comments",
  type="RFC",
  number="999",
  pages="1--22",
  year=1987,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1000",
url="https://www.rfc-editor.org/rfc/rfc999.txt",
  key="RFC 999",
  doi="10.17487/RFC0999",
  }

@misc{rfc1000,
  author="J.K. Reynolds and J. Postel",
  title="{Request For Comments reference guide}",
  howpublished="RFC 1000",
  series="Internet Request for Comments",
  type="RFC",
  number="1000",
  pages="1--149",
  year=1987,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1000.txt",
  key="RFC 1000",
  abstract={This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.  These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.},
  doi="10.17487/RFC1000",
  }

@misc{rfc1001,
  author="NetBIOS Working Group in the Defense Advanced Research Projects Agency and Internet Activities Board and End-to-End Services Task Force",
  title="{Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods}",
  howpublished="RFC 1001 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1001",
  pages="1--68",
  year=1987,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1001.txt",
  key="RFC 1001",
  abstract={This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment.  Both local network and internet operation are supported.  Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast.  This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques.  Detailed specifications are found in a companion RFC, ``Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications''.},
  keywords="NETBIOS",
  doi="10.17487/RFC1001",
  }

@misc{rfc1002,
  author="NetBIOS Working Group in the Defense Advanced Research Projects Agency and Internet Activities Board and End-to-End Services Task Force",
  title="{Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications}",
  howpublished="RFC 1002 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1002",
  pages="1--84",
  year=1987,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1002.txt",
  key="RFC 1002",
  abstract={This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment.  Both local network and internet operation are supported.  Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast.  This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables.  A more general overview is found in a companion RFC, ``Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods''.},
  keywords="NETBIOS",
  doi="10.17487/RFC1002",
  }

@misc{rfc1003,
  author="A.R. Katz",
  title="{Issues in defining an equations representation standard}",
  howpublished="RFC 1003",
  series="Internet Request for Comments",
  type="RFC",
  number="1003",
  pages="1--7",
  year=1987,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1003.txt",
  key="RFC 1003",
  abstract={This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations.  No attempt is made at a complete definition and more questions are asked than are answered.  Questions about the user interface are only addressed to the extent that they affect interchange issues.},
  doi="10.17487/RFC1003",
  }

@misc{rfc1004,
  author="D.L. Mills",
  title="{Distributed-protocol authentication scheme}",
  howpublished="RFC 1004 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1004",
  pages="1--8",
  year=1987,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1004.txt",
  key="RFC 1004",
  abstract={The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution.  The proposed solutions this document are not intended as standards for the Internet at this time.  Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards.  This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.},
  keywords="COOKIE-JAR",
  doi="10.17487/RFC1004",
  }

@misc{rfc1005,
  author="A. Khanna and A.G. Malis",
  title="{ARPANET AHIP-E Host Access Protocol (enhanced AHIP)}",
  howpublished="RFC 1005",
  series="Internet Request for Comments",
  type="RFC",
  number="1005",
  pages="1--34",
  year=1987,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1005.txt",
  key="RFC 1005",
  abstract={This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822).  These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.},
  doi="10.17487/RFC1005",
  }

@misc{rfc1006,
  author="M.T. Rose and D.E. Cass",
  title="{ISO Transport Service on top of the TCP Version: 3}",
  howpublished="RFC 1006 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1006",
  pages="1--19",
  year=1987,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2126",
url="https://www.rfc-editor.org/rfc/rfc1006.txt",
  key="RFC 1006",
  abstract={This memo specifies a standard for the Internet community.  Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard.  TCP port 102 is reserved for hosts which implement this standard.  This memo specifies version 3 of the protocol and supersedes RFC-983.  Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.},
  keywords="TP-TCP",
  doi="10.17487/RFC1006",
  }

@misc{rfc1007,
  author="W. McCoy",
  title="{Military supplement to the ISO Transport Protocol}",
  howpublished="RFC 1007",
  series="Internet Request for Comments",
  type="RFC",
  number="1007",
  pages="1--23",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1007.txt",
  key="RFC 1007",
  abstract={This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values.  This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement.  While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.},
  doi="10.17487/RFC1007",
  }

@misc{rfc1008,
  author="W. McCoy",
  title="{Implementation guide for the ISO Transport Protocol}",
  howpublished="RFC 1008",
  series="Internet Request for Comments",
  type="RFC",
  number="1008",
  pages="1--73",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1008.txt",
  key="RFC 1008",
  abstract={This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide.  While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.},
  doi="10.17487/RFC1008",
  }

@misc{rfc1009,
  author="R.T. Braden and J. Postel",
  title="{Requirements for Internet gateways}",
  howpublished="RFC 1009 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1009",
  pages="1--54",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1812",
url="https://www.rfc-editor.org/rfc/rfc1009.txt",
  key="RFC 1009",
  abstract={This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols.  This document is a formal statement of the requirements to be met by gateways used in the Internet system.  As such, it is an official specification for the Internet community.},
  keywords="",
  doi="10.17487/RFC1009",
  }

@misc{rfc1010,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 1010 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1010",
  pages="1--44",
  year=1987,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1060",
url="https://www.rfc-editor.org/rfc/rfc1010.txt",
  key="RFC 1010",
  abstract={This memo is an official status report on the numbers used in protocols in the Internet community.  It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.},
  doi="10.17487/RFC1010",
  }

@misc{rfc1011,
  author="J.K. Reynolds and J. Postel",
  title="{Official Internet protocols}",
  howpublished="RFC 1011",
  series="Internet Request for Comments",
  type="RFC",
  number="1011",
  pages="1--52",
  year=1987,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6093",
url="https://www.rfc-editor.org/rfc/rfc1011.txt",
  key="RFC 1011",
  abstract={This memo is an official status report on the protocols used in the Internet community.  It identifies the documents specifying the official protocols used in the Internet.  Comments indicate any revisions or changes planned.},
  doi="10.17487/RFC1011",
  }

@misc{rfc1012,
  author="J.K. Reynolds and J. Postel",
  title="{Bibliography of Request For Comments 1 through 999}",
  howpublished="RFC 1012 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1012",
  pages="1--64",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1012.txt",
  key="RFC 1012",
  abstract={This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.},
  doi="10.17487/RFC1012",
  }

@misc{rfc1013,
  author="R.W. Scheifler",
  title="{X Window System Protocol, version 11: Alpha update April 1987}",
  howpublished="RFC 1013",
  series="Internet Request for Comments",
  type="RFC",
  number="1013",
  pages="1--101",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1013.txt",
  key="RFC 1013",
  abstract={This RFC is distributed to the Internet community for information only.  It does not establish an Internet standard.  The X window system has been widely reviewed and tested.  The Internet community is encouraged to experiment with it.},
  doi="10.17487/RFC1013",
  }

@misc{rfc1014,
  author="Sun Microsystems",
  title="{XDR: External Data Representation standard}",
  howpublished="RFC 1014",
  series="Internet Request for Comments",
  type="RFC",
  number="1014",
  pages="1--20",
  year=1987,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1014.txt",
  key="RFC 1014",
  abstract={XDR is a standard for the description and encoding of data.  It is useful for transferring data between different computer architectures.  XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation.  The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing.  This RFC is distributed for information only, it does not establish a Internet standard.},
  doi="10.17487/RFC1014",
  }

@misc{rfc1015,
  author="B.M. Leiner",
  title="{Implementation plan for interagency research Internet}",
  howpublished="RFC 1015",
  series="Internet Request for Comments",
  type="RFC",
  number="1015",
  pages="1--24",
  year=1987,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1015.txt",
  key="RFC 1015",
  abstract={This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet.  This is an ``idea paper'' and discussion is strongly encouraged.},
  doi="10.17487/RFC1015",
  }

@misc{rfc1016,
  author="W. Prue and J. Postel",
  title="{Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)}",
  howpublished="RFC 1016",
  series="Internet Request for Comments",
  type="RFC",
  number="1016",
  pages="1--18",
  year=1987,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1016.txt",
  key="RFC 1016",
  abstract={The memo is intended to explore the issue of what a host could do with a source quench.  The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host.  This is a ``crazy idea paper'' and discussion is essential.},
  doi="10.17487/RFC1016",
  }

@misc{rfc1017,
  author="B.M. Leiner",
  title="{Network requirements for scientific research: Internet task force on scientific computing}",
  howpublished="RFC 1017",
  series="Internet Request for Comments",
  type="RFC",
  number="1017",
  pages="1--19",
  year=1987,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1017.txt",
  key="RFC 1017",
  abstract={This RFC identifies the requirements on communication networks for supporting scientific research.  It proposes some specific areas for near term work, as well as some long term goals.  This is an ``idea'' paper and discussion is strongly encouraged.},
  doi="10.17487/RFC1017",
  }

@misc{rfc1018,
  author="A.M. McKenzie",
  title="{Some comments on SQuID}",
  howpublished="RFC 1018",
  series="Internet Request for Comments",
  type="RFC",
  number="1018",
  pages="1--3",
  year=1987,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1018.txt",
  key="RFC 1018",
  abstract={This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench.  This memo introduces the distinction of the cause of congestion in a gateway between the effects of ``Funneling'' and ``Mismatch''.  It is offered in the same spirit as RFC-1016; to stimulate discussion.  The opinions offered are personal, not corporate, opinions.  Distribution of this memo is unlimited.},
  doi="10.17487/RFC1018",
  }

@misc{rfc1019,
  author="D. Arnon",
  title="{Report of the Workshop on Environments for Computational Mathematics}",
  howpublished="RFC 1019",
  series="Internet Request for Comments",
  type="RFC",
  number="1019",
  pages="1--8",
  year=1987,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1019.txt",
  key="RFC 1019",
  abstract={This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.},
  doi="10.17487/RFC1019",
  }

@misc{rfc1020,
  author="S. Romano and M.K. Stahl",
  title="{Internet numbers}",
  howpublished="RFC 1020",
  series="Internet Request for Comments",
  type="RFC",
  number="1020",
  pages="1--51",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1062, 1117, 1166",
url="https://www.rfc-editor.org/rfc/rfc1020.txt",
  key="RFC 1020",
  abstract={This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers.  This RFC obsoletes RFC-997.},
  doi="10.17487/RFC1020",
  }

@misc{rfc1021,
  author="C. Partridge and G. Trewitt",
  title="{High-level Entity Management System (HEMS)}",
  howpublished="RFC 1021 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1021",
  pages="1--5",
  year=1987,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1021.txt",
  key="RFC 1021",
  abstract={This memo provides a general overview of the High-level Entity management system (HEMS).  This system is experimental, and is currently being tested in portions of the Internet.},
  keywords="HEMS",
  doi="10.17487/RFC1021",
  }

@misc{rfc1022,
  author="C. Partridge and G. Trewitt",
  title="{High-level Entity Management Protocol (HEMP)}",
  howpublished="RFC 1022",
  series="Internet Request for Comments",
  type="RFC",
  number="1022",
  pages="1--12",
  year=1987,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1022.txt",
  key="RFC 1022",
  abstract={This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines.  This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021.  This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.},
  doi="10.17487/RFC1022",
  }

@misc{rfc1023,
  author="G. Trewitt and C. Partridge",
  title="{HEMS monitoring and control language}",
  howpublished="RFC 1023",
  series="Internet Request for Comments",
  type="RFC",
  number="1023",
  pages="1--17",
  year=1987,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1076",
url="https://www.rfc-editor.org/rfc/rfc1023.txt",
  key="RFC 1023",
  abstract={This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language.  This language defines the requests and replies used in HEMS.  This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.},
  doi="10.17487/RFC1023",
  }

@misc{rfc1024,
  author="C. Partridge and G. Trewitt",
  title="{HEMS variable definitions}",
  howpublished="RFC 1024",
  series="Internet Request for Comments",
  type="RFC",
  number="1024",
  pages="1--74",
  year=1987,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1024.txt",
  key="RFC 1024",
  abstract={This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023.  A general system has been described in previous memos (RFC-1021, RFC-1022).  This system is called the High-Level Entity Management System (HEMS).  This memo is provisional and the definitions are subject to change.  Readers should confirm with the authors that they have the most recent version.  This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.},
  doi="10.17487/RFC1024",
  }

@misc{rfc1025,
  author="J. Postel",
  title="{TCP and IP bake off}",
  howpublished="RFC 1025",
  series="Internet Request for Comments",
  type="RFC",
  number="1025",
  pages="1--6",
  year=1987,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1025.txt",
  key="RFC 1025",
  abstract={This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols.  These procedures and tests may still be of use in testing newly implemented TCP and IP modules.},
  doi="10.17487/RFC1025",
  }

@misc{rfc1026,
  author="S.E. Kille",
  title="{Addendum to RFC 987: (Mapping between X.400 and RFC-822)}",
  howpublished="RFC 1026",
  series="Internet Request for Comments",
  type="RFC",
  number="1026",
  pages="1--4",
  year=1987,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2156, 1327, updated by RFCs 1138, 1148",
url="https://www.rfc-editor.org/rfc/rfc1026.txt",
  key="RFC 1026",
  abstract={This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.},
  doi="10.17487/RFC1026",
  }

@misc{rfc1027,
  author="S. Carl-Mitchell and J.S. Quarterman",
  title="{Using ARP to implement transparent subnet gateways}",
  howpublished="RFC 1027",
  series="Internet Request for Comments",
  type="RFC",
  number="1027",
  pages="1--8",
  year=1987,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1027.txt",
  key="RFC 1027",
  abstract={This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of ``Proxy ARP''.},
  doi="10.17487/RFC1027",
  }

@misc{rfc1028,
  author="J. Davin and J.D. Case and M. Fedor and M.L. Schoffstall",
  title="{Simple Gateway Monitoring Protocol}",
  howpublished="RFC 1028 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1028",
  pages="1--35",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1028.txt",
  key="RFC 1028",
  abstract={This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users.  This proposal is intended only as an interim response to immediate gateway monitoring needs.},
  keywords="SGMP",
  doi="10.17487/RFC1028",
  }

@misc{rfc1029,
  author="G. Parr",
  title="{More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets}",
  howpublished="RFC 1029",
  series="Internet Request for Comments",
  type="RFC",
  number="1029",
  pages="1--17",
  year=1988,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1029.txt",
  key="RFC 1029",
  abstract={This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets.  The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions.  This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.},
  keywords="arp",
  doi="10.17487/RFC1029",
  }

@misc{rfc1030,
  author="M.L. Lambert",
  title="{On testing the NETBLT Protocol over divers networks}",
  howpublished="RFC 1030",
  series="Internet Request for Comments",
  type="RFC",
  number="1030",
  pages="1--16",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1030.txt",
  key="RFC 1030",
  abstract={This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays.  The results are not complete, but the information gathered so far has not been promising.  The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.},
  doi="10.17487/RFC1030",
  }

@misc{rfc1031,
  author="W.D. Lazear",
  title="{MILNET name domain transition}",
  howpublished="RFC 1031",
  series="Internet Request for Comments",
  type="RFC",
  number="1031",
  pages="1--10",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1031.txt",
  key="RFC 1031",
  abstract={This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community.  The introduction of domain style names will impact all hosts in the DDN/MILNET Internet.  This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.},
  doi="10.17487/RFC1031",
  }

@misc{rfc1032,
  author="M.K. Stahl",
  title="{Domain administrators guide}",
  howpublished="RFC 1032",
  series="Internet Request for Comments",
  type="RFC",
  number="1032",
  pages="1--14",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1032.txt",
  key="RFC 1032",
  abstract={Domains are administrative entities that provide decentralized management of host naming and addressing.  The domain-naming system is distributed and hierarchical.  This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920.  It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains.  The role of the domain administrator (DA) is that of coordinator, manager, and technician.  If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.},
  doi="10.17487/RFC1032",
  }

@misc{rfc1033,
  author="M. Lottor",
  title="{Domain Administrators Operations Guide}",
  howpublished="RFC 1033",
  series="Internet Request for Comments",
  type="RFC",
  number="1033",
  pages="1--22",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1033.txt",
  key="RFC 1033",
  abstract={This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database.  Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).},
  doi="10.17487/RFC1033",
  }

@misc{rfc1034,
  author="P.V. Mockapetris",
  title="{Domain names - concepts and facilities}",
  howpublished="RFC 1034 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1034",
  pages="1--55",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936, 8020",
url="https://www.rfc-editor.org/rfc/rfc1034.txt",
  key="RFC 1034",
  abstract={This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.},
  keywords="DOMAIN",
  doi="10.17487/RFC1034",
  }

@misc{rfc1035,
  author="P.V. Mockapetris",
  title="{Domain names - implementation and specification}",
  howpublished="RFC 1035 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1035",
  pages="1--55",
  year=1987,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766",
url="https://www.rfc-editor.org/rfc/rfc1035.txt",
  key="RFC 1035",
  abstract={This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883.  This memo documents the details of the domain name client - server communication.},
  keywords="DOMAIN, DNS",
  doi="10.17487/RFC1035",
  }

@misc{rfc1036,
  author="M.R. Horton and R. Adams",
  title="{Standard for interchange of USENET messages}",
  howpublished="RFC 1036",
  series="Internet Request for Comments",
  type="RFC",
  number="1036",
  pages="1--19",
  year=1987,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5536, 5537",
url="https://www.rfc-editor.org/rfc/rfc1036.txt",
  key="RFC 1036",
  abstract={This RFC defines the standard format for the interchange of network News messages among USENET hosts.  It updates and replaces RFC-850, reflecting version B2.11 of the News program.  This memo is distributed as an RFC to make this information easily accessible to the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1036",
  }

@misc{rfc1037,
  author="B. Greenberg and S. Keene",
  title="{NFILE - a file access protocol}",
  howpublished="RFC 1037 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1037",
  pages="1--86",
  year=1987,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1037.txt",
  key="RFC 1037",
  abstract={This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark.  The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas.  A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.},
  keywords="NFILE",
  doi="10.17487/RFC1037",
  }

@misc{rfc1038,
  author="M. St. Johns",
  title="{Draft revised IP security option}",
  howpublished="RFC 1038",
  series="Internet Request for Comments",
  type="RFC",
  number="1038",
  pages="1--7",
  year=1988,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1108",
url="https://www.rfc-editor.org/rfc/rfc1038.txt",
  key="RFC 1038",
  abstract={This memo is a pre-publication draft of the revised Internet Protocol Security Option.  This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only.  The final version of this document will be available from Navy publications and should not differ from this document in any major fashion.  This document will be published as a change to the MIL- STD 1777, ``Internet Protocol''.},
  doi="10.17487/RFC1038",
  }

@misc{rfc1039,
  author="D. Latham",
  title="{DoD statement on Open Systems Interconnection protocols}",
  howpublished="RFC 1039",
  series="Internet Request for Comments",
  type="RFC",
  number="1039",
  pages="1--3",
  year=1988,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1039.txt",
  key="RFC 1039",
  abstract={This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA).  This memo is distributed for information only.},
  doi="10.17487/RFC1039",
  }

@misc{rfc1040,
  author="J. Linn",
  title="{Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures}",
  howpublished="RFC 1040",
  series="Internet Request for Comments",
  type="RFC",
  number="1040",
  pages="1--29",
  year=1988,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1113",
url="https://www.rfc-editor.org/rfc/rfc1040.txt",
  key="RFC 1040",
  abstract={This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings.  This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet.  Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC.  As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys.  Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.},
  doi="10.17487/RFC1040",
  }

@misc{rfc1041,
  author="Y. Rekhter",
  title="{Telnet 3270 regime option}",
  howpublished="RFC 1041 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1041",
  pages="1--6",
  year=1988,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6270",
url="https://www.rfc-editor.org/rfc/rfc1041.txt",
  key="RFC 1041",
  abstract={This RFC specifies a proposed standard for the Internet community.  Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.},
  keywords="TOPT-3270",
  doi="10.17487/RFC1041",
  }

@misc{rfc1042,
  author="J. Postel and J.K. Reynolds",
  title="{Standard for the transmission of IP datagrams over IEEE 802 networks}",
  howpublished="RFC 1042 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1042",
  pages="1--15",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1042.txt",
  key="RFC 1042",
  abstract={This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations.  This RFC specifies a protocol standard for the Internet community.},
  keywords="IP-IEEE",
  doi="10.17487/RFC1042",
  }

@misc{rfc1043,
  author="A. Yasuda and T. Thompson",
  title="{Telnet Data Entry Terminal option: DODIIS implementation}",
  howpublished="RFC 1043 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1043",
  pages="1--26",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1043.txt",
  key="RFC 1043",
  abstract={This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community.  It is intended that this specification be capatible with the specification of DET Option in RFC-732.  Discussion and suggests for improvements are encouraged.},
  keywords="TOPT-DATA",
  doi="10.17487/RFC1043",
  }

@misc{rfc1044,
  author="K. Hardwick and J. Lekashman",
  title="{Internet Protocol on Network System's HYPERchannel: Protocol Specification}",
  howpublished="RFC 1044 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1044",
  pages="1--43",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc1044.txt",
  key="RFC 1044",
  abstract={This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.  This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet.  No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.},
  keywords="IP-HC",
  doi="10.17487/RFC1044",
  }

@misc{rfc1045,
  author="D.R. Cheriton",
  title="{VMTP: Versatile Message Transaction Protocol: Protocol specification}",
  howpublished="RFC 1045 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1045",
  pages="1--128",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1045.txt",
  key="RFC 1045",
  abstract={This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC).  The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level.  Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required.  Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples.  This RFC describes a protocol proposed as a standard for the Internet community.},
  keywords="VMTP",
  doi="10.17487/RFC1045",
  }

@misc{rfc1046,
  author="W. Prue and J. Postel",
  title="{Queuing algorithm to provide type-of-service for IP links}",
  howpublished="RFC 1046",
  series="Internet Request for Comments",
  type="RFC",
  number="1046",
  pages="1--11",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1046.txt",
  key="RFC 1046",
  abstract={This memo is intended to explore how Type-of-Service might be implemented in the Internet.  The proposal describes a method of queuing which can provide the different classes of service.  The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service.  This is an ``idea paper'' and discussion is strongly encouraged.},
  doi="10.17487/RFC1046",
  }

@misc{rfc1047,
  author="C. Partridge",
  title="{Duplicate messages and SMTP}",
  howpublished="RFC 1047",
  series="Internet Request for Comments",
  type="RFC",
  number="1047",
  pages="1--3",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1047.txt",
  key="RFC 1047",
  abstract={An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented.  This synchronization problem can cause a message to be delivered multiple times.  A method for avoiding this problem is suggested.  Nodding familiarity with the SMTP specification, RFC-821, is required.},
  doi="10.17487/RFC1047",
  }

@misc{rfc1048,
  author="P.A. Prindeville",
  title="{BOOTP vendor information extensions}",
  howpublished="RFC 1048",
  series="Internet Request for Comments",
  type="RFC",
  number="1048",
  pages="1--7",
  year=1988,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1084, 1395, 1497, 1533",
url="https://www.rfc-editor.org/rfc/rfc1048.txt",
  key="RFC 1048",
  abstract={This memo proposes an addition to the Bootstrap Protocol (BOOTP).  Comments and suggestions for improvements are sought.},
  doi="10.17487/RFC1048",
  }

@misc{rfc1049,
  author="M.A. Sirbu",
  title="{Content-type header field for Internet messages}",
  howpublished="RFC 1049 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1049",
  pages="1--8",
  year=1988,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1049.txt",
  key="RFC 1049",
  abstract={This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.},
  keywords="CONTENT",
  doi="10.17487/RFC1049",
  }

@misc{rfc1050,
  author="Sun Microsystems",
  title="{RPC: Remote Procedure Call Protocol specification}",
  howpublished="RFC 1050 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1050",
  pages="1--24",
  year=1988,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1057",
url="https://www.rfc-editor.org/rfc/rfc1050.txt",
  key="RFC 1050",
  abstract={This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package.  This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration.  It is not an Internet standard at this time.},
  keywords="SUN-RPC",
  doi="10.17487/RFC1050",
  }

@misc{rfc1051,
  author="P.A. Prindeville",
  title="{Standard for the transmission of IP datagrams and ARP packets over ARCNET networks}",
  howpublished="RFC 1051 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1051",
  pages="1--4",
  year=1988,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1201",
url="https://www.rfc-editor.org/rfc/rfc1051.txt",
  key="RFC 1051",
  abstract={This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET.  This RFC is a standard protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC1051",
  }

@misc{rfc1052,
  author="V.G. Cerf",
  title="{IAB recommendations for the development of Internet network management standards}",
  howpublished="RFC 1052",
  series="Internet Request for Comments",
  type="RFC",
  number="1052",
  pages="1--14",
  year=1988,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1052.txt",
  key="RFC 1052",
  abstract={This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment.  This memo does NOT, in and of itself, define or propose an Official Internet Protocol.  It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.},
  doi="10.17487/RFC1052",
  }

@misc{rfc1053,
  author="S. Levy and T. Jacobson",
  title="{Telnet X.3 PAD option}",
  howpublished="RFC 1053 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1053",
  pages="1--21",
  year=1988,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1053.txt",
  key="RFC 1053",
  abstract={This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.},
  keywords="TOPT-X.3",
  doi="10.17487/RFC1053",
  }

@misc{rfc1054,
  author="S.E. Deering",
  title="{Host extensions for IP multicasting}",
  howpublished="RFC 1054",
  series="Internet Request for Comments",
  type="RFC",
  number="1054",
  pages="1--19",
  year=1988,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1112",
url="https://www.rfc-editor.org/rfc/rfc1054.txt",
  key="RFC 1054",
  abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting.  IP multicasting is the transmission of an IP datagram to a ``host group'', a set hosts identified by a single IP destination address.  A multicast datagram is delivered to all members of its destination host group with the same ``best-efforts'' reliability as regular unicast IP datagrams.  It is proposed as a standard for IP multicasting in the Internet.  This specification is a major revision of RFC-988.},
  doi="10.17487/RFC1054",
  }

@misc{rfc1055,
  author="J.L. Romkey",
  title="{Nonstandard for transmission of IP datagrams over serial lines: SLIP}",
  howpublished="RFC 1055 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1055",
  pages="1--6",
  year=1988,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1055.txt",
  key="RFC 1055",
  abstract={The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines.  There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines.  SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP.  It is not an Internet standard.},
  keywords="IP-SLIP",
  doi="10.17487/RFC1055",
  }

@misc{rfc1056,
  author="M.L. Lambert",
  title="{PCMAIL: A distributed mail system for personal computers}",
  howpublished="RFC 1056 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1056",
  pages="1--38",
  year=1988,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1056.txt",
  key="RFC 1056",
  abstract={This memo is a discussion of the Pcmail workstation based distributed mail system.  It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described.  The new transport protocol is the result of continued research into ease of protocol implementation and use issues.},
  keywords="PCMAIL",
  doi="10.17487/RFC1056",
  }

@misc{rfc1057,
  author="Sun Microsystems",
  title="{RPC: Remote Procedure Call Protocol specification: Version 2}",
  howpublished="RFC 1057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1057",
  pages="1--25",
  year=1988,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1057.txt",
  key="RFC 1057",
  abstract={This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration.  This memo is not an Internet standard at this time.},
  keywords="SUN-RPC",
  doi="10.17487/RFC1057",
  }

@misc{rfc1058,
  author="C.L. Hedrick",
  title="{Routing Information Protocol}",
  howpublished="RFC 1058 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1058",
  pages="1--33",
  year=1988,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1388, 1723",
url="https://www.rfc-editor.org/rfc/rfc1058.txt",
  key="RFC 1058",
  abstract={This RFC describes an existing protocol for exchanging routing information among gateways and other hosts.  It is intended to be used as a basis for developing gateway software for use in the Internet community.},
  keywords="RIP",
  doi="10.17487/RFC1058",
  }

@misc{rfc1059,
  author="D.L. Mills",
  title="{Network Time Protocol (version 1) specification and implementation}",
  howpublished="RFC 1059",
  series="Internet Request for Comments",
  type="RFC",
  number="1059",
  pages="1--58",
  year=1988,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1119, 1305",
url="https://www.rfc-editor.org/rfc/rfc1059.txt",
  key="RFC 1059",
  abstract={This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation.  NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave.  It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio.  The servers can also redistribute reference time via local routing algorithms and time daemons.  The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document.  The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets.  This is a Draft Standard for an Elective protocol.},
  keywords="NTP, NTPv1, time, clock, synchronization",
  doi="10.17487/RFC1059",
  }

@misc{rfc1060,
  author="J.K. Reynolds and J. Postel",
  title="{Assigned numbers}",
  howpublished="RFC 1060 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1060",
  pages="1--86",
  year=1990,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1340, updated by RFC 1349",
url="https://www.rfc-editor.org/rfc/rfc1060.txt",
  key="RFC 1060",
  abstract={This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.  Distribution of this memo is unlimited.},
  doi="10.17487/RFC1060",
  }

@misc{rfc1062,
  author="S. Romano and M.K. Stahl and M. Recker",
  title="{Internet numbers}",
  howpublished="RFC 1062",
  series="Internet Request for Comments",
  type="RFC",
  number="1062",
  pages="1--65",
  year=1988,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1117, 1166",
url="https://www.rfc-editor.org/rfc/rfc1062.txt",
  key="RFC 1062",
  abstract={This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.},
  doi="10.17487/RFC1062",
  }

@misc{rfc1063,
  author="J.C. Mogul and C.A. Kent and C. Partridge and K. McCloghrie",
  title="{IP MTU discovery options}",
  howpublished="RFC 1063",
  series="Internet Request for Comments",
  type="RFC",
  number="1063",
  pages="1--11",
  year=1988,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1191",
url="https://www.rfc-editor.org/rfc/rfc1063.txt",
  key="RFC 1063",
  abstract={A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses.  This is a proposal for an Experimental protocol.},
  doi="10.17487/RFC1063",
  }

@misc{rfc1064,
  author="M.R. Crispin",
  title="{Interactive Mail Access Protocol: Version 2}",
  howpublished="RFC 1064",
  series="Internet Request for Comments",
  type="RFC",
  number="1064",
  pages="1--26",
  year=1988,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1176, 1203",
url="https://www.rfc-editor.org/rfc/rfc1064.txt",
  key="RFC 1064",
  abstract={This memo suggests a method for workstations to dynamically access mail from a mailbox server (``respository'').  This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community.  Discussion and suggestions for improvement are requested.},
  doi="10.17487/RFC1064",
  }

@misc{rfc1065,
  author="K. McCloghrie and M.T. Rose",
  title="{Structure and identification of management information for TCP/IP-based internets}",
  howpublished="RFC 1065 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1065",
  pages="1--21",
  year=1988,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1155",
url="https://www.rfc-editor.org/rfc/rfc1065.txt",
  key="RFC 1065",
  abstract={This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets.  In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet.  This memo specifies a draft standard for the Internet community.  TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.},
  doi="10.17487/RFC1065",
  }

@misc{rfc1066,
  author="K. McCloghrie and M.T. Rose",
  title="{Management Information Base for network management of TCP/IP-based internets}",
  howpublished="RFC 1066",
  series="Internet Request for Comments",
  type="RFC",
  number="1066",
  pages="1--90",
  year=1988,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1156",
url="https://www.rfc-editor.org/rfc/rfc1066.txt",
  key="RFC 1066",
  abstract={This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term.  In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet.  This memo specifies a draft standard for the Internet community.  TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.},
  doi="10.17487/RFC1066",
  }

@misc{rfc1067,
  author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin",
  title="{Simple Network Management Protocol}",
  howpublished="RFC 1067",
  series="Internet Request for Comments",
  type="RFC",
  number="1067",
  pages="1--33",
  year=1988,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1098",
url="https://www.rfc-editor.org/rfc/rfc1067.txt",
  key="RFC 1067",
  abstract={This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users.  In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet.  This memo specifies a draft standard for the Internet community.  TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.},
  doi="10.17487/RFC1067",
  }

@misc{rfc1068,
  author="A.L. DeSchon and R.T. Braden",
  title="{Background File Transfer Program (BFTP)}",
  howpublished="RFC 1068",
  series="Internet Request for Comments",
  type="RFC",
  number="1068",
  pages="1--27",
  year=1988,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1068.txt",
  key="RFC 1068",
  abstract={This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP.  No new protocols are involved.  The purpose of this memo is to stimulate discussions on new Internet service modes.},
  keywords="FTP",
  doi="10.17487/RFC1068",
  }

@misc{rfc1069,
  author="R.W. Callon and H.W. Braun",
  title="{Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol}",
  howpublished="RFC 1069",
  series="Internet Request for Comments",
  type="RFC",
  number="1069",
  pages="1--10",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1069.txt",
  key="RFC 1069",
  abstract={This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet.  This is a solution to one of the problems inherent in the use of ``ISO-grams'' in the Internet.  This memo is a revision of RFC 986.  This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC1069",
  }

@misc{rfc1070,
  author="R.A. Hagens and N.E. Hall and M.T. Rose",
  title="{Use of the Internet as a subnetwork for experimentation with the OSI network layer}",
  howpublished="RFC 1070",
  series="Internet Request for Comments",
  type="RFC",
  number="1070",
  pages="1--17",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1070.txt",
  key="RFC 1070",
  abstract={This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario.  This RFC also proposes the creation of an experimental OSI internet.  To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.},
  doi="10.17487/RFC1070",
  }

@misc{rfc1071,
  author="R.T. Braden and D.A. Borman and C. Partridge",
  title="{Computing the Internet checksum}",
  howpublished="RFC 1071 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1071",
  pages="1--24",
  year=1988,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1141",
url="https://www.rfc-editor.org/rfc/rfc1071.txt",
  key="RFC 1071",
  abstract={This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum.  It is not a standard, but a set of useful implementation techniques.},
  doi="10.17487/RFC1071",
  }

@misc{rfc1072,
  author="V. Jacobson and R.T. Braden",
  title="{TCP extensions for long-delay paths}",
  howpublished="RFC 1072 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1072",
  pages="1--16",
  year=1988,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1323, 2018, 6247",
url="https://www.rfc-editor.org/rfc/rfc1072.txt",
  key="RFC 1072",
  abstract={This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product.  These extensions are not proposed as an Internet standard at this time.  Instead, they are intended as a basis for further experimentation and research on transport protocol performance.},
  doi="10.17487/RFC1072",
  }

@misc{rfc1073,
  author="D. Waitzman",
  title="{Telnet window size option}",
  howpublished="RFC 1073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1073",
  pages="1--4",
  year=1988,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1073.txt",
  key="RFC 1073",
  abstract={This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.},
  keywords="TOPT-NAWS",
  doi="10.17487/RFC1073",
  }

@misc{rfc1074,
  author="J. Rekhter",
  title="{NSFNET backbone SPF based Interior Gateway Protocol}",
  howpublished="RFC 1074",
  series="Internet Request for Comments",
  type="RFC",
  number="1074",
  pages="1--5",
  year=1988,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1074.txt",
  key="RFC 1074",
  abstract={This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.},
  doi="10.17487/RFC1074",
  }

@misc{rfc1075,
  author="D. Waitzman and C. Partridge and S.E. Deering",
  title="{Distance Vector Multicast Routing Protocol}",
  howpublished="RFC 1075 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1075",
  pages="1--24",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1075.txt",
  key="RFC 1075",
  abstract={This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet.  It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054.  This is an experimental protocol, and its implementation is not recommended at this time.},
  keywords="IP-DVMRP",
  doi="10.17487/RFC1075",
  }

@misc{rfc1076,
  author="G. Trewitt and C. Partridge",
  title="{HEMS monitoring and control language}",
  howpublished="RFC 1076",
  series="Internet Request for Comments",
  type="RFC",
  number="1076",
  pages="1--42",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1076.txt",
  key="RFC 1076",
  abstract={This RFC specifies a query language for monitoring and control of network entities.  This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues.  This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022.  Readers may wish to consult these RFCs when reading this memo.  RFC 1024 contains detailed assignments of numbers and structures used in this system.  Portions of RFC 1024 that define query language structures are superceded by definitions in this memo.  This memo assumes a knowledge of the ISO data encoding standard, ASN.1.},
  doi="10.17487/RFC1076",
  }

@misc{rfc1077,
  author="B.M. Leiner",
  title="{Critical issues in high bandwidth networking}",
  howpublished="RFC 1077",
  series="Internet Request for Comments",
  type="RFC",
  number="1077",
  pages="1--46",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1077.txt",
  key="RFC 1077",
  abstract={This memo presents the results of a working group on High Bandwidth Networking.  This RFC is for your information and you are encouraged to comment on the issues presented.},
  doi="10.17487/RFC1077",
  }

@misc{rfc1078,
  author="M. Lottor",
  title="{TCP port service Multiplexer (TCPMUX)}",
  howpublished="RFC 1078 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1078",
  pages="1--2",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc1078.txt",
  key="RFC 1078",
  abstract={This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.},
  doi="10.17487/RFC1078",
  }

@misc{rfc1079,
  author="C.L. Hedrick",
  title="{Telnet terminal speed option}",
  howpublished="RFC 1079 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1079",
  pages="1--3",
  year=1988,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1079.txt",
  key="RFC 1079",
  abstract={This RFC specifies a standard for the Internet community.  Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.},
  keywords="TOPT-TS",
  doi="10.17487/RFC1079",
  }

@misc{rfc1080,
  author="C.L. Hedrick",
  title="{Telnet remote flow control option}",
  howpublished="RFC 1080",
  series="Internet Request for Comments",
  type="RFC",
  number="1080",
  pages="1--4",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1372",
url="https://www.rfc-editor.org/rfc/rfc1080.txt",
  key="RFC 1080",
  abstract={This RFC specifies a standard for the Internet community.  Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.},
  doi="10.17487/RFC1080",
  }

@misc{rfc1081,
  author="M.T. Rose",
  title="{Post Office Protocol: Version 3}",
  howpublished="RFC 1081",
  series="Internet Request for Comments",
  type="RFC",
  number="1081",
  pages="1--16",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1225",
url="https://www.rfc-editor.org/rfc/rfc1081.txt",
  key="RFC 1081",
  abstract={This memo suggests a simple method for workstations to dynamically access mail from a mailbox server.  This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC1081",
  }

@misc{rfc1082,
  author="M.T. Rose",
  title="{Post Office Protocol: Version 3: Extended service offerings}",
  howpublished="RFC 1082",
  series="Internet Request for Comments",
  type="RFC",
  number="1082",
  pages="1--11",
  year=1988,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1082.txt",
  key="RFC 1082",
  abstract={This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3).  This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.  All of the extensions described in this memo to the POP3 are OPTIONAL.},
  doi="10.17487/RFC1082",
  }

@misc{rfc1083,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{IAB official protocol standards}",
  howpublished="RFC 1083 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1083",
  pages="1--12",
  year=1988,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1100",
url="https://www.rfc-editor.org/rfc/rfc1083.txt",
  key="RFC 1083",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.  This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC1083",
  }

@misc{rfc1084,
  author="J.K. Reynolds",
  title="{BOOTP vendor information extensions}",
  howpublished="RFC 1084",
  series="Internet Request for Comments",
  type="RFC",
  number="1084",
  pages="1--8",
  year=1988,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1395, 1497, 1533",
url="https://www.rfc-editor.org/rfc/rfc1084.txt",
  key="RFC 1084",
  abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville.  This memo will be updated as additional tags are are defined.  This edition introduces Tag 13 for Boot File Size.  Comments and suggestions for improvements are sought.},
  doi="10.17487/RFC1084",
  }

@misc{rfc1085,
  author="M.T. Rose",
  title="{ISO presentation services on top of TCP/IP based internets}",
  howpublished="RFC 1085",
  series="Internet Request for Comments",
  type="RFC",
  number="1085",
  pages="1--32",
  year=1988,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1085.txt",
  key="RFC 1085",
  abstract={RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP.  Once this method is applied, one may implement ``real'' ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP.  Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP).  This memo describes an approach for providing ``stream-lined'' support of OSI application services on top of TCP/IP-based internets for such constrained environments.  This memo proposes a standard for the Internet community.},
  doi="10.17487/RFC1085",
  }

@misc{rfc1086,
  author="J.P. Onions and M.T. Rose",
  title="{ISO-TP0 bridge between TCP and X.25}",
  howpublished="RFC 1086",
  series="Internet Request for Comments",
  type="RFC",
  number="1086",
  pages="1--9",
  year=1988,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1086.txt",
  key="RFC 1086",
  abstract={This memo proposes a standard for the Internet community.  Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal.  TCP port 146 is reserved for this proposal.},
  doi="10.17487/RFC1086",
  }

@misc{rfc1087,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{Ethics and the Internet}",
  howpublished="RFC 1087",
  series="Internet Request for Comments",
  type="RFC",
  number="1087",
  pages="1--2",
  year=1989,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1087.txt",
  key="RFC 1087",
  abstract={This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.},
  keywords="Ethics, Internet",
  doi="10.17487/RFC1087",
  }

@misc{rfc1088,
  author="L.J. McLaughlin",
  title="{Standard for the transmission of IP datagrams over NetBIOS networks}",
  howpublished="RFC 1088 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1088",
  pages="1--3",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1088.txt",
  key="RFC 1088",
  abstract={This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.},
  keywords="IP-NETBIOS",
  doi="10.17487/RFC1088",
  }

@misc{rfc1089,
  author="M. Schoffstall and C. Davin and M. Fedor and J. Case",
  title="{SNMP over Ethernet}",
  howpublished="RFC 1089",
  series="Internet Request for Comments",
  type="RFC",
  number="1089",
  pages="1--3",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4789",
url="https://www.rfc-editor.org/rfc/rfc1089.txt",
  key="RFC 1089",
  abstract={This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack.  This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.},
  doi="10.17487/RFC1089",
  }

@misc{rfc1090,
  author="R. Ullmann",
  title="{SMTP on X.25}",
  howpublished="RFC 1090",
  series="Internet Request for Comments",
  type="RFC",
  number="1090",
  pages="1--4",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1090.txt",
  key="RFC 1090",
  abstract={This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.},
  doi="10.17487/RFC1090",
  }

@misc{rfc1091,
  author="J. VanBokkelen",
  title="{Telnet terminal-type option}",
  howpublished="RFC 1091 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1091",
  pages="1--7",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1091.txt",
  key="RFC 1091",
  abstract={This RFC specifies a standard for the Internet community.  Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard.  This standard supersedes RFC 930.  A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate},
  keywords="TOPT-TERM",
  doi="10.17487/RFC1091",
  }

@misc{rfc1092,
  author="J. Rekhter",
  title="{EGP and policy based routing in the new NSFNET backbone}",
  howpublished="RFC 1092",
  series="Internet Request for Comments",
  type="RFC",
  number="1092",
  pages="1--5",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1092.txt",
  key="RFC 1092",
  abstract={This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone.  Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.},
  doi="10.17487/RFC1092",
  }

@misc{rfc1093,
  author="H.W. Braun",
  title="{NSFNET routing architecture}",
  howpublished="RFC 1093",
  series="Internet Request for Comments",
  type="RFC",
  number="1093",
  pages="1--9",
  year=1989,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1093.txt",
  key="RFC 1093",
  abstract={This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.},
  doi="10.17487/RFC1093",
  }

@misc{rfc1094,
  author="B. Nowicki",
  title="{NFS: Network File System Protocol specification}",
  howpublished="RFC 1094 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1094",
  pages="1--27",
  year=1989,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1094.txt",
  key="RFC 1094",
  abstract={This RFC describes a protocol that Sun Microsystems, Inc., and others are using.  A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.},
  keywords="SUN-NFS",
  doi="10.17487/RFC1094",
  }

@misc{rfc1095,
  author="U.S. Warrier and L. Besaw",
  title="{Common Management Information Services and Protocol over TCP/IP (CMOT)}",
  howpublished="RFC 1095",
  series="Internet Request for Comments",
  type="RFC",
  number="1095",
  pages="1--67",
  year=1989,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1189",
url="https://www.rfc-editor.org/rfc/rfc1095.txt",
  key="RFC 1095",
  abstract={This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment.  This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element.  In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base.  DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard.  Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.},
  doi="10.17487/RFC1095",
  }

@misc{rfc1096,
  author="G.A. Marcy",
  title="{Telnet X display location option}",
  howpublished="RFC 1096 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1096",
  pages="1--3",
  year=1989,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1096.txt",
  key="RFC 1096",
  abstract={This RFC specifies a standard for the Internet community.  Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.},
  keywords="TOPT-XDL",
  doi="10.17487/RFC1096",
  }

@misc{rfc1097,
  author="B. Miller",
  title="{Telnet subliminal-message option}",
  howpublished="RFC 1097",
  series="Internet Request for Comments",
  type="RFC",
  number="1097",
  pages="1--3",
  year=1989,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1097.txt",
  key="RFC 1097",
  abstract={This RFC specifies a standard for the Internet community.  Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.},
  doi="10.17487/RFC1097",
  }

@misc{rfc1098,
  author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin",
  title="{Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 1098",
  series="Internet Request for Comments",
  type="RFC",
  number="1098",
  pages="1--34",
  year=1989,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1157",
url="https://www.rfc-editor.org/rfc/rfc1098.txt",
  key="RFC 1098",
  abstract={This RFC is a re-release of RFC 1067, with a changed ``Status of this Memo'' section.  This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users.  In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.},
  doi="10.17487/RFC1098",
  }

@misc{rfc1099,
  author="J. Reynolds",
  title="{Request for Comments Summary: RFC Numbers 1000-1099}",
  howpublished="RFC 1099 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1099",
  pages="1--22",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1099.txt",
  key="RFC 1099",
  doi="10.17487/RFC1099",
  }

@misc{rfc1100,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{IAB official protocol standards}",
  howpublished="RFC 1100 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1100",
  pages="1--14",
  year=1989,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1130",
url="https://www.rfc-editor.org/rfc/rfc1100.txt",
  key="RFC 1100",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.  This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.  Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo).  Do not use this memo after 31-July-89.},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC1100",
  }

@misc{rfc1101,
  author="P.V. Mockapetris",
  title="{DNS encoding of network names and other types}",
  howpublished="RFC 1101",
  series="Internet Request for Comments",
  type="RFC",
  number="1101",
  pages="1--14",
  year=1989,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1101.txt",
  key="RFC 1101",
  abstract={This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers.  The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.},
  doi="10.17487/RFC1101",
  }

@misc{rfc1102,
  author="D.D. Clark",
  title="{Policy routing in Internet protocols}",
  howpublished="RFC 1102",
  series="Internet Request for Comments",
  type="RFC",
  number="1102",
  pages="1--22",
  year=1989,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1102.txt",
  key="RFC 1102",
  abstract={The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution.  No proposed solutions in this document are intended as standards for the Internet.},
  doi="10.17487/RFC1102",
  }

@misc{rfc1103,
  author="D. Katz",
  title="{Proposed standard for the transmission of IP datagrams over FDDI Networks}",
  howpublished="RFC 1103",
  series="Internet Request for Comments",
  type="RFC",
  number="1103",
  pages="1--9",
  year=1989,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1188",
url="https://www.rfc-editor.org/rfc/rfc1103.txt",
  key="RFC 1103",
  abstract={This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]},
  doi="10.17487/RFC1103",
  }

@misc{rfc1104,
  author="H.W. Braun",
  title="{Models of policy based routing}",
  howpublished="RFC 1104",
  series="Internet Request for Comments",
  type="RFC",
  number="1104",
  pages="1--10",
  year=1989,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1104.txt",
  key="RFC 1104",
  abstract={The purpose of this RFC is to outline a variety of models for policy based routing.  The relative benefits of the different approaches are reviewed.  Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.},
  doi="10.17487/RFC1104",
  }

@misc{rfc1105,
  author="K. Lougheed and Y. Rekhter",
  title="{Border Gateway Protocol (BGP)}",
  howpublished="RFC 1105 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1105",
  pages="1--17",
  year=1989,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1163",
url="https://www.rfc-editor.org/rfc/rfc1105.txt",
  key="RFC 1105",
  abstract={This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems.  Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]},
  keywords="BGP",
  doi="10.17487/RFC1105",
  }

@misc{rfc1106,
  author="R. Fox",
  title="{TCP big window and NAK options}",
  howpublished="RFC 1106 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1106",
  pages="1--13",
  year=1989,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc1106.txt",
  key="RFC 1106",
  abstract={This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product.  The extensions described in this document have been implemented and shown to work using resources at NASA.  This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.},
  doi="10.17487/RFC1106",
  }

@misc{rfc1107,
  author="K.R. Sollins",
  title="{Plan for Internet directory services}",
  howpublished="RFC 1107 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1107",
  pages="1--19",
  year=1989,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1107.txt",
  key="RFC 1107",
  abstract={This memo proposes a program to develop a directory service for the Internet.  It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service.  This proposal is offered for comment, and does not represent a committed research activity of the Internet community.},
  doi="10.17487/RFC1107",
  }

@misc{rfc1108,
  author="S. Kent",
  title="{U.S. Department of Defense Security Options for the Internet Protocol}",
  howpublished="RFC 1108 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1108",
  pages="1--17",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1108.txt",
  key="RFC 1108",
  abstract={This RFC specifies the U.S.  Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol.  This RFC obsoletes RFC 1038, ``Revised IP Security Option'', dated January 1988. [STANDARDS-TRACK]},
  keywords="IPSO",
  doi="10.17487/RFC1108",
  }

@misc{rfc1109,
  author="V.G. Cerf",
  title="{Report of the second Ad Hoc Network Management Review Group}",
  howpublished="RFC 1109",
  series="Internet Request for Comments",
  type="RFC",
  number="1109",
  pages="1--8",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1109.txt",
  key="RFC 1109",
  abstract={This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet.  This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989.  The results of the first such meeting were reported in RFC 1052.},
  doi="10.17487/RFC1109",
  }

@misc{rfc1110,
  author="A.M. McKenzie",
  title="{Problem with the TCP big window option}",
  howpublished="RFC 1110 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1110",
  pages="1--3",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc1110.txt",
  key="RFC 1110",
  abstract={This memo comments on the TCP Big Window option described in RFC 1106.},
  doi="10.17487/RFC1110",
  }

@misc{rfc1111,
  author="J. Postel",
  title="{Request for comments on Request for Comments: Instructions to RFC authors}",
  howpublished="RFC 1111 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1111",
  pages="1--6",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1543, 2223",
url="https://www.rfc-editor.org/rfc/rfc1111.txt",
  key="RFC 1111",
  abstract={This RFC specifies a standard for the Internet community.  Authors of RFCs are expected to adopt and implement this standard.},
  doi="10.17487/RFC1111",
  }

@misc{rfc1112,
  author="S.E. Deering",
  title="{Host extensions for IP multicasting}",
  howpublished="RFC 1112 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1112",
  pages="1--17",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2236",
url="https://www.rfc-editor.org/rfc/rfc1112.txt",
  key="RFC 1112",
  abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting.  Recommended procedure for IP multicasting in the Internet.  This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]},
  keywords="IGMP, multicast",
  doi="10.17487/RFC1112",
  }

@misc{rfc1113,
  author="J. Linn",
  title="{Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures}",
  howpublished="RFC 1113 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1113",
  pages="1--34",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1421",
url="https://www.rfc-editor.org/rfc/rfc1113.txt",
  key="RFC 1113",
  abstract={This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC1113",
  }

@misc{rfc1114,
  author="S.T. Kent and J. Linn",
  title="{Privacy enhancement for Internet electronic mail: Part II - certificate-based key management}",
  howpublished="RFC 1114 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1114",
  pages="1--25",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1422",
url="https://www.rfc-editor.org/rfc/rfc1114.txt",
  key="RFC 1114",
  abstract={This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC1114",
  }

@misc{rfc1115,
  author="J. Linn",
  title="{Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers}",
  howpublished="RFC 1115 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1115",
  pages="1--8",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1423",
url="https://www.rfc-editor.org/rfc/rfc1115.txt",
  key="RFC 1115",
  abstract={This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC1115",
  }

@misc{rfc1116,
  author="D.A. Borman",
  title="{Telnet Linemode option}",
  howpublished="RFC 1116 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1116",
  pages="1--21",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1184",
url="https://www.rfc-editor.org/rfc/rfc1116.txt",
  key="RFC 1116",
  abstract={Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol.  Obsoleted by RFC 1184. [STANDARDS-TRACK]},
  doi="10.17487/RFC1116",
  }

@misc{rfc1117,
  author="S. Romano and M.K. Stahl and M. Recker",
  title="{Internet numbers}",
  howpublished="RFC 1117 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1117",
  pages="1--109",
  year=1989,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1166",
url="https://www.rfc-editor.org/rfc/rfc1117.txt",
  key="RFC 1117",
  abstract={This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.},
  doi="10.17487/RFC1117",
  }

@misc{rfc1118,
  author="E. Krol",
  title="{Hitchhikers guide to the Internet}",
  howpublished="RFC 1118 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1118",
  pages="1--24",
  year=1989,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1118.txt",
  key="RFC 1118",
  abstract={This RFC is being distributed to members of the Internet community in order to make available some ``hints'' which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor.  While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors.  No standards are defined or specified in this memo.},
  doi="10.17487/RFC1118",
  }

@misc{rfc1119,
  author="D.L. Mills",
  title="{Network Time Protocol (version 2) specification and implementation}",
  howpublished="RFC 1119 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1119",
  pages="1--1",
  year=1989,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1305",
url="https://www.rfc-editor.org/rfc/rfc1119.txt",
  key="RFC 1119",
  abstract={This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation.  NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave.  It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio.  The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]},
  keywords="NTP, NTPv2, time, clock, synchronization",
  doi="10.17487/RFC1119",
  }

@misc{rfc1120,
  author="V. Cerf",
  title="{Internet Activities Board}",
  howpublished="RFC 1120 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1120",
  pages="1--11",
  year=1989,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1160",
url="https://www.rfc-editor.org/rfc/rfc1120.txt",
  key="RFC 1120",
  abstract={This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations.  This memo is for informational use and does not constitute a standard.},
  doi="10.17487/RFC1120",
  }

@misc{rfc1121,
  author="J. Postel and L. Kleinrock and V.G. Cerf and B. Boehm",
  title="{Act one - the poems}",
  howpublished="RFC 1121 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1121",
  pages="1--6",
  year=1989,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1121.txt",
  key="RFC 1121",
  abstract={This RFC presents a collection of poems that were presented at ``Act One'', a symposium held partially in celebration of the 20th anniversary of the ARPANET.},
  doi="10.17487/RFC1121",
  }

@misc{rfc1122,
  author="R. Braden",
  title="{Requirements for Internet Hosts - Communication Layers}",
  howpublished="RFC 1122 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1122",
  pages="1--116",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029",
url="https://www.rfc-editor.org/rfc/rfc1122.txt",
  key="RFC 1122",
  abstract={This RFC is an official specification for the Internet community.  It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]},
  keywords="applicability",
  doi="10.17487/RFC1122",
  }

@misc{rfc1123,
  author="R. Braden",
  title="{Requirements for Internet Hosts - Application and Support}",
  howpublished="RFC 1123 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1123",
  pages="1--98",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1349, 2181, 5321, 5966, 7766",
url="https://www.rfc-editor.org/rfc/rfc1123.txt",
  key="RFC 1123",
  abstract={This RFC is an official specification for the Internet community.  It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]},
  keywords="applicability",
  doi="10.17487/RFC1123",
  }

@misc{rfc1124,
  author="B.M. Leiner",
  title="{Policy issues in interconnecting networks}",
  howpublished="RFC 1124",
  series="Internet Request for Comments",
  type="RFC",
  number="1124",
  pages="1--1",
  year=1989,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1124.txt",
  key="RFC 1124",
  abstract={To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks.  Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection.  The purpose of this RFC is to report the results of these workshops.},
  doi="10.17487/RFC1124",
  }

@misc{rfc1125,
  author="D. Estrin",
  title="{Policy requirements for inter Administrative Domain routing}",
  howpublished="RFC 1125",
  series="Internet Request for Comments",
  type="RFC",
  number="1125",
  pages="1--21",
  year=1989,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1125.txt",
  key="RFC 1125",
  abstract={The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution.  No proposed solutions in this document are intended as standards for the Internet.  Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.},
  doi="10.17487/RFC1125",
  }

@misc{rfc1126,
  author="M. Little",
  title="{Goals and functional requirements for inter-autonomous system routing}",
  howpublished="RFC 1126",
  series="Internet Request for Comments",
  type="RFC",
  number="1126",
  pages="1--25",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1126.txt",
  key="RFC 1126",
  abstract={This document describes the functional requirements for a routing protocol to be used between autonomous systems.  This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols.  It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol.  This memo does not specify a standard.},
  doi="10.17487/RFC1126",
  }

@misc{rfc1127,
  author="R.T. Braden",
  title="{Perspective on the Host Requirements RFCs}",
  howpublished="RFC 1127 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1127",
  pages="1--20",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1127.txt",
  key="RFC 1127",
  abstract={This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.},
  doi="10.17487/RFC1127",
  }

@misc{rfc1128,
  author="D.L. Mills",
  title="{Measured performance of the Network Time Protocol in the Internet system}",
  howpublished="RFC 1128",
  series="Internet Request for Comments",
  type="RFC",
  number="1128",
  pages="1--1",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1128.txt",
  key="RFC 1128",
  abstract={This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific.  The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119.  NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave.  In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio.  The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications.  For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe.  Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks.  The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks.  This memo does not specify a standard.},
  doi="10.17487/RFC1128",
  }

@misc{rfc1129,
  author="D.L. Mills",
  title="{Internet Time Synchronization: The Network Time Protocol}",
  howpublished="RFC 1129 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1129",
  pages="1--1",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1129.txt",
  key="RFC 1129",
  abstract={This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave.  It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio.  The servers can also redistribute time information within a network via local routing algorithms and time daemons.  The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper.  The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks.  This memo describes the Network Time Protocol in RFC-1119.},
  keywords="NTP",
  doi="10.17487/RFC1129",
  }

@misc{rfc1130,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{IAB official protocol standards}",
  howpublished="RFC 1130 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1130",
  pages="1--17",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1140",
url="https://www.rfc-editor.org/rfc/rfc1130.txt",
  key="RFC 1130",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC1130",
  }

@misc{rfc1131,
  author="J. Moy",
  title="{OSPF specification}",
  howpublished="RFC 1131 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1131",
  pages="1--1",
  year=1989,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1247",
url="https://www.rfc-editor.org/rfc/rfc1131.txt",
  key="RFC 1131",
  abstract={This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol.  OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System.  This routing protocol is based on the link-state approach (in contrast to the distance-vector approach).  This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]},
  doi="10.17487/RFC1131",
  }

@misc{rfc1132,
  author="L.J. McLaughlin",
  title="{Standard for the transmission of 802.2 packets over IPX networks}",
  howpublished="RFC 1132 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1132",
  pages="1--4",
  year=1989,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1132.txt",
  key="RFC 1132",
  abstract={This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX).  It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks.  It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.},
  keywords="IP-IPX",
  doi="10.17487/RFC1132",
  }

@misc{rfc1133,
  author="J.Y. Yu and H.W. Braun",
  title="{Routing between the NSFNET and the DDN}",
  howpublished="RFC 1133 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1133",
  pages="1--10",
  year=1989,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1133.txt",
  key="RFC 1133",
  abstract={This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET).  We hope that it can be used to expand towards interconnection of other Administrative Domains.  We would welcome discussion and suggestions about the methods employed for the interconnections.  No standards are specified in this memo.},
  doi="10.17487/RFC1133",
  }

@misc{rfc1134,
  author="D. Perkins",
  title="{Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links}",
  howpublished="RFC 1134 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1134",
  pages="1--38",
  year=1989,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1171",
url="https://www.rfc-editor.org/rfc/rfc1134.txt",
  key="RFC 1134",
  abstract={This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990.  Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]},
  doi="10.17487/RFC1134",
  }

@misc{rfc1135,
  author="J.K. Reynolds",
  title="{Helminthiasis of the Internet}",
  howpublished="RFC 1135 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1135",
  pages="1--33",
  year=1989,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1135.txt",
  key="RFC 1135",
  abstract={This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988.  This RFC provides information about an event that occurred in the life of the Internet.  This memo does not specify any standard.  This document provides a glimpse at the infection, its festering, and cure.  The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed.  A documentation review presents four publications that describe in detail this particular parasitic computer program.  Reference and bibliography sections are also included.},
  doi="10.17487/RFC1135",
  }

@misc{rfc1136,
  author="S. Hares and D. Katz",
  title="{Administrative Domains and Routing Domains: A model for routing in the Internet}",
  howpublished="RFC 1136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1136",
  pages="1--10",
  year=1989,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1136.txt",
  key="RFC 1136",
  abstract={This RFC proposes a model for describing routing within the Internet.  The model is an adaptation of the ``OSI Routeing Framework''.  This memo does not specify an Internet standard.},
  doi="10.17487/RFC1136",
  }

@misc{rfc1137,
  author="S. Kille",
  title="{Mapping between full RFC 822 and RFC 822 with restricted encoding}",
  howpublished="RFC 1137 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1137",
  pages="1--3",
  year=1989,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1137.txt",
  key="RFC 1137",
  abstract={This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements.  This memo does not specify an Internet standard.},
  keywords="",
  doi="10.17487/RFC1137",
  }

@misc{rfc1138,
  author="S.E. Kille",
  title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}",
  howpublished="RFC 1138 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1138",
  pages="1--92",
  year=1989,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2156, 1327, updated by RFC 1148",
url="https://www.rfc-editor.org/rfc/rfc1138.txt",
  key="RFC 1138",
  abstract={Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements.  This memo does not specify an Internet standard.  This memo updates RFCs 822, 987, and 1026.},
  doi="10.17487/RFC1138",
  }

@misc{rfc1139,
  author="R.A. Hagens",
  title="{Echo function for ISO 8473}",
  howpublished="RFC 1139 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1139",
  pages="1--6",
  year=1990,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1574, 1575",
url="https://www.rfc-editor.org/rfc/rfc1139.txt",
  key="RFC 1139",
  abstract={This memo defines an echo function for the connection-less network layer protocol.  Two mechanisms are introduced that may be used to implement the echo function.  The first mechanism is recommended as an interim solution for the Internet community.  The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item.  When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard.  This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK]},
  doi="10.17487/RFC1139",
  }

@misc{rfc1140,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{IAB official protocol standards}",
  howpublished="RFC 1140 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1140",
  pages="1--27",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1200",
url="https://www.rfc-editor.org/rfc/rfc1140.txt",
  key="RFC 1140",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.  Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority.  Do not use this edition after 31-Aug-90.},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC1140",
  }

@misc{rfc1141,
  author="T. Mallory and A. Kullberg",
  title="{Incremental updating of the Internet checksum}",
  howpublished="RFC 1141 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1141",
  pages="1--2",
  year=1990,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1624",
url="https://www.rfc-editor.org/rfc/rfc1141.txt",
  key="RFC 1141",
  abstract={This memo correctly describes the incremental update procedure for use with the standard Internet checksum.  It is intended to replace the description of Incremental Update in RFC 1071.  This is not a standard but rather, an implementation technique.},
  doi="10.17487/RFC1141",
  }

@misc{rfc1142,
  author="D. Oran",
  title="{OSI IS-IS Intra-domain Routing Protocol}",
  howpublished="RFC 1142 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1142",
  pages="1--517",
  year=1990,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7142",
url="https://www.rfc-editor.org/rfc/rfc1142.txt",
  key="RFC 1142",
  abstract={This RFC is a republication of ISO DP 10589 as a service to the Internet community.  This is not an Internet standard.},
  keywords="Domain, Routing, ISO",
  doi="10.17487/RFC1142",
  }

@misc{rfc1143,
  author="D.J. Bernstein",
  title="{The Q Method of Implementing TELNET Option Negotiation}",
  howpublished="RFC 1143 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1143",
  pages="1--10",
  year=1990,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1143.txt",
  key="RFC 1143",
  abstract={This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854).  It does not propose any changes to the TELNET protocol.  Rather, it discusses the implementation of the protocol of one feature, only.  This is not a protocol specification.  This is an experimental method of implementing a protocol.},
  keywords="",
  doi="10.17487/RFC1143",
  }

@misc{rfc1144,
  author="V. Jacobson",
  title="{Compressing TCP/IP Headers for Low-Speed Serial Links}",
  howpublished="RFC 1144 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1144",
  pages="1--49",
  year=1990,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1144.txt",
  key="RFC 1144",
  abstract={This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links.  The motivation, implementation and performance of the method are described.  C code for a sample implementation is given for reference. [STANDARDS-TRACK]},
  keywords="IP-CMPRS",
  doi="10.17487/RFC1144",
  }

@misc{rfc1145,
  author="J. Zweig and C. Partridge",
  title="{TCP alternate checksum options}",
  howpublished="RFC 1145 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1145",
  pages="1--5",
  year=1990,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1146, 6247",
url="https://www.rfc-editor.org/rfc/rfc1145.txt",
  key="RFC 1145",
  abstract={This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header.  The use of these options is experimental, and not recommended for production use.},
  doi="10.17487/RFC1145",
  }

@misc{rfc1146,
  author="J. Zweig and C. Partridge",
  title="{TCP alternate checksum options}",
  howpublished="RFC 1146 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1146",
  pages="1--5",
  year=1990,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc1146.txt",
  key="RFC 1146",
  abstract={This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header.  The use of these options is experimental, and not recommended for production use.  Note: This RFC corrects errors introduced in the editing process in RFC 1145.},
  keywords="TCP-ACO",
  doi="10.17487/RFC1146",
  }

@misc{rfc1147,
  author="R.H. Stine",
  title="{FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices}",
  howpublished="RFC 1147 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1147",
  pages="1--177",
  year=1990,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1470",
url="https://www.rfc-editor.org/rfc/rfc1147.txt",
  key="RFC 1147",
  abstract={The goal of this FYI memo is to provide practical information to site administrators and network managers.  This memo provides information for the Internet community.  It does not specify any standard.  It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources.  Entries in the catalog tell what a tool does, how it works, and how it can be obtained.},
  doi="10.17487/RFC1147",
  }

@misc{rfc1148,
  author="S.E. Kille",
  title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}",
  howpublished="RFC 1148 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1148",
  pages="1--94",
  year=1990,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2156, 1327",
url="https://www.rfc-editor.org/rfc/rfc1148.txt",
  key="RFC 1148",
  abstract={This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements.  This memo does not specify an Internet standard.  This edition includes material lost in editing.},
  doi="10.17487/RFC1148",
  }

@misc{rfc1149,
  author="D. Waitzman",
  title="{Standard for the transmission of IP datagrams on avian carriers}",
  howpublished="RFC 1149 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1149",
  pages="1--2",
  year=1990,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2549, 6214",
url="https://www.rfc-editor.org/rfc/rfc1149.txt",
  key="RFC 1149",
  abstract={This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers.  This specification is primarily useful in Metropolitan Area Networks.  This is an experimental, not recommended standard.},
  keywords="avian, carrier, april, fools",
  doi="10.17487/RFC1149",
  }

@misc{rfc1150,
  author="G.S. Malkin and J.K. Reynolds",
  title="{FYI on FYI: Introduction to the FYI Notes}",
  howpublished="RFC 1150 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1150",
  pages="1--4",
  year=1990,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6360",
url="https://www.rfc-editor.org/rfc/rfc1150.txt",
  key="RFC 1150",
  abstract={This memo is the first in a new sub-series of RFCs called FYIs (For Your Information).  This memo provides information for the Internet community.  It does not specify any standard. [Also FYI 1.]},
  doi="10.17487/RFC1150",
  }

@misc{rfc1151,
  author="C. Partridge and R.M. Hinden",
  title="{Version 2 of the Reliable Data Protocol (RDP)}",
  howpublished="RFC 1151 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1151",
  pages="1--4",
  year=1990,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1151.txt",
  key="RFC 1151",
  abstract={This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol.  This revised version of the protocol is experimental.},
  keywords="RDP",
  doi="10.17487/RFC1151",
  }

@misc{rfc1152,
  author="C. Partridge",
  title="{Workshop report: Internet research steering group workshop on very-high-speed networks}",
  howpublished="RFC 1152 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1152",
  pages="1--23",
  year=1990,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1152.txt",
  key="RFC 1152",
  abstract={This memo is a report on a workshop sponsored by the Internet Research Steering Group.  This memo is for information only.  This RFC does not specify an Internet standard.},
  doi="10.17487/RFC1152",
  }

@misc{rfc1153,
  author="F.J. Wancho",
  title="{Digest message format}",
  howpublished="RFC 1153 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1153",
  pages="1--4",
  year=1990,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1153.txt",
  key="RFC 1153",
  abstract={This memo describes the de facto standard Digest Message Format.  This is an elective experimental protocol.},
  keywords="DMF-MAIL",
  doi="10.17487/RFC1153",
  }

@misc{rfc1154,
  author="D. Robinson and R. Ullmann",
  title="{Encoding header field for internet messages}",
  howpublished="RFC 1154 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1154",
  pages="1--7",
  year=1990,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1505",
url="https://www.rfc-editor.org/rfc/rfc1154.txt",
  key="RFC 1154",
  abstract={This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages.  The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).},
  doi="10.17487/RFC1154",
  }

@misc{rfc1155,
  author="M.T. Rose and K. McCloghrie",
  title="{Structure and identification of management information for TCP/IP-based internets}",
  howpublished="RFC 1155 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1155",
  pages="1--22",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1155.txt",
  key="RFC 1155",
  abstract={This RFC is a re-release of RFC 1065, with a changed ``Status of this Memo'', plus a few minor typographical corrections.  The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]},
  keywords="SMI",
  doi="10.17487/RFC1155",
  }

@misc{rfc1156,
  author="K. McCloghrie and M.T. Rose",
  title="{Management Information Base for network management of TCP/IP-based internets}",
  howpublished="RFC 1156 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1156",
  pages="1--91",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1156.txt",
  key="RFC 1156",
  abstract={This RFC is a re-release of RFC 1066, with a changed ``Status of this Memo'', ``IAB Policy Statement'', and ``Introduction'' sections plus a few minor typographical corrections.  The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]},
  keywords="MIB-I",
  doi="10.17487/RFC1156",
  }

@misc{rfc1157,
  author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin",
  title="{Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 1157 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1157",
  pages="1--36",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1157.txt",
  key="RFC 1157",
  abstract={This RFC is a re-release of RFC 1098, with a changed ``Status of this Memo'' section plus a few minor typographical corrections.  This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]},
  keywords="SNMP",
  doi="10.17487/RFC1157",
  }

@misc{rfc1158,
  author="M.T. Rose",
  title="{Management Information Base for network management of TCP/IP-based internets: MIB-II}",
  howpublished="RFC 1158 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1158",
  pages="1--133",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1213",
url="https://www.rfc-editor.org/rfc/rfc1158.txt",
  key="RFC 1158",
  abstract={This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets.  In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community.  This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]},
  doi="10.17487/RFC1158",
  }

@misc{rfc1159,
  author="R. Nelson",
  title="{Message Send Protocol}",
  howpublished="RFC 1159 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1159",
  pages="1--2",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1312",
url="https://www.rfc-editor.org/rfc/rfc1159.txt",
  key="RFC 1159",
  abstract={This RFC suggests an Experimental Protocol for the Internet community.  Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.},
  doi="10.17487/RFC1159",
  }

@misc{rfc1160,
  author="V. Cerf",
  title="{Internet Activities Board}",
  howpublished="RFC 1160 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1160",
  pages="1--11",
  year=1990,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1160.txt",
  key="RFC 1160",
  abstract={This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations.  This memo is for informational use and does not constitute a standard.  This is a revision of RFC 1120.},
  doi="10.17487/RFC1160",
  }

@misc{rfc1161,
  author="M.T. Rose",
  title="{SNMP over OSI}",
  howpublished="RFC 1161 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1161",
  pages="1--8",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1418",
url="https://www.rfc-editor.org/rfc/rfc1161.txt",
  key="RFC 1161",
  abstract={This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports.  This memo does not specify a standard for the Internet community,},
  doi="10.17487/RFC1161",
  }

@misc{rfc1162,
  author="G. Satz",
  title="{Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base}",
  howpublished="RFC 1162 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1162",
  pages="1--70",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1238",
url="https://www.rfc-editor.org/rfc/rfc1162.txt",
  key="RFC 1162",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  This memo does not specify a standard for the Internet community.},
  doi="10.17487/RFC1162",
  }

@misc{rfc1163,
  author="K. Lougheed and Y. Rekhter",
  title="{Border Gateway Protocol (BGP)}",
  howpublished="RFC 1163 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1163",
  pages="1--29",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1267",
url="https://www.rfc-editor.org/rfc/rfc1163.txt",
  key="RFC 1163",
  abstract={This RFC, together with its companion RFC-1164, ``Application of the Border Gateway Protocol in the Internet'', specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="BGP",
  doi="10.17487/RFC1163",
  }

@misc{rfc1164,
  author="J.C. Honig and D. Katz and M. Mathis and Y. Rekhter and J.Y. Yu",
  title="{Application of the Border Gateway Protocol in the Internet}",
  howpublished="RFC 1164 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1164",
  pages="1--23",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1268",
url="https://www.rfc-editor.org/rfc/rfc1164.txt",
  key="RFC 1164",
  abstract={This RFC, together with its companion RFC-1163, ``A Border Gateway Protocol (BGP)'', specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="BGP",
  doi="10.17487/RFC1164",
  }

@misc{rfc1165,
  author="J. Crowcroft and J.P. Onions",
  title="{Network Time Protocol (NTP) over the OSI Remote Operations Service}",
  howpublished="RFC 1165 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1165",
  pages="1--10",
  year=1990,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1165.txt",
  key="RFC 1165",
  abstract={This memo suggests an Experimental Protocol for the OSI and Internet communities.  Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.},
  keywords="NTP-OSI",
  doi="10.17487/RFC1165",
  }

@misc{rfc1166,
  author="S. Kirkpatrick and M.K. Stahl and M. Recker",
  title="{Internet numbers}",
  howpublished="RFC 1166 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1166",
  pages="1--182",
  year=1990,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5737",
url="https://www.rfc-editor.org/rfc/rfc1166.txt",
  key="RFC 1166",
  abstract={This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.},
  doi="10.17487/RFC1166",
  }

@misc{rfc1167,
  author="V.G. Cerf",
  title="{Thoughts on the National Research and Education Network}",
  howpublished="RFC 1167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1167",
  pages="1--8",
  year=1990,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1167.txt",
  key="RFC 1167",
  abstract={The memo provides a brief outline of a National Research and Education Network (NREN).  This memo provides information for the Internet community.  It does not specify any standard.  It is not a statement of IAB policy or recommendations.},
  doi="10.17487/RFC1167",
  }

@misc{rfc1168,
  author="A. Westine and A.L. DeSchon and J. Postel and C.E. Ward",
  title="{Intermail and Commercial Mail Relay services}",
  howpublished="RFC 1168 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1168",
  pages="1--18",
  year=1990,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1168.txt",
  key="RFC 1168",
  abstract={This RFC discusses the history and evolution of the Intermail and Commercial mail systems.  The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed.  This RFC provides information for the Internet community, and does not specify any standard.},
  doi="10.17487/RFC1168",
  }

@misc{rfc1169,
  author="V.G. Cerf and K.L. Mills",
  title="{Explaining the role of GOSIP}",
  howpublished="RFC 1169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1169",
  pages="1--15",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1169.txt",
  key="RFC 1169",
  abstract={This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC).  This RFC does not specify a standard.},
  doi="10.17487/RFC1169",
  }

@misc{rfc1170,
  author="R.B. Fougner",
  title="{Public key standards and licenses}",
  howpublished="RFC 1170 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1170",
  pages="1--2",
  year=1991,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1170.txt",
  key="RFC 1170",
  abstract={This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses.  This memo is for informational use only, and does not constitute an Internet standard.},
  doi="10.17487/RFC1170",
  }

@misc{rfc1171,
  author="D. Perkins",
  title="{Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links}",
  howpublished="RFC 1171 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1171",
  pages="1--51",
  year=1990,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1331",
url="https://www.rfc-editor.org/rfc/rfc1171.txt",
  key="RFC 1171",
  abstract={This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community.  When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.},
  doi="10.17487/RFC1171",
  }

@misc{rfc1172,
  author="D. Perkins and R. Hobby",
  title="{Point-to-Point Protocol (PPP) initial configuration options}",
  howpublished="RFC 1172 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1172",
  pages="1--40",
  year=1990,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1331, 1332",
url="https://www.rfc-editor.org/rfc/rfc1172.txt",
  key="RFC 1172",
  abstract={This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community.  When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.},
  doi="10.17487/RFC1172",
  }

@misc{rfc1173,
  author="J. VanBokkelen",
  title="{Responsibilities of host and network managers: A summary of the ``oral tradition'' of the Internet}",
  howpublished="RFC 1173 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1173",
  pages="1--5",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1173.txt",
  key="RFC 1173",
  abstract={This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet.  It is a summary of the ``oral tradition'' of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions.  It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet.  This RFC does not specify a standard, or a policy of the IAB.},
  doi="10.17487/RFC1173",
  }

@misc{rfc1174,
  author="V.G. Cerf",
  title="{IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet ``connected'' status}",
  howpublished="RFC 1174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1174",
  pages="1--9",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1174.txt",
  key="RFC 1174",
  abstract={This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement.  This RFC does not specify a standard.},
  doi="10.17487/RFC1174",
  }

@misc{rfc1175,
  author="K.L. Bowers and T.L. LaQuey and J.K. Reynolds and K. Roubicek and M.K. Stahl and A. Yuan",
  title="{FYI on where to start: A bibliography of internetworking information}",
  howpublished="RFC 1175 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1175",
  pages="1--43",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1175.txt",
  key="RFC 1175",
  abstract={This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.  It does not specify any standard. [Also FYI 3.]},
  doi="10.17487/RFC1175",
  }

@misc{rfc1176,
  author="M.R. Crispin",
  title="{Interactive Mail Access Protocol: Version 2}",
  howpublished="RFC 1176 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1176",
  pages="1--30",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1176.txt",
  key="RFC 1176",
  abstract={This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server (``repository'').  It obosoletes RFC 1064.  This RFC specifies an Experimental Protocol for the Internet community.  Discussion and suggestions for improvement are requested.  Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.},
  keywords="IMAP2",
  doi="10.17487/RFC1176",
  }

@misc{rfc1177,
  author="G.S. Malkin and A.N. Marine and J.K. Reynolds",
  title="{FYI on Questions and Answers: Answers to commonly asked ``new internet user'' questions}",
  howpublished="RFC 1177 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1177",
  pages="1--24",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1206",
url="https://www.rfc-editor.org/rfc/rfc1177.txt",
  key="RFC 1177",
  abstract={This FYI RFC is one of three FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF).  The goal is to document the most commonly asked questions and answers in the Internet.  This memo provides information for the Internet community.  It does not specify any standard. [Also FYI 4.]},
  doi="10.17487/RFC1177",
  }

@misc{rfc1178,
  author="D. Libes",
  title="{Choosing a name for your computer}",
  howpublished="RFC 1178 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1178",
  pages="1--8",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1178.txt",
  key="RFC 1178",
  abstract={This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer.  This memo provides information for the Internet community.  It does not specify any standard. [Also FYI 5.]},
  doi="10.17487/RFC1178",
  }

@misc{rfc1179,
  author="L. McLaughlin",
  title="{Line printer daemon protocol}",
  howpublished="RFC 1179 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1179",
  pages="1--14",
  year=1990,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1179.txt",
  key="RFC 1179",
  abstract={This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers).  This memo is for informational purposes only, and does not specify an Internet standard.  Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.},
  keywords="LPDP",
  doi="10.17487/RFC1179",
  }

@misc{rfc1180,
  author="T.J. Socolofsky and C.J. Kale",
  title="{TCP/IP tutorial}",
  howpublished="RFC 1180 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1180",
  pages="1--28",
  year=1991,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1180.txt",
  key="RFC 1180",
  abstract={This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router.  It does not specify an Internet standard.},
  doi="10.17487/RFC1180",
  }

@misc{rfc1181,
  author="R. Blokzijl",
  title="{RIPE Terms of Reference}",
  howpublished="RFC 1181 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1181",
  pages="1--2",
  year=1990,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1181.txt",
  key="RFC 1181",
  abstract={This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks.  This memo provides information for the Internet community.  It does not specify any standard.},
  doi="10.17487/RFC1181",
  }

@misc{rfc1183,
  author="C.F. Everhart and L.A. Mamakos and R. Ullmann and P.V. Mockapetris",
  title="{New DNS RR Definitions}",
  howpublished="RFC 1183 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1183",
  pages="1--11",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5395, 5864, 6195, 6895",
url="https://www.rfc-editor.org/rfc/rfc1183.txt",
  key="RFC 1183",
  abstract={This memo defines five new DNS types for experimental purposes.  This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.},
  keywords="DNS-RR",
  doi="10.17487/RFC1183",
  }

@misc{rfc1184,
  author="D.A. Borman",
  title="{Telnet Linemode Option}",
  howpublished="RFC 1184 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1184",
  pages="1--23",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1184.txt",
  key="RFC 1184",
  abstract={This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol.  It obsoletes RFC 1116. [STANDARDS-TRACK]},
  keywords="TOPT-LINE",
  doi="10.17487/RFC1184",
  }

@misc{rfc1185,
  author="V. Jacobson and R.T. Braden and L. Zhang",
  title="{TCP Extension for High-Speed Paths}",
  howpublished="RFC 1185 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1185",
  pages="1--21",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1323",
url="https://www.rfc-editor.org/rfc/rfc1185.txt",
  key="RFC 1185",
  abstract={This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements.  Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.},
  doi="10.17487/RFC1185",
  }

@misc{rfc1186,
  author="R.L. Rivest",
  title="{MD4 Message Digest Algorithm}",
  howpublished="RFC 1186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1186",
  pages="1--18",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1320",
url="https://www.rfc-editor.org/rfc/rfc1186.txt",
  key="RFC 1186",
  abstract={This RFC is the specification of the MD4 Digest Algorithm.  If you are going to implement MD4, it is suggested you do it this way.  This memo is for informational use and does not constitute a standard.},
  doi="10.17487/RFC1186",
  }

@misc{rfc1187,
  author="M.T. Rose and K. McCloghrie and J.R. Davin",
  title="{Bulk Table Retrieval with the SNMP}",
  howpublished="RFC 1187 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1187",
  pages="1--12",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1187.txt",
  key="RFC 1187",
  abstract={This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP).  This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.  This memo does not specify a standard for the Internet community.  Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.},
  keywords="SNMP-BULK",
  doi="10.17487/RFC1187",
  }

@misc{rfc1188,
  author="D. Katz",
  title="{Proposed Standard for the Transmission of IP Datagrams over FDDI Networks}",
  howpublished="RFC 1188 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1188",
  pages="1--11",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1188.txt",
  key="RFC 1188",
  abstract={This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC1188",
  }

@misc{rfc1189,
  author="U.S. Warrier and L. Besaw and L. LaBarre and B.D. Handspicker",
  title="{Common Management Information Services and Protocols for the Internet (CMOT and CMIP)}",
  howpublished="RFC 1189 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1189",
  pages="1--15",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1189.txt",
  key="RFC 1189",
  abstract={This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]},
  keywords="CMOT",
  doi="10.17487/RFC1189",
  }

@misc{rfc1190,
  author="C. Topolcic",
  title="{Experimental Internet Stream Protocol: Version 2 (ST-II)}",
  howpublished="RFC 1190 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1190",
  pages="1--148",
  year=1990,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1819",
url="https://www.rfc-editor.org/rfc/rfc1190.txt",
  key="RFC 1190",
  abstract={This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements.  This is a Limited-Use Experimental Protocol.  Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.},
  doi="10.17487/RFC1190",
  }

@misc{rfc1191,
  author="J.C. Mogul and S.E. Deering",
  title="{Path MTU discovery}",
  howpublished="RFC 1191 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1191",
  pages="1--19",
  year=1990,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1191.txt",
  key="RFC 1191",
  abstract={This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]},
  keywords="IP-MTU",
  doi="10.17487/RFC1191",
  }

@misc{rfc1192,
  author="B. Kahin",
  title="{Commercialization of the Internet summary report}",
  howpublished="RFC 1192 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1192",
  pages="1--13",
  year=1990,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1192.txt",
  key="RFC 1192",
  abstract={This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F.  Kennedy School of Government, Harvard University, March 1-3, 1990.  This memo provides information for the Internet community.  It does not specify any standard.},
  doi="10.17487/RFC1192",
  }

@misc{rfc1193,
  author="D. Ferrari",
  title="{Client requirements for real-time communication services}",
  howpublished="RFC 1193 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1193",
  pages="1--24",
  year=1990,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1193.txt",
  key="RFC 1193",
  abstract={This memo describes client requirements for real-time communication services.  This memo provides information for the Internet community, and requests discussion and suggestions for improvements.  It does not specify any standard.},
  doi="10.17487/RFC1193",
  }

@misc{rfc1194,
  author="D.P. Zimmerman",
  title="{Finger User Information Protocol}",
  howpublished="RFC 1194 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1194",
  pages="1--12",
  year=1990,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1196, 1288",
url="https://www.rfc-editor.org/rfc/rfc1194.txt",
  key="RFC 1194",
  abstract={This memo describes the Finger User Information Protocol.  This is a simple protocol which provides an interface to a remote user information program.  Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection.  It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]},
  doi="10.17487/RFC1194",
  }

@misc{rfc1195,
  author="R.W. Callon",
  title="{Use of OSI IS-IS for routing in TCP/IP and dual environments}",
  howpublished="RFC 1195 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1195",
  pages="1--85",
  year=1990,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1349, 5302, 5304",
url="https://www.rfc-editor.org/rfc/rfc1195.txt",
  key="RFC 1195",
  abstract={This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI.  This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments.  This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]},
  keywords="IS-IS",
  doi="10.17487/RFC1195",
  }

@misc{rfc1196,
  author="D.P. Zimmerman",
  title="{Finger User Information Protocol}",
  howpublished="RFC 1196 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1196",
  pages="1--12",
  year=1990,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1288",
url="https://www.rfc-editor.org/rfc/rfc1196.txt",
  key="RFC 1196",
  abstract={This memo describes the Finger User Information Protocol.  This is a simple protocol which provides an interface to a remote user information program.  Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection.  It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.  This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]},
  doi="10.17487/RFC1196",
  }

@misc{rfc1197,
  author="M. Sherman",
  title="{Using ODA for translating multimedia information}",
  howpublished="RFC 1197 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1197",
  pages="1--2",
  year=1990,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1197.txt",
  key="RFC 1197",
  abstract={The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA).  Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences.  This memo provides information for the Internet community.  It does not specify any standard.},
  doi="10.17487/RFC1197",
  }

@misc{rfc1198,
  author="R.W. Scheifler",
  title="{FYI on the X window system}",
  howpublished="RFC 1198 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1198",
  pages="1--3",
  year=1991,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1198.txt",
  key="RFC 1198",
  abstract={This FYI RFC provides pointers to the published standards of the MIT X Consortium.  This memo provides information for the Internet community.  It does not specify any Internet standard.},
  doi="10.17487/RFC1198",
  }

@misc{rfc1199,
  author="J. Reynolds",
  title="{Request for Comments Summary Notes: 1100-1199}",
  howpublished="RFC 1199 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1199",
  pages="1--22",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1199.txt",
  key="RFC 1199",
  keywords="Summary, RFC",
  doi="10.17487/RFC1199",
  }

@misc{rfc1200,
  author="Defense Advanced Research Projects Agency and Internet Activities Board",
  title="{IAB official protocol standards}",
  howpublished="RFC 1200 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1200",
  pages="1--31",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1250",
url="https://www.rfc-editor.org/rfc/rfc1200.txt",
  key="RFC 1200",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC1200",
  }

@misc{rfc1201,
  author="D. Provan",
  title="{Transmitting IP traffic over ARCNET networks}",
  howpublished="RFC 1201 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1201",
  pages="1--7",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1201.txt",
  key="RFC 1201",
  abstract={This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the ``ARCNET Packet Header Definition Standard''. [STANDARDS-TRACK]},
  keywords="IP-ARC",
  doi="10.17487/RFC1201",
  }

@misc{rfc1202,
  author="M.T. Rose",
  title="{Directory Assistance service}",
  howpublished="RFC 1202 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1202",
  pages="1--11",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1202.txt",
  key="RFC 1202",
  abstract={This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection.  This is a local mechanism.  This memo provides information for the Internet community.  It does not specify any standard.},
  keywords="DAS",
  doi="10.17487/RFC1202",
  }

@misc{rfc1203,
  author="J. Rice",
  title="{Interactive Mail Access Protocol: Version 3}",
  howpublished="RFC 1203 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1203",
  pages="1--49",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1203.txt",
  key="RFC 1203",
  abstract={This RFC suggests a method for workstations to access mail dynamically from a mailbox server (``repository'').  The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol.  This RFC specifies an Experimental Protocol for the Internet community.  It does not specify any standard.},
  keywords="IMAP3",
  doi="10.17487/RFC1203",
  }

@misc{rfc1204,
  author="S. Yeh and D. Lee",
  title="{Message Posting Protocol (MPP)}",
  howpublished="RFC 1204 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1204",
  pages="1--6",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1204.txt",
  key="RFC 1204",
  abstract={This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host.  This RFC specifies an Experimental Protocol for the Internet community.  It does not specify any standard.},
  keywords="MPP",
  doi="10.17487/RFC1204",
  }

@misc{rfc1205,
  author="P. Chmielewski",
  title="{5250 Telnet interface}",
  howpublished="RFC 1205 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1205",
  pages="1--12",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2877",
url="https://www.rfc-editor.org/rfc/rfc1205.txt",
  key="RFC 1205",
  abstract={This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation.  This memo provides information for the Internet community.  It does not specify any standard.},
  doi="10.17487/RFC1205",
  }

@misc{rfc1206,
  author="G.S. Malkin and A.N. Marine",
  title="{FYI on Questions and Answers: Answers to commonly asked ``new Internet user'' questions}",
  howpublished="RFC 1206 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1206",
  pages="1--32",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1325",
url="https://www.rfc-editor.org/rfc/rfc1206.txt",
  key="RFC 1206",
  abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A).  The goal is to document the most commonly asked questions and answers in the Internet.  This memo provides information for the Internet community.  It does not specify any standard. [FYI 4]},
  doi="10.17487/RFC1206",
  }

@misc{rfc1207,
  author="G.S. Malkin and A.N. Marine and J.K. Reynolds",
  title="{FYI on Questions and Answers: Answers to commonly asked ``experienced Internet user'' questions}",
  howpublished="RFC 1207 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1207",
  pages="1--15",
  year=1991,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1207.txt",
  key="RFC 1207",
  abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF).  The goal is to document the most commonly asked questions and answers in the Internet.  This memo provides information for the Internet community.  It does not specify any standard.},
  doi="10.17487/RFC1207",
  }

@misc{rfc1208,
  author="O.J. Jacobsen and D.C. Lynch",
  title="{A Glossary of Networking Terms}",
  howpublished="RFC 1208 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1208",
  pages="1--18",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1208.txt",
  key="RFC 1208",
  abstract={This RFC is a glossary adapted from ``The INTEROP Pocket Glossary of Networking Terms'' distributed at Interop '90.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1208",
  }

@misc{rfc1209,
  author="D. Piscitello and J. Lawrence",
  title="{The Transmission of IP Datagrams over the SMDS Service}",
  howpublished="RFC 1209 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1209",
  pages="1--11",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1209.txt",
  key="RFC 1209",
  abstract={This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]},
  keywords="IP-SMDS, Switched Multi-megabit Data Service",
  doi="10.17487/RFC1209",
  }

@misc{rfc1210,
  author="V.G. Cerf and P.T. Kirstein and B. Randell",
  title="{Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990}",
  howpublished="RFC 1210 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1210",
  pages="1--36",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1210.txt",
  key="RFC 1210",
  abstract={This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1210",
  }

@misc{rfc1211,
  author="A. Westine and J. Postel",
  title="{Problems with the maintenance of large mailing lists}",
  howpublished="RFC 1211 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1211",
  pages="1--54",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1211.txt",
  key="RFC 1211",
  abstract={This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1211",
  }

@misc{rfc1212,
  author="M.T. Rose and K. McCloghrie",
  title="{Concise MIB definitions}",
  howpublished="RFC 1212 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1212",
  pages="1--19",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1212.txt",
  key="RFC 1212",
  abstract={This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules.  This memo defines a format for producing MIB modules. [STANDARDS-TRACK]},
  keywords="Concise-MIB",
  doi="10.17487/RFC1212",
  }

@misc{rfc1213,
  author="K. McCloghrie and M. Rose",
  title="{Management Information Base for Network Management of TCP/IP-based internets: MIB-II}",
  howpublished="RFC 1213 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1213",
  pages="1--70",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2011, 2012, 2013",
url="https://www.rfc-editor.org/rfc/rfc1213.txt",
  key="RFC 1213",
  abstract={This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]},
  keywords="MIB-II",
  doi="10.17487/RFC1213",
  }

@misc{rfc1214,
  author="L. LaBarre",
  title="{OSI internet management: Management Information Base}",
  howpublished="RFC 1214 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1214",
  pages="1--83",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1214.txt",
  key="RFC 1214",
  abstract={This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification.  It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]},
  keywords="OIM-MIB-II",
  doi="10.17487/RFC1214",
  }

@misc{rfc1215,
  author="M.T. Rose",
  title="{Convention for defining traps for use with the SNMP}",
  howpublished="RFC 1215 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1215",
  pages="1--9",
  year=1991,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1215.txt",
  key="RFC 1215",
  abstract={This memo suggests a straight-forward approach towards defining traps used with the SNMP.  This memo provides information for the Internet community.  It does not specify any standard.},
  keywords="SNMP-TRAPS",
  doi="10.17487/RFC1215",
  }

@misc{rfc1216,
  author="P. Richard and P. Kynikos",
  title="{Gigabit network economics and paradigm shifts}",
  howpublished="RFC 1216 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1216",
  pages="1--4",
  year=1991,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1216.txt",
  key="RFC 1216",
  abstract={This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]},
  doi="10.17487/RFC1216",
  }

@misc{rfc1217,
  author="V.G. Cerf",
  title="{Memo from the Consortium for Slow Commotion Research (CSCR)}",
  howpublished="RFC 1217 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1217",
  pages="1--5",
  year=1991,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1217.txt",
  key="RFC 1217",
  abstract={This RFC is in response to RFC 1216, ``Gigabit Network Economics and Paradigm Shifts''.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1217",
  }

@misc{rfc1218,
  author="North American Directory Forum",
  title="{Naming scheme for c=US}",
  howpublished="RFC 1218 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1218",
  pages="1--23",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1255, 1417",
url="https://www.rfc-editor.org/rfc/rfc1218.txt",
  key="RFC 1218",
  abstract={This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF).  As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1218",
  }

@misc{rfc1219,
  author="P.F. Tsuchiya",
  title="{On the assignment of subnet numbers}",
  howpublished="RFC 1219 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1219",
  pages="1--13",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1219.txt",
  key="RFC 1219",
  abstract={This memo suggests a new procedure for assigning subnet numbers.  Use of this assignment technique within a network would be a purely local matter, and would not effect other networks.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="SUBNETASGN",
  doi="10.17487/RFC1219",
  }

@misc{rfc1220,
  author="F. Baker",
  title="{Point-to-Point Protocol extensions for bridging}",
  howpublished="RFC 1220 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1220",
  pages="1--18",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1638",
url="https://www.rfc-editor.org/rfc/rfc1220.txt",
  key="RFC 1220",
  abstract={This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]},
  doi="10.17487/RFC1220",
  }

@misc{rfc1221,
  author="W. Edmond",
  title="{Host Access Protocol (HAP) specification: Version 2}",
  howpublished="RFC 1221 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1221",
  pages="1--68",
  year=1991,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1221.txt",
  key="RFC 1221",
  abstract={This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="HAP2",
  doi="10.17487/RFC1221",
  }

@misc{rfc1222,
  author="H.W. Braun and Y. Rekhter",
  title="{Advancing the NSFNET routing architecture}",
  howpublished="RFC 1222 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1222",
  pages="1--6",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1222.txt",
  key="RFC 1222",
  abstract={This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1222",
  }

@misc{rfc1223,
  author="J.M. Halpern",
  title="{OSI CLNS and LLC1 protocols on Network Systems HYPERchannel}",
  howpublished="RFC 1223 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1223",
  pages="1--12",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1223.txt",
  key="RFC 1223",
  abstract={The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="OSI-HYPER",
  doi="10.17487/RFC1223",
  }

@misc{rfc1224,
  author="L. Steinberg",
  title="{Techniques for managing asynchronously generated alerts}",
  howpublished="RFC 1224 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1224",
  pages="1--22",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1224.txt",
  key="RFC 1224",
  abstract={This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols.  This memo specifies an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="ALERTS",
  doi="10.17487/RFC1224",
  }

@misc{rfc1225,
  author="M.T. Rose",
  title="{Post Office Protocol: Version 3}",
  howpublished="RFC 1225 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1225",
  pages="1--16",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1460",
url="https://www.rfc-editor.org/rfc/rfc1225.txt",
  key="RFC 1225",
  abstract={This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]},
  doi="10.17487/RFC1225",
  }

@misc{rfc1226,
  author="B. Kantor",
  title="{Internet protocol encapsulation of AX.25 frames}",
  howpublished="RFC 1226 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1226",
  pages="1--2",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1226.txt",
  key="RFC 1226",
  abstract={This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets.  This technique is an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="IP-AX.25",
  doi="10.17487/RFC1226",
  }

@misc{rfc1227,
  author="M.T. Rose",
  title="{SNMP MUX protocol and MIB}",
  howpublished="RFC 1227 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1227",
  pages="1--13",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1227.txt",
  key="RFC 1227",
  abstract={This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB.  This mechanism would be local to the host.This is an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="SNMP-MUX",
  doi="10.17487/RFC1227",
  }

@misc{rfc1228,
  author="G. Carpenter and B. Wijnen",
  title="{SNMP-DPI: Simple Network Management Protocol Distributed Program Interface}",
  howpublished="RFC 1228 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1228",
  pages="1--50",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1592",
url="https://www.rfc-editor.org/rfc/rfc1228.txt",
  key="RFC 1228",
  abstract={This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs.  This is an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1228",
  }

@misc{rfc1229,
  author="K. McCloghrie",
  title="{Extensions to the generic-interface MIB}",
  howpublished="RFC 1229 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1229",
  pages="1--16",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1573, updated by RFC 1239",
url="https://www.rfc-editor.org/rfc/rfc1229.txt",
  key="RFC 1229",
  abstract={This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]},
  doi="10.17487/RFC1229",
  }

@misc{rfc1230,
  author="K. McCloghrie and R. Fox",
  title="{IEEE 802.4 Token Bus MIB}",
  howpublished="RFC 1230 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1230",
  pages="1--23",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1239",
url="https://www.rfc-editor.org/rfc/rfc1230.txt",
  key="RFC 1230",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]},
  keywords="802.4-MIP",
  doi="10.17487/RFC1230",
  }

@misc{rfc1231,
  author="K. McCloghrie and R. Fox and E. Decker",
  title="{IEEE 802.5 Token Ring MIB}",
  howpublished="RFC 1231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1231",
  pages="1--23",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1743, 1748, updated by RFC 1239",
url="https://www.rfc-editor.org/rfc/rfc1231.txt",
  key="RFC 1231",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]},
  doi="10.17487/RFC1231",
  }

@misc{rfc1232,
  author="F. Baker and C.P. Kolb",
  title="{Definitions of managed objects for the DS1 Interface type}",
  howpublished="RFC 1232 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1232",
  pages="1--28",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1406, updated by RFC 1239",
url="https://www.rfc-editor.org/rfc/rfc1232.txt",
  key="RFC 1232",
  doi="10.17487/RFC1232",
  }

@misc{rfc1233,
  author="T.A. Cox and K. Tesink",
  title="{Definitions of managed objects for the DS3 Interface type}",
  howpublished="RFC 1233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1233",
  pages="1--23",
  year=1991,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1407, updated by RFC 1239",
url="https://www.rfc-editor.org/rfc/rfc1233.txt",
  key="RFC 1233",
  abstract={This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]},
  doi="10.17487/RFC1233",
  }

@misc{rfc1234,
  author="D. Provan",
  title="{Tunneling IPX traffic through IP networks}",
  howpublished="RFC 1234 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1234",
  pages="1--6",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1234.txt",
  key="RFC 1234",
  abstract={This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]},
  keywords="IPX-IP",
  doi="10.17487/RFC1234",
  }

@misc{rfc1235,
  author="J. Ioannidis and G. Maguire",
  title="{Coherent File Distribution Protocol}",
  howpublished="RFC 1235 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1235",
  pages="1--12",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1235.txt",
  key="RFC 1235",
  abstract={This memo describes the Coherent File Distribution Protocol (CFDP).  This is an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="CFDP",
  doi="10.17487/RFC1235",
  }

@misc{rfc1236,
  author="L. Morales and P. Hasse",
  title="{IP to X.121 address mapping for DDN}",
  howpublished="RFC 1236 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1236",
  pages="1--7",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1236.txt",
  key="RFC 1236",
  abstract={This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="IP-X.121",
  doi="10.17487/RFC1236",
  }

@misc{rfc1237,
  author="R. Colella and E. Gardner and R. Callon",
  title="{Guidelines for OSI NSAP Allocation in the Internet}",
  howpublished="RFC 1237 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1237",
  pages="1--48",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1629",
url="https://www.rfc-editor.org/rfc/rfc1237.txt",
  key="RFC 1237",
  abstract={This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]},
  doi="10.17487/RFC1237",
  }

@misc{rfc1238,
  author="G. Satz",
  title="{CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)}",
  howpublished="RFC 1238 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1238",
  pages="1--32",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1238.txt",
  key="RFC 1238",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  This is an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="CLNS-MIB",
  doi="10.17487/RFC1238",
  }

@misc{rfc1239,
  author="J.K. Reynolds",
  title="{Reassignment of experimental MIBs to standard MIBs}",
  howpublished="RFC 1239 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1239",
  pages="1--2",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1239.txt",
  key="RFC 1239",
  abstract={This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]},
  keywords="STD-MIBs",
  doi="10.17487/RFC1239",
  }

@misc{rfc1240,
  author="C. Shue and W. Haggerty and K. Dobbins",
  title="{OSI connectionless transport services on top of UDP: Version 1}",
  howpublished="RFC 1240 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1240",
  pages="1--8",
  year=1991,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1240.txt",
  key="RFC 1240",
  abstract={This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]},
  keywords="OSI-UDP",
  doi="10.17487/RFC1240",
  }

@misc{rfc1241,
  author="R.A. Woodburn and D.L. Mills",
  title="{Scheme for an internet encapsulation protocol: Version 1}",
  howpublished="RFC 1241 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1241",
  pages="1--17",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1241.txt",
  key="RFC 1241",
  abstract={This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="IN-ENCAP",
  doi="10.17487/RFC1241",
  }

@misc{rfc1242,
  author="S. Bradner",
  title="{Benchmarking Terminology for Network Interconnection Devices}",
  howpublished="RFC 1242 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1242",
  pages="1--12",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6201",
url="https://www.rfc-editor.org/rfc/rfc1242.txt",
  key="RFC 1242",
  abstract={This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1242",
  }

@misc{rfc1243,
  author="S. Waldbusser",
  title="{AppleTalk Management Information Base}",
  howpublished="RFC 1243 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1243",
  pages="1--29",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1742",
url="https://www.rfc-editor.org/rfc/rfc1243.txt",
  key="RFC 1243",
  abstract={This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]},
  doi="10.17487/RFC1243",
  }

@misc{rfc1244,
  author="J.P. Holbrook and J.K. Reynolds",
  title="{Site Security Handbook}",
  howpublished="RFC 1244 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1244",
  pages="1--101",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2196",
url="https://www.rfc-editor.org/rfc/rfc1244.txt",
  key="RFC 1244",
  abstract={This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet.  This FYI RFC provides information for the Internet community.  It does not specify an Internet standard. [FYI 8]},
  doi="10.17487/RFC1244",
  }

@misc{rfc1245,
  author="J. Moy",
  title="{OSPF Protocol Analysis}",
  howpublished="RFC 1245 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1245",
  pages="1--12",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1245.txt",
  key="RFC 1245",
  abstract={This report attempts to summarize the key features of OSPF V2.  It also attempts to analyze how the protocol will perform and scale in the Internet.  This memo provides information for the Internet community.  It does not specify any Internet standard.},
  keywords="OSPF, SPF, routing, TOS, LSA, flooding",
  doi="10.17487/RFC1245",
  }

@misc{rfc1246,
  author="J. Moy",
  title="{Experience with the OSPF Protocol}",
  howpublished="RFC 1246 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1246",
  pages="1--31",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1246.txt",
  key="RFC 1246",
  abstract={This report documents experience with OSPF V2.  This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations.  This memo provides information for the Internet community.  It does not specify any Internet standard.},
  keywords="OSPF, SPF, routing, MIB, experience, testing",
  doi="10.17487/RFC1246",
  }

@misc{rfc1247,
  author="J. Moy",
  title="{OSPF Version 2}",
  howpublished="RFC 1247 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1247",
  pages="1--189",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1583, updated by RFC 1349",
url="https://www.rfc-editor.org/rfc/rfc1247.txt",
  key="RFC 1247",
  abstract={This memo documents version 2 of the OSPF protocol.  OSPF is a link- state based routing protocol. [STANDARDS-TRACK]},
  keywords="equal-cost, multipath, link state, LSA",
  doi="10.17487/RFC1247",
  }

@misc{rfc1248,
  author="F. Baker and R. Coltun",
  title="{OSPF Version 2 Management Information Base}",
  howpublished="RFC 1248 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1248",
  pages="1--42",
  year=1991,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1252, updated by RFC 1349",
url="https://www.rfc-editor.org/rfc/rfc1248.txt",
  key="RFC 1248",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]},
  keywords="OSPF, SPF, MIB, routing, network management",
  doi="10.17487/RFC1248",
  }

@misc{rfc1249,
  author="T. Howes and M. Smith and B. Beecher",
  title="{DIXIE Protocol Specification}",
  howpublished="RFC 1249 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1249",
  pages="1--10",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1249.txt",
  key="RFC 1249",
  abstract={This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP.  This memo provides information for the Internet community.  It does not specify any standard.},
  keywords="DIXIE, DIXIE, protocol, directory services, X.500, DAP",
  doi="10.17487/RFC1249",
  }

@misc{rfc1250,
  author="J. Postel",
  title="{IAB Official Protocol Standards}",
  howpublished="RFC 1250 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1250",
  pages="1--28",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2200, 1280",
url="https://www.rfc-editor.org/rfc/rfc1250.txt",
  key="RFC 1250",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="standards, protocol, IAB",
  doi="10.17487/RFC1250",
  }

@misc{rfc1251,
  author="G. Malkin",
  title="{Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members}",
  howpublished="RFC 1251 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1251",
  pages="1--26",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1336",
url="https://www.rfc-editor.org/rfc/rfc1251.txt",
  key="RFC 1251",
  abstract={This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF).  This memo provides information for the Internet community.  It does not specify an Internet standard. [FYI 9]},
  keywords="IESG, IRSG, IAB",
  doi="10.17487/RFC1251",
  }

@misc{rfc1252,
  author="F. Baker and R. Coltun",
  title="{OSPF Version 2 Management Information Base}",
  howpublished="RFC 1252 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1252",
  pages="1--42",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1253",
url="https://www.rfc-editor.org/rfc/rfc1252.txt",
  key="RFC 1252",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]},
  keywords="OSPF, SPF, MIB, routing, network management",
  doi="10.17487/RFC1252",
  }

@misc{rfc1253,
  author="F. Baker and R. Coltun",
  title="{OSPF Version 2 Management Information Base}",
  howpublished="RFC 1253 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1253",
  pages="1--42",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1850",
url="https://www.rfc-editor.org/rfc/rfc1253.txt",
  key="RFC 1253",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]},
  doi="10.17487/RFC1253",
  }

@misc{rfc1254,
  author="A. Mankin and K. Ramakrishnan",
  title="{Gateway Congestion Control Survey}",
  howpublished="RFC 1254 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1254",
  pages="1--25",
  year=1991,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1254.txt",
  key="RFC 1254",
  abstract={The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation.  Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.},
  keywords="gateway, congestion, SQ, source quench, fiar queueing, random drop",
  doi="10.17487/RFC1254",
  }

@misc{rfc1255,
  author="The North American Directory Forum",
  title="{A Naming Scheme for c=US}",
  howpublished="RFC 1255 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1255",
  pages="1--25",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1417",
url="https://www.rfc-editor.org/rfc/rfc1255.txt",
  key="RFC 1255",
  abstract={This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="naming, NADF, X.500, directory services, c=us",
  doi="10.17487/RFC1255",
  }

@misc{rfc1256,
  author="S. Deering",
  title="{ICMP Router Discovery Messages}",
  howpublished="RFC 1256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1256",
  pages="1--19",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1256.txt",
  key="RFC 1256",
  abstract={This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]},
  keywords="ICMP-ROUT, ICMP, router, gateway, discovery, standard, protocol",
  doi="10.17487/RFC1256",
  }

@misc{rfc1257,
  author="C. Partridge",
  title="{Isochronous applications do not require jitter-controlled networks}",
  howpublished="RFC 1257 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1257",
  pages="1--5",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1257.txt",
  key="RFC 1257",
  abstract={This memo argues that jitter control is not required for networks to support isochronous applications.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1257",
  }

@misc{rfc1258,
  author="B. Kantor",
  title="{BSD Rlogin}",
  howpublished="RFC 1258 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1258",
  pages="1--5",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1282",
url="https://www.rfc-editor.org/rfc/rfc1258.txt",
  key="RFC 1258",
  abstract={The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1258",
  }

@misc{rfc1259,
  author="M. Kapor",
  title="{Building the open road: The NREN as test-bed for the national public network}",
  howpublished="RFC 1259 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1259",
  pages="1--23",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1259.txt",
  key="RFC 1259",
  abstract={This memo discusses the background and importance of NREN.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NREN, test-bed, network policy",
  doi="10.17487/RFC1259",
  }

@misc{rfc1261,
  author="S. Williamson and L. Nobile",
  title="{Transition of Nic Services}",
  howpublished="RFC 1261 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1261",
  pages="1--3",
  year=1991,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1261.txt",
  key="RFC 1261",
  abstract={This memo outlines the transition of NIC Services.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NIC, transition",
  doi="10.17487/RFC1261",
  }

@misc{rfc1262,
  author="V.G. Cerf",
  title="{Guidelines for Internet Measurement Activities}",
  howpublished="RFC 1262 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1262",
  pages="1--3",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1262.txt",
  key="RFC 1262",
  abstract={This RFC represents IAB guidance for researchers considering measurement experiments on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1262",
  }

@misc{rfc1263,
  author="S. O'Malley and L.L. Peterson",
  title="{TCP Extensions Considered Harmful}",
  howpublished="RFC 1263 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1263",
  pages="1--19",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1263.txt",
  key="RFC 1263",
  abstract={This RFC comments on recent proposals to extend TCP.  It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1263",
  }

@misc{rfc1264,
  author="R.M. Hinden",
  title="{Internet Engineering Task Force Internet Routing Protocol Standardization Criteria}",
  howpublished="RFC 1264 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1264",
  pages="1--8",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4794",
url="https://www.rfc-editor.org/rfc/rfc1264.txt",
  key="RFC 1264",
  abstract={This informational RFC presents procedures for creating and documenting Internet standards on routing protocols.  These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG).  This memo provides information for the Internet community.  It does not specifiy an Internet standard.},
  doi="10.17487/RFC1264",
  }

@misc{rfc1265,
  author="Y. Rekhter",
  title="{BGP Protocol Analysis}",
  howpublished="RFC 1265 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1265",
  pages="1--8",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1265.txt",
  key="RFC 1265",
  abstract={This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1265",
  }

@misc{rfc1266,
  author="Y. Rekhter",
  title="{Experience with the BGP Protocol}",
  howpublished="RFC 1266 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1266",
  pages="1--9",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1266.txt",
  key="RFC 1266",
  abstract={The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1266",
  }

@misc{rfc1267,
  author="K. Lougheed and Y. Rekhter",
  title="{Border Gateway Protocol 3 (BGP-3)}",
  howpublished="RFC 1267 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1267",
  pages="1--35",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1267.txt",
  key="RFC 1267",
  abstract={This memo, together with its companion document, ``Application of the Border Gateway Protocol in the Internet'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="BGP3",
  doi="10.17487/RFC1267",
  }

@misc{rfc1268,
  author="Y. Rekhter and P. Gross",
  title="{Application of the Border Gateway Protocol in the Internet}",
  howpublished="RFC 1268 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1268",
  pages="1--13",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1655",
url="https://www.rfc-editor.org/rfc/rfc1268.txt",
  key="RFC 1268",
  abstract={This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]},
  keywords="BGP3",
  doi="10.17487/RFC1268",
  }

@misc{rfc1269,
  author="S. Willis and J.W. Burruss",
  title="{Definitions of Managed Objects for the Border Gateway Protocol: Version 3}",
  howpublished="RFC 1269 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1269",
  pages="1--13",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4273",
url="https://www.rfc-editor.org/rfc/rfc1269.txt",
  key="RFC 1269",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]},
  keywords="BGP-MIB",
  doi="10.17487/RFC1269",
  }

@misc{rfc1270,
  author="F. Kastenholz",
  title="{SNMP Communications Services}",
  howpublished="RFC 1270 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1270",
  pages="1--11",
  year=1991,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1270.txt",
  key="RFC 1270",
  abstract={This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1270",
  }

@misc{rfc1271,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base}",
  howpublished="RFC 1271 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1271",
  pages="1--81",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1757, updated by RFC 1513",
url="https://www.rfc-editor.org/rfc/rfc1271.txt",
  key="RFC 1271",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]},
  doi="10.17487/RFC1271",
  }

@misc{rfc1272,
  author="C. Mills and D. Hirsh and G.R. Ruth",
  title="{Internet Accounting: Background}",
  howpublished="RFC 1272 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1272",
  pages="1--19",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1272.txt",
  key="RFC 1272",
  abstract={This document provides background information for the ``Internet Accounting Architecture''.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1272",
  }

@misc{rfc1273,
  author="M.F. Schwartz",
  title="{Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations}",
  howpublished="RFC 1273 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1273",
  pages="1--8",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1273.txt",
  key="RFC 1273",
  abstract={This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1273",
  }

@misc{rfc1274,
  author="P. Barker and S. Kille",
  title="{The COSINE and Internet X.500 Schema}",
  howpublished="RFC 1274 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1274",
  pages="1--60",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4524",
url="https://www.rfc-editor.org/rfc/rfc1274.txt",
  key="RFC 1274",
  abstract={This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]},
  keywords="Naming",
  doi="10.17487/RFC1274",
  }

@misc{rfc1275,
  author="S.E. Hardcastle-Kille",
  title="{Replication Requirements to provide an Internet Directory using X.500}",
  howpublished="RFC 1275 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1275",
  pages="1--3",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1275.txt",
  key="RFC 1275",
  abstract={This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88].  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1275",
  }

@misc{rfc1276,
  author="S.E. Hardcastle-Kille",
  title="{Replication and Distributed Operations extensions to provide an Internet Directory using X.500}",
  howpublished="RFC 1276 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1276",
  pages="1--17",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1276.txt",
  key="RFC 1276",
  abstract={Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988).  This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC1276",
  }

@misc{rfc1277,
  author="S.E. Hardcastle-Kille",
  title="{Encoding Network Addresses to Support Operation over Non-OSI Lower Layers}",
  howpublished="RFC 1277 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1277",
  pages="1--12",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1277.txt",
  key="RFC 1277",
  abstract={This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]},
  keywords="address ISO OSI",
  doi="10.17487/RFC1277",
  }

@misc{rfc1278,
  author="S.E. Hardcastle-Kille",
  title="{A string encoding of Presentation Address}",
  howpublished="RFC 1278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1278",
  pages="1--7",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1278.txt",
  key="RFC 1278",
  abstract={There are a number of environments where a simple string encoding of Presentation Address is desirable.  This specification defines such a representation.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="OSI, ASN.1",
  doi="10.17487/RFC1278",
  }

@misc{rfc1279,
  author="S.E. Hardcastle-Kille",
  title="{X.500 and Domains}",
  howpublished="RFC 1279 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1279",
  pages="1--15",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1279.txt",
  key="RFC 1279",
  abstract={This RFC considers X.500 in relation to Internet and UK Domains.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="Domain, Name, naming",
  doi="10.17487/RFC1279",
  }

@misc{rfc1280,
  author="J. Postel",
  title="{IAB Official Protocol Standards}",
  howpublished="RFC 1280 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1280",
  pages="1--32",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1360",
url="https://www.rfc-editor.org/rfc/rfc1280.txt",
  key="RFC 1280",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1280",
  }

@misc{rfc1281,
  author="R. Pethia and S. Crocker and B. Fraser",
  title="{Guidelines for the Secure Operation of the Internet}",
  howpublished="RFC 1281 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1281",
  pages="1--10",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1281.txt",
  key="RFC 1281",
  abstract={The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="security, privacy, protection, guideline",
  doi="10.17487/RFC1281",
  }

@misc{rfc1282,
  author="B. Kantor",
  title="{BSD Rlogin}",
  howpublished="RFC 1282 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1282",
  pages="1--5",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1282.txt",
  key="RFC 1282",
  abstract={This memo documents an existing protocol and common implementation that is extensively used on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="BSD Login, Unix, remote-login, remote-logon",
  doi="10.17487/RFC1282",
  }

@misc{rfc1283,
  author="M. Rose",
  title="{SNMP over OSI}",
  howpublished="RFC 1283 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1283",
  pages="1--8",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1418",
url="https://www.rfc-editor.org/rfc/rfc1283.txt",
  key="RFC 1283",
  abstract={This memo describes mappings from the SNMP onto both the COTS and the CLTS.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet Standard.},
  keywords="ISO, Management, MIB",
  doi="10.17487/RFC1283",
  }

@misc{rfc1284,
  author="J. Cook",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 1284 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1284",
  pages="1--21",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1398",
url="https://www.rfc-editor.org/rfc/rfc1284.txt",
  key="RFC 1284",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]},
  keywords="SNMP, MIB, Management",
  doi="10.17487/RFC1284",
  }

@misc{rfc1285,
  author="J. Case",
  title="{FDDI Management Information Base}",
  howpublished="RFC 1285 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1285",
  pages="1--46",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1512",
url="https://www.rfc-editor.org/rfc/rfc1285.txt",
  key="RFC 1285",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]},
  keywords="FDDI-MIB, standard, standards, MIB, SNMP",
  doi="10.17487/RFC1285",
  }

@misc{rfc1286,
  author="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie",
  title="{Definitions of Managed Objects for Bridges}",
  howpublished="RFC 1286 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1286",
  pages="1--40",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1493, 1525",
url="https://www.rfc-editor.org/rfc/rfc1286.txt",
  key="RFC 1286",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments.  This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]},
  keywords="SNMP, MIB, standard, standards",
  doi="10.17487/RFC1286",
  }

@misc{rfc1287,
  author="D. Clark and L. Chapin and V. Cerf and R. Braden and R. Hobby",
  title="{Towards the Future Internet Architecture}",
  howpublished="RFC 1287 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1287",
  pages="1--29",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1287.txt",
  key="RFC 1287",
  abstract={This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1287",
  }

@misc{rfc1288,
  author="D. Zimmerman",
  title="{The Finger User Information Protocol}",
  howpublished="RFC 1288 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1288",
  pages="1--12",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1288.txt",
  key="RFC 1288",
  abstract={This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]},
  keywords="FINGER",
  doi="10.17487/RFC1288",
  }

@misc{rfc1289,
  author="J. Saperia",
  title="{DECnet Phase IV MIB Extensions}",
  howpublished="RFC 1289 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1289",
  pages="1--64",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1559",
url="https://www.rfc-editor.org/rfc/rfc1289.txt",
  key="RFC 1289",
  abstract={This memo is an extension to the SNMP MIB.  This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]},
  keywords="SNMP, Management, protocol, standard, standards",
  doi="10.17487/RFC1289",
  }

@misc{rfc1290,
  author="J. Martin",
  title="{There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places}",
  howpublished="RFC 1290 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1290",
  pages="1--27",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1402",
url="https://www.rfc-editor.org/rfc/rfc1290.txt",
  key="RFC 1290",
  abstract={This paper will present some of the ``gold nuggets'' of information and file repositories on the network that could be of use to end users.  This RFC provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="SIGUCCS, User Services, Help, Internet",
  doi="10.17487/RFC1290",
  }

@misc{rfc1291,
  author="V. Aggarwal",
  title="{Mid-Level Networks Potential Technical Services}",
  howpublished="RFC 1291 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1291",
  pages="1--10",
  year=1991,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1291.txt",
  key="RFC 1291",
  abstract={This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks.  This RFC provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="statistics, connectivity, management",
  doi="10.17487/RFC1291",
  }

@misc{rfc1292,
  author="R. Lang and R. Wright",
  title="{A Catalog of Available X.500 Implementations}",
  howpublished="RFC 1292 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1292",
  pages="1--103",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1632",
url="https://www.rfc-editor.org/rfc/rfc1292.txt",
  key="RFC 1292",
  abstract={The goal of this document is to provide information regarding the availability and capability of implementations of X.500.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1292",
  }

@misc{rfc1293,
  author="T. Bradley and C. Brown",
  title="{Inverse Address Resolution Protocol}",
  howpublished="RFC 1293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1293",
  pages="1--6",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2390",
url="https://www.rfc-editor.org/rfc/rfc1293.txt",
  key="RFC 1293",
  abstract={This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]},
  keywords="standard, standards, ARP, DLCI",
  doi="10.17487/RFC1293",
  }

@misc{rfc1294,
  author="T. Bradley and C. Brown and A. Malis",
  title="{Multiprotocol Interconnect over Frame Relay}",
  howpublished="RFC 1294 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1294",
  pages="1--28",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1490, 2427",
url="https://www.rfc-editor.org/rfc/rfc1294.txt",
  key="RFC 1294",
  abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone.  It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]},
  keywords="standard, standards",
  doi="10.17487/RFC1294",
  }

@misc{rfc1295,
  author="The North American Directory Forum",
  title="{User Bill of Rights for entries and listings in the Public Directory}",
  howpublished="RFC 1295 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1295",
  pages="1--2",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1417",
url="https://www.rfc-editor.org/rfc/rfc1295.txt",
  key="RFC 1295",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects.  This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NADF-265, NADF, X.500",
  doi="10.17487/RFC1295",
  }

@misc{rfc1296,
  author="M. Lottor",
  title="{Internet Growth (1981-1991)}",
  howpublished="RFC 1296 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1296",
  pages="1--9",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1296.txt",
  key="RFC 1296",
  abstract={This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables.  This memo provides information for the Internet community.  It does not specify an Internet standard.  This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]},
  keywords="statistics, ZONE",
  doi="10.17487/RFC1296",
  }

@misc{rfc1297,
  author="D. Johnson",
  title="{NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist (``NOC TT REQUIREMENTS'')}",
  howpublished="RFC 1297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1297",
  pages="1--12",
  year=1992,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1297.txt",
  key="RFC 1297",
  abstract={This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="problems, tracking, operations, NOC",
  doi="10.17487/RFC1297",
  }

@misc{rfc1298,
  author="R. Wormley and S. Bostock",
  title="{SNMP over IPX}",
  howpublished="RFC 1298 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1298",
  pages="1--5",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1420",
url="https://www.rfc-editor.org/rfc/rfc1298.txt",
  key="RFC 1298",
  abstract={This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1298",
  }

@misc{rfc1299,
  author="M. Kennedy",
  title="{Summary of 1200-1299}",
  howpublished="RFC 1299 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1299",
  pages="1--20",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1299.txt",
  key="RFC 1299",
  keywords="Index",
  doi="10.17487/RFC1299",
  }

@misc{rfc1300,
  author="S. Greenfield",
  title="{Remembrances of Things Past}",
  howpublished="RFC 1300 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1300",
  pages="1--4",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1300.txt",
  key="RFC 1300",
  abstract={Poem.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="poem",
  doi="10.17487/RFC1300",
  }

@misc{rfc1301,
  author="S. Armstrong and A. Freier and K. Marzullo",
  title="{Multicast Transport Protocol}",
  howpublished="RFC 1301 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1301",
  pages="1--38",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1301.txt",
  key="RFC 1301",
  abstract={This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures.  The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members.  It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="MTP, MTP, reliable transport, multicast, broadcast, collaboration, networking",
  doi="10.17487/RFC1301",
  }

@misc{rfc1302,
  author="D. Sitzler and P. Smith and A. Marine",
  title="{Building a Network Information Services Infrastructure}",
  howpublished="RFC 1302 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1302",
  pages="1--13",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1302.txt",
  key="RFC 1302",
  abstract={This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NISI, NIC, User Services",
  doi="10.17487/RFC1302",
  }

@misc{rfc1303,
  author="K. McCloghrie and M. Rose",
  title="{A Convention for Describing SNMP-based Agents}",
  howpublished="RFC 1303 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1303",
  pages="1--12",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1303.txt",
  key="RFC 1303",
  abstract={This memo suggests a straight-forward approach towards describing SNMP- based agents.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="SNMP, MIB, Network Management,",
  doi="10.17487/RFC1303",
  }

@misc{rfc1304,
  author="T. Cox and K. Tesink",
  title="{Definitions of Managed Objects for the SIP Interface Type}",
  howpublished="RFC 1304 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1304",
  pages="1--25",
  year=1992,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1694",
url="https://www.rfc-editor.org/rfc/rfc1304.txt",
  key="RFC 1304",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]},
  keywords="Standard, MIB, Network Management, SMDS",
  doi="10.17487/RFC1304",
  }

@misc{rfc1305,
  author="D. Mills",
  title="{Network Time Protocol (Version 3) Specification, Implementation and Analysis}",
  howpublished="RFC 1305 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1305",
  pages="1--109",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5905",
url="https://www.rfc-editor.org/rfc/rfc1305.txt",
  key="RFC 1305",
  abstract={This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]},
  keywords="NTPV3, NTP",
  doi="10.17487/RFC1305",
  }

@misc{rfc1306,
  author="A. Nicholson and J. Young",
  title="{Experiences Supporting By-Request Circuit-Switched T3 Networks}",
  howpublished="RFC 1306 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1306",
  pages="1--10",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1306.txt",
  key="RFC 1306",
  abstract={This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services.  While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.  This RFC provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="WAN, Wide Area Net, FDDI",
  doi="10.17487/RFC1306",
  }

@misc{rfc1307,
  author="J. Young and A. Nicholson",
  title="{Dynamically Switched Link Control Protocol}",
  howpublished="RFC 1307 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1307",
  pages="1--13",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1307.txt",
  key="RFC 1307",
  abstract={This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services.  The protocol is used for the control of network connections external to a host, but known to the host.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DSLCP, Experimental Protocol, T3, FDDI",
  doi="10.17487/RFC1307",
  }

@misc{rfc1308,
  author="C. Weider and J. Reynolds",
  title="{Executive Introduction to Directory Services Using the X.500 Protocol}",
  howpublished="RFC 1308 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1308",
  pages="1--4",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1308.txt",
  key="RFC 1308",
  abstract={This document is an Executive Introduction to Directory Services using the X.500 protocol.  It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1308",
  }

@misc{rfc1309,
  author="C. Weider and J. Reynolds and S. Heker",
  title="{Technical Overview of Directory Services Using the X.500 Protocol}",
  howpublished="RFC 1309 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1309",
  pages="1--16",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1309.txt",
  key="RFC 1309",
  abstract={This document is an overview of the X.500 standard for people not familiar with the technology.  It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet.  This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1309",
  }

@misc{rfc1310,
  author="L. Chapin",
  title="{The Internet Standards Process}",
  howpublished="RFC 1310 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1310",
  pages="1--23",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1602",
url="https://www.rfc-editor.org/rfc/rfc1310.txt",
  key="RFC 1310",
  abstract={This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]},
  doi="10.17487/RFC1310",
  }

@misc{rfc1311,
  author="J. Postel",
  title="{Introduction to the STD Notes}",
  howpublished="RFC 1311 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1311",
  pages="1--5",
  year=1992,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1311.txt",
  key="RFC 1311",
  abstract={The STDs are a subseries of notes within the RFC series that are the Internet standards.  The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]},
  keywords="new, IAB",
  doi="10.17487/RFC1311",
  }

@misc{rfc1312,
  author="R. Nelson and G. Arnold",
  title="{Message Send Protocol 2}",
  howpublished="RFC 1312 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1312",
  pages="1--8",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1312.txt",
  key="RFC 1312",
  abstract={The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MSP2, MSP, talk",
  doi="10.17487/RFC1312",
  }

@misc{rfc1313,
  author="C. Partridge",
  title="{Today's Programming for KRFC AM 1313 Internet Talk Radio}",
  howpublished="RFC 1313 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1313",
  pages="1--3",
  year=1992,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1313.txt",
  key="RFC 1313",
  abstract={Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1313",
  }

@misc{rfc1314,
  author="A. Katz and D. Cohen",
  title="{A File Format for the Exchange of Images in the Internet}",
  howpublished="RFC 1314 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1314",
  pages="1--23",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1314.txt",
  key="RFC 1314",
  abstract={This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]},
  keywords="NETFAX, netfax, TIFF, facsimile",
  doi="10.17487/RFC1314",
  }

@misc{rfc1315,
  author="C. Brown and F. Baker and C. Carvalho",
  title="{Management Information Base for Frame Relay DTEs}",
  howpublished="RFC 1315 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1315",
  pages="1--19",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2115",
url="https://www.rfc-editor.org/rfc/rfc1315.txt",
  key="RFC 1315",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Frame Relay. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC1315",
  }

@misc{rfc1316,
  author="B. Stewart",
  title="{Definitions of Managed Objects for Character Stream Devices}",
  howpublished="RFC 1316 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1316",
  pages="1--17",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1658",
url="https://www.rfc-editor.org/rfc/rfc1316.txt",
  key="RFC 1316",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC1316",
  }

@misc{rfc1317,
  author="B. Stewart",
  title="{Definitions of Managed Objects for RS-232-like Hardware Devices}",
  howpublished="RFC 1317 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1317",
  pages="1--17",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1659",
url="https://www.rfc-editor.org/rfc/rfc1317.txt",
  key="RFC 1317",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC1317",
  }

@misc{rfc1318,
  author="B. Stewart",
  title="{Definitions of Managed Objects for Parallel-printer-like Hardware Devices}",
  howpublished="RFC 1318 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1318",
  pages="1--11",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1660",
url="https://www.rfc-editor.org/rfc/rfc1318.txt",
  key="RFC 1318",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC1318",
  }

@misc{rfc1319,
  author="B. Kaliski",
  title="{The MD2 Message-Digest Algorithm}",
  howpublished="RFC 1319 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1319",
  pages="1--17",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6149",
url="https://www.rfc-editor.org/rfc/rfc1319.txt",
  key="RFC 1319",
  abstract={This document describes the MD2 message-digest algorithm.  The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="security, encryption, signature",
  doi="10.17487/RFC1319",
  }

@misc{rfc1320,
  author="R. Rivest",
  title="{The MD4 Message-Digest Algorithm}",
  howpublished="RFC 1320 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1320",
  pages="1--20",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6150",
url="https://www.rfc-editor.org/rfc/rfc1320.txt",
  key="RFC 1320",
  abstract={This document describes the MD4 message-digest algorithm [1].  The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="MD4, security, encryption, signature",
  doi="10.17487/RFC1320",
  }

@misc{rfc1321,
  author="R. Rivest",
  title="{The MD5 Message-Digest Algorithm}",
  howpublished="RFC 1321 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1321",
  pages="1--21",
  year=1992,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6151",
url="https://www.rfc-editor.org/rfc/rfc1321.txt",
  key="RFC 1321",
  abstract={This document describes the MD5 message-digest algorithm.  The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="security, signature, eneryption",
  doi="10.17487/RFC1321",
  }

@misc{rfc1322,
  author="D. Estrin and Y. Rekhter and S. Hotz",
  title="{A Unified Approach to Inter-Domain Routing}",
  howpublished="RFC 1322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1322",
  pages="1--38",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1322.txt",
  key="RFC 1322",
  abstract={This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="path, vector, routing, source, demand, routing",
  doi="10.17487/RFC1322",
  }

@misc{rfc1323,
  author="V. Jacobson and R. Braden and D. Borman",
  title="{TCP Extensions for High Performance}",
  howpublished="RFC 1323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1323",
  pages="1--37",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7323",
url="https://www.rfc-editor.org/rfc/rfc1323.txt",
  key="RFC 1323",
  abstract={This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths.  It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]},
  keywords="TCP-EXT, options, PAWS, window, scale, window",
  doi="10.17487/RFC1323",
  }

@misc{rfc1324,
  author="D. Reed",
  title="{A Discussion on Computer Network Conferencing}",
  howpublished="RFC 1324 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1324",
  pages="1--11",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1324.txt",
  key="RFC 1324",
  abstract={This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="talk, real time, chat",
  doi="10.17487/RFC1324",
  }

@misc{rfc1325,
  author="G. Malkin and A. Marine",
  title="{FYI on Questions and Answers Answers to Commonly asked ``New Internet User'' Questions}",
  howpublished="RFC 1325 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1325",
  pages="1--42",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1594",
url="https://www.rfc-editor.org/rfc/rfc1325.txt",
  key="RFC 1325",
  abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF).  The goal is to document the most commonly asked questions and answers in the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="documentation, help, information",
  doi="10.17487/RFC1325",
  }

@misc{rfc1326,
  author="P. Tsuchiya",
  title="{Mutual Encapsulation Considered Dangerous}",
  howpublished="RFC 1326 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1326",
  pages="1--5",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1326.txt",
  key="RFC 1326",
  abstract={This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="protocol, layering, wrapping",
  doi="10.17487/RFC1326",
  }

@misc{rfc1327,
  author="S. Hardcastle-Kille",
  title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}",
  howpublished="RFC 1327 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1327",
  pages="1--113",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2156, updated by RFC 1495",
url="https://www.rfc-editor.org/rfc/rfc1327.txt",
  key="RFC 1327",
  abstract={This document specifies a mapping between two protocols.  This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community.  This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]},
  keywords="Electronic-mail,Message handling systems",
  doi="10.17487/RFC1327",
  }

@misc{rfc1328,
  author="S. Hardcastle-Kille",
  title="{X.400 1988 to 1984 downgrading}",
  howpublished="RFC 1328 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1328",
  pages="1--5",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1328.txt",
  key="RFC 1328",
  abstract={This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84].  Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components.  This document defines a number of extensions to this annexe. [STANDARDS-TRACK]},
  keywords="Electronic-mail, message handling systems,mail",
  doi="10.17487/RFC1328",
  }

@misc{rfc1329,
  author="P. Kuehn",
  title="{Thoughts on Address Resolution for Dual MAC FDDI Networks}",
  howpublished="RFC 1329 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1329",
  pages="1--28",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc1329.txt",
  key="RFC 1329",
  abstract={In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1329",
  }

@misc{rfc1330,
  author="ESCC X.500/X.400 Task Force and ESnet Site Coordinating Comittee (ESCC) and Energy Sciences Network (ESnet)",
  title="{Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community}",
  howpublished="RFC 1330 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1330",
  pages="1--87",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1330.txt",
  key="RFC 1330",
  abstract={This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1330",
  }

@misc{rfc1331,
  author="W. Simpson",
  title="{The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links}",
  howpublished="RFC 1331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1331",
  pages="1--69",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1548",
url="https://www.rfc-editor.org/rfc/rfc1331.txt",
  key="RFC 1331",
  abstract={This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]},
  keywords="serial line, IP over serial, dial-up",
  doi="10.17487/RFC1331",
  }

@misc{rfc1332,
  author="G. McGregor",
  title="{The PPP Internet Protocol Control Protocol (IPCP)}",
  howpublished="RFC 1332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1332",
  pages="1--14",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3241",
url="https://www.rfc-editor.org/rfc/rfc1332.txt",
  key="RFC 1332",
  abstract={The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]},
  keywords="PPP-IPCP, serial line, IP over serial, dial-up",
  doi="10.17487/RFC1332",
  }

@misc{rfc1333,
  author="W. Simpson",
  title="{PPP Link Quality Monitoring}",
  howpublished="RFC 1333 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1333",
  pages="1--17",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1989",
url="https://www.rfc-editor.org/rfc/rfc1333.txt",
  key="RFC 1333",
  abstract={The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]},
  keywords="serial line, IP over serial, dial-up",
  doi="10.17487/RFC1333",
  }

@misc{rfc1334,
  author="B. Lloyd and W. Simpson",
  title="{PPP Authentication Protocols}",
  howpublished="RFC 1334 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1334",
  pages="1--16",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1994",
url="https://www.rfc-editor.org/rfc/rfc1334.txt",
  key="RFC 1334",
  abstract={This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]},
  keywords="point, serial, line, dial-up",
  doi="10.17487/RFC1334",
  }

@misc{rfc1335,
  author="Z. Wang and J. Crowcroft",
  title="{A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion}",
  howpublished="RFC 1335 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1335",
  pages="1--7",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1335.txt",
  key="RFC 1335",
  abstract={This RFC presents a solution to problem of address space exhaustion in the Internet.  It proposes a two-tier address structure for the Internet.  This is an ``idea'' paper and discussion is strongly encouraged.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="internet, protocol, IP",
  doi="10.17487/RFC1335",
  }

@misc{rfc1336,
  author="G. Malkin",
  title="{Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members}",
  howpublished="RFC 1336 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1336",
  pages="1--33",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1336.txt",
  key="RFC 1336",
  abstract={This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF).  This memo provides information for the Internet community.  It does not specify any standard.},
  keywords="Almquist, Braden, Braun, Callon, Cerf, Chiappa, Chapin, Clark, Crocker, Davin, Estrin, Hobby, Huitema, Huizer, Kent, Lauck, Leiner, Lynch, Piscitello, Postel, Reynolds, Schwartz, Stockman, Vaudreuil",
  doi="10.17487/RFC1336",
  }

@misc{rfc1337,
  author="R. Braden",
  title="{TIME-WAIT Assassination Hazards in TCP}",
  howpublished="RFC 1337 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1337",
  pages="1--11",
  year=1992,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1337.txt",
  key="RFC 1337",
  abstract={This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies.  In particular, one very simple fix is identified.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="TCP protocol, protocol state, graceful close, reset",
  doi="10.17487/RFC1337",
  }

@misc{rfc1338,
  author="V. Fuller and T. Li and J. Yu and K. Varadhan",
  title="{Supernetting: an Address Assignment and Aggregation Strategy}",
  howpublished="RFC 1338 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1338",
  pages="1--20",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1519",
url="https://www.rfc-editor.org/rfc/rfc1338.txt",
  key="RFC 1338",
  abstract={This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="internet address, routing",
  doi="10.17487/RFC1338",
  }

@misc{rfc1339,
  author="S. Dorner and P. Resnick",
  title="{Remote Mail Checking Protocol}",
  howpublished="RFC 1339 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1339",
  pages="1--6",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1339.txt",
  key="RFC 1339",
  abstract={This RFC defines a protocol to provide a mail checking service to be used between a client and server pair.  Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="RMCP, email, remote mail",
  doi="10.17487/RFC1339",
  }

@misc{rfc1340,
  author="J. Reynolds and J. Postel",
  title="{Assigned Numbers}",
  howpublished="RFC 1340 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1340",
  pages="1--139",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1700",
url="https://www.rfc-editor.org/rfc/rfc1340.txt",
  key="RFC 1340",
  abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.  This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.},
  doi="10.17487/RFC1340",
  }

@misc{rfc1341,
  author="N. Borenstein and N. Freed",
  title="{MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies}",
  howpublished="RFC 1341 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1341",
  pages="1--80",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1521",
url="https://www.rfc-editor.org/rfc/rfc1341.txt",
  key="RFC 1341",
  abstract={This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]},
  keywords="EMail, Multimedia",
  doi="10.17487/RFC1341",
  }

@misc{rfc1342,
  author="K. Moore",
  title="{Representation of Non-ASCII Text in Internet Message Headers}",
  howpublished="RFC 1342 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1342",
  pages="1--7",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1522",
url="https://www.rfc-editor.org/rfc/rfc1342.txt",
  key="RFC 1342",
  abstract={This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as ``RFC 1341''), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]},
  keywords="EMail, Character Sets",
  doi="10.17487/RFC1342",
  }

@misc{rfc1343,
  author="N. Borenstein",
  title="{A User Agent Configuration Mechanism for Multimedia Mail Format Information}",
  howpublished="RFC 1343 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1343",
  pages="1--10",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1343.txt",
  key="RFC 1343",
  abstract={This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="EMail, Multimedia",
  doi="10.17487/RFC1343",
  }

@misc{rfc1344,
  author="N. Borenstein",
  title="{Implications of MIME for Internet Mail Gateways}",
  howpublished="RFC 1344 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1344",
  pages="1--9",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1344.txt",
  key="RFC 1344",
  abstract={While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME.  These opportunities are the subject of this memo.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="EMail, Forwarding, Relaying, Fragmentation, Multimedia",
  doi="10.17487/RFC1344",
  }

@misc{rfc1345,
  author="K. Simonsen",
  title="{Character Mnemonics and Character Sets}",
  howpublished="RFC 1345 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1345",
  pages="1--103",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1345.txt",
  key="RFC 1345",
  abstract={This memo lists a selection of characters and their presence in some coded character sets.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1345",
  }

@misc{rfc1346,
  author="P. Jones",
  title="{Resource Allocation, Control, and Accounting for the Use of Network Resources}",
  howpublished="RFC 1346 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1346",
  pages="1--6",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1346.txt",
  key="RFC 1346",
  abstract={The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular.  No solution discussed in this document is intended as a standard.  Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1346",
  }

@misc{rfc1347,
  author="R. Callon",
  title="{TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing}",
  howpublished="RFC 1347 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1347",
  pages="1--8",
  year=1992,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1347.txt",
  key="RFC 1347",
  abstract={This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1347",
  }

@misc{rfc1348,
  author="B. Manning",
  title="{DNS NSAP RRs}",
  howpublished="RFC 1348 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1348",
  pages="1--4",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1637",
url="https://www.rfc-editor.org/rfc/rfc1348.txt",
  key="RFC 1348",
  abstract={This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain names, CLNP, resource records",
  doi="10.17487/RFC1348",
  }

@misc{rfc1349,
  author="P. Almquist",
  title="{Type of Service in the Internet Protocol Suite}",
  howpublished="RFC 1349 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1349",
  pages="1--28",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2474",
url="https://www.rfc-editor.org/rfc/rfc1349.txt",
  key="RFC 1349",
  abstract={This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]},
  keywords="TOS, TOS, IP",
  doi="10.17487/RFC1349",
  }

@misc{rfc1350,
  author="K. Sollins",
  title="{The TFTP Protocol (Revision 2)}",
  howpublished="RFC 1350 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1350",
  pages="1--11",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1782, 1783, 1784, 1785, 2347, 2348, 2349",
url="https://www.rfc-editor.org/rfc/rfc1350.txt",
  key="RFC 1350",
  abstract={TFTP is a very simple protocol used to transfer files.  It is from this that its name comes, Trivial File Transfer Protocol or TFTP.  Each nonterminal packet is acknowledged separately.  This document describes the protocol and its types of packets.  The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]},
  keywords="TFTP, trivial, file, transfer, booting",
  doi="10.17487/RFC1350",
  }

@misc{rfc1351,
  author="J. Davin and J. Galvin and K. McCloghrie",
  title="{SNMP Administrative Model}",
  howpublished="RFC 1351 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1351",
  pages="1--35",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1351.txt",
  key="RFC 1351",
  abstract={This memo presents an elaboration of the SNMP administrative model set forth in [1].  This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]},
  keywords="SNMP-ADMIN, network, management, authentication",
  doi="10.17487/RFC1351",
  }

@misc{rfc1352,
  author="J. Galvin and K. McCloghrie and J. Davin",
  title="{SNMP Security Protocols}",
  howpublished="RFC 1352 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1352",
  pages="1--41",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1352.txt",
  key="RFC 1352",
  abstract={The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols.  The SNMP administrative model described in [2] provides a framework for securing SNMP network management.  In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]},
  keywords="SNMP-SEC, network, management, authentication",
  doi="10.17487/RFC1352",
  }

@misc{rfc1353,
  author="K. McCloghrie and J. Davin and J. Galvin",
  title="{Definitions of Managed Objects for Administration of SNMP Parties}",
  howpublished="RFC 1353 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1353",
  pages="1--26",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1353.txt",
  key="RFC 1353",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]},
  keywords="SNMP-PARTY-MIB, network, management, authentication",
  doi="10.17487/RFC1353",
  }

@misc{rfc1354,
  author="F. Baker",
  title="{IP Forwarding Table MIB}",
  howpublished="RFC 1354 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1354",
  pages="1--12",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2096",
url="https://www.rfc-editor.org/rfc/rfc1354.txt",
  key="RFC 1354",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK]},
  keywords="Network, Management, Route, Table",
  doi="10.17487/RFC1354",
  }

@misc{rfc1355,
  author="J. Curran and A. Marine",
  title="{Privacy and Accuracy Issues in Network Information Center Databases}",
  howpublished="RFC 1355 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1355",
  pages="1--4",
  year=1992,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1355.txt",
  key="RFC 1355",
  abstract={This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NIC, data, privacy, accuracy",
  doi="10.17487/RFC1355",
  }

@misc{rfc1356,
  author="A. Malis and D. Robinson and R. Ullmann",
  title="{Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode}",
  howpublished="RFC 1356 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1356",
  pages="1--14",
  year=1992,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1356.txt",
  key="RFC 1356",
  abstract={This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards.  It is a replacement for RFC 877, ``A Standard for the Transmission of IP Datagrams Over Public Data Networks'' [1]. [STANDARDS-TRACK]},
  keywords="IP-X.25, IP, on, X.25",
  doi="10.17487/RFC1356",
  }

@misc{rfc1357,
  author="D. Cohen",
  title="{A Format for E-mailing Bibliographic Records}",
  howpublished="RFC 1357 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1357",
  pages="1--13",
  year=1992,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1807",
url="https://www.rfc-editor.org/rfc/rfc1357.txt",
  key="RFC 1357",
  abstract={This memo defines a format for E-mailing bibliographic records of technical reports.  It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="library, technical, reports, email, services",
  doi="10.17487/RFC1357",
  }

@misc{rfc1358,
  author="L. Chapin",
  title="{Charter of the Internet Architecture Board (IAB)}",
  howpublished="RFC 1358 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1358",
  pages="1--5",
  year=1992,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1601",
url="https://www.rfc-editor.org/rfc/rfc1358.txt",
  key="RFC 1358",
  abstract={The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="ISOC, Internet, Society, IETF, IRTF",
  doi="10.17487/RFC1358",
  }

@misc{rfc1359,
  author="ACM SIGUCCS",
  title="{Connecting to the Internet - What Connecting Institutions Should Anticipate}",
  howpublished="RFC 1359 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1359",
  pages="1--25",
  year=1992,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1359.txt",
  key="RFC 1359",
  abstract={This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Internet, access",
  doi="10.17487/RFC1359",
  }

@misc{rfc1360,
  author="J. Postel",
  title="{IAB Official Protocol Standards}",
  howpublished="RFC 1360 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1360",
  pages="1--33",
  year=1992,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1410",
url="https://www.rfc-editor.org/rfc/rfc1360.txt",
  key="RFC 1360",
  keywords="proposed, draft, experimental, informational, historic, full",
  doi="10.17487/RFC1360",
  }

@misc{rfc1361,
  author="D. Mills",
  title="{Simple Network Time Protocol (SNTP)}",
  howpublished="RFC 1361 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1361",
  pages="1--10",
  year=1992,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1769",
url="https://www.rfc-editor.org/rfc/rfc1361.txt",
  key="RFC 1361",
  abstract={This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet.  This memorandum does not obsolete or update any RFC.  This memo provides information for the Internet community.  It does not specify an Internet standard.  Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms.  Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization.  Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]},
  keywords="Clocks, Synchronization, NTP",
  doi="10.17487/RFC1361",
  }

@misc{rfc1362,
  author="M. Allen",
  title="{Novell IPX over Various WAN Media (IPXWAN)}",
  howpublished="RFC 1362 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1362",
  pages="1--13",
  year=1992,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1634",
url="https://www.rfc-editor.org/rfc/rfc1362.txt",
  key="RFC 1362",
  abstract={This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="IPX on X.25, IPX on PPP, IPX on Frame Relay",
  doi="10.17487/RFC1362",
  }

@misc{rfc1363,
  author="C. Partridge",
  title="{A Proposed Flow Specification}",
  howpublished="RFC 1363 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1363",
  pages="1--20",
  year=1992,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1363.txt",
  key="RFC 1363",
  keywords="flow, spec, resource, reservation, stream, type of service, quality of service",
  doi="10.17487/RFC1363",
  }

@misc{rfc1364,
  author="K. Varadhan",
  title="{BGP OSPF Interaction}",
  howpublished="RFC 1364 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1364",
  pages="1--14",
  year=1992,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1403",
url="https://www.rfc-editor.org/rfc/rfc1364.txt",
  key="RFC 1364",
  keywords="autonomous, system, border, router, open, shortest, path, first, routing, protocol, domain, route, exchange, exporting, importing",
  doi="10.17487/RFC1364",
  }

@misc{rfc1365,
  author="K. Siyan",
  title="{An IP Address Extension Proposal}",
  howpublished="RFC 1365 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1365",
  pages="1--6",
  year=1992,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1365.txt",
  key="RFC 1365",
  keywords="class F addresses",
  doi="10.17487/RFC1365",
  }

@misc{rfc1366,
  author="E. Gerich",
  title="{Guidelines for Management of IP Address Space}",
  howpublished="RFC 1366 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1366",
  pages="1--8",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1466",
url="https://www.rfc-editor.org/rfc/rfc1366.txt",
  key="RFC 1366",
  abstract={This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE).  There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.  This memo provides information for the Internet community.  It does not specify an Internet standard.  This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements.  This memo provides information for the Internet community.  It does not specify an Internet standard.  This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only).  This RFC is a product of the Internet Research Task Force (IRTF).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="routing, tables, allocation, registry, IR, IANA",
  doi="10.17487/RFC1366",
  }

@misc{rfc1367,
  author="C. Topolcic",
  title="{Schedule for IP Address Space Management Guidelines}",
  howpublished="RFC 1367 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1367",
  pages="1--3",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1467",
url="https://www.rfc-editor.org/rfc/rfc1367.txt",
  key="RFC 1367",
  abstract={This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="routing, tables, allocation, registry, IR, IANA",
  doi="10.17487/RFC1367",
  }

@misc{rfc1368,
  author="D. McMaster and K. McCloghrie",
  title="{Definition of Managed Objects for IEEE 802.3 Repeater Devices}",
  howpublished="RFC 1368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1368",
  pages="1--40",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1516",
url="https://www.rfc-editor.org/rfc/rfc1368.txt",
  key="RFC 1368",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as ``hubs''. [STANDARDS-TRACK]},
  keywords="MIB, hub, management",
  doi="10.17487/RFC1368",
  }

@misc{rfc1369,
  author="F. Kastenholz",
  title="{Implementation Notes and Experience for the Internet Ethernet MIB}",
  howpublished="RFC 1369 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1369",
  pages="1--7",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1369.txt",
  key="RFC 1369",
  abstract={This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="management",
  doi="10.17487/RFC1369",
  }

@misc{rfc1370,
  author="Internet Architecture Board and L. Chapin",
  title="{Applicability Statement for OSPF}",
  howpublished="RFC 1370 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1370",
  pages="1--2",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1370.txt",
  key="RFC 1370",
  abstract={This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]},
  keywords="routing, open, shortest, path, first",
  doi="10.17487/RFC1370",
  }

@misc{rfc1371,
  author="P. Gross",
  title="{Choosing a Common IGP for the IP Internet}",
  howpublished="RFC 1371 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1371",
  pages="1--9",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1371.txt",
  key="RFC 1371",
  abstract={This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single ``common IGP'' for the IP portions of the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="routing, recommendation, interior, gateway, protocol",
  doi="10.17487/RFC1371",
  }

@misc{rfc1372,
  author="C. Hedrick and D. Borman",
  title="{Telnet Remote Flow Control Option}",
  howpublished="RFC 1372 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1372",
  pages="1--6",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1372.txt",
  key="RFC 1372",
  abstract={This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]},
  keywords="TOPT-RFC, terminal, access",
  doi="10.17487/RFC1372",
  }

@misc{rfc1373,
  author="T. Tignor",
  title="{Portable DUAs}",
  howpublished="RFC 1373 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1373",
  pages="1--12",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1373.txt",
  key="RFC 1373",
  abstract={This document comes in two parts.  The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory.  The second part is for ISODE-maintainers wishing to provide portable DUAs to users.  This part gives instructions in a similar but longer, step-by-step format.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="directory, user, agents, whois, de, dixie, ud, doog, ISODE, X.500",
  doi="10.17487/RFC1373",
  }

@misc{rfc1374,
  author="J. Renwick and A. Nicholson",
  title="{IP and ARP on HIPPI}",
  howpublished="RFC 1374 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1374",
  pages="1--43",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2834",
url="https://www.rfc-editor.org/rfc/rfc1374.txt",
  key="RFC 1374",
  abstract={The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI.  Another X3T9.3 draft describes the operation of HIPPI physical switches.  X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.  This memo is intended to become an Internet Standard. [STANDARDS-TRACK]},
  doi="10.17487/RFC1374",
  }

@misc{rfc1375,
  author="P. Robinson",
  title="{Suggestion for New Classes of IP Addresses}",
  howpublished="RFC 1375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1375",
  pages="1--7",
  year=1992,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1375.txt",
  key="RFC 1375",
  abstract={This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="network, numbers",
  doi="10.17487/RFC1375",
  }

@misc{rfc1376,
  author="S. Senum",
  title="{The PPP DECnet Phase IV Control Protocol (DNCP)}",
  howpublished="RFC 1376 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1376",
  pages="1--6",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1762",
url="https://www.rfc-editor.org/rfc/rfc1376.txt",
  key="RFC 1376",
  abstract={This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.  This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]},
  keywords="point, DNA, DDCMP",
  doi="10.17487/RFC1376",
  }

@misc{rfc1377,
  author="D. Katz",
  title="{The PPP OSI Network Layer Control Protocol (OSINLCP)}",
  howpublished="RFC 1377 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1377",
  pages="1--10",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1377.txt",
  key="RFC 1377",
  abstract={This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]},
  keywords="PPP-OSINLCP, point, open, systems, interconnection",
  doi="10.17487/RFC1377",
  }

@misc{rfc1378,
  author="B. Parker",
  title="{The PPP AppleTalk Control Protocol (ATCP)}",
  howpublished="RFC 1378 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1378",
  pages="1--16",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1378.txt",
  key="RFC 1378",
  abstract={This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]},
  keywords="PPP-ATCP, point",
  doi="10.17487/RFC1378",
  }

@misc{rfc1379,
  author="R. Braden",
  title="{Extending TCP for Transactions -- Concepts}",
  howpublished="RFC 1379 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1379",
  pages="1--38",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247, updated by RFC 1644",
url="https://www.rfc-editor.org/rfc/rfc1379.txt",
  key="RFC 1379",
  abstract={This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="transmission, control, protocol",
  doi="10.17487/RFC1379",
  }

@misc{rfc1380,
  author="P. Gross and P. Almquist",
  title="{IESG Deliberations on Routing and Addressing}",
  howpublished="RFC 1380 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1380",
  pages="1--22",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1380.txt",
  key="RFC 1380",
  abstract={This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="ROAD",
  doi="10.17487/RFC1380",
  }

@misc{rfc1381,
  author="D. Throop and F. Baker",
  title="{SNMP MIB Extension for X.25 LAPB}",
  howpublished="RFC 1381 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1381",
  pages="1--33",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1381.txt",
  key="RFC 1381",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK]},
  keywords="SNMP-LAPB, management",
  doi="10.17487/RFC1381",
  }

@misc{rfc1382,
  author="D. Throop",
  title="{SNMP MIB Extension for the X.25 Packet Layer}",
  howpublished="RFC 1382 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1382",
  pages="1--69",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1382.txt",
  key="RFC 1382",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]},
  keywords="SNMP-X.25, management",
  doi="10.17487/RFC1382",
  }

@misc{rfc1383,
  author="C. Huitema",
  title="{An Experiment in DNS Based IP Routing}",
  howpublished="RFC 1383 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1383",
  pages="1--14",
  year=1992,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1383.txt",
  key="RFC 1383",
  abstract={Potential solutions to the routing explosion.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS-IP",
  doi="10.17487/RFC1383",
  }

@misc{rfc1384,
  author="P. Barker and S.E. Hardcastle-Kille",
  title="{Naming Guidelines for Directory Pilots}",
  howpublished="RFC 1384 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1384",
  pages="1--12",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1617, NaN",
url="https://www.rfc-editor.org/rfc/rfc1384.txt",
  key="RFC 1384",
  abstract={This document defines a number of naming guidelines.  Alignment to these guidelines is recommended for directory pilots.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="X.500, Multinational",
  doi="10.17487/RFC1384",
  }

@misc{rfc1385,
  author="Z. Wang",
  title="{EIP: The Extended Internet Protocol}",
  howpublished="RFC 1385 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1385",
  pages="1--17",
  year=1992,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6814",
url="https://www.rfc-editor.org/rfc/rfc1385.txt",
  key="RFC 1385",
  abstract={EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition.  This is an ``idea'' paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="addressing",
  doi="10.17487/RFC1385",
  }

@misc{rfc1386,
  author="A. Cooper and J. Postel",
  title="{The US Domain}",
  howpublished="RFC 1386 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1386",
  pages="1--31",
  year=1992,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1480",
url="https://www.rfc-editor.org/rfc/rfc1386.txt",
  key="RFC 1386",
  abstract={This is a description of the US Top Level Domains on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="DNS, top-level",
  doi="10.17487/RFC1386",
  }

@misc{rfc1387,
  author="G. Malkin",
  title="{RIP Version 2 Protocol Analysis}",
  howpublished="RFC 1387 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1387",
  pages="1--3",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1721",
url="https://www.rfc-editor.org/rfc/rfc1387.txt",
  key="RFC 1387",
  abstract={As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="RIP-2",
  doi="10.17487/RFC1387",
  }

@misc{rfc1388,
  author="G. Malkin",
  title="{RIP Version 2 Carrying Additional Information}",
  howpublished="RFC 1388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1388",
  pages="1--7",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1723",
url="https://www.rfc-editor.org/rfc/rfc1388.txt",
  key="RFC 1388",
  abstract={This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]},
  keywords="RIP-2",
  doi="10.17487/RFC1388",
  }

@misc{rfc1389,
  author="G. Malkin and F. Baker",
  title="{RIP Version 2 MIB Extensions}",
  howpublished="RFC 1389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1389",
  pages="1--13",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1724",
url="https://www.rfc-editor.org/rfc/rfc1389.txt",
  key="RFC 1389",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]},
  keywords="RIP-2, Management, Information, Base",
  doi="10.17487/RFC1389",
  }

@misc{rfc1390,
  author="D. Katz",
  title="{Transmission of IP and ARP over FDDI Networks}",
  howpublished="RFC 1390 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1390",
  pages="1--11",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1390.txt",
  key="RFC 1390",
  abstract={This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]},
  keywords="IP-FDDI, IEEE, 802, MAC",
  doi="10.17487/RFC1390",
  }

@misc{rfc1391,
  author="G. Malkin",
  title="{The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force}",
  howpublished="RFC 1391 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1391",
  pages="1--19",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1539",
url="https://www.rfc-editor.org/rfc/rfc1391.txt",
  key="RFC 1391",
  abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="meetings",
  doi="10.17487/RFC1391",
  }

@misc{rfc1392,
  author="G. Malkin and T. LaQuey Parker",
  title="{Internet Users' Glossary}",
  howpublished="RFC 1392 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1392",
  pages="1--53",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1983",
url="https://www.rfc-editor.org/rfc/rfc1392.txt",
  key="RFC 1392",
  abstract={There are many networking glossaries in existence.  This glossary concentrates on terms which are specific to the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1392",
  }

@misc{rfc1393,
  author="G. Malkin",
  title="{Traceroute Using an IP Option}",
  howpublished="RFC 1393 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1393",
  pages="1--7",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6814",
url="https://www.rfc-editor.org/rfc/rfc1393.txt",
  key="RFC 1393",
  abstract={This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TRACE-IP, ICMP, MTU, Line, Speed",
  doi="10.17487/RFC1393",
  }

@misc{rfc1394,
  author="P. Robinson",
  title="{Relationship of Telex Answerback Codes to Internet Domains}",
  howpublished="RFC 1394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1394",
  pages="1--15",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1394.txt",
  key="RFC 1394",
  abstract={This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers.  It also lists the telex code and international dialing code, wherever it is available.  It will also list major Internet ``Public'' E-Mail addresses.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="DNS, Country",
  doi="10.17487/RFC1394",
  }

@misc{rfc1395,
  author="J. Reynolds",
  title="{BOOTP Vendor Information Extensions}",
  howpublished="RFC 1395 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1395",
  pages="1--8",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1497, 1533",
url="https://www.rfc-editor.org/rfc/rfc1395.txt",
  key="RFC 1395",
  abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo.  This memo will be updated as additional tags are defined.  This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path.  This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).},
  keywords="TAGS",
  doi="10.17487/RFC1395",
  }

@misc{rfc1396,
  author="S. Crocker",
  title="{The Process for Organization of Internet Standards Working Group (POISED)}",
  howpublished="RFC 1396 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1396",
  pages="1--10",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1396.txt",
  key="RFC 1396",
  abstract={This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="IAB, IESG, ISOC",
  doi="10.17487/RFC1396",
  }

@misc{rfc1397,
  author="D. Haskin",
  title="{Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol}",
  howpublished="RFC 1397 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1397",
  pages="1--2",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1397.txt",
  key="RFC 1397",
  abstract={This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]},
  keywords="BGP",
  doi="10.17487/RFC1397",
  }

@misc{rfc1398,
  author="F. Kastenholz",
  title="{Definitions of Managed Objects for the Ethernet-Like Interface Types}",
  howpublished="RFC 1398 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1398",
  pages="1--17",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1623",
url="https://www.rfc-editor.org/rfc/rfc1398.txt",
  key="RFC 1398",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK]},
  keywords="MIB, Management",
  doi="10.17487/RFC1398",
  }

@misc{rfc1399,
  author="J. Elliott",
  title="{Summary of 1300-1399}",
  howpublished="RFC 1399 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1399",
  pages="1--22",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1399.txt",
  key="RFC 1399",
  keywords="Index",
  doi="10.17487/RFC1399",
  }

@misc{rfc1400,
  author="S. Williamson",
  title="{Transition and Modernization of the Internet Registration Service}",
  howpublished="RFC 1400 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1400",
  pages="1--7",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1400.txt",
  key="RFC 1400",
  abstract={As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="INTERNIC IR",
  doi="10.17487/RFC1400",
  }

@misc{rfc1401,
  author="Internet Architecture Board",
  title="{Correspondence between the IAB and DISA on the use of DNS}",
  howpublished="RFC 1401 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1401",
  pages="1--8",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1401.txt",
  key="RFC 1401",
  abstract={This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as ``hosts.txt''.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Domain Name, Milnet",
  doi="10.17487/RFC1401",
  }

@misc{rfc1402,
  author="J. Martin",
  title="{There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places}",
  howpublished="RFC 1402 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1402",
  pages="1--39",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1402.txt",
  key="RFC 1402",
  abstract={The ultimate goal is to make the route to these sources of information invisible to you.  At present, this is not easy to do.  I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer.  This RFC provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="information, introduction, SIGUCCS, User Services, Help",
  doi="10.17487/RFC1402",
  }

@misc{rfc1403,
  author="K. Varadhan",
  title="{BGP OSPF Interaction}",
  howpublished="RFC 1403 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1403",
  pages="1--17",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1403.txt",
  key="RFC 1403",
  abstract={This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]},
  keywords="BGP-OSPF, border gateway protocol, open shortest path first routing",
  doi="10.17487/RFC1403",
  }

@misc{rfc1404,
  author="B. Stockman",
  title="{A Model for Common Operational Statistics}",
  howpublished="RFC 1404 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1404",
  pages="1--27",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1857",
url="https://www.rfc-editor.org/rfc/rfc1404.txt",
  key="RFC 1404",
  abstract={This memo describes a model for operational statistics in the Internet.  It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Management, Operations",
  doi="10.17487/RFC1404",
  }

@misc{rfc1405,
  author="C. Allocchio",
  title="{Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)}",
  howpublished="RFC 1405 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1405",
  pages="1--19",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2162",
url="https://www.rfc-editor.org/rfc/rfc1405.txt",
  key="RFC 1405",
  abstract={This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SMTP, EMail, 822",
  doi="10.17487/RFC1405",
  }

@misc{rfc1406,
  author="F. Baker and J. Watt",
  title="{Definitions of Managed Objects for the DS1 and E1 Interface Types}",
  howpublished="RFC 1406 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1406",
  pages="1--50",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2495",
url="https://www.rfc-editor.org/rfc/rfc1406.txt",
  key="RFC 1406",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]},
  keywords="DS1/E1-MIB, T1, MIB, Management, SNMP",
  doi="10.17487/RFC1406",
  }

@misc{rfc1407,
  author="T. Cox and K. Tesink",
  title="{Definitions of Managed Objects for the DS3/E3 Interface Type}",
  howpublished="RFC 1407 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1407",
  pages="1--43",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2496",
url="https://www.rfc-editor.org/rfc/rfc1407.txt",
  key="RFC 1407",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]},
  keywords="DS3/E3-MIB, T3, MIB, Management, SNMP",
  doi="10.17487/RFC1407",
  }

@misc{rfc1408,
  author="D. Borman",
  title="{Telnet Environment Option}",
  howpublished="RFC 1408 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1408",
  pages="1--7",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1571",
url="https://www.rfc-editor.org/rfc/rfc1408.txt",
  key="RFC 1408",
  abstract={This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]},
  keywords="TOPT-ENVIR, Negotiation",
  doi="10.17487/RFC1408",
  }

@misc{rfc1409,
  author="D. Borman",
  title="{Telnet Authentication Option}",
  howpublished="RFC 1409 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1409",
  pages="1--7",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1416",
url="https://www.rfc-editor.org/rfc/rfc1409.txt",
  key="RFC 1409",
  abstract={This memo defines an Experimental Protocol for the Internet community.},
  keywords="security",
  doi="10.17487/RFC1409",
  }

@misc{rfc1410,
  author="J. Postel",
  title="{IAB Official Protocol Standards}",
  howpublished="RFC 1410 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1410",
  pages="1--35",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1500",
url="https://www.rfc-editor.org/rfc/rfc1410.txt",
  key="RFC 1410",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).},
  keywords="proposed, draft, experimental, informational, historic, full",
  doi="10.17487/RFC1410",
  }

@misc{rfc1411,
  author="D. Borman",
  title="{Telnet Authentication: Kerberos Version 4}",
  howpublished="RFC 1411 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1411",
  pages="1--4",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1411.txt",
  key="RFC 1411",
  abstract={This memo defines an Experimental Protocol for the Internet community.},
  keywords="TEL-KER, Security, option",
  doi="10.17487/RFC1411",
  }

@misc{rfc1412,
  author="K. Alagappan",
  title="{Telnet Authentication: SPX}",
  howpublished="RFC 1412 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1412",
  pages="1--4",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1412.txt",
  key="RFC 1412",
  abstract={This memo defines an Experimental Protocol for the Internet community.},
  keywords="TEL-SPX, Security, option",
  doi="10.17487/RFC1412",
  }

@misc{rfc1413,
  author="M. St. Johns",
  title="{Identification Protocol}",
  howpublished="RFC 1413 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1413",
  pages="1--8",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1413.txt",
  key="RFC 1413",
  abstract={The Identification Protocol was formerly called the Authentication Server Protocol.  It has been renamed to better reflect its function. [STANDARDS-TRACK]},
  keywords="IDENT, Authentication",
  doi="10.17487/RFC1413",
  }

@misc{rfc1414,
  author="M. St. Johns and M. Rose",
  title="{Identification MIB}",
  howpublished="RFC 1414 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1414",
  pages="1--7",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1414.txt",
  key="RFC 1414",
  abstract={This memo defines a MIB for use with identifying the users associated with TCP connections.  It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]},
  keywords="IDENT-MIB, Management, SNMP",
  doi="10.17487/RFC1414",
  }

@misc{rfc1415,
  author="J. Mindel and R. Slaski",
  title="{FTP-FTAM Gateway Specification}",
  howpublished="RFC 1415 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1415",
  pages="1--58",
  year=1993,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1415.txt",
  key="RFC 1415",
  abstract={This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]},
  keywords="FTP, FTAM, transfer, ISO, OSI",
  doi="10.17487/RFC1415",
  }

@misc{rfc1416,
  author="D. Borman",
  title="{Telnet Authentication Option}",
  howpublished="RFC 1416 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1416",
  pages="1--7",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2941",
url="https://www.rfc-editor.org/rfc/rfc1416.txt",
  key="RFC 1416",
  abstract={This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of ``REPLY'' should be ``IS'').  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TOPT-AUTH, Security",
  doi="10.17487/RFC1416",
  }

@misc{rfc1417,
  author="The North American Directory Forum",
  title="{NADF Standing Documents: A Brief Overview}",
  howpublished="RFC 1417 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1417",
  pages="1--4",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1758",
url="https://www.rfc-editor.org/rfc/rfc1417.txt",
  key="RFC 1417",
  abstract={The purpose of this document is to provide a brief overview of the NADF's Standing Document series.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="X.500, Directory",
  doi="10.17487/RFC1417",
  }

@misc{rfc1418,
  author="M. Rose",
  title="{SNMP over OSI}",
  howpublished="RFC 1418 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1418",
  pages="1--4",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1418.txt",
  key="RFC 1418",
  abstract={This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]},
  keywords="SNMP-OSI, Management",
  doi="10.17487/RFC1418",
  }

@misc{rfc1419,
  author="G. Minshall and M. Ritter",
  title="{SNMP over AppleTalk}",
  howpublished="RFC 1419 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1419",
  pages="1--7",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1419.txt",
  key="RFC 1419",
  abstract={This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]},
  keywords="SNMP-AT, Management",
  doi="10.17487/RFC1419",
  }

@misc{rfc1420,
  author="S. Bostock",
  title="{SNMP over IPX}",
  howpublished="RFC 1420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1420",
  pages="1--4",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1420.txt",
  key="RFC 1420",
  abstract={This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]},
  keywords="SNMP-IPX, Management",
  doi="10.17487/RFC1420",
  }

@misc{rfc1421,
  author="J. Linn",
  title="{Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures}",
  howpublished="RFC 1421 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1421",
  pages="1--42",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1421.txt",
  key="RFC 1421",
  abstract={This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]},
  keywords="PEM-ENC, PEM",
  doi="10.17487/RFC1421",
  }

@misc{rfc1422,
  author="S. Kent",
  title="{Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management}",
  howpublished="RFC 1422 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1422",
  pages="1--32",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1422.txt",
  key="RFC 1422",
  abstract={This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]},
  keywords="PEM-CKM, PEM",
  doi="10.17487/RFC1422",
  }

@misc{rfc1423,
  author="D. Balenson",
  title="{Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers}",
  howpublished="RFC 1423 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1423",
  pages="1--14",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1423.txt",
  key="RFC 1423",
  abstract={This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]},
  keywords="PEM-ALG, PEM",
  doi="10.17487/RFC1423",
  }

@misc{rfc1424,
  author="B. Kaliski",
  title="{Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services}",
  howpublished="RFC 1424 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1424",
  pages="1--9",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1424.txt",
  key="RFC 1424",
  abstract={This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]},
  keywords="PEM-KEY, PEM",
  doi="10.17487/RFC1424",
  }

@misc{rfc1425,
  author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker",
  title="{SMTP Service Extensions}",
  howpublished="RFC 1425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1425",
  pages="1--10",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1651",
url="https://www.rfc-editor.org/rfc/rfc1425.txt",
  key="RFC 1425",
  abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]},
  keywords="Mail",
  doi="10.17487/RFC1425",
  }

@misc{rfc1426,
  author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker",
  title="{SMTP Service Extension for 8bit-MIMEtransport}",
  howpublished="RFC 1426 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1426",
  pages="1--6",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1652",
url="https://www.rfc-editor.org/rfc/rfc1426.txt",
  key="RFC 1426",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex},
  keywords="Mail",
  doi="10.17487/RFC1426",
  }

@misc{rfc1427,
  author="J. Klensin and N. Freed and K. Moore",
  title="{SMTP Service Extension for Message Size Declaration}",
  howpublished="RFC 1427 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1427",
  pages="1--8",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1653",
url="https://www.rfc-editor.org/rfc/rfc1427.txt",
  key="RFC 1427",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]},
  keywords="Mail",
  doi="10.17487/RFC1427",
  }

@misc{rfc1428,
  author="G. Vaudreuil",
  title="{Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME}",
  howpublished="RFC 1428 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1428",
  pages="1--6",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1428.txt",
  key="RFC 1428",
  abstract={This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.  This RFC provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Mail",
  doi="10.17487/RFC1428",
  }

@misc{rfc1429,
  author="E. Thomas",
  title="{Listserv Distribute Protocol}",
  howpublished="RFC 1429 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1429",
  pages="1--8",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1429.txt",
  key="RFC 1429",
  abstract={This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="LISTSERV, Mail",
  doi="10.17487/RFC1429",
  }

@misc{rfc1430,
  author="S. Hardcastle-Kille and E. Huizer and V. Cerf and R. Hobby and S. Kent",
  title="{A Strategic Plan for Deploying an Internet X.500 Directory Service}",
  howpublished="RFC 1430 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1430",
  pages="1--20",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1430.txt",
  key="RFC 1430",
  abstract={This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="X.500",
  doi="10.17487/RFC1430",
  }

@misc{rfc1431,
  author="P. Barker",
  title="{DUA Metrics (OSI-DS 33 (v2))}",
  howpublished="RFC 1431 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1431",
  pages="1--19",
  year=1993,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1431.txt",
  key="RFC 1431",
  abstract={This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Directory User Agent, Measurement, Statistics, Survey, X.500",
  doi="10.17487/RFC1431",
  }

@misc{rfc1432,
  author="J. Quarterman",
  title="{Recent Internet Books}",
  howpublished="RFC 1432 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1432",
  pages="1--15",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1432.txt",
  key="RFC 1432",
  abstract={Here is a list of books related to using the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="bibiography",
  doi="10.17487/RFC1432",
  }

@misc{rfc1433,
  author="J. Garrett and J. Hagan and J. Wong",
  title="{Directed ARP}",
  howpublished="RFC 1433 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1433",
  pages="1--18",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1433.txt",
  key="RFC 1433",
  abstract={Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DIR-ARP, public networks, SMDS",
  doi="10.17487/RFC1433",
  }

@misc{rfc1434,
  author="R. Dixon and D. Kushi",
  title="{Data Link Switching: Switch-to-Switch Protocol}",
  howpublished="RFC 1434 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1434",
  pages="1--33",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1795",
url="https://www.rfc-editor.org/rfc/rfc1434.txt",
  key="RFC 1434",
  abstract={This RFC describes IBM's support of Data Link Switching over TCP/IP.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="IBM, SNA, DLS, SSP, NetBIos",
  doi="10.17487/RFC1434",
  }

@misc{rfc1435,
  author="S. Knowles",
  title="{IESG Advice from Experience with Path MTU Discovery}",
  howpublished="RFC 1435 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1435",
  pages="1--2",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1435.txt",
  key="RFC 1435",
  abstract={In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered.  The problem results from the optional suppression of ICMP messages implemented in some routers.  This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Maximum, Transmission, Unit",
  doi="10.17487/RFC1435",
  }

@misc{rfc1436,
  author="F. Anklesaria and M. McCahill and P. Lindner and D. Johnson and D. Torrey and B. Albert",
  title="{The Internet Gopher Protocol (a distributed document search and retrieval protocol)}",
  howpublished="RFC 1436 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1436",
  pages="1--16",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1436.txt",
  key="RFC 1436",
  abstract={This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="GOPHER, information, locating",
  doi="10.17487/RFC1436",
  }

@misc{rfc1437,
  author="N. Borenstein and M. Linimon",
  title="{The Extension of MIME Content-Types to a New Medium}",
  howpublished="RFC 1437 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1437",
  pages="1--6",
  year=1993,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1437.txt",
  key="RFC 1437",
  abstract={This document defines one particular type of MIME data, the matter- transport/sentient-life-form type.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="life form, Matter, transport, Sentient",
  doi="10.17487/RFC1437",
  }

@misc{rfc1438,
  author="A. Lyman Chapin and C. Huitema",
  title="{Internet Engineering Task Force Statements Of Boredom (SOBs)}",
  howpublished="RFC 1438 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1438",
  pages="1--2",
  year=1993,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1438.txt",
  key="RFC 1438",
  abstract={This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="process, policy",
  doi="10.17487/RFC1438",
  }

@misc{rfc1439,
  author="C. Finseth",
  title="{The Uniqueness of Unique Identifiers}",
  howpublished="RFC 1439 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1439",
  pages="1--11",
  year=1993,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1439.txt",
  key="RFC 1439",
  abstract={This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="names",
  doi="10.17487/RFC1439",
  }

@misc{rfc1440,
  author="R. Troth",
  title="{SIFT/UFT: Sender-Initiated/Unsolicited File Transfer}",
  howpublished="RFC 1440 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1440",
  pages="1--9",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1440.txt",
  key="RFC 1440",
  abstract={This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SIFT, UFT, Send, FTP",
  doi="10.17487/RFC1440",
  }

@misc{rfc1441,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Introduction to version 2 of the Internet-standard Network Management Framework}",
  howpublished="RFC 1441 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1441",
  pages="1--13",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1441.txt",
  key="RFC 1441",
  abstract={The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]},
  keywords="SNMPv2, SNMP, Management, Framework",
  doi="10.17487/RFC1441",
  }

@misc{rfc1442,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1442 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1442",
  pages="1--56",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1902",
url="https://www.rfc-editor.org/rfc/rfc1442.txt",
  key="RFC 1442",
  abstract={Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB).  Collections of related objects are defined in MIB modules.  These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1].  It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework, SMI",
  doi="10.17487/RFC1442",
  }

@misc{rfc1443,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1443 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1443",
  pages="1--31",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1903",
url="https://www.rfc-editor.org/rfc/rfc1443.txt",
  key="RFC 1443",
  abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1443",
  }

@misc{rfc1444,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1444 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1444",
  pages="1--33",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1904",
url="https://www.rfc-editor.org/rfc/rfc1444.txt",
  key="RFC 1444",
  abstract={It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved.  It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1444",
  }

@misc{rfc1445,
  author="J. Galvin and K. McCloghrie",
  title="{Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1445 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1445",
  pages="1--48",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1445.txt",
  key="RFC 1445",
  abstract={It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1445",
  }

@misc{rfc1446,
  author="J. Galvin and K. McCloghrie",
  title="{Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1446 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1446",
  pages="1--52",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1446.txt",
  key="RFC 1446",
  abstract={It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1446",
  }

@misc{rfc1447,
  author="K. McCloghrie and J. Galvin",
  title="{Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1447 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1447",
  pages="1--50",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1447.txt",
  key="RFC 1447",
  abstract={The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies.  It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1447",
  }

@misc{rfc1448,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1448 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1448",
  pages="1--36",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1905",
url="https://www.rfc-editor.org/rfc/rfc1448.txt",
  key="RFC 1448",
  abstract={It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1448",
  }

@misc{rfc1449,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1449 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1449",
  pages="1--25",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1906",
url="https://www.rfc-editor.org/rfc/rfc1449.txt",
  key="RFC 1449",
  abstract={It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1449",
  }

@misc{rfc1450,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1450 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1450",
  pages="1--27",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1907",
url="https://www.rfc-editor.org/rfc/rfc1450.txt",
  key="RFC 1450",
  abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1450",
  }

@misc{rfc1451,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Manager-to-Manager Management Information Base}",
  howpublished="RFC 1451 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1451",
  pages="1--36",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1451.txt",
  key="RFC 1451",
  abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1451",
  }

@misc{rfc1452,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework}",
  howpublished="RFC 1452 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1452",
  pages="1--17",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1908",
url="https://www.rfc-editor.org/rfc/rfc1452.txt",
  key="RFC 1452",
  abstract={The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]},
  keywords="SNMP, Management, Framework",
  doi="10.17487/RFC1452",
  }

@misc{rfc1453,
  author="W. Chimiak",
  title="{A Comment on Packet Video Remote Conferencing and the Transport/Network Layers}",
  howpublished="RFC 1453 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1453",
  pages="1--10",
  year=1993,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1453.txt",
  key="RFC 1453",
  abstract={This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="XTP",
  doi="10.17487/RFC1453",
  }

@misc{rfc1454,
  author="T. Dixon",
  title="{Comparison of Proposals for Next Version of IP}",
  howpublished="RFC 1454 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1454",
  pages="1--15",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1454.txt",
  key="RFC 1454",
  abstract={This is a slightly edited reprint of RARE Technical Report (RTC(93)004).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="IPng, PIP, TUBA, SIP",
  doi="10.17487/RFC1454",
  }

@misc{rfc1455,
  author="D. {Eastlake 3rd}",
  title="{Physical Link Security Type of Service}",
  howpublished="RFC 1455 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1455",
  pages="1--6",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2474",
url="https://www.rfc-editor.org/rfc/rfc1455.txt",
  key="RFC 1455",
  abstract={This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security.  This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TOS-LS, TOS",
  doi="10.17487/RFC1455",
  }

@misc{rfc1456,
  author="Vietnamese Standardization Working Group",
  title="{Conventions for Encoding the Vietnamese Language  VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification}",
  howpublished="RFC 1456 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1456",
  pages="1--7",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1456.txt",
  key="RFC 1456",
  abstract={This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Character, Set",
  doi="10.17487/RFC1456",
  }

@misc{rfc1457,
  author="R. Housley",
  title="{Security Label Framework for the Internet}",
  howpublished="RFC 1457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1457",
  pages="1--14",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1457.txt",
  key="RFC 1457",
  abstract={This memo presents a security labeling framework for the Internet.  The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1457",
  }

@misc{rfc1458,
  author="R. Braudes and S. Zabele",
  title="{Requirements for Multicast Protocols}",
  howpublished="RFC 1458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1458",
  pages="1--19",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1458.txt",
  key="RFC 1458",
  abstract={This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Real-Time",
  doi="10.17487/RFC1458",
  }

@misc{rfc1459,
  author="J. Oikarinen and D. Reed",
  title="{Internet Relay Chat Protocol}",
  howpublished="RFC 1459 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1459",
  pages="1--65",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2810, 2811, 2812, 2813, 7194",
url="https://www.rfc-editor.org/rfc/rfc1459.txt",
  key="RFC 1459",
  abstract={The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IRCP, IRC",
  doi="10.17487/RFC1459",
  }

@misc{rfc1460,
  author="M. Rose",
  title="{Post Office Protocol - Version 3}",
  howpublished="RFC 1460 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1460",
  pages="1--17",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1725",
url="https://www.rfc-editor.org/rfc/rfc1460.txt",
  key="RFC 1460",
  abstract={This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]},
  keywords="Email",
  doi="10.17487/RFC1460",
  }

@misc{rfc1461,
  author="D. Throop",
  title="{SNMP MIB extension for Multiprotocol Interconnect over X.25}",
  howpublished="RFC 1461 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1461",
  pages="1--21",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1461.txt",
  key="RFC 1461",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]},
  keywords="X25-MIB",
  doi="10.17487/RFC1461",
  }

@misc{rfc1462,
  author="E. Krol and E. Hoffman",
  title="{FYI on ``What is the Internet?''}",
  howpublished="RFC 1462 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1462",
  pages="1--11",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1462.txt",
  key="RFC 1462",
  abstract={This FYI RFC answers the question, ``What is the Internet?'' and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Introduction",
  doi="10.17487/RFC1462",
  }

@misc{rfc1463,
  author="E. Hoffman and L. Jackson",
  title="{FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings}",
  howpublished="RFC 1463 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1463",
  pages="1--4",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1463.txt",
  key="RFC 1463",
  abstract={This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1463",
  }

@misc{rfc1464,
  author="R. Rosenbaum",
  title="{Using the Domain Name System To Store Arbitrary String Attributes}",
  howpublished="RFC 1464 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1464",
  pages="1--4",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1464.txt",
  key="RFC 1464",
  abstract={This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS, TXT",
  doi="10.17487/RFC1464",
  }

@misc{rfc1465,
  author="D. Eppenberger",
  title="{Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing}",
  howpublished="RFC 1465 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1465",
  pages="1--31",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1465.txt",
  key="RFC 1465",
  abstract={This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="X400",
  doi="10.17487/RFC1465",
  }

@misc{rfc1466,
  author="E. Gerich",
  title="{Guidelines for Management of IP Address Space}",
  howpublished="RFC 1466 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1466",
  pages="1--10",
  year=1993,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2050",
url="https://www.rfc-editor.org/rfc/rfc1466.txt",
  key="RFC 1466",
  abstract={This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="CIDR",
  doi="10.17487/RFC1466",
  }

@misc{rfc1467,
  author="C. Topolcic",
  title="{Status of CIDR Deployment in the Internet}",
  howpublished="RFC 1467 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1467",
  pages="1--9",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1467.txt",
  key="RFC 1467",
  abstract={This document describes the current status of the development and deployment of CIDR technology into the Internet.  This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="routing, tables, allocation, registry, IR, IANA, classless",
  doi="10.17487/RFC1467",
  }

@misc{rfc1468,
  author="J. Murai and M. Crispin and E. van der Poel",
  title="{Japanese Character Encoding for Internet Messages}",
  howpublished="RFC 1468 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1468",
  pages="1--6",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1468.txt",
  key="RFC 1468",
  abstract={This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Set",
  doi="10.17487/RFC1468",
  }

@misc{rfc1469,
  author="T. Pusateri",
  title="{IP Multicast over Token-Ring Local Area Networks}",
  howpublished="RFC 1469 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1469",
  pages="1--4",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1469.txt",
  key="RFC 1469",
  abstract={This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]},
  keywords="IP-TR-MC, 802.2, 802.5",
  doi="10.17487/RFC1469",
  }

@misc{rfc1470,
  author="R. Enger and J. Reynolds",
  title="{FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices}",
  howpublished="RFC 1470 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1470",
  pages="1--192",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1470.txt",
  key="RFC 1470",
  abstract={The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NOCTOOLS",
  doi="10.17487/RFC1470",
  }

@misc{rfc1471,
  author="F. Kastenholz",
  title="{The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol}",
  howpublished="RFC 1471 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1471",
  pages="1--25",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1471.txt",
  key="RFC 1471",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]},
  keywords="PPP/LCP MIB, Management, Framework, PPP",
  doi="10.17487/RFC1471",
  }

@misc{rfc1472,
  author="F. Kastenholz",
  title="{The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol}",
  howpublished="RFC 1472 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1472",
  pages="1--13",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1472.txt",
  key="RFC 1472",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]},
  keywords="PPP/SEC MIB, Management, Framework, PPP",
  doi="10.17487/RFC1472",
  }

@misc{rfc1473,
  author="F. Kastenholz",
  title="{The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol}",
  howpublished="RFC 1473 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1473",
  pages="1--10",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1473.txt",
  key="RFC 1473",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]},
  keywords="PPP/IP MIB, Management, Framework, PPP",
  doi="10.17487/RFC1473",
  }

@misc{rfc1474,
  author="F. Kastenholz",
  title="{The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol}",
  howpublished="RFC 1474 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1474",
  pages="1--15",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1474.txt",
  key="RFC 1474",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]},
  keywords="PPP/Bridge, Management, Framework, PPP",
  doi="10.17487/RFC1474",
  }

@misc{rfc1475,
  author="R. Ullmann",
  title="{TP/IX: The Next Internet}",
  howpublished="RFC 1475 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1475",
  pages="1--35",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6814",
url="https://www.rfc-editor.org/rfc/rfc1475.txt",
  key="RFC 1475",
  abstract={This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="TP-IX, IPv7, IPng",
  doi="10.17487/RFC1475",
  }

@misc{rfc1476,
  author="R. Ullmann",
  title="{RAP: Internet Route Access Protocol}",
  howpublished="RFC 1476 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1476",
  pages="1--20",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1476.txt",
  key="RFC 1476",
  abstract={This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="RAP, Routing",
  doi="10.17487/RFC1476",
  }

@misc{rfc1477,
  author="M. Steenstrup",
  title="{IDPR as a Proposed Standard}",
  howpublished="RFC 1477 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1477",
  pages="1--13",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1477.txt",
  key="RFC 1477",
  abstract={This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Routing, Policy",
  doi="10.17487/RFC1477",
  }

@misc{rfc1478,
  author="M. Steenstrup",
  title="{An Architecture for Inter-Domain Policy Routing}",
  howpublished="RFC 1478 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1478",
  pages="1--35",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1478.txt",
  key="RFC 1478",
  abstract={We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]},
  keywords="IDPR-ARCH, IDPR",
  doi="10.17487/RFC1478",
  }

@misc{rfc1479,
  author="M. Steenstrup",
  title="{Inter-Domain Policy Routing Protocol Specification: Version 1}",
  howpublished="RFC 1479 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1479",
  pages="1--108",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1479.txt",
  key="RFC 1479",
  abstract={We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]},
  keywords="IDPR, IDPR",
  doi="10.17487/RFC1479",
  }

@misc{rfc1480,
  author="A. Cooper and J. Postel",
  title="{The US Domain}",
  howpublished="RFC 1480 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1480",
  pages="1--47",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1480.txt",
  key="RFC 1480",
  abstract={This is a description of the US Top Level Domains on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="DNS, top-level",
  doi="10.17487/RFC1480",
  }

@misc{rfc1481,
  author="C. Huitema",
  title="{IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling}",
  howpublished="RFC 1481 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1481",
  pages="1--2",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1481.txt",
  key="RFC 1481",
  abstract={CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="CIDR",
  doi="10.17487/RFC1481",
  }

@misc{rfc1482,
  author="M. Knopper and S. Richardson",
  title="{Aggregation Support in the NSFNET Policy-Based Routing Database}",
  howpublished="RFC 1482 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1482",
  pages="1--11",
  year=1993,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1482.txt",
  key="RFC 1482",
  abstract={This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="CIDR",
  doi="10.17487/RFC1482",
  }

@misc{rfc1483,
  author="Juha Heinanen",
  title="{Multiprotocol Encapsulation over ATM Adaptation Layer 5}",
  howpublished="RFC 1483 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1483",
  pages="1--16",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2684",
url="https://www.rfc-editor.org/rfc/rfc1483.txt",
  key="RFC 1483",
  abstract={This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]},
  keywords="ATM-ENCAP, IP, AAL5, over",
  doi="10.17487/RFC1483",
  }

@misc{rfc1484,
  author="S. Hardcastle-Kille",
  title="{Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))}",
  howpublished="RFC 1484 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1484",
  pages="1--25",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1781, 3494",
url="https://www.rfc-editor.org/rfc/rfc1484.txt",
  key="RFC 1484",
  abstract={This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="X.500, directory names, representing names",
  doi="10.17487/RFC1484",
  }

@misc{rfc1485,
  author="S. Hardcastle-Kille",
  title="{A String Representation of Distinguished Names (OSI-DS 23 (v5))}",
  howpublished="RFC 1485 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1485",
  pages="1--7",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1779, 3494",
url="https://www.rfc-editor.org/rfc/rfc1485.txt",
  key="RFC 1485",
  abstract={When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]},
  keywords="X.500, directory names, representing names",
  doi="10.17487/RFC1485",
  }

@misc{rfc1486,
  author="M. Rose and C. Malamud",
  title="{An Experiment in Remote Printing}",
  howpublished="RFC 1486 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1486",
  pages="1--14",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1528, 1529",
url="https://www.rfc-editor.org/rfc/rfc1486.txt",
  key="RFC 1486",
  abstract={This memo describes a technique for ``remote printing'' using the Internet mail infrastructure.  In particular, this memo focuses on the case in which remote printers are connected to the international telephone network.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="electronic mail, facsimile",
  doi="10.17487/RFC1486",
  }

@misc{rfc1487,
  author="W. Yeong and T. Howes and S. Kille",
  title="{X.500 Lightweight Directory Access Protocol}",
  howpublished="RFC 1487 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1487",
  pages="1--21",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1777, 3494",
url="https://www.rfc-editor.org/rfc/rfc1487.txt",
  key="RFC 1487",
  abstract={The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]},
  keywords="X.500, DAP, interactive access",
  doi="10.17487/RFC1487",
  }

@misc{rfc1488,
  author="T. Howes and S. Kille and W. Yeong and C. Robbins",
  title="{The X.500 String Representation of Standard Attribute Syntaxes}",
  howpublished="RFC 1488 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1488",
  pages="1--11",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1778",
url="https://www.rfc-editor.org/rfc/rfc1488.txt",
  key="RFC 1488",
  abstract={This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]},
  keywords="X.500, LDAP, lightweight directory protocol",
  doi="10.17487/RFC1488",
  }

@misc{rfc1489,
  author="A. Chernov",
  title="{Registration of a Cyrillic Character Set}",
  howpublished="RFC 1489 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1489",
  pages="1--5",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1489.txt",
  key="RFC 1489",
  abstract={Though the proposed character set ``koi8-r'' is not currently an international standard, there is very large user community (including Relcom Net) supporting it.  Factually, ``koi8-r'' is de-facto standard for Unix and global network applications in the former Soviet Union.  This is the reason the Society of Unix User Groups (SUUG) believes ``koi8-r'' should be registered.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1489",
  }

@misc{rfc1490,
  author="T. Bradley and C. Brown and A. Malis",
  title="{Multiprotocol Interconnect over Frame Relay}",
  howpublished="RFC 1490 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1490",
  pages="1--35",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2427",
url="https://www.rfc-editor.org/rfc/rfc1490.txt",
  key="RFC 1490",
  abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone.  It covers aspects of both Bridging and Routing.  Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]},
  keywords="standard, standards, IP, over",
  doi="10.17487/RFC1490",
  }

@misc{rfc1491,
  author="C. Weider and R. Wright",
  title="{A Survey of Advanced Usages of X.500}",
  howpublished="RFC 1491 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1491",
  pages="1--18",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1491.txt",
  key="RFC 1491",
  abstract={This document is the result of a survey asking people to detail their advanced usages of X.500.  It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a ``White Pages'' service.  This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="directory",
  doi="10.17487/RFC1491",
  }

@misc{rfc1492,
  author="C. Finseth",
  title="{An Access Control Protocol, Sometimes Called TACACS}",
  howpublished="RFC 1492 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1492",
  pages="1--21",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1492.txt",
  key="RFC 1492",
  abstract={This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers.  This same protocol is used by the University of Minnesota's distributed authentication system.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="TACACS, Terminal, Server, TAC",
  doi="10.17487/RFC1492",
  }

@misc{rfc1493,
  author="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie",
  title="{Definitions of Managed Objects for Bridges}",
  howpublished="RFC 1493 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1493",
  pages="1--34",
  year=1993,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4188",
url="https://www.rfc-editor.org/rfc/rfc1493.txt",
  key="RFC 1493",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]},
  keywords="BRIDGE-MIB, SNMP, MIB, standard, standards",
  doi="10.17487/RFC1493",
  }

@misc{rfc1494,
  author="H. Alvestrand and S. Thompson",
  title="{Equivalences between 1988 X.400 and RFC-822 Message Bodies}",
  howpublished="RFC 1494 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1494",
  pages="1--19",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1494.txt",
  key="RFC 1494",
  abstract={This document describes the content of the ``IANA MHS/MIME Equivalence table'', and defines the initial configuration of this table.  Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]},
  keywords="Equiv, Mail",
  doi="10.17487/RFC1494",
  }

@misc{rfc1495,
  author="H. Alvestrand and S. Kille and R. Miles and M. Rose and S. Thompson",
  title="{Mapping between X.400 and RFC-822 Message Bodies}",
  howpublished="RFC 1495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1495",
  pages="1--11",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2156",
url="https://www.rfc-editor.org/rfc/rfc1495.txt",
  key="RFC 1495",
  abstract={Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822.  The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers.  This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]},
  keywords="Mail",
  doi="10.17487/RFC1495",
  }

@misc{rfc1496,
  author="H. Alvestrand and J. Romaguera and K. Jordan",
  title="{Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages}",
  howpublished="RFC 1496 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1496",
  pages="1--5",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1496.txt",
  key="RFC 1496",
  abstract={This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328.  The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]},
  keywords="HARPOON, Mail",
  doi="10.17487/RFC1496",
  }

@misc{rfc1497,
  author="J. Reynolds",
  title="{BOOTP Vendor Information Extensions}",
  howpublished="RFC 1497 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1497",
  pages="1--8",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1533",
url="https://www.rfc-editor.org/rfc/rfc1497.txt",
  key="RFC 1497",
  abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo.  This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).},
  keywords="TAGS, Boot",
  doi="10.17487/RFC1497",
  }

@misc{rfc1498,
  author="J. Saltzer",
  title="{On the Naming and Binding of Network Destinations}",
  howpublished="RFC 1498 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1498",
  pages="1--10",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1498.txt",
  key="RFC 1498",
  abstract={This brief paper offers a perspective on the subject of names of destinations in data communication networks.  It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network.  Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NAMES, Addresses, Routes, Objects, Nodes, Paths",
  doi="10.17487/RFC1498",
  }

@misc{rfc1499,
  author="J. Elliott",
  title="{Summary of 1400-1499}",
  howpublished="RFC 1499 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1499",
  pages="1--21",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1499.txt",
  key="RFC 1499",
  keywords="Index",
  doi="10.17487/RFC1499",
  }

@misc{rfc1500,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1500 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1500",
  pages="1--36",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1540",
url="https://www.rfc-editor.org/rfc/rfc1500.txt",
  key="RFC 1500",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]},
  keywords="IAB",
  doi="10.17487/RFC1500",
  }

@misc{rfc1501,
  author="E. Brunsen",
  title="{OS/2 User Group}",
  howpublished="RFC 1501 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1501",
  pages="1--2",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1501.txt",
  key="RFC 1501",
  abstract={Memo soliciting reactions to the proposal of a OS/2 User Group.  This memo provides information for the Internet community.  This memo does not specify an IAB standard of any kind.},
  doi="10.17487/RFC1501",
  }

@misc{rfc1502,
  author="H. Alvestrand",
  title="{X.400 Use of Extended Character Sets}",
  howpublished="RFC 1502 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1502",
  pages="1--14",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1502.txt",
  key="RFC 1502",
  abstract={This RFC defines a suggested method of using ``GeneralText'' in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]},
  keywords="Mail",
  doi="10.17487/RFC1502",
  }

@misc{rfc1503,
  author="K. McCloghrie and M. Rose",
  title="{Algorithms for Automating Administration in SNMPv2 Managers}",
  howpublished="RFC 1503 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1503",
  pages="1--14",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1503.txt",
  key="RFC 1503",
  abstract={When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications.  This memo suggests an approach to achieve this goal.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Management, SNMP",
  doi="10.17487/RFC1503",
  }

@misc{rfc1504,
  author="A. Oppenheimer",
  title="{Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing}",
  howpublished="RFC 1504 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1504",
  pages="1--82",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1504.txt",
  key="RFC 1504",
  abstract={This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing.  AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="AVRP",
  doi="10.17487/RFC1504",
  }

@misc{rfc1505,
  author="A. Costanzo and D. Robinson and R. Ullmann",
  title="{Encoding Header Field for Internet Messages}",
  howpublished="RFC 1505 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1505",
  pages="1--36",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1505.txt",
  key="RFC 1505",
  abstract={This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages.  It replaces RFC 1154.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="EHF-MAIL, Mail",
  doi="10.17487/RFC1505",
  }

@misc{rfc1506,
  author="J. Houttuin",
  title="{A Tutorial on Gatewaying between X.400 and Internet Mail}",
  howpublished="RFC 1506 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1506",
  pages="1--39",
  year=1993,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1506.txt",
  key="RFC 1506",
  abstract={This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="822, email, RTR",
  doi="10.17487/RFC1506",
  }

@misc{rfc1507,
  author="C. Kaufman",
  title="{DASS - Distributed Authentication Security Service}",
  howpublished="RFC 1507 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1507",
  pages="1--119",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1507.txt",
  key="RFC 1507",
  abstract={The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="DASS, CAT",
  doi="10.17487/RFC1507",
  }

@misc{rfc1508,
  author="J. Linn",
  title="{Generic Security Service Application Program Interface}",
  howpublished="RFC 1508 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1508",
  pages="1--49",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2078",
url="https://www.rfc-editor.org/rfc/rfc1508.txt",
  key="RFC 1508",
  abstract={This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]},
  keywords="CAT,GSS,API",
  doi="10.17487/RFC1508",
  }

@misc{rfc1509,
  author="J. Wray",
  title="{Generic Security Service API : C-bindings}",
  howpublished="RFC 1509 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1509",
  pages="1--48",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2744",
url="https://www.rfc-editor.org/rfc/rfc1509.txt",
  key="RFC 1509",
  abstract={This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]},
  keywords="GSSAPI, CAT,GSS",
  doi="10.17487/RFC1509",
  }

@misc{rfc1510,
  author="J. Kohl and C. Neuman",
  title="{The Kerberos Network Authentication Service (V5)}",
  howpublished="RFC 1510 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1510",
  pages="1--112",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4120, 6649",
url="https://www.rfc-editor.org/rfc/rfc1510.txt",
  key="RFC 1510",
  abstract={This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]},
  keywords="KERBEROS, CAT,Security",
  doi="10.17487/RFC1510",
  }

@misc{rfc1511,
  author="J. Linn",
  title="{Common Authentication Technology Overview}",
  howpublished="RFC 1511 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1511",
  pages="1--2",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1511.txt",
  key="RFC 1511",
  abstract={This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="CAT,Security",
  doi="10.17487/RFC1511",
  }

@misc{rfc1512,
  author="J. Case and A. Rijsinghani",
  title="{FDDI Management Information Base}",
  howpublished="RFC 1512 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1512",
  pages="1--51",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1512.txt",
  key="RFC 1512",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.},
  keywords="FDDI-MIB , MIB, SNMP",
  doi="10.17487/RFC1512",
  }

@misc{rfc1513,
  author="S. Waldbusser",
  title="{Token Ring Extensions to the Remote Network Monitoring MIB}",
  howpublished="RFC 1513 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1513",
  pages="1--55",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1513.txt",
  key="RFC 1513",
  abstract={This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]},
  keywords="Monitoring, SNMP",
  doi="10.17487/RFC1513",
  }

@misc{rfc1514,
  author="P. Grillo and S. Waldbusser",
  title="{Host Resources MIB}",
  howpublished="RFC 1514 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1514",
  pages="1--33",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2790",
url="https://www.rfc-editor.org/rfc/rfc1514.txt",
  key="RFC 1514",
  abstract={This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]},
  keywords="HOST-MIB, Management, SNMP",
  doi="10.17487/RFC1514",
  }

@misc{rfc1515,
  author="D. McMaster and K. McCloghrie and S. Roberts",
  title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}",
  howpublished="RFC 1515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1515",
  pages="1--25",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3636",
url="https://www.rfc-editor.org/rfc/rfc1515.txt",
  key="RFC 1515",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]},
  keywords="MIB, Management, SNMP",
  doi="10.17487/RFC1515",
  }

@misc{rfc1516,
  author="D. McMaster and K. McCloghrie",
  title="{Definitions of Managed Objects for IEEE 802.3 Repeater Devices}",
  howpublished="RFC 1516 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1516",
  pages="1--40",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2108",
url="https://www.rfc-editor.org/rfc/rfc1516.txt",
  key="RFC 1516",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as ``hubs.'' [STANDARDS-TRACK]},
  keywords="Management, SNMP",
  doi="10.17487/RFC1516",
  }

@misc{rfc1517,
  author="Internet Engineering Steering Group and R. Hinden",
  title="{Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)}",
  howpublished="RFC 1517 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1517",
  pages="1--4",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1517.txt",
  key="RFC 1517",
  abstract={Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]},
  keywords="CIDR, Address",
  doi="10.17487/RFC1517",
  }

@misc{rfc1518,
  author="Y. Rekhter and T. Li",
  title="{An Architecture for IP Address Allocation with CIDR}",
  howpublished="RFC 1518 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1518",
  pages="1--27",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1518.txt",
  key="RFC 1518",
  abstract={This paper provides an architecture and a plan for allocating IP addresses in the Internet.  This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]},
  keywords="CIDR-ARCH, Classless, Routing",
  doi="10.17487/RFC1518",
  }

@misc{rfc1519,
  author="V. Fuller and T. Li and J. Yu and K. Varadhan",
  title="{Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy}",
  howpublished="RFC 1519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1519",
  pages="1--24",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4632",
url="https://www.rfc-editor.org/rfc/rfc1519.txt",
  key="RFC 1519",
  abstract={This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]},
  keywords="CIDR-STRA]",
  doi="10.17487/RFC1519",
  }

@misc{rfc1520,
  author="Y. Rekhter and C. Topolcic",
  title="{Exchanging Routing Information Across Provider Boundaries in the CIDR Environment}",
  howpublished="RFC 1520 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1520",
  pages="1--9",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1520.txt",
  key="RFC 1520",
  abstract={The purpose of this document is twofold.  First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not.  Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Classless, Routing",
  doi="10.17487/RFC1520",
  }

@misc{rfc1521,
  author="N. Borenstein and N. Freed",
  title="{MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies}",
  howpublished="RFC 1521 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1521",
  pages="1--81",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049, updated by RFC 1590",
url="https://www.rfc-editor.org/rfc/rfc1521.txt",
  key="RFC 1521",
  abstract={This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information.  This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]},
  keywords="email, multimedia",
  doi="10.17487/RFC1521",
  }

@misc{rfc1522,
  author="K. Moore",
  title="{MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text}",
  howpublished="RFC 1522 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1522",
  pages="1--10",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049",
url="https://www.rfc-editor.org/rfc/rfc1522.txt",
  key="RFC 1522",
  abstract={This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers.  The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.},
  keywords="email, character",
  doi="10.17487/RFC1522",
  }

@misc{rfc1523,
  author="N. Borenstein",
  title="{The text/enriched MIME Content-type}",
  howpublished="RFC 1523 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1523",
  pages="1--15",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 1563, 1896",
url="https://www.rfc-editor.org/rfc/rfc1523.txt",
  key="RFC 1523",
  abstract={MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.  This document defines one particular type of MIME data, the text/enriched type, a refinement of the ``text/richtext'' type defined in RFC 1341.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="email, mail, richtext",
  doi="10.17487/RFC1523",
  }

@misc{rfc1524,
  author="N. Borenstein",
  title="{A User Agent Configuration Mechanism For Multimedia Mail Format Information}",
  howpublished="RFC 1524 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1524",
  pages="1--12",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1524.txt",
  key="RFC 1524",
  abstract={This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="MIME, email, mailcap",
  doi="10.17487/RFC1524",
  }

@misc{rfc1525,
  author="E. Decker and K. McCloghrie and P. Langille and A. Rijsinghani",
  title="{Definitions of Managed Objects for Source Routing Bridges}",
  howpublished="RFC 1525 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1525",
  pages="1--18",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1525.txt",
  key="RFC 1525",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular, it defines objects for managing source routing and source routing transparent bridges.  These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]},
  keywords="SRB-MIB, MIB, Management, SNMP",
  doi="10.17487/RFC1525",
  }

@misc{rfc1526,
  author="D. Piscitello",
  title="{Assignment of System Identifiers for TUBA/CLNP Hosts}",
  howpublished="RFC 1526 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1526",
  pages="1--8",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1526.txt",
  key="RFC 1526",
  abstract={This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="NSAP, Address",
  doi="10.17487/RFC1526",
  }

@misc{rfc1527,
  author="G. Cook",
  title="{What Should We Plan Given the Dilemma of the Network?}",
  howpublished="RFC 1527 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1527",
  pages="1--17",
  year=1993,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1527.txt",
  key="RFC 1527",
  abstract={The Internet community needs to be asking what the most important policy issues facing the network are.  And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1527",
  }

@misc{rfc1528,
  author="C. Malamud and M. Rose",
  title="{Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures}",
  howpublished="RFC 1528 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1528",
  pages="1--12",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1528.txt",
  key="RFC 1528",
  abstract={This memo describes a technique for ``remote printing'' using the Internet mail infrastructure.  In particular, this memo focuses on the case in which remote printers are connected to the international telephone network.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.},
  keywords="REM-PRINT, FAX, Facsimile",
  doi="10.17487/RFC1528",
  }

@misc{rfc1529,
  author="C. Malamud and M. Rose",
  title="{Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies}",
  howpublished="RFC 1529 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1529",
  pages="1--5",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1529.txt",
  key="RFC 1529",
  abstract={This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain.  The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="FAX, Facsimile",
  doi="10.17487/RFC1529",
  }

@misc{rfc1530,
  author="C. Malamud and M. Rose",
  title="{Principles of Operation for the TPC.INT Subdomain: General Principles and Policy}",
  howpublished="RFC 1530 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1530",
  pages="1--7",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1530.txt",
  key="RFC 1530",
  abstract={This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="FAX, Facsimile",
  doi="10.17487/RFC1530",
  }

@misc{rfc1531,
  author="R. Droms",
  title="{Dynamic Host Configuration Protocol}",
  howpublished="RFC 1531 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1531",
  pages="1--39",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1541",
url="https://www.rfc-editor.org/rfc/rfc1531.txt",
  key="RFC 1531",
  abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]},
  keywords="DHCP",
  doi="10.17487/RFC1531",
  }

@misc{rfc1532,
  author="W. Wimer",
  title="{Clarifications and Extensions for the Bootstrap Protocol}",
  howpublished="RFC 1532 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1532",
  pages="1--22",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1542",
url="https://www.rfc-editor.org/rfc/rfc1532.txt",
  key="RFC 1532",
  abstract={Some aspects of the BOOTP protocol were rather loosely defined in its original specification.  In particular, only a general description was provided for the behavior of ``BOOTP relay agents'' (originally called BOOTP forwarding agents").  The client behavior description also suffered in certain ways.  This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]},
  keywords="BOOTP",
  doi="10.17487/RFC1532",
  }

@misc{rfc1533,
  author="S. Alexander and R. Droms",
  title="{DHCP Options and BOOTP Vendor Extensions}",
  howpublished="RFC 1533 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1533",
  pages="1--30",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2132",
url="https://www.rfc-editor.org/rfc/rfc1533.txt",
  key="RFC 1533",
  abstract={This document specifies the current set of DHCP options. [STANDARDS-TRACK]},
  keywords="Dynamic, Host, Configuration, Bootstrap",
  doi="10.17487/RFC1533",
  }

@misc{rfc1534,
  author="R. Droms",
  title="{Interoperation Between DHCP and BOOTP}",
  howpublished="RFC 1534 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1534",
  pages="1--4",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1534.txt",
  key="RFC 1534",
  abstract={DHCP provides a superset of the functions provided by BOOTP.  This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]},
  keywords="DHCP-BOOTP, Dynamic, Host, Configuration, Bootstrap",
  doi="10.17487/RFC1534",
  }

@misc{rfc1535,
  author="E. Gavron",
  title="{A Security Problem and Proposed Correction With Widely Deployed DNS Software}",
  howpublished="RFC 1535 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1535",
  pages="1--5",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1535.txt",
  key="RFC 1535",
  abstract={This document discusses a flaw in some of the currently distributed name resolver clients.  The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit.  This document points out the flaw, a case in point, and a solution.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Domain, Name, System",
  doi="10.17487/RFC1535",
  }

@misc{rfc1536,
  author="A. Kumar and J. Postel and C. Neuman and P. Danzig and S. Miller",
  title="{Common DNS Implementation Errors and Suggested Fixes}",
  howpublished="RFC 1536 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1536",
  pages="1--12",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1536.txt",
  key="RFC 1536",
  abstract={This memo describes common errors seen in DNS implementations and suggests some fixes.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Domain, Name, System",
  doi="10.17487/RFC1536",
  }

@misc{rfc1537,
  author="P. Beertema",
  title="{Common DNS Data File Configuration Errors}",
  howpublished="RFC 1537 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1537",
  pages="1--9",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1912",
url="https://www.rfc-editor.org/rfc/rfc1537.txt",
  key="RFC 1537",
  abstract={This memo describes errors often found in DNS data files.  It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Domain, Name, System",
  doi="10.17487/RFC1537",
  }

@misc{rfc1538,
  author="W. Behl and B. Sterling and W. Teskey",
  title="{Advanced SNA/IP : A Simple SNA Transport Protocol}",
  howpublished="RFC 1538 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1538",
  pages="1--10",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1538.txt",
  key="RFC 1538",
  abstract={This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="ADSNA-IP, Domain, Name, System",
  doi="10.17487/RFC1538",
  }

@misc{rfc1539,
  author="G. Malkin",
  title="{The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force}",
  howpublished="RFC 1539 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1539",
  pages="1--22",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1718",
url="https://www.rfc-editor.org/rfc/rfc1539.txt",
  key="RFC 1539",
  abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This memo provides information for the Internet community.  It does not specify an Internet standard. [FYI 17]},
  keywords="Introduction",
  doi="10.17487/RFC1539",
  }

@misc{rfc1540,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1540 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1540",
  pages="1--34",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1600",
url="https://www.rfc-editor.org/rfc/rfc1540.txt",
  key="RFC 1540",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1540",
  }

@misc{rfc1541,
  author="R. Droms",
  title="{Dynamic Host Configuration Protocol}",
  howpublished="RFC 1541 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1541",
  pages="1--39",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2131",
url="https://www.rfc-editor.org/rfc/rfc1541.txt",
  key="RFC 1541",
  abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.  DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]},
  keywords="DHCP",
  doi="10.17487/RFC1541",
  }

@misc{rfc1542,
  author="W. Wimer",
  title="{Clarifications and Extensions for the Bootstrap Protocol}",
  howpublished="RFC 1542 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1542",
  pages="1--23",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1542.txt",
  key="RFC 1542",
  abstract={Some aspects of the BOOTP protocol were rather loosely defined in its original specification.  In particular, only a general description was provided for the behavior of ``BOOTP relay agents'' (originally called ``BOOTP forwarding agents'').  The client behavior description also suffered in certain ways.  This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]},
  keywords="BOOTP",
  doi="10.17487/RFC1542",
  }

@misc{rfc1543,
  author="J. Postel",
  title="{Instructions to RFC Authors}",
  howpublished="RFC 1543 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1543",
  pages="1--16",
  year=1993,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2223",
url="https://www.rfc-editor.org/rfc/rfc1543.txt",
  key="RFC 1543",
  abstract={This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Request, For, Comment",
  doi="10.17487/RFC1543",
  }

@misc{rfc1544,
  author="M. Rose",
  title="{The Content-MD5 Header Field}",
  howpublished="RFC 1544 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1544",
  pages="1--3",
  year=1993,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1864",
url="https://www.rfc-editor.org/rfc/rfc1544.txt",
  key="RFC 1544",
  abstract={This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]},
  keywords="MIME, EMail, Integrity, MIC, Digest",
  doi="10.17487/RFC1544",
  }

@misc{rfc1545,
  author="D. Piscitello",
  title="{FTP Operation Over Big Address Records (FOOBAR)}",
  howpublished="RFC 1545 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1545",
  pages="1--5",
  year=1993,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1639",
url="https://www.rfc-editor.org/rfc/rfc1545.txt",
  key="RFC 1545",
  abstract={This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959).  This is a general solution, applicable for all ``next generation'' IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="FTP, File Transfer, PORT, PASV, LPRT, LPSV",
  doi="10.17487/RFC1545",
  }

@misc{rfc1546,
  author="C. Partridge and T. Mendez and W. Milliken",
  title="{Host Anycasting Service}",
  howpublished="RFC 1546 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1546",
  pages="1--9",
  year=1993,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1546.txt",
  key="RFC 1546",
  abstract={This RFC describes an internet anycasting service for IP.  The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Resource Location, Multicasting",
  doi="10.17487/RFC1546",
  }

@misc{rfc1547,
  author="D. Perkins",
  title="{Requirements for an Internet Standard Point-to-Point Protocol}",
  howpublished="RFC 1547 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1547",
  pages="1--21",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1547.txt",
  key="RFC 1547",
  abstract={This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP, link, serial, line",
  doi="10.17487/RFC1547",
  }

@misc{rfc1548,
  author="W. Simpson",
  title="{The Point-to-Point Protocol (PPP)}",
  howpublished="RFC 1548 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1548",
  pages="1--53",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1661, updated by RFC 1570",
url="https://www.rfc-editor.org/rfc/rfc1548.txt",
  key="RFC 1548",
  abstract={This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]},
  keywords="link, serial, line",
  doi="10.17487/RFC1548",
  }

@misc{rfc1549,
  author="W. Simpson",
  title="{PPP in HDLC Framing}",
  howpublished="RFC 1549 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1549",
  pages="1--18",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1662",
url="https://www.rfc-editor.org/rfc/rfc1549.txt",
  key="RFC 1549",
  abstract={This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="point, link, serial, line",
  doi="10.17487/RFC1549",
  }

@misc{rfc1550,
  author="S. Bradner and A. Mankin",
  title="{IP: Next Generation (IPng) White Paper Solicitation}",
  howpublished="RFC 1550 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1550",
  pages="1--6",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1550.txt",
  key="RFC 1550",
  abstract={This memo solicits white papers on topics related to the IPng requirements and selection criteria.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1550",
  }

@misc{rfc1551,
  author="M. Allen",
  title="{Novell IPX Over Various WAN Media (IPXWAN)}",
  howpublished="RFC 1551 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1551",
  pages="1--22",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1634",
url="https://www.rfc-editor.org/rfc/rfc1551.txt",
  key="RFC 1551",
  abstract={This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internetworking, Packet, Exchange",
  doi="10.17487/RFC1551",
  }

@misc{rfc1552,
  author="W. Simpson",
  title="{The PPP Internetworking Packet Exchange Control Protocol (IPXCP)}",
  howpublished="RFC 1552 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1552",
  pages="1--16",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1552.txt",
  key="RFC 1552",
  abstract={This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]},
  keywords="IPXCP, IPX, point, serial, line, link",
  doi="10.17487/RFC1552",
  }

@misc{rfc1553,
  author="S. Mathur and M. Lewis",
  title="{Compressing IPX Headers Over WAN Media (CIPX)}",
  howpublished="RFC 1553 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1553",
  pages="1--23",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1553.txt",
  key="RFC 1553",
  abstract={This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]},
  keywords="CIPX, Internetworking, Packet, Exchange",
  doi="10.17487/RFC1553",
  }

@misc{rfc1554,
  author="M. Ohta and K. Handa",
  title="{ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP}",
  howpublished="RFC 1554 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1554",
  pages="1--6",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1554.txt",
  key="RFC 1554",
  abstract={This memo describes a text encoding scheme: ``ISO-2022-JP-2'', which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks.  The encoding is a multilingual extension of ``ISO-2022-JP'', the existing encoding for Japanese [2022JP].  The encoding is supported by an Emacs based multilingual text editor: MULE [MULE].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Character Set, Japanese",
  doi="10.17487/RFC1554",
  }

@misc{rfc1555,
  author="H. Nussbacher and Y. Bourvine",
  title="{Hebrew Character Encoding for Internet Messages}",
  howpublished="RFC 1555 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1555",
  pages="1--5",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1555.txt",
  key="RFC 1555",
  abstract={This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew.  The standard devised makes use of MIME [RFC1521] and ISO-8859-8.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Character Set",
  doi="10.17487/RFC1555",
  }

@misc{rfc1556,
  author="H. Nussbacher",
  title="{Handling of Bi-directional Texts in MIME}",
  howpublished="RFC 1556 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1556",
  pages="1--3",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1556.txt",
  key="RFC 1556",
  abstract={This document describes the format and syntax of the ``direction'' keyword to be used with bi-directional texts in MIME.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Character Set",
  doi="10.17487/RFC1556",
  }

@misc{rfc1557,
  author="U. Choi and K. Chon and H. Park",
  title="{Korean Character Encoding for Internet Messages}",
  howpublished="RFC 1557 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1557",
  pages="1--5",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1557.txt",
  key="RFC 1557",
  abstract={This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822].  This encoding method was specified in 1991, and has since then been used.  It has now widely being used in Korean IP networks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Character Set",
  doi="10.17487/RFC1557",
  }

@misc{rfc1558,
  author="T. Howes",
  title="{A String Representation of LDAP Search Filters}",
  howpublished="RFC 1558 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1558",
  pages="1--3",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1960",
url="https://www.rfc-editor.org/rfc/rfc1558.txt",
  key="RFC 1558",
  abstract={The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server.  Some applications may find it useful to have a common way of representing these search filters in a human-readable form.  This document defines a human-readable string format for representing LDAP search filters.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="X.500, Directory",
  doi="10.17487/RFC1558",
  }

@misc{rfc1559,
  author="J. Saperia",
  title="{DECnet Phase IV MIB Extensions}",
  howpublished="RFC 1559 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1559",
  pages="1--69",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1559.txt",
  key="RFC 1559",
  abstract={This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB.  It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]},
  keywords="DECNET-MIB, Management, SNMP",
  doi="10.17487/RFC1559",
  }

@misc{rfc1560,
  author="B. Leiner and Y. Rekhter",
  title="{The MultiProtocol Internet}",
  howpublished="RFC 1560 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1560",
  pages="1--7",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1560.txt",
  key="RFC 1560",
  abstract={There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol.  This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas.  It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Architecture, Protocol",
  doi="10.17487/RFC1560",
  }

@misc{rfc1561,
  author="D. Piscitello",
  title="{Use of ISO CLNP in TUBA Environments}",
  howpublished="RFC 1561 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1561",
  pages="1--25",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1561.txt",
  key="RFC 1561",
  abstract={This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses.  It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="CLNP-TUBA, OSI, IP, Internet, Protocol",
  doi="10.17487/RFC1561",
  }

@misc{rfc1562,
  author="G. Michaelson and M. Prior",
  title="{Naming Guidelines for the AARNet X.500 Directory Service}",
  howpublished="RFC 1562 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1562",
  pages="1--4",
  year=1993,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1562.txt",
  key="RFC 1562",
  abstract={This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001).  AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Australia",
  doi="10.17487/RFC1562",
  }

@misc{rfc1563,
  author="N. Borenstein",
  title="{The text/enriched MIME Content-type}",
  howpublished="RFC 1563 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1563",
  pages="1--16",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1896",
url="https://www.rfc-editor.org/rfc/rfc1563.txt",
  key="RFC 1563",
  abstract={MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.  This document defines one particular type of MIME data, the text/enriched type, a refinement of the ``text/richtext'' type defined in RFC 1341.  The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="email, mail, richtext",
  doi="10.17487/RFC1563",
  }

@misc{rfc1564,
  author="P. Barker and R. Hedberg",
  title="{DSA Metrics (OSI-DS 34 (v3))}",
  howpublished="RFC 1564 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1564",
  pages="1--21",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1564.txt",
  key="RFC 1564",
  abstract={This document defines a set of criteria by which a DSA implementation may be judged.  Particular issues covered include conformance to standards; performance; demonstrated interoperability.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="x.500, Directory, Service, Agent",
  doi="10.17487/RFC1564",
  }

@misc{rfc1565,
  author="S. Kille and N. Freed",
  title="{Network Services Monitoring MIB}",
  howpublished="RFC 1565 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1565",
  pages="1--17",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2248",
url="https://www.rfc-editor.org/rfc/rfc1565.txt",
  key="RFC 1565",
  abstract={This document defines a MIB which contains the elements common to the monitoring of any network service application.  This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]},
  keywords="Management, Information, Base",
  doi="10.17487/RFC1565",
  }

@misc{rfc1566,
  author="S. Kille and N. Freed",
  title="{Mail Monitoring MIB}",
  howpublished="RFC 1566 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1566",
  pages="1--20",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2249, 2789",
url="https://www.rfc-editor.org/rfc/rfc1566.txt",
  key="RFC 1566",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs).  It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]},
  keywords="Management, Information, Base",
  doi="10.17487/RFC1566",
  }

@misc{rfc1567,
  author="G. Mansfield and S. Kille",
  title="{X.500 Directory Monitoring MIB}",
  howpublished="RFC 1567 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1567",
  pages="1--18",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2605",
url="https://www.rfc-editor.org/rfc/rfc1567.txt",
  key="RFC 1567",
  abstract={This document defines a portion of the Management Information Base (MIB).  It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory.  This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]},
  keywords="X500-MIB, Management, Information, Base",
  doi="10.17487/RFC1567",
  }

@misc{rfc1568,
  author="A. Gwinn",
  title="{Simple Network Paging Protocol - Version 1(b)}",
  howpublished="RFC 1568 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1568",
  pages="1--8",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1645",
url="https://www.rfc-editor.org/rfc/rfc1568.txt",
  key="RFC 1568",
  abstract={This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Beeper",
  doi="10.17487/RFC1568",
  }

@misc{rfc1569,
  author="M. Rose",
  title="{Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures}",
  howpublished="RFC 1569 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1569",
  pages="1--6",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1703",
url="https://www.rfc-editor.org/rfc/rfc1569.txt",
  key="RFC 1569",
  abstract={This memo describes a technique for radio paging using the Internet mail infrastructure.  In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Beeper",
  doi="10.17487/RFC1569",
  }

@misc{rfc1570,
  author="W. Simpson",
  title="{PPP LCP Extensions}",
  howpublished="RFC 1570 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1570",
  pages="1--19",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2484",
url="https://www.rfc-editor.org/rfc/rfc1570.txt",
  key="RFC 1570",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.  This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]},
  keywords="PPP-LCP, Point-to Point, Link, Control, Protocol, serial, line",
  doi="10.17487/RFC1570",
  }

@misc{rfc1571,
  author="D. Borman",
  title="{Telnet Environment Option Interoperability Issues}",
  howpublished="RFC 1571 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1571",
  pages="1--4",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1571.txt",
  key="RFC 1571",
  abstract={This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1571",
  }

@misc{rfc1572,
  author="S. Alexander",
  title="{Telnet Environment Option}",
  howpublished="RFC 1572 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1572",
  pages="1--7",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1572.txt",
  key="RFC 1572",
  abstract={This document specifies a mechanism for passing environment information between a telnet client and server.  Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]},
  keywords="TOPT-ENVIR",
  doi="10.17487/RFC1572",
  }

@misc{rfc1573,
  author="K. McCloghrie and F. Kastenholz",
  title="{Evolution of the Interfaces Group of MIB-II}",
  howpublished="RFC 1573 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1573",
  pages="1--55",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2233",
url="https://www.rfc-editor.org/rfc/rfc1573.txt",
  key="RFC 1573",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]},
  keywords="Management, Information, Base",
  doi="10.17487/RFC1573",
  }

@misc{rfc1574,
  author="S. Hares and C. Wittbrodt",
  title="{Essential Tools for the OSI Internet}",
  howpublished="RFC 1574 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1574",
  pages="1--13",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1574.txt",
  key="RFC 1574",
  abstract={This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Echo, Traceroute, Routing Table, CLNP",
  doi="10.17487/RFC1574",
  }

@misc{rfc1575,
  author="S. Hares and C. Wittbrodt",
  title="{An Echo Function for CLNP (ISO 8473)}",
  howpublished="RFC 1575 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1575",
  pages="1--9",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1575.txt",
  key="RFC 1575",
  abstract={This memo defines an echo function for the connection-less network layer protocol.  The mechanism that is mandated here is in the final process of being standardized by ISO as ``Amendment X: Addition of an Echo function to ISO 8473'' an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]},
  keywords="ISO-TS-ECHO",
  doi="10.17487/RFC1575",
  }

@misc{rfc1576,
  author="J. Penner",
  title="{TN3270 Current Practices}",
  howpublished="RFC 1576 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1576",
  pages="1--12",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1576.txt",
  key="RFC 1576",
  abstract={This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities.  The name traditionally associated with this implementation is TN3270.  This memo provides information for the Internet community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Telnet Option Terminal Type EOR Binary",
  doi="10.17487/RFC1576",
  }

@misc{rfc1577,
  author="M. Laubach",
  title="{Classical IP and ARP over ATM}",
  howpublished="RFC 1577 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1577",
  pages="1--17",
  year=1994,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2225",
url="https://www.rfc-editor.org/rfc/rfc1577.txt",
  key="RFC 1577",
  abstract={This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]},
  keywords="Internet, Protocol, Address, Resolution, Asynchronous, Transmission, Mode",
  doi="10.17487/RFC1577",
  }

@misc{rfc1578,
  author="J. Sellers",
  title="{FYI on Questions and Answers - Answers to Commonly Asked ``Primary and Secondary School Internet User'' Questions}",
  howpublished="RFC 1578 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1578",
  pages="1--53",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1941",
url="https://www.rfc-editor.org/rfc/rfc1578.txt",
  key="RFC 1578",
  abstract={The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind. [FYI 22]},
  keywords="K12",
  doi="10.17487/RFC1578",
  }

@misc{rfc1579,
  author="S. Bellovin",
  title="{Firewall-Friendly FTP}",
  howpublished="RFC 1579 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1579",
  pages="1--4",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1579.txt",
  key="RFC 1579",
  abstract={This memo describes a suggested change to the behavior of FTP client programs.  This document provides information for the Internet community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="file, transfer, PORT, PASV, Security",
  doi="10.17487/RFC1579",
  }

@misc{rfc1580,
  author="EARN Staff",
  title="{Guide to Network Resource Tools}",
  howpublished="RFC 1580 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1580",
  pages="1--107",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1580.txt",
  key="RFC 1580",
  abstract={The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind. [FYI 23]},
  keywords="EARN, BITNET, Gopher, World-Wide Web, WWW, WAIS, Archie, Whois, X.500, Netfind, Trickle, BIFTP, Listserv, Netnews, Astra, NetServ, Mail Base, Prospero, IRC, Relay",
  doi="10.17487/RFC1580",
  }

@misc{rfc1581,
  author="G. Meyer",
  title="{Protocol Analysis for Extensions to RIP to Support Demand Circuits}",
  howpublished="RFC 1581 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1581",
  pages="1--4",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1581.txt",
  key="RFC 1581",
  abstract={As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="routing, Protocol",
  doi="10.17487/RFC1581",
  }

@misc{rfc1582,
  author="G. Meyer",
  title="{Extensions to RIP to Support Demand Circuits}",
  howpublished="RFC 1582 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1582",
  pages="1--29",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1582.txt",
  key="RFC 1582",
  abstract={This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]},
  keywords="RIP-DC, routing, Protocol",
  doi="10.17487/RFC1582",
  }

@misc{rfc1583,
  author="J. Moy",
  title="{OSPF Version 2}",
  howpublished="RFC 1583 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1583",
  pages="1--216",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2178",
url="https://www.rfc-editor.org/rfc/rfc1583.txt",
  key="RFC 1583",
  abstract={This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol. [STANDARDS-TRACK]},
  keywords="equal-cost, multipath, link state, LSA",
  doi="10.17487/RFC1583",
  }

@misc{rfc1584,
  author="J. Moy",
  title="{Multicast Extensions to OSPF}",
  howpublished="RFC 1584 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1584",
  pages="1--102",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1584.txt",
  key="RFC 1584",
  abstract={This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]},
  keywords="OSPF-Multi, Open, Shortest, Path, First",
  doi="10.17487/RFC1584",
  }

@misc{rfc1585,
  author="J. Moy",
  title="{MOSPF: Analysis and Experience}",
  howpublished="RFC 1585 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1585",
  pages="1--13",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1585.txt",
  key="RFC 1585",
  abstract={This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by ``Internet Engineering Task Force internet routing protocol standardization criteria'' ([RFC 1264]).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Multicast, Open, Shortest, Path, First, OSPF",
  doi="10.17487/RFC1585",
  }

@misc{rfc1586,
  author="O. deSouza and M. Rodrigues",
  title="{Guidelines for Running OSPF Over Frame Relay Networks}",
  howpublished="RFC 1586 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1586",
  pages="1--6",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1586.txt",
  key="RFC 1586",
  abstract={This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="FR, Open, Shortest, Path, First",
  doi="10.17487/RFC1586",
  }

@misc{rfc1587,
  author="R. Coltun and V. Fuller",
  title="{The OSPF NSSA Option}",
  howpublished="RFC 1587 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1587",
  pages="1--17",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3101",
url="https://www.rfc-editor.org/rfc/rfc1587.txt",
  key="RFC 1587",
  abstract={This document describes a new optional type of OSPF area, somewhat humorously referred to as a ``not-so-stubby'' area (or NSSA).  NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]},
  keywords="OSPF-NSSA, Open, Shortest, Path, First, not so stubby, area, routing, protocol",
  doi="10.17487/RFC1587",
  }

@misc{rfc1588,
  author="J. Postel and C. Anderson",
  title="{White Pages Meeting Report}",
  howpublished="RFC 1588 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1588",
  pages="1--35",
  year=1994,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1588.txt",
  key="RFC 1588",
  abstract={This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="X-500 directory",
  doi="10.17487/RFC1588",
  }

@misc{rfc1589,
  author="D. Mills",
  title="{A Kernel Model for Precision Timekeeping}",
  howpublished="RFC 1589 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1589",
  pages="1--37",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1589.txt",
  key="RFC 1589",
  abstract={This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system.  The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Time, NTP, Clock",
  doi="10.17487/RFC1589",
  }

@misc{rfc1590,
  author="J. Postel",
  title="{Media Type Registration Procedure}",
  howpublished="RFC 1590 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1590",
  pages="1--7",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049",
url="https://www.rfc-editor.org/rfc/rfc1590.txt",
  key="RFC 1590",
  abstract={Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications.  This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes).  It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="email, multimedia",
  doi="10.17487/RFC1590",
  }

@misc{rfc1591,
  author="J. Postel",
  title="{Domain Name System Structure and Delegation}",
  howpublished="RFC 1591 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1591",
  pages="1--7",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1591.txt",
  key="RFC 1591",
  abstract={This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DNS, Policy, Top-Level, TLD",
  doi="10.17487/RFC1591",
  }

@misc{rfc1592,
  author="B. Wijnen and G. Carpenter and K. Curran and A. Sehgal and G. Waters",
  title="{Simple Network Management Protocol Distributed Protocol Interface Version 2.0}",
  howpublished="RFC 1592 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1592",
  pages="1--54",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1592.txt",
  key="RFC 1592",
  abstract={This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SNMP-DPI, SNMP, DPT, IBM",
  doi="10.17487/RFC1592",
  }

@misc{rfc1593,
  author="W. McKenzie and J. Cheng",
  title="{SNA APPN Node MIB}",
  howpublished="RFC 1593 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1593",
  pages="1--120",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1593.txt",
  key="RFC 1593",
  abstract={This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IBM, Management",
  doi="10.17487/RFC1593",
  }

@misc{rfc1594,
  author="A. Marine and J. Reynolds and G. Malkin",
  title="{FYI on Questions and Answers - Answers to Commonly asked ``New Internet User'' Questions}",
  howpublished="RFC 1594 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1594",
  pages="1--44",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2664",
url="https://www.rfc-editor.org/rfc/rfc1594.txt",
  key="RFC 1594",
  abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A).  The goal is to document the most commonly asked questions and answers in the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind. [FYI 4]},
  keywords="documentation, help, information, FAQ",
  doi="10.17487/RFC1594",
  }

@misc{rfc1595,
  author="T. Brown and K. Tesink",
  title="{Definitions of Managed Objects for the SONET/SDH Interface Type}",
  howpublished="RFC 1595 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1595",
  pages="1--59",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2558",
url="https://www.rfc-editor.org/rfc/rfc1595.txt",
  key="RFC 1595",
  keywords="SONET-MIB, MIB, Management, SNMP",
  doi="10.17487/RFC1595",
  }

@misc{rfc1596,
  author="T. Brown",
  title="{Definitions of Managed Objects for Frame Relay Service}",
  howpublished="RFC 1596 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1596",
  pages="1--46",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1604",
url="https://www.rfc-editor.org/rfc/rfc1596.txt",
  key="RFC 1596",
  keywords="FR, MIB, Management, SNMP",
  doi="10.17487/RFC1596",
  }

@misc{rfc1597,
  author="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. de Groot",
  title="{Address Allocation for Private Internets}",
  howpublished="RFC 1597 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1597",
  pages="1--8",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1918",
url="https://www.rfc-editor.org/rfc/rfc1597.txt",
  key="RFC 1597",
  abstract={This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Network, Number, Local",
  doi="10.17487/RFC1597",
  }

@misc{rfc1598,
  author="W. Simpson",
  title="{PPP in X.25}",
  howpublished="RFC 1598 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1598",
  pages="1--8",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1598.txt",
  key="RFC 1598",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="PPP-X25, point",
  doi="10.17487/RFC1598",
  }

@misc{rfc1599,
  author="M. Kennedy",
  title="{Summary of 1500-1599}",
  howpublished="RFC 1599 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1599",
  pages="1--22",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1599.txt",
  key="RFC 1599",
  keywords="Index",
  doi="10.17487/RFC1599",
  }

@misc{rfc1600,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1600 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1600",
  pages="1--36",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1610",
url="https://www.rfc-editor.org/rfc/rfc1600.txt",
  key="RFC 1600",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1600",
  }

@misc{rfc1601,
  author="C. Huitema",
  title="{Charter of the Internet Architecture Board (IAB)}",
  howpublished="RFC 1601 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1601",
  pages="1--6",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2850",
url="https://www.rfc-editor.org/rfc/rfc1601.txt",
  key="RFC 1601",
  abstract={This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ISOC, Internet Society, IETF, IRTF",
  doi="10.17487/RFC1601",
  }

@misc{rfc1602,
  author="Internet Architecture Board and Internet Engineering Steering Group",
  title="{The Internet Standards Process -- Revision 2}",
  howpublished="RFC 1602 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1602",
  pages="1--37",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2026, updated by RFC 1871",
url="https://www.rfc-editor.org/rfc/rfc1602.txt",
  key="RFC 1602",
  abstract={This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1602",
  }

@misc{rfc1603,
  author="E. Huizer and D. Crocker",
  title="{IETF Working Group Guidelines and Procedures}",
  howpublished="RFC 1603 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1603",
  pages="1--29",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2418, updated by RFC 1871",
url="https://www.rfc-editor.org/rfc/rfc1603.txt",
  key="RFC 1603",
  abstract={This document describes the guidelines and procedures for formation and operation of IETF working groups.  It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="WG",
  doi="10.17487/RFC1603",
  }

@misc{rfc1604,
  author="T. Brown",
  title="{Definitions of Managed Objects for Frame Relay Service}",
  howpublished="RFC 1604 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1604",
  pages="1--46",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2954",
url="https://www.rfc-editor.org/rfc/rfc1604.txt",
  key="RFC 1604",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]},
  keywords="FR-MIB, MIB, Management, SNMP, Network",
  doi="10.17487/RFC1604",
  }

@misc{rfc1605,
  author="W. Shakespeare",
  title="{SONET to Sonnet Translation}",
  howpublished="RFC 1605 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1605",
  pages="1--3",
  year=1994,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1605.txt",
  key="RFC 1605",
  abstract={Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link.  This memo describes a particular method, SONET Over Novel English Translation (SONNET).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Humor",
  doi="10.17487/RFC1605",
  }

@misc{rfc1606,
  author="J. Onions",
  title="{A Historical Perspective On The Usage Of IP Version 9}",
  howpublished="RFC 1606 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1606",
  pages="1--4",
  year=1994,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1606.txt",
  key="RFC 1606",
  abstract={This paper reviews the usages of the old IP version protocol.  It considers some of its successes and its failures.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Humor",
  doi="10.17487/RFC1606",
  }

@misc{rfc1607,
  author="V. Cerf",
  title="{A VIEW FROM THE 21ST CENTURY}",
  howpublished="RFC 1607 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1607",
  pages="1--14",
  year=1994,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1607.txt",
  key="RFC 1607",
  abstract={This document is a composition of letters discussing a possible future.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="V. Cerf",
  doi="10.17487/RFC1607",
  }

@misc{rfc1608,
  author="T. Johannsen and G. Mansfield and M. Kosters and S. Sataluri",
  title="{Representing IP Information in the X.500 Directory}",
  howpublished="RFC 1608 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1608",
  pages="1--20",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1608.txt",
  key="RFC 1608",
  abstract={This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory.  It extends the work ``Charting networks in the X.500 Directory'' [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="X500-DIR, Data, Structure, Schemo",
  doi="10.17487/RFC1608",
  }

@misc{rfc1609,
  author="G. Mansfield and T. Johannsen and M. Knopper",
  title="{Charting Networks in the X.500 Directory}",
  howpublished="RFC 1609 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1609",
  pages="1--15",
  year=1994,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1609.txt",
  key="RFC 1609",
  abstract={This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="X500-CHART, Data, Structure, Schemo",
  doi="10.17487/RFC1609",
  }

@misc{rfc1610,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1610 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1610",
  pages="1--36",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1720",
url="https://www.rfc-editor.org/rfc/rfc1610.txt",
  key="RFC 1610",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1610",
  }

@misc{rfc1611,
  author="R. Austein and J. Saperia",
  title="{DNS Server MIB Extensions}",
  howpublished="RFC 1611 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1611",
  pages="1--30",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1611.txt",
  key="RFC 1611",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of extensions which instrument DNS name server functions.  This memo was produced by the DNS working group. [STANDARDS-TRACK]},
  keywords="DNS-S-MIB, Domain, Name, System, Management, Information, Base",
  doi="10.17487/RFC1611",
  }

@misc{rfc1612,
  author="R. Austein and J. Saperia",
  title="{DNS Resolver MIB Extensions}",
  howpublished="RFC 1612 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1612",
  pages="1--32",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1612.txt",
  key="RFC 1612",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of extensions which instrument DNS resolver functions.  This memo was produced by the DNS working group. [STANDARDS-TRACK]},
  keywords="DNS-R-MIB, Domain, Name, System, Management, Information, Base",
  doi="10.17487/RFC1612",
  }

@misc{rfc1613,
  author="J. Forster and G. Satz and G. Glick and R. Day",
  title="{cisco Systems X.25 over TCP (XOT)}",
  howpublished="RFC 1613 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1613",
  pages="1--13",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1613.txt",
  key="RFC 1613",
  abstract={This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Transmission, Control, Protocol",
  doi="10.17487/RFC1613",
  }

@misc{rfc1614,
  author="C. Adie",
  title="{Network Access to Multimedia Information}",
  howpublished="RFC 1614 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1614",
  pages="1--79",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1614.txt",
  key="RFC 1614",
  abstract={This report summarises the requirements of research and academic network users for network access to multimedia information.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RARE, Technical, Report",
  doi="10.17487/RFC1614",
  }

@misc{rfc1615,
  author="J. Houttuin and J. Craigie",
  title="{Migrating from X.400(84) to X.400(88)}",
  howpublished="RFC 1615 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1615",
  pages="1--17",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1615.txt",
  key="RFC 1615",
  abstract={This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RARE, Technical, Report, email",
  doi="10.17487/RFC1615",
  }

@misc{rfc1616,
  author="RARE WG-MSG Task Force 88 and E. Huizer and J. Romaguera",
  title="{X.400(1988) for the Academic and Research Community in Europe}",
  howpublished="RFC 1616 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1616",
  pages="1--44",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1616.txt",
  key="RFC 1616",
  abstract={The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RARE, Technical, Report, email",
  doi="10.17487/RFC1616",
  }

@misc{rfc1617,
  author="P. Barker and S. Kille and T. Lenggenhager",
  title="{Naming and Structuring Guidelines for X.500 Directory Pilots}",
  howpublished="RFC 1617 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1617",
  pages="1--28",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1617.txt",
  key="RFC 1617",
  abstract={This document defines a number of naming and structuring guidelines focused on White Pages usage.  Alignment to these guidelines is recommended for directory pilots.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RARE, Technical, Report, White Pages",
  doi="10.17487/RFC1617",
  }

@misc{rfc1618,
  author="W. Simpson",
  title="{PPP over ISDN}",
  howpublished="RFC 1618 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1618",
  pages="1--7",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1618.txt",
  key="RFC 1618",
  abstract={This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]},
  keywords="PPP-ISDN, Point, Integrated Services Digital Network",
  doi="10.17487/RFC1618",
  }

@misc{rfc1619,
  author="W. Simpson",
  title="{PPP over SONET/SDH}",
  howpublished="RFC 1619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1619",
  pages="1--5",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2615",
url="https://www.rfc-editor.org/rfc/rfc1619.txt",
  key="RFC 1619",
  abstract={This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]},
  keywords="PPP-SONET, Point, Synchronous Optical Network Digital Heirarchy",
  doi="10.17487/RFC1619",
  }

@misc{rfc1620,
  author="B. Braden and J. Postel and Y. Rekhter",
  title="{Internet Architecture Extensions for Shared Media}",
  howpublished="RFC 1620 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1620",
  pages="1--19",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1620.txt",
  key="RFC 1620",
  abstract={This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Public, data, networks, ARP, address, resolution, protocol",
  doi="10.17487/RFC1620",
  }

@misc{rfc1621,
  author="P. Francis",
  title="{Pip Near-term Architecture}",
  howpublished="RFC 1621 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1621",
  pages="1--51",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1621.txt",
  key="RFC 1621",
  abstract={The purpose of this RFC and the companion RFC ``Pip Header Processing'' are to record the ideas (good and bad) of Pip.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet Protocol, IPng",
  doi="10.17487/RFC1621",
  }

@misc{rfc1622,
  author="P. Francis",
  title="{Pip Header Processing}",
  howpublished="RFC 1622 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1622",
  pages="1--16",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1622.txt",
  key="RFC 1622",
  abstract={The purpose of this RFC and the companion RFC ``Pip Near-term Architecture'' are to record the ideas (good and bad) of Pip.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet Protocol, IPng",
  doi="10.17487/RFC1622",
  }

@misc{rfc1623,
  author="F. Kastenholz",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 1623 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1623",
  pages="1--19",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1643",
url="https://www.rfc-editor.org/rfc/rfc1623.txt",
  key="RFC 1623",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]},
  keywords="MIB, Management, Information, Base",
  doi="10.17487/RFC1623",
  }

@misc{rfc1624,
  author="A. Rijsinghani",
  title="{Computation of the Internet Checksum via Incremental Update}",
  howpublished="RFC 1624 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1624",
  pages="1--6",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1624.txt",
  key="RFC 1624",
  abstract={This memo describes an updated technique for incremental computation of the standard Internet checksum.  It updates the method described in RFC 1141.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1624",
  }

@misc{rfc1625,
  author="M. St. Pierre and J. Fullton and K. Gamiel and J. Goldman and B. Kahle and J. Kunze and H. Morris and F. Schiettecatte",
  title="{WAIS over Z39.50-1988}",
  howpublished="RFC 1625 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1625",
  pages="1--7",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1625.txt",
  key="RFC 1625",
  abstract={The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Wide, Area, Information, Servers, Library",
  doi="10.17487/RFC1625",
  }

@misc{rfc1626,
  author="R. Atkinson",
  title="{Default IP MTU for use over ATM AAL5}",
  howpublished="RFC 1626 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1626",
  pages="1--5",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2225",
url="https://www.rfc-editor.org/rfc/rfc1626.txt",
  key="RFC 1626",
  abstract={There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5.  This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]},
  keywords="Maximum, Transmission, Unit, Asynchronous, Transfer, Mode, Adaptation, Layer, Size, Packet",
  doi="10.17487/RFC1626",
  }

@misc{rfc1627,
  author="E. Lear and E. Fair and D. Crocker and T. Kessler",
  title="{Network 10 Considered Harmful (Some Practices Shouldn't be Codified)}",
  howpublished="RFC 1627 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1627",
  pages="1--8",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1918",
url="https://www.rfc-editor.org/rfc/rfc1627.txt",
  key="RFC 1627",
  abstract={This document restates the arguments for maintaining a unique address space.  Concerns for Internet architecture and operations, as well as IETF procedure, are explored.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Network, Number, Local",
  doi="10.17487/RFC1627",
  }

@misc{rfc1628,
  author="J. Case",
  title="{UPS Management Information Base}",
  howpublished="RFC 1628 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1628",
  pages="1--45",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1628.txt",
  key="RFC 1628",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]},
  keywords="UPS-MIB, Uninterruptible, Power, Supply, MIB",
  doi="10.17487/RFC1628",
  }

@misc{rfc1629,
  author="R. Colella and R. Callon and E. Gardner and Y. Rekhter",
  title="{Guidelines for OSI NSAP Allocation in the Internet}",
  howpublished="RFC 1629 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1629",
  pages="1--52",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1629.txt",
  key="RFC 1629",
  abstract={This paper provides guidelines for allocating NSAP addresses in the Internet.  The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]},
  keywords="OSI-NSAP, CLNP, Address",
  doi="10.17487/RFC1629",
  }

@misc{rfc1630,
  author="T. Berners-Lee",
  title="{Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web}",
  howpublished="RFC 1630 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1630",
  pages="1--28",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1630.txt",
  key="RFC 1630",
  abstract={This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="World, Wide, Web, URI",
  doi="10.17487/RFC1630",
  }

@misc{rfc1631,
  author="K. Egevang and P. Francis",
  title="{The IP Network Address Translator (NAT)}",
  howpublished="RFC 1631 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1631",
  pages="1--10",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3022",
url="https://www.rfc-editor.org/rfc/rfc1631.txt",
  key="RFC 1631",
  abstract={This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary.  The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet Protocol",
  doi="10.17487/RFC1631",
  }

@misc{rfc1632,
  author="A. Getchell and S. Sataluri",
  title="{A Revised Catalog of Available X.500 Implementations}",
  howpublished="RFC 1632 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1632",
  pages="1--94",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2116",
url="https://www.rfc-editor.org/rfc/rfc1632.txt",
  key="RFC 1632",
  abstract={This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings.  This document is a revision of RFC 1292.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Directory, White, Pages",
  doi="10.17487/RFC1632",
  }

@misc{rfc1633,
  author="R. Braden and D. Clark and S. Shenker",
  title="{Integrated Services in the Internet Architecture: an Overview}",
  howpublished="RFC 1633 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1633",
  pages="1--33",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1633.txt",
  key="RFC 1633",
  abstract={This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="real time, Multi-media, reservations, Protocol",
  doi="10.17487/RFC1633",
  }

@misc{rfc1634,
  author="M. Allen",
  title="{Novell IPX Over Various WAN Media (IPXWAN)}",
  howpublished="RFC 1634 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1634",
  pages="1--23",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1634.txt",
  key="RFC 1634",
  abstract={This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="wide, area, network",
  doi="10.17487/RFC1634",
  }

@misc{rfc1635,
  author="P. Deutsch and A. Emtage and A. Marine",
  title="{How to Use Anonymous FTP}",
  howpublished="RFC 1635 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1635",
  pages="1--13",
  year=1994,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1635.txt",
  key="RFC 1635",
  abstract={This document provides information for the novice Internet user about using the File Transfer Protocol (FTP).  It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="File, Transfer, Protocol",
  doi="10.17487/RFC1635",
  }

@misc{rfc1636,
  author="R. Braden and D. Clark and S. Crocker and C. Huitema",
  title="{Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994}",
  howpublished="RFC 1636 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1636",
  pages="1--52",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1636.txt",
  key="RFC 1636",
  abstract={This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994.  This workshop generally focused on security issues in the Internet architecture.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Architecture, Board",
  doi="10.17487/RFC1636",
  }

@misc{rfc1637,
  author="B. Manning and R. Colella",
  title="{DNS NSAP Resource Records}",
  howpublished="RFC 1637 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1637",
  pages="1--11",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1706",
url="https://www.rfc-editor.org/rfc/rfc1637.txt",
  key="RFC 1637",
  abstract={This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain, Name, System, ISO, OSI, Address",
  doi="10.17487/RFC1637",
  }

@misc{rfc1638,
  author="F. Baker and R. Bowen",
  title="{PPP Bridging Control Protocol (BCP)}",
  howpublished="RFC 1638 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1638",
  pages="1--28",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2878",
url="https://www.rfc-editor.org/rfc/rfc1638.txt",
  key="RFC 1638",
  abstract={This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]},
  keywords="PPP-BCP, Point to Point",
  doi="10.17487/RFC1638",
  }

@misc{rfc1639,
  author="D. Piscitello",
  title="{FTP Operation Over Big Address Records (FOOBAR)}",
  howpublished="RFC 1639 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1639",
  pages="1--5",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1639.txt",
  key="RFC 1639",
  abstract={This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a ``long Port (LPRT)'' command and ``Long Passive (LPSV)'' reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="FOOBAR, File, Transfer, Port",
  doi="10.17487/RFC1639",
  }

@misc{rfc1640,
  author="S. Crocker",
  title="{The Process for Organization of Internet Standards Working Group (POISED)}",
  howpublished="RFC 1640 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1640",
  pages="1--10",
  year=1994,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1640.txt",
  key="RFC 1640",
  abstract={This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IETF, IESG, IAB, ISOC",
  doi="10.17487/RFC1640",
  }

@misc{rfc1641,
  author="D. Goldsmith and M. Davis",
  title="{Using Unicode with MIME}",
  howpublished="RFC 1641 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1641",
  pages="1--6",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1641.txt",
  key="RFC 1641",
  abstract={This document specifies the usage of Unicode within MIME.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIME-UNI, Multipurpose, Internet, Mail, Extension, Character, Set",
  doi="10.17487/RFC1641",
  }

@misc{rfc1642,
  author="D. Goldsmith and M. Davis",
  title="{UTF-7 - A Mail-Safe Transformation Format of Unicode}",
  howpublished="RFC 1642 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1642",
  pages="1--14",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2152",
url="https://www.rfc-editor.org/rfc/rfc1642.txt",
  key="RFC 1642",
  abstract={This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="character, Set",
  doi="10.17487/RFC1642",
  }

@misc{rfc1643,
  author="F. Kastenholz",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 1643 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1643",
  pages="1--19",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3638",
url="https://www.rfc-editor.org/rfc/rfc1643.txt",
  key="RFC 1643",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]},
  keywords="ETHER-MIB, MIB, Network, Management, SNMP, Ethernet",
  doi="10.17487/RFC1643",
  }

@misc{rfc1644,
  author="R. Braden",
  title="{T/TCP -- TCP Extensions for Transactions Functional Specification}",
  howpublished="RFC 1644 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1644",
  pages="1--38",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc1644.txt",
  key="RFC 1644",
  abstract={This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service.  This memo describes an Experimental Protocol for the Internet community.},
  keywords="T/TCP, Transmission, Control, Protocol",
  doi="10.17487/RFC1644",
  }

@misc{rfc1645,
  author="A. Gwinn",
  title="{Simple Network Paging Protocol - Version 2}",
  howpublished="RFC 1645 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1645",
  pages="1--15",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1861",
url="https://www.rfc-editor.org/rfc/rfc1645.txt",
  key="RFC 1645",
  abstract={This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Beeper, SNPP, Mail",
  doi="10.17487/RFC1645",
  }

@misc{rfc1646,
  author="C. Graves and T. Butts and M. Angel",
  title="{TN3270 Extensions for LUname and Printer Selection}",
  howpublished="RFC 1646 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1646",
  pages="1--13",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1646.txt",
  key="RFC 1646",
  abstract={This document describes protocol extensions to TN3270.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Telnet, Option",
  doi="10.17487/RFC1646",
  }

@misc{rfc1647,
  author="B. Kelly",
  title="{TN3270 Enhancements}",
  howpublished="RFC 1647 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1647",
  pages="1--34",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2355",
url="https://www.rfc-editor.org/rfc/rfc1647.txt",
  key="RFC 1647",
  abstract={This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]},
  keywords="Telnet, Option",
  doi="10.17487/RFC1647",
  }

@misc{rfc1648,
  author="A. Cargille",
  title="{Postmaster Convention for X.400 Operations}",
  howpublished="RFC 1648 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1648",
  pages="1--4",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1648.txt",
  key="RFC 1648",
  abstract={This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]},
  keywords="Mail",
  doi="10.17487/RFC1648",
  }

@misc{rfc1649,
  author="R. Hagens and A. Hansen",
  title="{Operational Requirements for X.400 Management Domains in the GO-MHS Community}",
  howpublished="RFC 1649 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1649",
  pages="1--14",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1649.txt",
  key="RFC 1649",
  abstract={The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Mail, Global, Open, Message, Handling, System",
  doi="10.17487/RFC1649",
  }

@misc{rfc1650,
  author="F. Kastenholz",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2}",
  howpublished="RFC 1650 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1650",
  pages="1--20",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2358",
url="https://www.rfc-editor.org/rfc/rfc1650.txt",
  key="RFC 1650",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]},
  keywords="MIB, Management, Information, Base, 802.3",
  doi="10.17487/RFC1650",
  }

@misc{rfc1651,
  author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker",
  title="{SMTP Service Extensions}",
  howpublished="RFC 1651 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1651",
  pages="1--11",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1869",
url="https://www.rfc-editor.org/rfc/rfc1651.txt",
  key="RFC 1651",
  abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]},
  keywords="Mail, Simple, Transfer",
  doi="10.17487/RFC1651",
  }

@misc{rfc1652,
  author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker",
  title="{SMTP Service Extension for 8bit-MIMEtransport}",
  howpublished="RFC 1652 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1652",
  pages="1--6",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6152",
url="https://www.rfc-editor.org/rfc/rfc1652.txt",
  key="RFC 1652",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]},
  keywords="SMTP, Mail, Simple, Transfer",
  doi="10.17487/RFC1652",
  }

@misc{rfc1653,
  author="J. Klensin and N. Freed and K. Moore",
  title="{SMTP Service Extension for Message Size Declaration}",
  howpublished="RFC 1653 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1653",
  pages="1--8",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1870",
url="https://www.rfc-editor.org/rfc/rfc1653.txt",
  key="RFC 1653",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]},
  keywords="Mail, Simple, Transfer, Protocol",
  doi="10.17487/RFC1653",
  }

@misc{rfc1654,
  author="Y. Rekhter and T. Li",
  title="{A Border Gateway Protocol 4 (BGP-4)}",
  howpublished="RFC 1654 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1654",
  pages="1--56",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1771",
url="https://www.rfc-editor.org/rfc/rfc1654.txt",
  key="RFC 1654",
  abstract={This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="routing",
  doi="10.17487/RFC1654",
  }

@misc{rfc1655,
  author="Y. Rekhter and P. Gross",
  title="{Application of the Border Gateway Protocol in the Internet}",
  howpublished="RFC 1655 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1655",
  pages="1--19",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1772",
url="https://www.rfc-editor.org/rfc/rfc1655.txt",
  key="RFC 1655",
  abstract={This document, together with its companion document, ``A Border Gateway Protocol 4 (BGP-4)'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="BGP-4, Routing",
  doi="10.17487/RFC1655",
  }

@misc{rfc1656,
  author="P. Traina",
  title="{BGP-4 Protocol Document Roadmap and Implementation Experience}",
  howpublished="RFC 1656 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1656",
  pages="1--4",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1773",
url="https://www.rfc-editor.org/rfc/rfc1656.txt",
  key="RFC 1656",
  abstract={Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol.  It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Border, Gateway, Protocol, Routing",
  doi="10.17487/RFC1656",
  }

@misc{rfc1657,
  author="S. Willis and J. Burruss and J. Chu",
  title="{Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2}",
  howpublished="RFC 1657 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1657",
  pages="1--21",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4273",
url="https://www.rfc-editor.org/rfc/rfc1657.txt",
  key="RFC 1657",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]},
  keywords="BGP-4-MIB, MIB, Management, Information, Base",
  doi="10.17487/RFC1657",
  }

@misc{rfc1658,
  author="B. Stewart",
  title="{Definitions of Managed Objects for Character Stream Devices using SMIv2}",
  howpublished="RFC 1658 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1658",
  pages="1--18",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1658.txt",
  key="RFC 1658",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]},
  keywords="MIB, Network, Management, Base",
  doi="10.17487/RFC1658",
  }

@misc{rfc1659,
  author="B. Stewart",
  title="{Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2}",
  howpublished="RFC 1659 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1659",
  pages="1--21",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1659.txt",
  key="RFC 1659",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]},
  keywords="MIB, Network, Management, Base",
  doi="10.17487/RFC1659",
  }

@misc{rfc1660,
  author="B. Stewart",
  title="{Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2}",
  howpublished="RFC 1660 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1660",
  pages="1--10",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1660.txt",
  key="RFC 1660",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]},
  keywords="MIB, Network, Management, Base",
  doi="10.17487/RFC1660",
  }

@misc{rfc1661,
  author="W. Simpson",
  title="{The Point-to-Point Protocol (PPP)}",
  howpublished="RFC 1661 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1661",
  pages="1--53",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2153",
url="https://www.rfc-editor.org/rfc/rfc1661.txt",
  key="RFC 1661",
  abstract={This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]},
  keywords="PPP, Specification, Standard, link, serial, line",
  doi="10.17487/RFC1661",
  }

@misc{rfc1662,
  author="W. Simpson",
  title="{PPP in HDLC-like Framing}",
  howpublished="RFC 1662 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1662",
  pages="1--26",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1662.txt",
  key="RFC 1662",
  abstract={This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="PPP-HDLC, Point, Protocol, Specification, Standard, link, serial, line",
  doi="10.17487/RFC1662",
  }

@misc{rfc1663,
  author="D. Rand",
  title="{PPP Reliable Transmission}",
  howpublished="RFC 1663 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1663",
  pages="1--8",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1663.txt",
  key="RFC 1663",
  abstract={This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]},
  keywords="PPP-TRANS, Point, Protocol",
  doi="10.17487/RFC1663",
  }

@misc{rfc1664,
  author="C. Allocchio and A. Bonito and B. Cole and S. Giordano and R. Hagens",
  title="{Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables}",
  howpublished="RFC 1664 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1664",
  pages="1--23",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2163",
url="https://www.rfc-editor.org/rfc/rfc1664.txt",
  key="RFC 1664",
  abstract={This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain, Name, System, X.400, Email",
  doi="10.17487/RFC1664",
  }

@misc{rfc1665,
  author="Z. Kielczewski and D. Kostick and K. Shih",
  title="{Definitions of Managed Objects for SNA NAUs using SMIv2}",
  howpublished="RFC 1665 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1665",
  pages="1--67",
  year=1994,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1666",
url="https://www.rfc-editor.org/rfc/rfc1665.txt",
  key="RFC 1665",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]},
  keywords="MIB, Management, Information, Base, System, Network, Architecture, Addressable, Units",
  doi="10.17487/RFC1665",
  }

@misc{rfc1666,
  author="Z. Kielczewski and D. Kostick and K. Shih",
  title="{Definitions of Managed Objects for SNA NAUs using SMIv2}",
  howpublished="RFC 1666 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1666",
  pages="1--68",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1666.txt",
  key="RFC 1666",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]},
  keywords="SNANAU-MIB, Network, Management, SNMP, MIB, Protocol, Units, Architecture, Addressable, Information, System",
  doi="10.17487/RFC1666",
  }

@misc{rfc1667,
  author="S. Symington and D. Wood and M. Pullen",
  title="{Modeling and Simulation Requirements for IPng}",
  howpublished="RFC 1667 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1667",
  pages="1--7",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1667.txt",
  key="RFC 1667",
  abstract={This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1667",
  }

@misc{rfc1668,
  author="D. Estrin and T. Li and Y. Rekhter",
  title="{Unified Routing Requirements for IPng}",
  howpublished="RFC 1668 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1668",
  pages="1--3",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1668.txt",
  key="RFC 1668",
  abstract={The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1668",
  }

@misc{rfc1669,
  author="J. Curran",
  title="{Market Viability as a IPng Criteria}",
  howpublished="RFC 1669 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1669",
  pages="1--4",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1669.txt",
  key="RFC 1669",
  abstract={``Viability in the Marketplace'' is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1669",
  }

@misc{rfc1670,
  author="D. Heagerty",
  title="{Input to IPng Engineering Considerations}",
  howpublished="RFC 1670 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1670",
  pages="1--3",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1670.txt",
  key="RFC 1670",
  abstract={This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition.  It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1670",
  }

@misc{rfc1671,
  author="B. Carpenter",
  title="{IPng White Paper on Transition and Other Considerations}",
  howpublished="RFC 1671 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1671",
  pages="1--8",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1671.txt",
  key="RFC 1671",
  abstract={This white paper outlines some general requirements for IPng in selected areas.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1671",
  }

@misc{rfc1672,
  author="N. Brownlee",
  title="{Accounting Requirements for IPng}",
  howpublished="RFC 1672 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1672",
  pages="1--3",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1672.txt",
  key="RFC 1672",
  abstract={This white paper discusses accounting requirements for IPng.  It recommends that all IPng packets carry accounting tags, which would vary in size.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1672",
  }

@misc{rfc1673,
  author="R. Skelton",
  title="{Electric Power Research Institute Comments on IPng}",
  howpublished="RFC 1673 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1673",
  pages="1--4",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1673.txt",
  key="RFC 1673",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1673",
  }

@misc{rfc1674,
  author="M. Taylor",
  title="{A Cellular Industry View of IPng}",
  howpublished="RFC 1674 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1674",
  pages="1--3",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1674.txt",
  key="RFC 1674",
  abstract={This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1674",
  }

@misc{rfc1675,
  author="S. Bellovin",
  title="{Security Concerns for IPng}",
  howpublished="RFC 1675 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1675",
  pages="1--4",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1675.txt",
  key="RFC 1675",
  abstract={A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective.  While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1675",
  }

@misc{rfc1676,
  author="A. Ghiselli and D. Salomoni and C. Vistoli",
  title="{INFN Requirements for an IPng}",
  howpublished="RFC 1676 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1676",
  pages="1--4",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1676.txt",
  key="RFC 1676",
  abstract={With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1676",
  }

@misc{rfc1677,
  author="B. Adamson",
  title="{Tactical Radio Frequency Communication Requirements for IPng}",
  howpublished="RFC 1677 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1677",
  pages="1--9",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1677.txt",
  key="RFC 1677",
  abstract={This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1677",
  }

@misc{rfc1678,
  author="E. Britton and J. Tavs",
  title="{IPng Requirements of Large Corporate Networks}",
  howpublished="RFC 1678 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1678",
  pages="1--8",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1678.txt",
  key="RFC 1678",
  abstract={This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1678",
  }

@misc{rfc1679,
  author="D. Green and P. Irey and D. Marlow and K. O'Donoghue",
  title="{HPN Working Group Input to the IPng Requirements Solicitation}",
  howpublished="RFC 1679 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1679",
  pages="1--10",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1679.txt",
  key="RFC 1679",
  abstract={The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1679",
  }

@misc{rfc1680,
  author="C. Brazdziunas",
  title="{IPng Support for ATM Services}",
  howpublished="RFC 1680 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1680",
  pages="1--7",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1680.txt",
  key="RFC 1680",
  abstract={This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1680",
  }

@misc{rfc1681,
  author="S. Bellovin",
  title="{On Many Addresses per Host}",
  howpublished="RFC 1681 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1681",
  pages="1--5",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1681.txt",
  key="RFC 1681",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1681",
  }

@misc{rfc1682,
  author="J. Bound",
  title="{IPng BSD Host Implementation Analysis}",
  howpublished="RFC 1682 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1682",
  pages="1--10",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1682.txt",
  key="RFC 1682",
  abstract={This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper, Unix",
  doi="10.17487/RFC1682",
  }

@misc{rfc1683,
  author="R. Clark and M. Ammar and K. Calvert",
  title="{Multiprotocol Interoperability In IPng}",
  howpublished="RFC 1683 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1683",
  pages="1--12",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1683.txt",
  key="RFC 1683",
  abstract={In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1683",
  }

@misc{rfc1684,
  author="P. Jurg",
  title="{Introduction to White Pages Services based on X.500}",
  howpublished="RFC 1684 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1684",
  pages="1--10",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1684.txt",
  key="RFC 1684",
  abstract={The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Directory",
  doi="10.17487/RFC1684",
  }

@misc{rfc1685,
  author="H. Alvestrand",
  title="{Writing X.400 O/R Names}",
  howpublished="RFC 1685 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1685",
  pages="1--11",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1685.txt",
  key="RFC 1685",
  abstract={There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way.  This memo is a discussion of this topic.  This memo provides information for the Internet Community.  It does not specify an Internet Standard of any kind.},
  keywords="EMail, Mail",
  doi="10.17487/RFC1685",
  }

@misc{rfc1686,
  author="M. Vecchi",
  title="{IPng Requirements: A Cable Television Industry Viewpoint}",
  howpublished="RFC 1686 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1686",
  pages="1--14",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1686.txt",
  key="RFC 1686",
  abstract={This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1686",
  }

@misc{rfc1687,
  author="E. Fleischman",
  title="{A Large Corporate User's View of IPng}",
  howpublished="RFC 1687 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1687",
  pages="1--13",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1687.txt",
  key="RFC 1687",
  abstract={The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1687",
  }

@misc{rfc1688,
  author="W. Simpson",
  title="{IPng Mobility Considerations}",
  howpublished="RFC 1688 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1688",
  pages="1--9",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1688.txt",
  key="RFC 1688",
  abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Paper",
  doi="10.17487/RFC1688",
  }

@misc{rfc1689,
  author="J. Foster",
  title="{A Status Report on Networked Information Retrieval: Tools and Groups}",
  howpublished="RFC 1689 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1689",
  pages="1--226",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1689.txt",
  key="RFC 1689",
  abstract={The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NIR",
  doi="10.17487/RFC1689",
  }

@misc{rfc1690,
  author="G. Huston",
  title="{Introducing the Internet Engineering and Planning Group (IEPG)}",
  howpublished="RFC 1690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1690",
  pages="1--2",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1690.txt",
  key="RFC 1690",
  abstract={This memo introduces the IEPG to the Internet Community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="charter",
  doi="10.17487/RFC1690",
  }

@misc{rfc1691,
  author="W. Turner",
  title="{The Document Architecture for the Cornell Digital Library}",
  howpublished="RFC 1691 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1691",
  pages="1--10",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1691.txt",
  key="RFC 1691",
  abstract={This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1691",
  }

@misc{rfc1692,
  author="P. Cameron and D. Crocker and D. Cohen and J. Postel",
  title="{Transport Multiplexing Protocol (TMux)}",
  howpublished="RFC 1692 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1692",
  pages="1--12",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1692.txt",
  key="RFC 1692",
  abstract={This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers.  This same protocol is used by the University of Minnesota's distributed authentication system.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="TMUX, Internet, Protocol, IP",
  doi="10.17487/RFC1692",
  }

@misc{rfc1693,
  author="T.  Connolly and P. Amer and P. Conrad",
  title="{An Extension to TCP : Partial Order Service}",
  howpublished="RFC 1693 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1693",
  pages="1--36",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc1693.txt",
  key="RFC 1693",
  abstract={This RFC introduces a new transport mechanism for TCP based upon partial ordering.  The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TCP-POS, Transmission, Control, Protocol",
  doi="10.17487/RFC1693",
  }

@misc{rfc1694,
  author="T. Brown and K. Tesink",
  title="{Definitions of Managed Objects for SMDS Interfaces using SMIv2}",
  howpublished="RFC 1694 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1694",
  pages="1--35",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1694.txt",
  key="RFC 1694",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK]},
  keywords="SIP-MIB, Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS",
  doi="10.17487/RFC1694",
  }

@misc{rfc1695,
  author="M. Ahmed and K. Tesink",
  title="{Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2}",
  howpublished="RFC 1695 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1695",
  pages="1--73",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2515",
url="https://www.rfc-editor.org/rfc/rfc1695.txt",
  key="RFC 1695",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]},
  keywords="ATM-MIB, MIB, Management,Information,Base,Asychronous,Transmission,Mode",
  doi="10.17487/RFC1695",
  }

@misc{rfc1696,
  author="J. Barnes and L. Brown and R. Royston and S. Waldbusser",
  title="{Modem Management Information Base (MIB) using SMIv2}",
  howpublished="RFC 1696 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1696",
  pages="1--31",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1696.txt",
  key="RFC 1696",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]},
  keywords="MODEM-MIB",
  doi="10.17487/RFC1696",
  }

@misc{rfc1697,
  author="D. Brower and B. Purvy and A. Daniel and M. Sinykin and J. Smith",
  title="{Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2}",
  howpublished="RFC 1697 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1697",
  pages="1--38",
  year=1994,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1697.txt",
  key="RFC 1697",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]},
  keywords="RDBMS-MIB",
  doi="10.17487/RFC1697",
  }

@misc{rfc1698,
  author="P. Furniss",
  title="{Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications}",
  howpublished="RFC 1698 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1698",
  pages="1--29",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1698.txt",
  key="RFC 1698",
  abstract={This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with ``basic communications requirements''.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Protocol, Headers",
  doi="10.17487/RFC1698",
  }

@misc{rfc1699,
  author="J. Elliott",
  title="{Summary of 1600-1699}",
  howpublished="RFC 1699 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1699",
  pages="1--21",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1699.txt",
  key="RFC 1699",
  keywords="Index",
  doi="10.17487/RFC1699",
  }

@misc{rfc1700,
  author="J. Reynolds and J. Postel",
  title="{Assigned Numbers}",
  howpublished="RFC 1700 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1700",
  pages="1--230",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3232",
url="https://www.rfc-editor.org/rfc/rfc1700.txt",
  key="RFC 1700",
  abstract={This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite.  To make the current information readily available the assignments are kept up-to- date in a set of online text files.  This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.},
  keywords="status, procedure, index, parameters, registered, allocated",
  doi="10.17487/RFC1700",
  }

@misc{rfc1701,
  author="S. Hanks and T. Li and D. Farinacci and P. Traina",
  title="{Generic Routing Encapsulation (GRE)}",
  howpublished="RFC 1701 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1701",
  pages="1--8",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1701.txt",
  key="RFC 1701",
  abstract={This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GRE, Internet, Protocol, IP",
  doi="10.17487/RFC1701",
  }

@misc{rfc1702,
  author="S. Hanks and T. Li and D. Farinacci and P. Traina",
  title="{Generic Routing Encapsulation over IPv4 networks}",
  howpublished="RFC 1702 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1702",
  pages="1--4",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1702.txt",
  key="RFC 1702",
  abstract={This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload.  This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GRE-IPv4, Internet, Protocol, IP",
  doi="10.17487/RFC1702",
  }

@misc{rfc1703,
  author="M. Rose",
  title="{Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures}",
  howpublished="RFC 1703 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1703",
  pages="1--9",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1703.txt",
  key="RFC 1703",
  abstract={This memo describes a technique for radio paging using the Internet mail infrastructure.  In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RADIO-PAGE, Beepers",
  doi="10.17487/RFC1703",
  }

@misc{rfc1704,
  author="N. Haller and R. Atkinson",
  title="{On Internet Authentication}",
  howpublished="RFC 1704 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1704",
  pages="1--17",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1704.txt",
  key="RFC 1704",
  abstract={This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet.  This document provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Security, Energyption, Policy, Guidelines",
  doi="10.17487/RFC1704",
  }

@misc{rfc1705,
  author="R. Carlson and D. Ficarella",
  title="{Six Virtual Inches to the Left: The Problem with IPng}",
  howpublished="RFC 1705 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1705",
  pages="1--27",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1705.txt",
  key="RFC 1705",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.  This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White paper",
  doi="10.17487/RFC1705",
  }

@misc{rfc1706,
  author="B. Manning and R. Colella",
  title="{DNS NSAP Resource Records}",
  howpublished="RFC 1706 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1706",
  pages="1--10",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1706.txt",
  key="RFC 1706",
  abstract={This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping.  The RR may be used with any NSAP address format.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DNS-NSAP, Domain, Name, System, ISO, OSI, Address, RR, Record, Resource",
  doi="10.17487/RFC1706",
  }

@misc{rfc1707,
  author="M. McGovern and R. Ullmann",
  title="{CATNIP: Common Architecture for the Internet}",
  howpublished="RFC 1707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1707",
  pages="1--16",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1707.txt",
  key="RFC 1707",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.  This paper describes a common architecture for the network layer protocol.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White, Paper, IPv7",
  doi="10.17487/RFC1707",
  }

@misc{rfc1708,
  author="D. Gowin",
  title="{NTP PICS PROFORMA - For the Network Time Protocol Version 3}",
  howpublished="RFC 1708 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1708",
  pages="1--13",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1708.txt",
  key="RFC 1708",
  abstract={This RFC describes a PICS Proforma translated into an Internet acceptable form.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1708",
  }

@misc{rfc1709,
  author="J. Gargano and D. Wasley",
  title="{K-12 Internetworking Guidelines}",
  howpublished="RFC 1709 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1709",
  pages="1--26",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1709.txt",
  key="RFC 1709",
  abstract={The K-12 community traditionally has not had this level of staffing available for telecommunications planning.  This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="school, network, education, connection",
  doi="10.17487/RFC1709",
  }

@misc{rfc1710,
  author="R. Hinden",
  title="{Simple Internet Protocol Plus White Paper}",
  howpublished="RFC 1710 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1710",
  pages="1--23",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1710.txt",
  key="RFC 1710",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SIPP, IPng",
  doi="10.17487/RFC1710",
  }

@misc{rfc1711,
  author="J. Houttuin",
  title="{Classifications in E-mail Routing}",
  howpublished="RFC 1711 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1711",
  pages="1--19",
  year=1994,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1711.txt",
  key="RFC 1711",
  abstract={This paper presents a classification for e-mail routing issues.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Email, Electronic, Mail",
  doi="10.17487/RFC1711",
  }

@misc{rfc1712,
  author="C. Farrell and M. Schulze and S. Pleitner and D. Baldoni",
  title="{DNS Encoding of Geographical Location}",
  howpublished="RFC 1712 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1712",
  pages="1--7",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1712.txt",
  key="RFC 1712",
  abstract={This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DNS-ENCODE, Domain, Names, System, GPOS",
  doi="10.17487/RFC1712",
  }

@misc{rfc1713,
  author="A. Romao",
  title="{Tools for DNS debugging}",
  howpublished="RFC 1713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1713",
  pages="1--13",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1713.txt",
  key="RFC 1713",
  abstract={Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work.  This document presents some tools available for domain administrators to detect and correct those anomalies.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Domain, Names, System, Host, DNSWalk, DOC, DDT, Checker",
  doi="10.17487/RFC1713",
  }

@misc{rfc1714,
  author="S. Williamson and M. Kosters",
  title="{Referral Whois Protocol (RWhois)}",
  howpublished="RFC 1714 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1714",
  pages="1--46",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2167",
url="https://www.rfc-editor.org/rfc/rfc1714.txt",
  key="RFC 1714",
  abstract={This memo describes version 1.0 of the client/server interaction of RWhois.  RWhois provides a distributed system for the display of hierarchical information.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Pages, Directory",
  doi="10.17487/RFC1714",
  }

@misc{rfc1715,
  author="C. Huitema",
  title="{The H Ratio for Address Assignment Efficiency}",
  howpublished="RFC 1715 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1715",
  pages="1--4",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3194",
url="https://www.rfc-editor.org/rfc/rfc1715.txt",
  key="RFC 1715",
  abstract={This document was submitted to the IETF IPng area in response to RFC 1550.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White, Paper",
  doi="10.17487/RFC1715",
  }

@misc{rfc1716,
  author="P. Almquist and F. Kastenholz",
  title="{Towards Requirements for IP Routers}",
  howpublished="RFC 1716 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1716",
  pages="1--192",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1812",
url="https://www.rfc-editor.org/rfc/rfc1716.txt",
  key="RFC 1716",
  abstract={The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document.  It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Gateway, Internet, Protocol",
  doi="10.17487/RFC1716",
  }

@misc{rfc1717,
  author="K. Sklower and B. Lloyd and G. McGregor and D. Carr",
  title="{The PPP Multilink Protocol (MP)}",
  howpublished="RFC 1717 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1717",
  pages="1--21",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1990",
url="https://www.rfc-editor.org/rfc/rfc1717.txt",
  key="RFC 1717",
  abstract={This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]},
  keywords="Point",
  doi="10.17487/RFC1717",
  }

@misc{rfc1718,
  author="IETF Secretariat and G. Malkin",
  title="{The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force}",
  howpublished="RFC 1718 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1718",
  pages="1--23",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3160",
url="https://www.rfc-editor.org/rfc/rfc1718.txt",
  key="RFC 1718",
  abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This memo provides information for the Internet community.  It does not specify an Internet standard. [FYI 17]},
  keywords="Internet, Engineering, Task, Force, Meeting",
  doi="10.17487/RFC1718",
  }

@misc{rfc1719,
  author="P. Gross",
  title="{A Direction for IPng}",
  howpublished="RFC 1719 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1719",
  pages="1--6",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1719.txt",
  key="RFC 1719",
  abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White, Paper, Internet, Protocol",
  doi="10.17487/RFC1719",
  }

@misc{rfc1720,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1720 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1720",
  pages="1--41",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1780",
url="https://www.rfc-editor.org/rfc/rfc1720.txt",
  key="RFC 1720",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1720",
  }

@misc{rfc1721,
  author="G. Malkin",
  title="{RIP Version 2 Protocol Analysis}",
  howpublished="RFC 1721 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1721",
  pages="1--4",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1721.txt",
  key="RFC 1721",
  abstract={As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.  This report is a prerequisite to advancing RIP-2 on the standards track.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RIP-2",
  doi="10.17487/RFC1721",
  }

@misc{rfc1722,
  author="G. Malkin",
  title="{RIP Version 2 Protocol Applicability Statement}",
  howpublished="RFC 1722 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1722",
  pages="1--5",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1722.txt",
  key="RFC 1722",
  abstract={As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet.  This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]},
  keywords="RIP2-APP, RIP-2",
  doi="10.17487/RFC1722",
  }

@misc{rfc1723,
  author="G. Malkin",
  title="{RIP Version 2 - Carrying Additional Information}",
  howpublished="RFC 1723 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1723",
  pages="1--9",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2453",
url="https://www.rfc-editor.org/rfc/rfc1723.txt",
  key="RFC 1723",
  abstract={This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security.  This memo obsoletes RFC 1388, which specifies an update to the ``Routing Information Protocol'' STD 34, RFC 1058. [STANDARDS-TRACK]},
  keywords="RIP-2",
  doi="10.17487/RFC1723",
  }

@misc{rfc1724,
  author="G. Malkin and F. Baker",
  title="{RIP Version 2 MIB Extension}",
  howpublished="RFC 1724 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1724",
  pages="1--18",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1724.txt",
  key="RFC 1724",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing RIP Version 2. [STANDARDS-TRACK]},
  keywords="RIP2-MIB, RIP-2, Management, Information, Base",
  doi="10.17487/RFC1724",
  }

@misc{rfc1725,
  author="J. Myers and M. Rose",
  title="{Post Office Protocol - Version 3}",
  howpublished="RFC 1725 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1725",
  pages="1--18",
  year=1994,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1939",
url="https://www.rfc-editor.org/rfc/rfc1725.txt",
  key="RFC 1725",
  abstract={This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]},
  keywords="POP, Email, Electronic, Mail",
  doi="10.17487/RFC1725",
  }

@misc{rfc1726,
  author="C. Partridge and F. Kastenholz",
  title="{Technical Criteria for Choosing IP The Next Generation (IPng)}",
  howpublished="RFC 1726 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1726",
  pages="1--31",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1726.txt",
  key="RFC 1726",
  abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White, Paper, Internet, Protocol",
  doi="10.17487/RFC1726",
  }

@misc{rfc1727,
  author="C. Weider and P. Deutsch",
  title="{A Vision of an Integrated Internet Information Service}",
  howpublished="RFC 1727 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1727",
  pages="1--11",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1727.txt",
  key="RFC 1727",
  abstract={This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Universal, Resource, Names",
  doi="10.17487/RFC1727",
  }

@misc{rfc1728,
  author="C. Weider",
  title="{Resource Transponders}",
  howpublished="RFC 1728 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1728",
  pages="1--6",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1728.txt",
  key="RFC 1728",
  abstract={This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Universal, Resource, Names, Location, System",
  doi="10.17487/RFC1728",
  }

@misc{rfc1729,
  author="C. Lynch",
  title="{Using the Z39.50 Information Retrieval Protocol}",
  howpublished="RFC 1729 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1729",
  pages="1--8",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1729.txt",
  key="RFC 1729",
  abstract={This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Basic, Endcoding, Rules, ASN1",
  doi="10.17487/RFC1729",
  }

@misc{rfc1730,
  author="M. Crispin",
  title="{Internet Message Access Protocol - Version 4}",
  howpublished="RFC 1730 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1730",
  pages="1--77",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2060, 2061",
url="https://www.rfc-editor.org/rfc/rfc1730.txt",
  key="RFC 1730",
  abstract={The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.  IMAP4 permits manipulation of remote message folders, called ``mailboxes'', in a way that is functionally equivalent to local mailboxes.  IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]},
  keywords="IMAP, IMAP4, EMail",
  doi="10.17487/RFC1730",
  }

@misc{rfc1731,
  author="J. Myers",
  title="{IMAP4 Authentication Mechanisms}",
  howpublished="RFC 1731 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1731",
  pages="1--6",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1731.txt",
  key="RFC 1731",
  abstract={The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions.  This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]},
  keywords="IMAP4-AUTH, Internet, Message, Access, Protocol, Email",
  doi="10.17487/RFC1731",
  }

@misc{rfc1732,
  author="M. Crispin",
  title="{IMAP4 Compatibility with IMAP2 and IMAP2bis}",
  howpublished="RFC 1732 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1732",
  pages="1--5",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1732.txt",
  key="RFC 1732",
  abstract={This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Message, Access, Protocol, Email",
  doi="10.17487/RFC1732",
  }

@misc{rfc1733,
  author="M. Crispin",
  title="{Distributed Electronic Mail Models in IMAP4}",
  howpublished="RFC 1733 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1733",
  pages="1--3",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1733.txt",
  key="RFC 1733",
  abstract={There are three fundamental models of client/server email: offline, online, and disconnected use.  IMAP4 can be used in any one of these three models.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Message, Access, Protocol, Email",
  doi="10.17487/RFC1733",
  }

@misc{rfc1734,
  author="J. Myers",
  title="{POP3 AUTHentication command}",
  howpublished="RFC 1734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1734",
  pages="1--5",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5034",
url="https://www.rfc-editor.org/rfc/rfc1734.txt",
  key="RFC 1734",
  abstract={This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]},
  keywords="POP3-AUTH, Post, Office, Protocol, Email",
  doi="10.17487/RFC1734",
  }

@misc{rfc1735,
  author="J. Heinanen and R. Govindan",
  title="{NBMA Address Resolution Protocol (NARP)}",
  howpublished="RFC 1735 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1735",
  pages="1--11",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1735.txt",
  key="RFC 1735",
  abstract={This document describes the NBMA Address Resolution Protocol (NARP).  NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NARP, Non-Broadcast, Multi, Access, Address, Resolution, Protocol",
  doi="10.17487/RFC1735",
  }

@misc{rfc1736,
  author="J. Kunze",
  title="{Functional Recommendations for Internet Resource Locators}",
  howpublished="RFC 1736 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1736",
  pages="1--10",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1736.txt",
  key="RFC 1736",
  abstract={This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Uniform, Resource, URL",
  doi="10.17487/RFC1736",
  }

@misc{rfc1737,
  author="K. Sollins and L. Masinter",
  title="{Functional Requirements for Uniform Resource Names}",
  howpublished="RFC 1737 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1737",
  pages="1--7",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1737.txt",
  key="RFC 1737",
  abstract={This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1737",
  }

@misc{rfc1738,
  author="T. Berners-Lee and L. Masinter and M. McCahill",
  title="{Uniform Resource Locators (URL)}",
  howpublished="RFC 1738 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1738",
  pages="1--25",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4248, 4266, updated by RFCs 1808, 2368, 2396, 3986, 6196, 6270, 8089",
url="https://www.rfc-editor.org/rfc/rfc1738.txt",
  key="RFC 1738",
  abstract={This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]},
  keywords="URL",
  doi="10.17487/RFC1738",
  }

@misc{rfc1739,
  author="G. Kessler and S. Shepard",
  title="{A Primer On Internet and TCP/IP Tools}",
  howpublished="RFC 1739 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1739",
  pages="1--46",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2151",
url="https://www.rfc-editor.org/rfc/rfc1739.txt",
  key="RFC 1739",
  abstract={This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy.  It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NSlookup, PING, FINGER, TRACEROUTE, FTP, TELNET, WHOIS, NICNAME, KNOWBOT, NETFIND, ARCHIE, Gopher, Email, Mailing, Lists, USENET",
  doi="10.17487/RFC1739",
  }

@misc{rfc1740,
  author="P. Faltstrom and D. Crocker and E. Fair",
  title="{MIME Encapsulation of Macintosh Files - MacMIME}",
  howpublished="RFC 1740 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1740",
  pages="1--16",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1740.txt",
  key="RFC 1740",
  abstract={This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]},
  keywords="MacMIME, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1740",
  }

@misc{rfc1741,
  author="P. Faltstrom and D. Crocker and E. Fair",
  title="{MIME Content Type for BinHex Encoded Files}",
  howpublished="RFC 1741 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1741",
  pages="1--6",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1741.txt",
  key="RFC 1741",
  abstract={This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="BINHEX, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1741",
  }

@misc{rfc1742,
  author="S. Waldbusser and K. Frisa",
  title="{AppleTalk Management Information Base II}",
  howpublished="RFC 1742 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1742",
  pages="1--84",
  year=1995,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1742.txt",
  key="RFC 1742",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK]},
  keywords="AT-MIB",
  doi="10.17487/RFC1742",
  }

@misc{rfc1743,
  author="K. McCloghrie and E. Decker",
  title="{IEEE 802.5 MIB using SMIv2}",
  howpublished="RFC 1743 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1743",
  pages="1--25",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1748",
url="https://www.rfc-editor.org/rfc/rfc1743.txt",
  key="RFC 1743",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]},
  keywords="Management, Information, Base, SNMP,",
  doi="10.17487/RFC1743",
  }

@misc{rfc1744,
  author="G. Huston",
  title="{Observations on the Management of the Internet Address Space}",
  howpublished="RFC 1744 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1744",
  pages="1--12",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1744.txt",
  key="RFC 1744",
  abstract={This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Internet, Protocol",
  doi="10.17487/RFC1744",
  }

@misc{rfc1745,
  author="K. Varadhan and S. Hares and Y. Rekhter",
  title="{BGP4/IDRP for IP---OSPF Interaction}",
  howpublished="RFC 1745 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1745",
  pages="1--19",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1745.txt",
  key="RFC 1745",
  abstract={This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]},
  keywords="BGP4/IDRP, Internet, Inter-Domain, Routing, Protocol, Border, Gateway, Open, Shortest, Path, First",
  doi="10.17487/RFC1745",
  }

@misc{rfc1746,
  author="B. Manning and D. Perkins",
  title="{Ways to Define User Expectations}",
  howpublished="RFC 1746 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1746",
  pages="1--18",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1746.txt",
  key="RFC 1746",
  abstract={This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1746",
  }

@misc{rfc1747,
  author="J. Hilgeman and S. Nix and A. Bartky and W. Clark",
  title="{Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2}",
  howpublished="RFC 1747 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1747",
  pages="1--67",
  year=1995,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1747.txt",
  key="RFC 1747",
  abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]},
  keywords="SDLCSMIv2",
  doi="10.17487/RFC1747",
  }

@misc{rfc1748,
  author="K. McCloghrie and E. Decker",
  title="{IEEE 802.5 MIB using SMIv2}",
  howpublished="RFC 1748 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1748",
  pages="1--25",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 1749",
url="https://www.rfc-editor.org/rfc/rfc1748.txt",
  key="RFC 1748",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]},
  keywords="802.5-MIB, Management, Information, Base, SNMP",
  doi="10.17487/RFC1748",
  }

@misc{rfc1749,
  author="K. McCloghrie and F. Baker and E. Decker",
  title="{IEEE 802.5 Station Source Routing MIB using SMIv2}",
  howpublished="RFC 1749 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1749",
  pages="1--10",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1749.txt",
  key="RFC 1749",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]},
  keywords="802.5-SSR, Management, Information, Base, SNMP",
  doi="10.17487/RFC1749",
  }

@misc{rfc1750,
  author="D. {Eastlake 3rd} and S. Crocker and J. Schiller",
  title="{Randomness Recommendations for Security}",
  howpublished="RFC 1750 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1750",
  pages="1--30",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4086",
url="https://www.rfc-editor.org/rfc/rfc1750.txt",
  key="RFC 1750",
  abstract={Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Random, Numbers, Seed",
  doi="10.17487/RFC1750",
  }

@misc{rfc1751,
  author="D. McDonald",
  title="{A Convention for Human-Readable 128-bit Keys}",
  howpublished="RFC 1751 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1751",
  pages="1--15",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1751.txt",
  key="RFC 1751",
  abstract={This memo proposes a convention for use with Internet applications \& protocols using 128-bit cryptographic keys.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Security, Password",
  doi="10.17487/RFC1751",
  }

@misc{rfc1752,
  author="S. Bradner and A. Mankin",
  title="{The Recommendation for the IP Next Generation Protocol}",
  howpublished="RFC 1752 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1752",
  pages="1--52",
  year=1995,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1752.txt",
  key="RFC 1752",
  abstract={This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]},
  keywords="IPNG, IPng, Internet",
  doi="10.17487/RFC1752",
  }

@misc{rfc1753,
  author="N. Chiappa",
  title="{IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture}",
  howpublished="RFC 1753 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1753",
  pages="1--18",
  year=1994,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1753.txt",
  key="RFC 1753",
  abstract={This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol.  To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng, White, Paper, Internet, Protocol",
  doi="10.17487/RFC1753",
  }

@misc{rfc1754,
  author="M. Laubach",
  title="{IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1}",
  howpublished="RFC 1754 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1754",
  pages="1--7",
  year=1995,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1754.txt",
  key="RFC 1754",
  abstract={This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Asynchromous, Transfer, Mode",
  doi="10.17487/RFC1754",
  }

@misc{rfc1755,
  author="M. Perez and F. Liaw and A. Mankin and E. Hoffman and D. Grossman and A. Malis",
  title="{ATM Signaling Support for IP over ATM}",
  howpublished="RFC 1755 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1755",
  pages="1--32",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1755.txt",
  key="RFC 1755",
  abstract={This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]},
  keywords="ATM, Asynchronous, Transfer, Mode",
  doi="10.17487/RFC1755",
  }

@misc{rfc1756,
  author="T. Rinne",
  title="{Remote Write Protocol - Version 1.0}",
  howpublished="RFC 1756 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1756",
  pages="1--11",
  year=1995,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1756.txt",
  key="RFC 1756",
  abstract={This document describes a simple Remote Write Protocol (RWP).  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RWP, Application",
  doi="10.17487/RFC1756",
  }

@misc{rfc1757,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base}",
  howpublished="RFC 1757 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1757",
  pages="1--91",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2819",
url="https://www.rfc-editor.org/rfc/rfc1757.txt",
  key="RFC 1757",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]},
  keywords="RMON-MIB, MIB, RMON",
  doi="10.17487/RFC1757",
  }

@misc{rfc1758,
  author="The North American Directory Forum",
  title="{NADF Standing Documents: A Brief Overview}",
  howpublished="RFC 1758 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1758",
  pages="1--4",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1758.txt",
  key="RFC 1758",
  abstract={The purpose of this document is to provide a brief overview of the NADF's Standing Document series.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="X.500, North, American, Directory, Forum, Public, CCITT, Providers",
  doi="10.17487/RFC1758",
  }

@misc{rfc1759,
  author="R. Smith and F. Wright and T. Hastings and S. Zilles and J. Gyllenskog",
  title="{Printer MIB}",
  howpublished="RFC 1759 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1759",
  pages="1--113",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3805",
url="https://www.rfc-editor.org/rfc/rfc1759.txt",
  key="RFC 1759",
  abstract={A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied.  The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]},
  keywords="Print-MIB, Management, Information, Base",
  doi="10.17487/RFC1759",
  }

@misc{rfc1760,
  author="N. Haller",
  title="{The S/KEY One-Time Password System}",
  howpublished="RFC 1760 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1760",
  pages="1--12",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1760.txt",
  key="RFC 1760",
  abstract={This document describes the S/KEY* One-Time Password system as released for public use by Bellcore.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Security",
  doi="10.17487/RFC1760",
  }

@misc{rfc1761,
  author="B. Callaghan and R. Gilligan",
  title="{Snoop Version 2 Packet Capture File Format}",
  howpublished="RFC 1761 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1761",
  pages="1--6",
  year=1995,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1761.txt",
  key="RFC 1761",
  abstract={This paper describes the file format used by ``snoop'', a packet monitoring and capture program developed by Sun.  This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SNOOP, Measurement, debugging, collecting, data",
  doi="10.17487/RFC1761",
  }

@misc{rfc1762,
  author="S. Senum",
  title="{The PPP DECnet Phase IV Control Protocol (DNCP)}",
  howpublished="RFC 1762 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1762",
  pages="1--7",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1762.txt",
  key="RFC 1762",
  abstract={This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.  This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]},
  keywords="PPP-DNCP, Point, Digital, Equipment, Corporation",
  doi="10.17487/RFC1762",
  }

@misc{rfc1763,
  author="S. Senum",
  title="{The PPP Banyan Vines Control Protocol (BVCP)}",
  howpublished="RFC 1763 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1763",
  pages="1--10",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1763.txt",
  key="RFC 1763",
  abstract={This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]},
  keywords="BVCP, Point",
  doi="10.17487/RFC1763",
  }

@misc{rfc1764,
  author="S. Senum",
  title="{The PPP XNS IDP Control Protocol (XNSCP)}",
  howpublished="RFC 1764 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1764",
  pages="1--5",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1764.txt",
  key="RFC 1764",
  abstract={This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]},
  keywords="XNSCP, Point, Xerox, Network, Internetwork, Datagram, Service",
  doi="10.17487/RFC1764",
  }

@misc{rfc1765,
  author="J. Moy",
  title="{OSPF Database Overflow}",
  howpublished="RFC 1765 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1765",
  pages="1--9",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1765.txt",
  key="RFC 1765",
  abstract={This memo details a way of gracefully handling unanticipated database overflows.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="OSPF-OVFL",
  doi="10.17487/RFC1765",
  }

@misc{rfc1766,
  author="H. Alvestrand",
  title="{Tags for the Identification of Languages}",
  howpublished="RFC 1766 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1766",
  pages="1--9",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3066, 3282",
url="https://www.rfc-editor.org/rfc/rfc1766.txt",
  key="RFC 1766",
  abstract={This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]},
  keywords="Lang-Tag",
  doi="10.17487/RFC1766",
  }

@misc{rfc1767,
  author="D. Crocker",
  title="{MIME Encapsulation of EDI Objects}",
  howpublished="RFC 1767 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1767",
  pages="1--7",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1767.txt",
  key="RFC 1767",
  abstract={Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]},
  keywords="MIME-EDI, Electronic, Data, Interchange, Multipurpose, Internet, Mail, Extensions, delivery, mechanism, encapsulation",
  doi="10.17487/RFC1767",
  }

@misc{rfc1768,
  author="D. Marlow",
  title="{Host Group Extensions for CLNP Multicasting}",
  howpublished="RFC 1768 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1768",
  pages="1--45",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1768.txt",
  key="RFC 1768",
  abstract={This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="CLNP-MULT, ISO, OSI",
  doi="10.17487/RFC1768",
  }

@misc{rfc1769,
  author="D. Mills",
  title="{Simple Network Time Protocol (SNTP)}",
  howpublished="RFC 1769 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1769",
  pages="1--14",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2030, 4330",
url="https://www.rfc-editor.org/rfc/rfc1769.txt",
  key="RFC 1769",
  abstract={This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Clocks, Synchronization, NTP",
  doi="10.17487/RFC1769",
  }

@misc{rfc1770,
  author="C. Graff",
  title="{IPv4 Option for Sender Directed Multi-Destination Delivery}",
  howpublished="RFC 1770 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1770",
  pages="1--6",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6814",
url="https://www.rfc-editor.org/rfc/rfc1770.txt",
  key="RFC 1770",
  abstract={This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SDMD",
  doi="10.17487/RFC1770",
  }

@misc{rfc1771,
  author="Y. Rekhter and T. Li",
  title="{A Border Gateway Protocol 4 (BGP-4)}",
  howpublished="RFC 1771 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1771",
  pages="1--57",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4271",
url="https://www.rfc-editor.org/rfc/rfc1771.txt",
  key="RFC 1771",
  abstract={This document, together with its companion document, ``Application of the Border Gateway Protocol in the Internet'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]},
  keywords="BGP-4, routing",
  doi="10.17487/RFC1771",
  }

@misc{rfc1772,
  author="Y. Rekhter and P. Gross",
  title="{Application of the Border Gateway Protocol in the Internet}",
  howpublished="RFC 1772 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1772",
  pages="1--19",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1772.txt",
  key="RFC 1772",
  abstract={This document, together with its companion document, ``A Border Gateway Protocol 4 (BGP-4)'', define an inter-autonomous system routing protocol for the Internet.  This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]},
  keywords="BGP-4-APP, BGP-4, Routing",
  doi="10.17487/RFC1772",
  }

@misc{rfc1773,
  author="P. Traina",
  title="{Experience with the BGP-4 protocol}",
  howpublished="RFC 1773 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1773",
  pages="1--9",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1773.txt",
  key="RFC 1773",
  abstract={The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).  This report documents experience with BGP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="BGP-4, Border, Gateway, Protocol, Routing",
  doi="10.17487/RFC1773",
  }

@misc{rfc1774,
  author="P. Traina",
  title="{BGP-4 Protocol Analysis}",
  howpublished="RFC 1774 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1774",
  pages="1--10",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1774.txt",
  key="RFC 1774",
  abstract={The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4).  This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Border, Gateway, Routing",
  doi="10.17487/RFC1774",
  }

@misc{rfc1775,
  author="D. Crocker",
  title="{To Be ``On'' the Internet}",
  howpublished="RFC 1775 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1775",
  pages="1--4",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1775.txt",
  key="RFC 1775",
  abstract={The Internet permits different levels of access for consumers and providers of service.  The nature of those differences is quite important in the capabilities They afford.  Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is ``on'' the Internet.  This document suggests four terms, for distinguishing the major classes of access.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="access, full, Client, Mediated, Messaging",
  doi="10.17487/RFC1775",
  }

@misc{rfc1776,
  author="S. Crocker",
  title="{The Address is the Message}",
  howpublished="RFC 1776 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1776",
  pages="1--2",
  year=1995,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1776.txt",
  key="RFC 1776",
  abstract={Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPng",
  doi="10.17487/RFC1776",
  }

@misc{rfc1777,
  author="W. Yeong and T. Howes and S. Kille",
  title="{Lightweight Directory Access Protocol}",
  howpublished="RFC 1777 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1777",
  pages="1--22",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3494",
url="https://www.rfc-editor.org/rfc/rfc1777.txt",
  key="RFC 1777",
  abstract={The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]},
  keywords="X.500, DAP, interactive, access",
  doi="10.17487/RFC1777",
  }

@misc{rfc1778,
  author="T. Howes and S. Kille and W. Yeong and C. Robbins",
  title="{The String Representation of Standard Attribute Syntaxes}",
  howpublished="RFC 1778 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1778",
  pages="1--12",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3494, updated by RFC 2559",
url="https://www.rfc-editor.org/rfc/rfc1778.txt",
  key="RFC 1778",
  abstract={The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings.  This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]},
  keywords="X.500, LDAP, lightweight directory protocol",
  doi="10.17487/RFC1778",
  }

@misc{rfc1779,
  author="S. Kille",
  title="{A String Representation of Distinguished Names}",
  howpublished="RFC 1779 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1779",
  pages="1--8",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2253, 3494",
url="https://www.rfc-editor.org/rfc/rfc1779.txt",
  key="RFC 1779",
  abstract={The OSI Directory uses distinguished names as the primary keys to entries in the directory.  Distinguished Names are encoded in ASN.1.  When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.  This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]},
  keywords="STR-REP, X.500, directory names, representing names",
  doi="10.17487/RFC1779",
  }

@misc{rfc1780,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1780 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1780",
  pages="1--39",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1800",
url="https://www.rfc-editor.org/rfc/rfc1780.txt",
  key="RFC 1780",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1780",
  }

@misc{rfc1781,
  author="S. Kille",
  title="{Using the OSI Directory to Achieve User Friendly Naming}",
  howpublished="RFC 1781 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1781",
  pages="1--26",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3494",
url="https://www.rfc-editor.org/rfc/rfc1781.txt",
  key="RFC 1781",
  abstract={This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]},
  keywords="OSI-Dir, X.500, directory names, representing names",
  doi="10.17487/RFC1781",
  }

@misc{rfc1782,
  author="G. Malkin and A. Harkin",
  title="{TFTP Option Extension}",
  howpublished="RFC 1782 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1782",
  pages="1--6",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2347",
url="https://www.rfc-editor.org/rfc/rfc1782.txt",
  key="RFC 1782",
  abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.},
  keywords="trivial, file, transfer, booting",
  doi="10.17487/RFC1782",
  }

@misc{rfc1783,
  author="G. Malkin and A. Harkin",
  title="{TFTP Blocksize Option}",
  howpublished="RFC 1783 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1783",
  pages="1--5",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2348",
url="https://www.rfc-editor.org/rfc/rfc1783.txt",
  key="RFC 1783",
  abstract={This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]},
  keywords="trivial, file, transfer, booting",
  doi="10.17487/RFC1783",
  }

@misc{rfc1784,
  author="G. Malkin and A. Harkin",
  title="{TFTP Timeout Interval and Transfer Size Options}",
  howpublished="RFC 1784 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1784",
  pages="1--4",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2349",
url="https://www.rfc-editor.org/rfc/rfc1784.txt",
  key="RFC 1784",
  abstract={This document describes two TFTP options.  The first allows the client and server to negotiate the Timeout Interval.  The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]},
  keywords="trivial, file, transfer, booting",
  doi="10.17487/RFC1784",
  }

@misc{rfc1785,
  author="G. Malkin and A. Harkin",
  title="{TFTP Option Negotiation Analysis}",
  howpublished="RFC 1785 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1785",
  pages="1--2",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1785.txt",
  key="RFC 1785",
  abstract={This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="trivial, file, transfer, booting",
  doi="10.17487/RFC1785",
  }

@misc{rfc1786,
  author="T. Bates and E. Gerich and L. Joncheray and J-M. Jouanigot and D. Karrenberg and M. Terpstra and J. Yu",
  title="{Representation of IP Routing Policies in a Routing Registry (ripe-81++)}",
  howpublished="RFC 1786 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1786",
  pages="1--83",
  year=1995,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1786.txt",
  key="RFC 1786",
  abstract={This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database.  It incorporates several extensions proposed by Merit Inc.  and gives details of a generalized IP routing policy representation to be used by all Internet routing registries.  It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1786",
  }

@misc{rfc1787,
  author="Y. Rekhter",
  title="{Routing in a Multi-provider Internet}",
  howpublished="RFC 1787 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1787",
  pages="1--8",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1787.txt",
  key="RFC 1787",
  abstract={This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, Architechure Board, IAB",
  doi="10.17487/RFC1787",
  }

@misc{rfc1788,
  author="W. Simpson",
  title="{ICMP Domain Name Messages}",
  howpublished="RFC 1788 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1788",
  pages="1--7",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6918",
url="https://www.rfc-editor.org/rfc/rfc1788.txt",
  key="RFC 1788",
  abstract={This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address.  This document defines an Experimental Protocol for the Internet community.  This does not specify an Internet standard of any kind.},
  keywords="ICMP-DM, Internet, Control, Message, Protocol, DNS, Service",
  doi="10.17487/RFC1788",
  }

@misc{rfc1789,
  author="C. Yang",
  title="{INETPhone: Telephone Services and Servers on Internet}",
  howpublished="RFC 1789 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1789",
  pages="1--6",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1789.txt",
  key="RFC 1789",
  abstract={This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1789",
  }

@misc{rfc1790,
  author="V. Cerf",
  title="{An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols}",
  howpublished="RFC 1790 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1790",
  pages="1--4",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1790.txt",
  key="RFC 1790",
  abstract={This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ISOC",
  doi="10.17487/RFC1790",
  }

@misc{rfc1791,
  author="T. Sung",
  title="{TCP And UDP Over IPX Networks With Fixed Path MTU}",
  howpublished="RFC 1791 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1791",
  pages="1--12",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1791.txt",
  key="RFC 1791",
  abstract={TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX.  And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX.  This document defines an Experimental Protocol for the Internet community.  This does not specify an Internet standard of any kind.},
  keywords="Transmission, Control, Protocol, User, Datagram, Maxium, Unit",
  doi="10.17487/RFC1791",
  }

@misc{rfc1792,
  author="T. Sung",
  title="{TCP/IPX Connection Mib Specification}",
  howpublished="RFC 1792 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1792",
  pages="1--9",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1792.txt",
  key="RFC 1792",
  abstract={New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX.  This document defines an Experimental Protocol for the Internet community.  This does not specify an Internet standard of any kind.},
  keywords="TCP/IPXMIB, Transmission, Control, Protocol, Management, Information, Base",
  doi="10.17487/RFC1792",
  }

@misc{rfc1793,
  author="J. Moy",
  title="{Extending OSPF to Support Demand Circuits}",
  howpublished="RFC 1793 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1793",
  pages="1--32",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3883",
url="https://www.rfc-editor.org/rfc/rfc1793.txt",
  key="RFC 1793",
  abstract={This memo defines enhancements to the OSPF protocol that allow efficient operation over ``demand circuits''. [STANDARDS-TRACK]},
  keywords="OSPF-DC, Open, Shortest, Path, First",
  doi="10.17487/RFC1793",
  }

@misc{rfc1794,
  author="T. Brisco",
  title="{DNS Support for Load Balancing}",
  howpublished="RFC 1794 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1794",
  pages="1--7",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1794.txt",
  key="RFC 1794",
  abstract={This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Domain, Name, System",
  doi="10.17487/RFC1794",
  }

@misc{rfc1795,
  author="L. Wells and A. Bartky",
  title="{Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1}",
  howpublished="RFC 1795 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1795",
  pages="1--91",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1795.txt",
  key="RFC 1795",
  abstract={This RFC describes use of Data Link Switching over TCP/IP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IBM, SNA, DLS, SSP, NetBIos, APPN",
  doi="10.17487/RFC1795",
  }

@misc{rfc1796,
  author="C. Huitema and J. Postel and S. Crocker",
  title="{Not All RFCs are Standards}",
  howpublished="RFC 1796 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1796",
  pages="1--4",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1796.txt",
  key="RFC 1796",
  abstract={This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1796",
  }

@misc{rfc1797,
  author="Internet Assigned Numbers Authority (IANA)",
  title="{Class A Subnet Experiment}",
  howpublished="RFC 1797 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1797",
  pages="1--4",
  year=1995,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1797.txt",
  key="RFC 1797",
  abstract={There appears to be some interest in experimenting with subnetting the class A addresses.  It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important.  This document defines an Experimental Protocol for the Internet community.  This does not specify an Internet standard of any kind.},
  keywords="Network, Address, 39, Number",
  doi="10.17487/RFC1797",
  }

@misc{rfc1798,
  author="A. Young",
  title="{Connection-less Lightweight X.500 Directory Access Protocol}",
  howpublished="RFC 1798 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1798",
  pages="1--9",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3352",
url="https://www.rfc-editor.org/rfc/rfc1798.txt",
  key="RFC 1798",
  abstract={The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]},
  keywords="CLDAP, CLDAP, Presentation, Address, Application, Entity, Title",
  doi="10.17487/RFC1798",
  }

@misc{rfc1799,
  author="M. Kennedy",
  title="{Request for Comments Summary RFC Numbers 1700-1799}",
  howpublished="RFC 1799 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1799",
  pages="1--21",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1799.txt",
  key="RFC 1799",
  keywords="Index",
  doi="10.17487/RFC1799",
  }

@misc{rfc1800,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1800 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1800",
  pages="1--36",
  year=1995,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1880",
url="https://www.rfc-editor.org/rfc/rfc1800.txt",
  key="RFC 1800",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1800",
  }

@misc{rfc1801,
  author="S. Kille",
  title="{MHS use of the X.500 Directory to support MHS Routing}",
  howpublished="RFC 1801 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1801",
  pages="1--73",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1801.txt",
  key="RFC 1801",
  abstract={The key problem in routing is to map from an O/R Address onto an MTA (next hop).  This shall be an MTA which in some sense is ``nearer'' to the destination UA.  This is done repeatedly until the message can be directly delivered to the recipient UA.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Routing, Mail, EMail, Message, Handling, System, X.400",
  doi="10.17487/RFC1801",
  }

@misc{rfc1802,
  author="H. Alvestrand and K. Jordan and S. Langlois and J. Romaguera",
  title="{Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing}",
  howpublished="RFC 1802 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1802",
  pages="1--11",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1802.txt",
  key="RFC 1802",
  abstract={This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Mail, EMail, Message, Handling, System, MHS",
  doi="10.17487/RFC1802",
  }

@misc{rfc1803,
  author="R. Wright and A. Getchell and T. Howes and S. Sataluri and P. Yee and W. Yeong",
  title="{Recommendations for an X.500 Production Directory Service}",
  howpublished="RFC 1803 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1803",
  pages="1--8",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1803.txt",
  key="RFC 1803",
  abstract={This document contains a set of basic recommendations for a country- level X.500 DSA.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="White, Pages, DSA, Directory, User, Agent",
  doi="10.17487/RFC1803",
  }

@misc{rfc1804,
  author="G. Mansfield and P. Rajeev and S. Raghavan and T. Howes",
  title="{Schema Publishing in X.500 Directory}",
  howpublished="RFC 1804 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1804",
  pages="1--10",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1804.txt",
  key="RFC 1804",
  abstract={In this document we propose a solution using the existing mechanisms of the directory [1] itself.  We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC1804",
  }

@misc{rfc1805,
  author="A. Rubin",
  title="{Location-Independent Data/Software Integrity Protocol}",
  howpublished="RFC 1805 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1805",
  pages="1--6",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1805.txt",
  key="RFC 1805",
  abstract={This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Betsi, Security, Cryptography",
  doi="10.17487/RFC1805",
  }

@misc{rfc1806,
  author="R. Troost and S. Dorner",
  title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header}",
  howpublished="RFC 1806 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1806",
  pages="1--8",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2183",
url="https://www.rfc-editor.org/rfc/rfc1806.txt",
  key="RFC 1806",
  abstract={This memo provides a mechanism whereby messages conforming to the [RFC 1521] (``MIME'') specification can convey presentational information.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIME, EMail, Mail",
  doi="10.17487/RFC1806",
  }

@misc{rfc1807,
  author="R. Lasher and D. Cohen",
  title="{A Format for Bibliographic Records}",
  howpublished="RFC 1807 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1807",
  pages="1--15",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1807.txt",
  key="RFC 1807",
  abstract={This RFC defines a format for bibliographic records describing technical reports.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="library, technical reports, email services",
  doi="10.17487/RFC1807",
  }

@misc{rfc1808,
  author="R. Fielding",
  title="{Relative Uniform Resource Locators}",
  howpublished="RFC 1808 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1808",
  pages="1--16",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3986, updated by RFCs 2368, 2396",
url="https://www.rfc-editor.org/rfc/rfc1808.txt",
  key="RFC 1808",
  abstract={In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance.  This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]},
  keywords="URL, URL, syntax, semantics",
  doi="10.17487/RFC1808",
  }

@misc{rfc1809,
  author="C. Partridge",
  title="{Using the Flow Label Field in IPv6}",
  howpublished="RFC 1809 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1809",
  pages="1--6",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1809.txt",
  key="RFC 1809",
  abstract={The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1809",
  }

@misc{rfc1810,
  author="J. Touch",
  title="{Report on MD5 Performance}",
  howpublished="RFC 1810 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1810",
  pages="1--7",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1810.txt",
  key="RFC 1810",
  abstract={This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPv6, Message, Digest, Algorithm, Authentication",
  doi="10.17487/RFC1810",
  }

@misc{rfc1811,
  author="Federal Networking Council",
  title="{U.S. Government Internet Domain Names}",
  howpublished="RFC 1811 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1811",
  pages="1--3",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1816",
url="https://www.rfc-editor.org/rfc/rfc1811.txt",
  key="RFC 1811",
  abstract={This document describes the registration policies for the top-level domain ``.GOV''.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GOV, FNC, IANA",
  doi="10.17487/RFC1811",
  }

@misc{rfc1812,
  author="F. Baker",
  title="{Requirements for IP Version 4 Routers}",
  howpublished="RFC 1812 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1812",
  pages="1--175",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2644, 6633",
url="https://www.rfc-editor.org/rfc/rfc1812.txt",
  key="RFC 1812",
  abstract={This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]},
  keywords="routing, IPv4",
  doi="10.17487/RFC1812",
  }

@misc{rfc1813,
  author="B. Callaghan and B. Pawlowski and P. Staubach",
  title="{NFS Version 3 Protocol Specification}",
  howpublished="RFC 1813 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1813",
  pages="1--126",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1813.txt",
  key="RFC 1813",
  abstract={This paper describes the NFS version 3 protocol.  This paper is provided so that people can write compatible implementations.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NFSV3",
  doi="10.17487/RFC1813",
  }

@misc{rfc1814,
  author="E. Gerich",
  title="{Unique Addresses are Good}",
  howpublished="RFC 1814 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1814",
  pages="1--3",
  year=1995,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1814.txt",
  key="RFC 1814",
  abstract={The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Registries, Protocol, Private, Network, Numbers",
  doi="10.17487/RFC1814",
  }

@misc{rfc1815,
  author="M. Ohta",
  title="{Character Sets ISO-10646 and ISO-10646-J-1}",
  howpublished="RFC 1815 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1815",
  pages="1--6",
  year=1995,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1815.txt",
  key="RFC 1815",
  abstract={For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.  This memo provides information on such profiling, along with charset names to each profiled instance.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Japanese, Latin",
  doi="10.17487/RFC1815",
  }

@misc{rfc1816,
  author="Federal Networking Council",
  title="{U.S. Government Internet Domain Names}",
  howpublished="RFC 1816 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1816",
  pages="1--8",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2146",
url="https://www.rfc-editor.org/rfc/rfc1816.txt",
  key="RFC 1816",
  abstract={This memo provides an update and clarification to RFC 1811.  This document describes the registration policies for the top-level domain ``.GOV''.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GOV, FNC, IANA",
  doi="10.17487/RFC1816",
  }

@misc{rfc1817,
  author="Y. Rekhter",
  title="{CIDR and Classful Routing}",
  howpublished="RFC 1817 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1817",
  pages="1--2",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1817.txt",
  key="RFC 1817",
  abstract={This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Classless, Inter, Domain, Routing",
  doi="10.17487/RFC1817",
  }

@misc{rfc1818,
  author="J. Postel and T. Li and Y. Rekhter",
  title="{Best Current Practices}",
  howpublished="RFC 1818 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1818",
  pages="1--3",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1818.txt",
  key="RFC 1818",
  abstract={This document describes a new series of documents which describe best current practices for the Internet community.  Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).},
  keywords="BCP",
  doi="10.17487/RFC1818",
  }

@misc{rfc1819,
  author="L. Delgrossi and L. Berger",
  title="{Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+}",
  howpublished="RFC 1819 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1819",
  pages="1--109",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1819.txt",
  key="RFC 1819",
  abstract={This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ST2",
  doi="10.17487/RFC1819",
  }

@misc{rfc1820,
  author="E. Huizer",
  title="{Multimedia E-mail (MIME) User Agent Checklist}",
  howpublished="RFC 1820 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1820",
  pages="1--8",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1844",
url="https://www.rfc-editor.org/rfc/rfc1820.txt",
  key="RFC 1820",
  abstract={This document presents a checklist to facilitate evaluation of MIME capable User Agents.  Access to a MIME test-responder, that generates test-messages is described.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Multipurpose, Internet, Mail, Extensions, Media, Types",
  doi="10.17487/RFC1820",
  }

@misc{rfc1821,
  author="M. Borden and E. Crawley and B. Davie and S. Batsell",
  title="{Integration of Real-time Services in an IP-ATM Network Architecture}",
  howpublished="RFC 1821 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1821",
  pages="1--24",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1821.txt",
  key="RFC 1821",
  abstract={The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Asynchronous, Transfer, Mode",
  doi="10.17487/RFC1821",
  }

@misc{rfc1822,
  author="J. Lowe",
  title="{A Grant of Rights to Use a Specific IBM patent with Photuris}",
  howpublished="RFC 1822 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1822",
  pages="1--2",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1822.txt",
  key="RFC 1822",
  abstract={This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Key, Management, Protocol, IKMP, IETF",
  doi="10.17487/RFC1822",
  }

@misc{rfc1823,
  author="T. Howes and M. Smith",
  title="{The LDAP Application Program Interface}",
  howpublished="RFC 1823 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1823",
  pages="1--22",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1823.txt",
  key="RFC 1823",
  abstract={This document defines a C language application program interface to the lightweight directory access protocol (LDAP).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="lightweight, directory, access, protocol, API, X.500",
  doi="10.17487/RFC1823",
  }

@misc{rfc1824,
  author="H. Danisch",
  title="{The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)}",
  howpublished="RFC 1824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1824",
  pages="1--21",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1824.txt",
  key="RFC 1824",
  abstract={This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="TESS, public, keys",
  doi="10.17487/RFC1824",
  }

@misc{rfc1825,
  author="R. Atkinson",
  title="{Security Architecture for the Internet Protocol}",
  howpublished="RFC 1825 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1825",
  pages="1--22",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2401",
url="https://www.rfc-editor.org/rfc/rfc1825.txt",
  key="RFC 1825",
  abstract={This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]},
  keywords="IPv4, IPv6, IP-layer, ipsec",
  doi="10.17487/RFC1825",
  }

@misc{rfc1826,
  author="R. Atkinson",
  title="{IP Authentication Header}",
  howpublished="RFC 1826 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1826",
  pages="1--13",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2402",
url="https://www.rfc-editor.org/rfc/rfc1826.txt",
  key="RFC 1826",
  abstract={This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]},
  keywords="ipsec, IPV6-AH, Internet, Protocol, AH, security, IPv4, IPv6",
  doi="10.17487/RFC1826",
  }

@misc{rfc1827,
  author="R. Atkinson",
  title="{IP Encapsulating Security Payload (ESP)}",
  howpublished="RFC 1827 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1827",
  pages="1--12",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2406",
url="https://www.rfc-editor.org/rfc/rfc1827.txt",
  key="RFC 1827",
  abstract={This document describes the IP Encapsulating Security Payload (ESP).  ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]},
  keywords="ESP, Internet, Protocol, IPv4, IPv6, ipsec",
  doi="10.17487/RFC1827",
  }

@misc{rfc1828,
  author="P. Metzger and W. Simpson",
  title="{IP Authentication using Keyed MD5}",
  howpublished="RFC 1828 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1828",
  pages="1--6",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1828.txt",
  key="RFC 1828",
  abstract={This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]},
  keywords="ipsec, Internet, Protocol, Authentication, Header, AH, Message, Digest, 5, Security",
  doi="10.17487/RFC1828",
  }

@misc{rfc1829,
  author="P. Karn and P. Metzger and W. Simpson",
  title="{The ESP DES-CBC Transform}",
  howpublished="RFC 1829 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1829",
  pages="1--11",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1829.txt",
  key="RFC 1829",
  abstract={This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="Encapsulating, Security, Payload, US, Data, Encryption, Standard, Cipher, Block, Chaining, IP, Internet, Protocol, Security, ipsec",
  doi="10.17487/RFC1829",
  }

@misc{rfc1830,
  author="G. Vaudreuil",
  title="{SMTP Service Extensions for Transmission of Large and Binary MIME Messages}",
  howpublished="RFC 1830 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1830",
  pages="1--8",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3030",
url="https://www.rfc-editor.org/rfc/rfc1830.txt",
  key="RFC 1830",
  abstract={This memo defines two extensions to the SMTP service.  The first service enables a SMTP client and server to negotiate the use of an alternate DATA command ``BDAT'' for efficiently sending large MIME messages.  The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Simple, Mail, Transfer, Multipurpose, Mail, Extensions",
  doi="10.17487/RFC1830",
  }

@misc{rfc1831,
  author="R. Srinivasan",
  title="{RPC: Remote Procedure Call Protocol Specification Version 2}",
  howpublished="RFC 1831 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1831",
  pages="1--18",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5531",
url="https://www.rfc-editor.org/rfc/rfc1831.txt",
  key="RFC 1831",
  abstract={This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]},
  keywords="RPC], ONC, Open, Network, Computing",
  doi="10.17487/RFC1831",
  }

@misc{rfc1832,
  author="R. Srinivasan",
  title="{XDR: External Data Representation Standard}",
  howpublished="RFC 1832 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1832",
  pages="1--24",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4506",
url="https://www.rfc-editor.org/rfc/rfc1832.txt",
  key="RFC 1832",
  abstract={This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]},
  keywords="XDR, RPC, ONC, Open, Network, Computing",
  doi="10.17487/RFC1832",
  }

@misc{rfc1833,
  author="R. Srinivasan",
  title="{Binding Protocols for ONC RPC Version 2}",
  howpublished="RFC 1833 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1833",
  pages="1--14",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5665",
url="https://www.rfc-editor.org/rfc/rfc1833.txt",
  key="RFC 1833",
  abstract={This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]},
  keywords="ONC, Open, Network, Computing",
  doi="10.17487/RFC1833",
  }

@misc{rfc1834,
  author="J. Gargano and K. Weiss",
  title="{Whois and Network Information Lookup Service, Whois++}",
  howpublished="RFC 1834 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1834",
  pages="1--7",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1834.txt",
  key="RFC 1834",
  abstract={This memo describes new features for WHOIS.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="nicname, TCP, Transmission, Control, Protocol, directory, service, server, retrieval",
  doi="10.17487/RFC1834",
  }

@misc{rfc1835,
  author="P. Deutsch and R. Schoultz and P. Faltstrom and C. Weider",
  title="{Architecture of the WHOIS++ service}",
  howpublished="RFC 1835 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1835",
  pages="1--41",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1835.txt",
  key="RFC 1835",
  abstract={This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]},
  keywords="WHOIS++, nicname, TCP, Transmission, Control, Protocol, directory, service, server, retrieval",
  doi="10.17487/RFC1835",
  }

@misc{rfc1836,
  author="S. Kille",
  title="{Representing the O/R Address hierarchy in the X.500 Directory Information Tree}",
  howpublished="RFC 1836 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1836",
  pages="1--11",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2294",
url="https://www.rfc-editor.org/rfc/rfc1836.txt",
  key="RFC 1836",
  abstract={This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1].  This memo defines an Experimental Protocol for the Internet community.},
  keywords="message, handling",
  doi="10.17487/RFC1836",
  }

@misc{rfc1837,
  author="S. Kille",
  title="{Representing Tables and Subtrees in the X.500 Directory}",
  howpublished="RFC 1837 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1837",
  pages="1--7",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2293",
url="https://www.rfc-editor.org/rfc/rfc1837.txt",
  key="RFC 1837",
  abstract={This document defines techniques for representing two types of information mapping in the OSI Directory.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="message, handling",
  doi="10.17487/RFC1837",
  }

@misc{rfc1838,
  author="S. Kille",
  title="{Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses}",
  howpublished="RFC 1838 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1838",
  pages="1--8",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2164",
url="https://www.rfc-editor.org/rfc/rfc1838.txt",
  key="RFC 1838",
  abstract={This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].  This memo defines an Experimental Protocol for the Internet community.},
  keywords="message, handling",
  doi="10.17487/RFC1838",
  }

@misc{rfc1841,
  author="J. Chapman and D. Coli and A. Harvey and B. Jensen and K. Rowett",
  title="{PPP Network Control Protocol for LAN Extension}",
  howpublished="RFC 1841 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1841",
  pages="1--66",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1841.txt",
  key="RFC 1841",
  keywords="point-to-point, local, area, interface,",
  doi="10.17487/RFC1841",
  }

@misc{rfc1842,
  author="Y. Wei and Y. Zhang and J. Li and J. Ding and Y. Jiang",
  title="{ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages}",
  howpublished="RFC 1842 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1842",
  pages="1--12",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1842.txt",
  key="RFC 1842",
  abstract={This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.  Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost.  Access to the network is changing from modems to more intelligent devices.  This informational RFC discusses a PPP Network Control Protocol for one such intelligent device.  The protocol is the LAN extension interface protocol.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="electronic, mail, HZ-GB-2312",
  doi="10.17487/RFC1842",
  }

@misc{rfc1843,
  author="F. Lee",
  title="{HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters}",
  howpublished="RFC 1843 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1843",
  pages="1--5",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1843.txt",
  key="RFC 1843",
  abstract={The content of this memo is identical to an article of the same title written by the author on September 4, 1989.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GB2312-80, electronic, mail",
  doi="10.17487/RFC1843",
  }

@misc{rfc1844,
  author="E. Huizer",
  title="{Multimedia E-mail (MIME) User Agent Checklist}",
  howpublished="RFC 1844 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1844",
  pages="1--8",
  year=1995,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1844.txt",
  key="RFC 1844",
  abstract={This document presents a checklist to facilitate evaluation of MIME capable User Agents.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Multipurpose, Internet, Mail, Extensions, Media, Types",
  doi="10.17487/RFC1844",
  }

@misc{rfc1845,
  author="D. Crocker and N. Freed and A. Cargille",
  title="{SMTP Service Extension for Checkpoint/Restart}",
  howpublished="RFC 1845 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1845",
  pages="1--7",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1845.txt",
  key="RFC 1845",
  keywords="simple, mail, transfer, transaction",
  doi="10.17487/RFC1845",
  }

@misc{rfc1846,
  author="A. Durand and F. Dupont",
  title="{SMTP 521 Reply Code}",
  howpublished="RFC 1846 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1846",
  pages="1--4",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7504",
url="https://www.rfc-editor.org/rfc/rfc1846.txt",
  key="RFC 1846",
  keywords="simple, mail, transfer",
  doi="10.17487/RFC1846",
  }

@misc{rfc1847,
  author="J. Galvin and S. Murphy and S. Crocker and N. Freed",
  title="{Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted}",
  howpublished="RFC 1847 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1847",
  pages="1--11",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1847.txt",
  key="RFC 1847",
  abstract={This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.  This memo defines an Experimental Protocol for the Internet community.  This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIME-Encyp, mail, multipurpose, extensions",
  doi="10.17487/RFC1847",
  }

@misc{rfc1848,
  author="S. Crocker and N. Freed and J. Galvin and S. Murphy",
  title="{MIME Object Security Services}",
  howpublished="RFC 1848 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1848",
  pages="1--48",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1848.txt",
  key="RFC 1848",
  abstract={This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]},
  keywords="MIME-Sec, mail, multipurpose, extensions",
  doi="10.17487/RFC1848",
  }

@misc{rfc1849,
  author="H. Spencer",
  title="{``Son of 1036'': News Article Format and Transmission}",
  howpublished="RFC 1849 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1849",
  pages="1--106",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5536, 5537",
url="https://www.rfc-editor.org/rfc/rfc1849.txt",
  key="RFC 1849",
  abstract={By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This ``Internet-Draft-to-be'', though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname ``Son of 1036''. Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews. It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.},
  keywords="netnews, usenet, rfc 1036, usefor, historic",
  doi="10.17487/RFC1849",
  }

@misc{rfc1850,
  author="F. Baker and R. Coltun",
  title="{OSPF Version 2 Management Information Base}",
  howpublished="RFC 1850 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1850",
  pages="1--80",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4750",
url="https://www.rfc-editor.org/rfc/rfc1850.txt",
  key="RFC 1850",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]},
  keywords="OSPF-MIB, Open, Shortest, Path, First, SPF, MIB, routing, network management",
  doi="10.17487/RFC1850",
  }

@misc{rfc1851,
  author="P. Karn and P. Metzger and W. Simpson",
  title="{The ESP Triple DES Transform}",
  howpublished="RFC 1851 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1851",
  pages="1--11",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1851.txt",
  key="RFC 1851",
  keywords="ESP3DES, encryption encapsulating security payload cipher block chaining",
  doi="10.17487/RFC1851",
  }

@misc{rfc1852,
  author="P. Metzger and W. Simpson",
  title="{IP Authentication using Keyed SHA}",
  howpublished="RFC 1852 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1852",
  pages="1--6",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2841",
url="https://www.rfc-editor.org/rfc/rfc1852.txt",
  key="RFC 1852",
  keywords="encryption secure hash algorithm",
  doi="10.17487/RFC1852",
  }

@misc{rfc1853,
  author="W. Simpson",
  title="{IP in IP Tunneling}",
  howpublished="RFC 1853 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1853",
  pages="1--8",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1853.txt",
  key="RFC 1853",
  abstract={This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols.  This memo provides information for the Internet community.  It does not specify an Internet standard.  This document describes the use of keyed SHA with the IP Authentication Header.  This document defines an Experimental Protocol for the Internet community.  This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP).  This document defines an Experimental Protocol for the Internet community.},
  keywords="internet protocol payload encapsulation",
  doi="10.17487/RFC1853",
  }

@misc{rfc1854,
  author="N. Freed",
  title="{SMTP Service Extension for Command Pipelining}",
  howpublished="RFC 1854 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1854",
  pages="1--7",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2197",
url="https://www.rfc-editor.org/rfc/rfc1854.txt",
  key="RFC 1854",
  abstract={This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]},
  keywords="simple mail transfer protocol",
  doi="10.17487/RFC1854",
  }

@misc{rfc1855,
  author="S. Hambridge",
  title="{Netiquette Guidelines}",
  howpublished="RFC 1855 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1855",
  pages="1--21",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1855.txt",
  key="RFC 1855",
  abstract={This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Network, Etiquette",
  doi="10.17487/RFC1855",
  }

@misc{rfc1856,
  author="H. Clark",
  title="{The Opstat Client-Server Model for Statistics Retrieval}",
  howpublished="RFC 1856 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1856",
  pages="1--17",
  year=1995,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1856.txt",
  key="RFC 1856",
  keywords="tools, performance, utilization",
  doi="10.17487/RFC1856",
  }

@misc{rfc1857,
  author="M. Lambert",
  title="{A Model for Common Operational Statistics}",
  howpublished="RFC 1857 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1857",
  pages="1--27",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1857.txt",
  key="RFC 1857",
  abstract={This memo describes a model for operational statistics in the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.  This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="metrics, measurements, polling periods",
  doi="10.17487/RFC1857",
  }

@misc{rfc1858,
  author="G. Ziemba and D. Reed and P. Traina",
  title="{Security Considerations for IP Fragment Filtering}",
  howpublished="RFC 1858 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1858",
  pages="1--10",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3128",
url="https://www.rfc-editor.org/rfc/rfc1858.txt",
  key="RFC 1858",
  abstract={IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts.  This document describes two methods of attack as well as remedies to prevent them.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="internet, protocol, tcp, transmission, control, protocol, routers, hosts",
  doi="10.17487/RFC1858",
  }

@misc{rfc1859,
  author="Y. Pouffary",
  title="{ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension}",
  howpublished="RFC 1859 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1859",
  pages="1--8",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1859.txt",
  key="RFC 1859",
  abstract={This document is an extension to STD35, RFC1006, a standard for the Internet community.  The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073.  It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="International, Standard, Organizatio",
  doi="10.17487/RFC1859",
  }

@misc{rfc1860,
  author="T. Pummill and B. Manning",
  title="{Variable Length Subnet Table For IPv4}",
  howpublished="RFC 1860 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1860",
  pages="1--3",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1878",
url="https://www.rfc-editor.org/rfc/rfc1860.txt",
  key="RFC 1860",
  abstract={This document itemizes the potential values for IPv4 subnets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="values, IPv4, subnets",
  doi="10.17487/RFC1860",
  }

@misc{rfc1861,
  author="A. Gwinn",
  title="{Simple Network Paging Protocol - Version 3 -Two-Way Enhanced}",
  howpublished="RFC 1861 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1861",
  pages="1--23",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1861.txt",
  key="RFC 1861",
  abstract={This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SNPP, SNPP, wireless, paging",
  doi="10.17487/RFC1861",
  }

@misc{rfc1862,
  author="M. McCahill and J. Romkey and M. Schwartz and K. Sollins and T. Verschuren and C. Weider",
  title="{Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994}",
  howpublished="RFC 1862 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1862",
  pages="1--27",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1862.txt",
  key="RFC 1862",
  abstract={This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994.  This workshop generally focused on aspects of the information infrastructure on the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Architecture, Board",
  doi="10.17487/RFC1862",
  }

@misc{rfc1863,
  author="D. Haskin",
  title="{A BGP/IDRP Route Server alternative to a full mesh routing}",
  howpublished="RFC 1863 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1863",
  pages="1--16",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4223",
url="https://www.rfc-editor.org/rfc/rfc1863.txt",
  key="RFC 1863",
  abstract={This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="BGP-IDRP, border, gateway, protocol, inter-domain, routing",
  doi="10.17487/RFC1863",
  }

@misc{rfc1864,
  author="J. Myers and M. Rose",
  title="{The Content-MD5 Header Field}",
  howpublished="RFC 1864 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1864",
  pages="1--4",
  year=1995,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1864.txt",
  key="RFC 1864",
  abstract={This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]},
  keywords="CON-MD5, MIME, EMail, Integrity, MIC, Digest",
  doi="10.17487/RFC1864",
  }

@misc{rfc1865,
  author="W. Houser and J. Griffin and C. Hage",
  title="{EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet}",
  howpublished="RFC 1865 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1865",
  pages="1--41",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1865.txt",
  key="RFC 1865",
  abstract={This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers.  The memo introduces the Internet and assumes a basic knowledge of EDI.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="FAQ",
  doi="10.17487/RFC1865",
  }

@misc{rfc1866,
  author="T. Berners-Lee and D. Connolly",
  title="{Hypertext Markup Language - 2.0}",
  howpublished="RFC 1866 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1866",
  pages="1--77",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2854",
url="https://www.rfc-editor.org/rfc/rfc1866.txt",
  key="RFC 1866",
  abstract={This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]},
  keywords="HTML, HTML, SGML, Standard, Generalized, Language, WWW, World, Wide, Web",
  doi="10.17487/RFC1866",
  }

@misc{rfc1867,
  author="E. Nebel and L. Masinter",
  title="{Form-based File Upload in HTML}",
  howpublished="RFC 1867 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1867",
  pages="1--13",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2854",
url="https://www.rfc-editor.org/rfc/rfc1867.txt",
  key="RFC 1867",
  abstract={Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Hypertext, Markup, Language, MIME, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1867",
  }

@misc{rfc1868,
  author="G. Malkin",
  title="{ARP Extension - UNARP}",
  howpublished="RFC 1868 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1868",
  pages="1--4",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1868.txt",
  key="RFC 1868",
  abstract={This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="UNARP, Address, Resolution, Protocol, delete, entry",
  doi="10.17487/RFC1868",
  }

@misc{rfc1869,
  author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker",
  title="{SMTP Service Extensions}",
  howpublished="RFC 1869 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1869",
  pages="1--11",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2821",
url="https://www.rfc-editor.org/rfc/rfc1869.txt",
  key="RFC 1869",
  abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]},
  keywords="ESMTP, Simple, Mail, Transfer, Protocol",
  doi="10.17487/RFC1869",
  }

@misc{rfc1870,
  author="J. Klensin and N. Freed and K. Moore",
  title="{SMTP Service Extension for Message Size Declaration}",
  howpublished="RFC 1870 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1870",
  pages="1--9",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1870.txt",
  key="RFC 1870",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]},
  keywords="SMTP-SIZE, Simple Mail Transfer Protocol",
  doi="10.17487/RFC1870",
  }

@misc{rfc1871,
  author="J. Postel",
  title="{Addendum to RFC 1602 -- Variance Procedure}",
  howpublished="RFC 1871 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1871",
  pages="1--4",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2026",
url="https://www.rfc-editor.org/rfc/rfc1871.txt",
  key="RFC 1871",
  abstract={This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="BCP, WG, escape, clause, procedures",
  doi="10.17487/RFC1871",
  }

@misc{rfc1872,
  author="E. Levinson",
  title="{The MIME Multipart/Related Content-type}",
  howpublished="RFC 1872 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1872",
  pages="1--8",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2112",
url="https://www.rfc-editor.org/rfc/rfc1872.txt",
  key="RFC 1872",
  abstract={The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.  This document defines the Multipart/Related content-type and provides examples of its use.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1872",
  }

@misc{rfc1873,
  author="E. Levinson",
  title="{Message/External-Body Content-ID Access Type}",
  howpublished="RFC 1873 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1873",
  pages="1--4",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1873.txt",
  key="RFC 1873",
  abstract={The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object.  The Content-ID access method described in this document provides the capability to refer to an object within the message.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="CONT-MT, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1873",
  }

@misc{rfc1874,
  author="E. Levinson",
  title="{SGML Media Types}",
  howpublished="RFC 1874 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1874",
  pages="1--6",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1874.txt",
  key="RFC 1874",
  abstract={This document proposes new media sub-types of Text/SGML and Application/SGML.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SGML-MT, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1874",
  }

@misc{rfc1875,
  author="N. Berge",
  title="{UNINETT PCA Policy Statements}",
  howpublished="RFC 1875 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1875",
  pages="1--10",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1875.txt",
  key="RFC 1875",
  abstract={This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Policy, Certification, Authority, Encryption",
  doi="10.17487/RFC1875",
  }

@misc{rfc1876,
  author="C. Davis and P. Vixie and T. Goodwin and I. Dickinson",
  title="{A Means for Expressing Location Information in the Domain Name System}",
  howpublished="RFC 1876 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1876",
  pages="1--18",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1876.txt",
  key="RFC 1876",
  abstract={This memo defines a new DNS RR type for experimental purposes.  This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS-LOC, DNS, Resource, Record, (RR), LOC",
  doi="10.17487/RFC1876",
  }

@misc{rfc1877,
  author="S. Cobb",
  title="{PPP Internet Protocol Control Protocol Extensions for Name Server Addresses}",
  howpublished="RFC 1877 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1877",
  pages="1--6",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1877.txt",
  key="RFC 1877",
  abstract={This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Point-to-Point, Protocol, Network, Control, Domain, System, NetBIOS",
  doi="10.17487/RFC1877",
  }

@misc{rfc1878,
  author="T. Pummill and B. Manning",
  title="{Variable Length Subnet Table For IPv4}",
  howpublished="RFC 1878 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1878",
  pages="1--8",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1878.txt",
  key="RFC 1878",
  abstract={This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="values, IPv4, subnets",
  doi="10.17487/RFC1878",
  }

@misc{rfc1879,
  author="B. Manning",
  title="{Class A Subnet Experiment Results and Recommendations}",
  howpublished="RFC 1879 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1879",
  pages="1--6",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1879.txt",
  key="RFC 1879",
  abstract={This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Registry, Operations",
  doi="10.17487/RFC1879",
  }

@misc{rfc1880,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1880 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1880",
  pages="1--38",
  year=1995,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 1920",
url="https://www.rfc-editor.org/rfc/rfc1880.txt",
  key="RFC 1880",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1880",
  }

@misc{rfc1881,
  author="IAB and IESG",
  title="{IPv6 Address Allocation Management}",
  howpublished="RFC 1881 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1881",
  pages="1--2",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1881.txt",
  key="RFC 1881",
  abstract={The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IANA, Internet, Assigned, Numbers, Authority",
  doi="10.17487/RFC1881",
  }

@misc{rfc1882,
  author="B. Hancock",
  title="{The 12-Days of Technology Before Christmas}",
  howpublished="RFC 1882 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1882",
  pages="1--5",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1882.txt",
  key="RFC 1882",
  abstract={This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1882",
  }

@misc{rfc1883,
  author="S. Deering and R. Hinden",
  title="{Internet Protocol, Version 6 (IPv6) Specification}",
  howpublished="RFC 1883 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1883",
  pages="1--37",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2460",
url="https://www.rfc-editor.org/rfc/rfc1883.txt",
  key="RFC 1883",
  abstract={This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]},
  keywords="IP, Next, Generation, IPng",
  doi="10.17487/RFC1883",
  }

@misc{rfc1884,
  author="R. Hinden and S. Deering",
  title="{IP Version 6 Addressing Architecture}",
  howpublished="RFC 1884 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1884",
  pages="1--18",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2373",
url="https://www.rfc-editor.org/rfc/rfc1884.txt",
  key="RFC 1884",
  abstract={This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]},
  keywords="IPV6-Addr, IP, Next, Generation, IPng",
  doi="10.17487/RFC1884",
  }

@misc{rfc1885,
  author="A. Conta and S. Deering",
  title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)}",
  howpublished="RFC 1885 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1885",
  pages="1--20",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2463",
url="https://www.rfc-editor.org/rfc/rfc1885.txt",
  key="RFC 1885",
  abstract={This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]},
  keywords="IP, Next, Generation, IPng, Internet, Group, Management, IGMP",
  doi="10.17487/RFC1885",
  }

@misc{rfc1886,
  author="S. Thomson and C. Huitema",
  title="{DNS Extensions to support IP version 6}",
  howpublished="RFC 1886 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1886",
  pages="1--5",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3596, updated by RFCs 2874, 3152",
url="https://www.rfc-editor.org/rfc/rfc1886.txt",
  key="RFC 1886",
  abstract={This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]},
  keywords="DNS-IPV6, IP, Next, Generation, IPng, Domain, Name, System",
  doi="10.17487/RFC1886",
  }

@misc{rfc1887,
  author="Y. Rekhter and T. Li",
  title="{An Architecture for IPv6 Unicast Address Allocation}",
  howpublished="RFC 1887 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1887",
  pages="1--26",
  year=1995,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1887.txt",
  key="RFC 1887",
  abstract={This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet.  This document provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Next, Generation, IPng,",
  doi="10.17487/RFC1887",
  }

@misc{rfc1888,
  author="J. Bound and B. Carpenter and D. Harrington and J. Houldsworth and A. Lloyd",
  title="{OSI NSAPs and IPv6}",
  howpublished="RFC 1888 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1888",
  pages="1--16",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4048, updated by RFC 4548",
url="https://www.rfc-editor.org/rfc/rfc1888.txt",
  key="RFC 1888",
  abstract={This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Internet, Protocol, Open, Systems, Interconnection",
  doi="10.17487/RFC1888",
  }

@misc{rfc1889,
  author="Audio-Video Transport Working Group and H. Schulzrinne and S. Casner and R. Frederick and V. Jacobson",
  title="{RTP: A Transport Protocol for Real-Time Applications}",
  howpublished="RFC 1889 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1889",
  pages="1--75",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3550",
url="https://www.rfc-editor.org/rfc/rfc1889.txt",
  key="RFC 1889",
  abstract={This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]},
  keywords="RTP, end-to-end, network, audio, video, RTCP",
  doi="10.17487/RFC1889",
  }

@misc{rfc1890,
  author="Audio-Video Transport Working Group and H. Schulzrinne",
  title="{RTP Profile for Audio and Video Conferences with Minimal Control}",
  howpublished="RFC 1890 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1890",
  pages="1--18",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3551",
url="https://www.rfc-editor.org/rfc/rfc1890.txt",
  key="RFC 1890",
  abstract={This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]},
  keywords="RTP-AV, end-to-end, network, conference",
  doi="10.17487/RFC1890",
  }

@misc{rfc1891,
  author="K. Moore",
  title="{SMTP Service Extension for Delivery Status Notifications}",
  howpublished="RFC 1891 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1891",
  pages="1--31",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3461",
url="https://www.rfc-editor.org/rfc/rfc1891.txt",
  key="RFC 1891",
  abstract={This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]},
  keywords="SMTP-DSN, simple, mail, transfer, protocol",
  doi="10.17487/RFC1891",
  }

@misc{rfc1892,
  author="G. Vaudreuil",
  title="{The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages}",
  howpublished="RFC 1892 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1892",
  pages="1--4",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3462",
url="https://www.rfc-editor.org/rfc/rfc1892.txt",
  key="RFC 1892",
  abstract={The Multipart/Report MIME content-type is a general ``family'' or ``container'' type for electronic mail reports of any kind.  Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]},
  keywords="MIME-RPT, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1892",
  }

@misc{rfc1893,
  author="G. Vaudreuil",
  title="{Enhanced Mail System Status Codes}",
  howpublished="RFC 1893 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1893",
  pages="1--15",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3463",
url="https://www.rfc-editor.org/rfc/rfc1893.txt",
  key="RFC 1893",
  abstract={There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages.  There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN].  This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]},
  keywords="EMS-CODE, simple, mail, transfer, protocol, SMTP",
  doi="10.17487/RFC1893",
  }

@misc{rfc1894,
  author="K. Moore and G. Vaudreuil",
  title="{An Extensible Message Format for Delivery Status Notifications}",
  howpublished="RFC 1894 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1894",
  pages="1--39",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3464, updated by RFC 2852",
url="https://www.rfc-editor.org/rfc/rfc1894.txt",
  key="RFC 1894",
  abstract={This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]},
  keywords="DSN, Multipurpose, Internet, Mail, Extensions, Content, Type",
  doi="10.17487/RFC1894",
  }

@misc{rfc1895,
  author="E. Levinson",
  title="{The Application/CALS-1840 Content-type}",
  howpublished="RFC 1895 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1895",
  pages="1--6",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1895.txt",
  key="RFC 1895",
  abstract={This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, ``Automated Interchange of Technical Information,'' with the Internet electronic mail standards, RFC 822 and RFC 1521.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="MIL-STD-1840, MIME, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1895",
  }

@misc{rfc1896,
  author="P. Resnick and A. Walker",
  title="{The text/enriched MIME Content-type}",
  howpublished="RFC 1896 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1896",
  pages="1--21",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1896.txt",
  key="RFC 1896",
  abstract={This document defines one particular type of MIME data, the text/enriched MIME type.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="MIME, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC1896",
  }

@misc{rfc1897,
  author="R. Hinden and J. Postel",
  title="{IPv6 Testing Address Allocation}",
  howpublished="RFC 1897 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1897",
  pages="1--4",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2471",
url="https://www.rfc-editor.org/rfc/rfc1897.txt",
  key="RFC 1897",
  abstract={This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software.  This document specifies an Experimental protocol for the Internet community.},
  keywords="Internet, Protocol, prototype, software",
  doi="10.17487/RFC1897",
  }

@misc{rfc1898,
  author="D. {Eastlake 3rd} and B. Boesch and S. Crocker and M. Yesil",
  title="{CyberCash Credit Card Protocol Version 0.8}",
  howpublished="RFC 1898 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1898",
  pages="1--52",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1898.txt",
  key="RFC 1898",
  abstract={This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="general, payments, system",
  doi="10.17487/RFC1898",
  }

@misc{rfc1899,
  author="J. Elliott",
  title="{Request for Comments Summary RFC Numbers 1800-1899}",
  howpublished="RFC 1899 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1899",
  pages="1--20",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1899.txt",
  key="RFC 1899",
  keywords="Index",
  doi="10.17487/RFC1899",
  }

@misc{rfc1900,
  author="B. Carpenter and Y. Rekhter",
  title="{Renumbering Needs Work}",
  howpublished="RFC 1900 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1900",
  pages="1--4",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1900.txt",
  key="RFC 1900",
  abstract={Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols.  A change in such IP addressing information associated with a host or subnet is known as ``renumbering''.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, network, number, addressing",
  doi="10.17487/RFC1900",
  }

@misc{rfc1901,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Introduction to Community-based SNMPv2}",
  howpublished="RFC 1901 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1901",
  pages="1--8",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1901.txt",
  key="RFC 1901",
  abstract={The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2).  This document specifies an Experimental protocol for the Internet community.},
  keywords="SNMPV2CB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1901",
  }

@misc{rfc1902,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1902 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1902",
  pages="1--40",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2578",
url="https://www.rfc-editor.org/rfc/rfc1902.txt",
  key="RFC 1902",
  abstract={It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1902",
  }

@misc{rfc1903,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1903 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1903",
  pages="1--23",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2579",
url="https://www.rfc-editor.org/rfc/rfc1903.txt",
  key="RFC 1903",
  abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1903",
  }

@misc{rfc1904,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1904 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1904",
  pages="1--24",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2580",
url="https://www.rfc-editor.org/rfc/rfc1904.txt",
  key="RFC 1904",
  abstract={It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved.  It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1904",
  }

@misc{rfc1905,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1905 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1905",
  pages="1--24",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3416",
url="https://www.rfc-editor.org/rfc/rfc1905.txt",
  key="RFC 1905",
  abstract={It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]},
  keywords="OPS-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1905",
  }

@misc{rfc1906,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1906 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1906",
  pages="1--13",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3417",
url="https://www.rfc-editor.org/rfc/rfc1906.txt",
  key="RFC 1906",
  abstract={It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]},
  keywords="TRANS-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1906",
  }

@misc{rfc1907,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)}",
  howpublished="RFC 1907 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1907",
  pages="1--20",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3418",
url="https://www.rfc-editor.org/rfc/rfc1907.txt",
  key="RFC 1907",
  abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]},
  keywords="SNMPv2-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1907",
  }

@misc{rfc1908,
  author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser",
  title="{Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework}",
  howpublished="RFC 1908 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1908",
  pages="1--10",
  year=1996,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2576",
url="https://www.rfc-editor.org/rfc/rfc1908.txt",
  key="RFC 1908",
  abstract={The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]},
  keywords="COEX-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1908",
  }

@misc{rfc1909,
  author="K. McCloghrie",
  title="{An Administrative Infrastructure for SNMPv2}",
  howpublished="RFC 1909 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1909",
  pages="1--19",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1909.txt",
  key="RFC 1909",
  abstract={It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SNMPV2AI, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1909",
  }

@misc{rfc1910,
  author="G. Waters",
  title="{User-based Security Model for SNMPv2}",
  howpublished="RFC 1910 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1910",
  pages="1--44",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1910.txt",
  key="RFC 1910",
  abstract={In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions.  Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SNMPV2SM, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC1910",
  }

@misc{rfc1911,
  author="G. Vaudreuil",
  title="{Voice Profile for Internet Mail}",
  howpublished="RFC 1911 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1911",
  pages="1--22",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 2421, 2422, 2423",
url="https://www.rfc-editor.org/rfc/rfc1911.txt",
  key="RFC 1911",
  abstract={The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIME, Multipurpose, Internet, Mail, Extensions, ESMTP, SMTP, Service, Extensions",
  doi="10.17487/RFC1911",
  }

@misc{rfc1912,
  author="D. Barr",
  title="{Common DNS Operational and Configuration Errors}",
  howpublished="RFC 1912 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1912",
  pages="1--16",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1912.txt",
  key="RFC 1912",
  abstract={This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Domain, Name, System",
  doi="10.17487/RFC1912",
  }

@misc{rfc1913,
  author="C. Weider and J. Fullton and S. Spero",
  title="{Architecture of the Whois++ Index Service}",
  howpublished="RFC 1913 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1913",
  pages="1--16",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1913.txt",
  key="RFC 1913",
  abstract={The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]},
  keywords="WHOIS++A, Bunyip Information Systems, Inc., MCNC Center for Communications",
  doi="10.17487/RFC1913",
  }

@misc{rfc1914,
  author="P. Faltstrom and R. Schoultz and C. Weider",
  title="{How to Interact with a Whois++ Mesh}",
  howpublished="RFC 1914 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1914",
  pages="1--10",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1914.txt",
  key="RFC 1914",
  abstract={In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]},
  keywords="WHOIS++M, distributed, databases, directory, service",
  doi="10.17487/RFC1914",
  }

@misc{rfc1915,
  author="F. Kastenholz",
  title="{Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol}",
  howpublished="RFC 1915 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="1915",
  pages="1--7",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1915.txt",
  key="RFC 1915",
  abstract={The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt.  The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Point, to, Point, Protocol",
  doi="10.17487/RFC1915",
  }

@misc{rfc1916,
  author="H. Berkowitz and P. Ferguson and W. Leland and P. Nesser",
  title="{Enterprise Renumbering: Experience and Information Solicitation}",
  howpublished="RFC 1916 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1916",
  pages="1--8",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1916.txt",
  key="RFC 1916",
  abstract={Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts.  The intent of these documents is to provide both educational and practical information to the Internet community.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="tools, applications",
  doi="10.17487/RFC1916",
  }

@misc{rfc1917,
  author="P. Nesser II",
  title="{An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA}",
  howpublished="RFC 1917 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="1917",
  pages="1--10",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1917.txt",
  key="RFC 1917",
  abstract={This document is an appeal to the Internet community to return unused address space, i.e.  any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="address, space, Internet, Assigned, Numbers, Authority, IANA",
  doi="10.17487/RFC1917",
  }

@misc{rfc1918,
  author="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. J. de Groot and E. Lear",
  title="{Address Allocation for Private Internets}",
  howpublished="RFC 1918 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="1918",
  pages="1--9",
  year=1996,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6761",
url="https://www.rfc-editor.org/rfc/rfc1918.txt",
  key="RFC 1918",
  abstract={This document describes address allocation for private internets.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="TCP/IP, network, host",
  doi="10.17487/RFC1918",
  }

@misc{rfc1919,
  author="M. Chatel",
  title="{Classical versus Transparent IP Proxies}",
  howpublished="RFC 1919 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1919",
  pages="1--35",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1919.txt",
  key="RFC 1919",
  abstract={This document explains ``classical'' and ``transparent'' proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="firewalls, security",
  doi="10.17487/RFC1919",
  }

@misc{rfc1920,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 1920 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1920",
  pages="1--40",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2000",
url="https://www.rfc-editor.org/rfc/rfc1920.txt",
  key="RFC 1920",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]},
  keywords="status, procedure, index",
  doi="10.17487/RFC1920",
  }

@misc{rfc1921,
  author="J. Dujonc",
  title="{TNVIP Protocol}",
  howpublished="RFC 1921 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1921",
  pages="1--30",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1921.txt",
  key="RFC 1921",
  abstract={The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC1921",
  }

@misc{rfc1922,
  author="HF. Zhu and DY. Hu and ZG. Wang and TC. Kao and WCH. Chang and M. Crispin",
  title="{Chinese Character Encoding for Internet Messages}",
  howpublished="RFC 1922 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1922",
  pages="1--27",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1922.txt",
  key="RFC 1922",
  abstract={This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866].  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="transport, electronic, mail, telnet, WWW",
  doi="10.17487/RFC1922",
  }

@misc{rfc1923,
  author="J. Halpern and S. Bradner",
  title="{RIPv1 Applicability Statement for Historic Status}",
  howpublished="RFC 1923 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1923",
  pages="1--3",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1923.txt",
  key="RFC 1923",
  abstract={RIP Version 1 [RFC-1058] has been declared an historic document.  This Applicability statement provides the supporting motivation for that declaration.  The primary reason, as described below, is the Classful nature of RIPv1.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Routing, Information, Protocol",
  doi="10.17487/RFC1923",
  }

@misc{rfc1924,
  author="R. Elz",
  title="{A Compact Representation of IPv6 Addresses}",
  howpublished="RFC 1924 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1924",
  pages="1--6",
  year=1996,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1924.txt",
  key="RFC 1924",
  abstract={This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="encoding",
  doi="10.17487/RFC1924",
  }

@misc{rfc1925,
  author="R. Callon",
  title="{The Twelve Networking Truths}",
  howpublished="RFC 1925 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1925",
  pages="1--3",
  year=1996,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1925.txt",
  key="RFC 1925",
  abstract={This memo documents the fundamental truths of networking for the Internet community.  This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="fundamentals",
  doi="10.17487/RFC1925",
  }

@misc{rfc1926,
  author="J. Eriksson",
  title="{An Experimental Encapsulation of IP Datagrams on Top of ATM}",
  howpublished="RFC 1926 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1926",
  pages="1--2",
  year=1996,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1926.txt",
  key="RFC 1926",
  abstract={This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM).  This is a non-recommended standard.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Acoustical, Transmission, Media (ATM)",
  doi="10.17487/RFC1926",
  }

@misc{rfc1927,
  author="C. Rogers",
  title="{Suggested Additional MIME Types for Associating Documents}",
  howpublished="RFC 1927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1927",
  pages="1--3",
  year=1996,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1927.txt",
  key="RFC 1927",
  abstract={Seven new types of MIME types are suggested in this document.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="media-type",
  doi="10.17487/RFC1927",
  }

@misc{rfc1928,
  author="M. Leech and M. Ganis and Y. Lee and R. Kuris and D. Koblas and L. Jones",
  title="{SOCKS Protocol Version 5}",
  howpublished="RFC 1928 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1928",
  pages="1--9",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1928.txt",
  key="RFC 1928",
  abstract={This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1].  This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]},
  keywords="SOCKSV5, firewalls, authentication",
  doi="10.17487/RFC1928",
  }

@misc{rfc1929,
  author="M. Leech",
  title="{Username/Password Authentication for SOCKS V5}",
  howpublished="RFC 1929 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1929",
  pages="1--2",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1929.txt",
  key="RFC 1929",
  abstract={The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup.  This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication ``subnegotiation''. [STANDARDS-TRACK]},
  keywords="AUTH-SOCKS, firewalls, authentication",
  doi="10.17487/RFC1929",
  }

@misc{rfc1930,
  author="J. Hawkinson and T. Bates",
  title="{Guidelines for creation, selection, and registration of an Autonomous System (AS)}",
  howpublished="RFC 1930 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="1930",
  pages="1--10",
  year=1996,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6996, 7300",
url="https://www.rfc-editor.org/rfc/rfc1930.txt",
  key="RFC 1930",
  abstract={This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="routing, policy, Exterior, Gateway, Protocol, Border, Inter-Domain, Domain, Identifier, EGP, BGP, IDRP",
  doi="10.17487/RFC1930",
  }

@misc{rfc1931,
  author="D. Brownell",
  title="{Dynamic RARP Extensions for Automatic Network Address Acquisition}",
  howpublished="RFC 1931 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1931",
  pages="1--11",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1931.txt",
  key="RFC 1931",
  abstract={This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP).  This memo provides information for the Internet community.  This memo does not define an Internet standard of any kind.},
  keywords="Reverse, Address, Resolution, Protocol",
  doi="10.17487/RFC1931",
  }

@misc{rfc1932,
  author="R. Cole and D. Shur and C. Villamizar",
  title="{IP over ATM: A Framework Document}",
  howpublished="RFC 1932 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1932",
  pages="1--31",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1932.txt",
  key="RFC 1932",
  abstract={It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="end-to-end, connectivity",
  doi="10.17487/RFC1932",
  }

@misc{rfc1933,
  author="R. Gilligan and E. Nordmark",
  title="{Transition Mechanisms for IPv6 Hosts and Routers}",
  howpublished="RFC 1933 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1933",
  pages="1--22",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2893",
url="https://www.rfc-editor.org/rfc/rfc1933.txt",
  key="RFC 1933",
  abstract={This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]},
  keywords="TRANS-IPV6, IPv4",
  doi="10.17487/RFC1933",
  }

@misc{rfc1934,
  author="K. Smith",
  title="{Ascend's Multilink Protocol Plus (MP+)}",
  howpublished="RFC 1934 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1934",
  pages="1--47",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1934.txt",
  key="RFC 1934",
  abstract={This document proposes an extension to the PPP Multilink Protocol (MP) [1].  Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP",
  doi="10.17487/RFC1934",
  }

@misc{rfc1935,
  author="J. Quarterman and S. Carl-Mitchell",
  title="{What is the Internet, Anyway?}",
  howpublished="RFC 1935 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1935",
  pages="1--11",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1935.txt",
  key="RFC 1935",
  abstract={This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="information, tutorial",
  doi="10.17487/RFC1935",
  }

@misc{rfc1936,
  author="J. Touch and B. Parham",
  title="{Implementing the Internet Checksum in Hardware}",
  howpublished="RFC 1936 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1936",
  pages="1--21",
  year=1996,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1936.txt",
  key="RFC 1936",
  abstract={This memo presents a techniques for efficiently implementing the Internet Checksum in hardware.  It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PLD, code, UDP, TCP",
  doi="10.17487/RFC1936",
  }

@misc{rfc1937,
  author="Y. Rekhter and D. Kandlur",
  title="{``Local/Remote'' Forwarding Decision in Switched Data Link Subnetworks}",
  howpublished="RFC 1937 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1937",
  pages="1--8",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1937.txt",
  key="RFC 1937",
  abstract={This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, subnet",
  doi="10.17487/RFC1937",
  }

@misc{rfc1938,
  author="N. Haller and C. Metz",
  title="{A One-Time Password System}",
  howpublished="RFC 1938 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1938",
  pages="1--18",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2289",
url="https://www.rfc-editor.org/rfc/rfc1938.txt",
  key="RFC 1938",
  abstract={This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]},
  keywords="OTP, authentication, S/KEY",
  doi="10.17487/RFC1938",
  }

@misc{rfc1939,
  author="J. Myers and M. Rose",
  title="{Post Office Protocol - Version 3}",
  howpublished="RFC 1939 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1939",
  pages="1--23",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 1957, 2449, 6186",
url="https://www.rfc-editor.org/rfc/rfc1939.txt",
  key="RFC 1939",
  abstract={The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]},
  keywords="POP3, POP3",
  doi="10.17487/RFC1939",
  }

@misc{rfc1940,
  author="D. Estrin and T. Li and Y. Rekhter and K. Varadhan and D. Zappala",
  title="{Source Demand Routing: Packet Format and Forwarding Specification (Version 1)}",
  howpublished="RFC 1940 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1940",
  pages="1--27",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1940.txt",
  key="RFC 1940",
  abstract={The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="SDRP",
  doi="10.17487/RFC1940",
  }

@misc{rfc1941,
  author="J. Sellers and J. Robichaux",
  title="{Frequently Asked Questions for Schools}",
  howpublished="RFC 1941 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1941",
  pages="1--70",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1941.txt",
  key="RFC 1941",
  abstract={The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="FAQ, Internet, Education",
  doi="10.17487/RFC1941",
  }

@misc{rfc1942,
  author="D. Raggett",
  title="{HTML Tables}",
  howpublished="RFC 1942 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1942",
  pages="1--30",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2854",
url="https://www.rfc-editor.org/rfc/rfc1942.txt",
  key="RFC 1942",
  abstract={This specification extends HTML to support a wide variety of tables.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="HTML-TBL, HyperText, Markup, Language, SGML",
  doi="10.17487/RFC1942",
  }

@misc{rfc1943,
  author="B. Jennings",
  title="{Building an X.500 Directory Service in the US}",
  howpublished="RFC 1943 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1943",
  pages="1--22",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1943.txt",
  key="RFC 1943",
  abstract={This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="White, Pages",
  doi="10.17487/RFC1943",
  }

@misc{rfc1944,
  author="S. Bradner and J. McQuaid",
  title="{Benchmarking Methodology for Network Interconnect Devices}",
  howpublished="RFC 1944 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1944",
  pages="1--30",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2544",
url="https://www.rfc-editor.org/rfc/rfc1944.txt",
  key="RFC 1944",
  abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="testing, performance",
  doi="10.17487/RFC1944",
  }

@misc{rfc1945,
  author="T. Berners-Lee and R. Fielding and H. Frystyk",
  title="{Hypertext Transfer Protocol -- HTTP/1.0}",
  howpublished="RFC 1945 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1945",
  pages="1--60",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1945.txt",
  key="RFC 1945",
  abstract={The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="HTTP-1.0, HTTP, World-Wide, Web, application",
  doi="10.17487/RFC1945",
  }

@misc{rfc1946,
  author="S. Jackowski",
  title="{Native ATM Support for ST2+}",
  howpublished="RFC 1946 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1946",
  pages="1--21",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1946.txt",
  key="RFC 1946",
  abstract={This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="integrated, services, ATM, Quality, of, Service, QoS",
  doi="10.17487/RFC1946",
  }

@misc{rfc1947,
  author="D. Spinellis",
  title="{Greek Character Encoding for Electronic Mail Messages}",
  howpublished="RFC 1947 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1947",
  pages="1--7",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1947.txt",
  key="RFC 1947",
  abstract={This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="character, set, ISO, MIME",
  doi="10.17487/RFC1947",
  }

@misc{rfc1948,
  author="S. Bellovin",
  title="{Defending Against Sequence Number Attacks}",
  howpublished="RFC 1948 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1948",
  pages="1--6",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6528",
url="https://www.rfc-editor.org/rfc/rfc1948.txt",
  key="RFC 1948",
  abstract={IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01).  While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="crypgraphic, authentication, spoofing",
  doi="10.17487/RFC1948",
  }

@misc{rfc1949,
  author="A. Ballardie",
  title="{Scalable Multicast Key Distribution}",
  howpublished="RFC 1949 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1949",
  pages="1--18",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1949.txt",
  key="RFC 1949",
  abstract={This memo provides a scalable solution to the multicast key distribution problem.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SMKD, MBONE, security, authentication",
  doi="10.17487/RFC1949",
  }

@misc{rfc1950,
  author="P. Deutsch and J-L. Gailly",
  title="{ZLIB Compressed Data Format Specification version 3.3}",
  howpublished="RFC 1950 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1950",
  pages="1--11",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1950.txt",
  key="RFC 1950",
  abstract={This specification defines a lossless compressed data format.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ZLIB, compressed, data, format, checksum",
  doi="10.17487/RFC1950",
  }

@misc{rfc1951,
  author="P. Deutsch",
  title="{DEFLATE Compressed Data Format Specification version 1.3}",
  howpublished="RFC 1951 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1951",
  pages="1--17",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1951.txt",
  key="RFC 1951",
  abstract={This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DEFLATE, compressed, data, format, coding",
  doi="10.17487/RFC1951",
  }

@misc{rfc1952,
  author="P. Deutsch",
  title="{GZIP file format specification version 4.3}",
  howpublished="RFC 1952 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1952",
  pages="1--12",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1952.txt",
  key="RFC 1952",
  abstract={This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GZIP, compressed, data, format, redundancy, check",
  doi="10.17487/RFC1952",
  }

@misc{rfc1953,
  author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall",
  title="{Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0}",
  howpublished="RFC 1953 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1953",
  pages="1--20",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1953.txt",
  key="RFC 1953",
  abstract={The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow.  This document provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IFMP, IP, flow, routing, information",
  doi="10.17487/RFC1953",
  }

@misc{rfc1954,
  author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall",
  title="{Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0}",
  howpublished="RFC 1954 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1954",
  pages="1--8",
  year=1996,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1954.txt",
  key="RFC 1954",
  abstract={This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP].  This document provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="datagrams, IFMP",
  doi="10.17487/RFC1954",
  }

@misc{rfc1955,
  author="R. Hinden",
  title="{New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG}",
  howpublished="RFC 1955 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1955",
  pages="1--5",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1955.txt",
  key="RFC 1955",
  abstract={This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPNG, addressing, routing",
  doi="10.17487/RFC1955",
  }

@misc{rfc1956,
  author="D. Engebretson and R. Plzak",
  title="{Registration in the MIL Domain}",
  howpublished="RFC 1956 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1956",
  pages="1--2",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1956.txt",
  key="RFC 1956",
  abstract={This RFC describes the policy for the registration of second level domains under the ``.MIL'' domain.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DoD, Department, of, Defense",
  doi="10.17487/RFC1956",
  }

@misc{rfc1957,
  author="R. Nelson",
  title="{Some Observations on Implementations of the Post Office Protocol (POP3)}",
  howpublished="RFC 1957 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1957",
  pages="1--2",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1957.txt",
  key="RFC 1957",
  abstract={This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="client, server",
  doi="10.17487/RFC1957",
  }

@misc{rfc1958,
  author="B. Carpenter",
  title="{Architectural Principles of the Internet}",
  howpublished="RFC 1958 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1958",
  pages="1--8",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3439",
url="https://www.rfc-editor.org/rfc/rfc1958.txt",
  key="RFC 1958",
  abstract={The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan.  While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture.  This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IAB",
  doi="10.17487/RFC1958",
  }

@misc{rfc1959,
  author="T. Howes and M. Smith",
  title="{An LDAP URL Format}",
  howpublished="RFC 1959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1959",
  pages="1--4",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2255",
url="https://www.rfc-editor.org/rfc/rfc1959.txt",
  key="RFC 1959",
  abstract={This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]},
  keywords="LDAP-URL, Lightweight, Directory, Access, Protocol, Uniform, Resource, Locator",
  doi="10.17487/RFC1959",
  }

@misc{rfc1960,
  author="T. Howes",
  title="{A String Representation of LDAP Search Filters}",
  howpublished="RFC 1960 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1960",
  pages="1--3",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2254",
url="https://www.rfc-editor.org/rfc/rfc1960.txt",
  key="RFC 1960",
  abstract={The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server.  Some applications may find it useful to have a common way of representing these search filters in a human-readable form.  This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]},
  keywords="LDAP-STR, Lightweight, Directory, Access, Protocol",
  doi="10.17487/RFC1960",
  }

@misc{rfc1961,
  author="P. McMahon",
  title="{GSS-API Authentication Method for SOCKS Version 5}",
  howpublished="RFC 1961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1961",
  pages="1--9",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1961.txt",
  key="RFC 1961",
  abstract={This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]},
  keywords="GSSAPI-SOC, Generic, Security, Service, Application, Program, Interface",
  doi="10.17487/RFC1961",
  }

@misc{rfc1962,
  author="D. Rand",
  title="{The PPP Compression Control Protocol (CCP)}",
  howpublished="RFC 1962 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1962",
  pages="1--9",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2153",
url="https://www.rfc-editor.org/rfc/rfc1962.txt",
  key="RFC 1962",
  abstract={This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]},
  keywords="PPP-CCP, point-to-point, protocol, data, links",
  doi="10.17487/RFC1962",
  }

@misc{rfc1963,
  author="K. Schneider and S. Venters",
  title="{PPP Serial Data Transport Protocol (SDTP)}",
  howpublished="RFC 1963 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1963",
  pages="1--20",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1963.txt",
  key="RFC 1963",
  abstract={This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Point-to-Point, Protocol",
  doi="10.17487/RFC1963",
  }

@misc{rfc1964,
  author="J. Linn",
  title="{The Kerberos Version 5 GSS-API Mechanism}",
  howpublished="RFC 1964 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1964",
  pages="1--20",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4121, 6649",
url="https://www.rfc-editor.org/rfc/rfc1964.txt",
  key="RFC 1964",
  abstract={This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]},
  keywords="GSSAPI-KER, Generic, Security, Service, Application, Program, Interface",
  doi="10.17487/RFC1964",
  }

@misc{rfc1965,
  author="P. Traina",
  title="{Autonomous System Confederations for BGP}",
  howpublished="RFC 1965 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1965",
  pages="1--7",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3065",
url="https://www.rfc-editor.org/rfc/rfc1965.txt",
  key="RFC 1965",
  abstract={This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="BGP-ASC, Border, Gateway, Protocol",
  doi="10.17487/RFC1965",
  }

@misc{rfc1966,
  author="T. Bates and R. Chandra",
  title="{BGP Route Reflection An alternative to full mesh IBGP}",
  howpublished="RFC 1966 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1966",
  pages="1--7",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4456, updated by RFC 2796",
url="https://www.rfc-editor.org/rfc/rfc1966.txt",
  key="RFC 1966",
  abstract={This document describes the use and design of a method known as ``Route Reflection'' to alleviate the the need for ``full mesh'' IBGP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="BGP-RR, Border, Gateway, Protocol, autonomous, system",
  doi="10.17487/RFC1966",
  }

@misc{rfc1967,
  author="K. Schneider and R. Friend",
  title="{PPP LZS-DCP Compression Protocol (LZS-DCP)}",
  howpublished="RFC 1967 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1967",
  pages="1--18",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1967.txt",
  key="RFC 1967",
  abstract={This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6].  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Point-to-Point, Protocol, Compression, Control, CCP",
  doi="10.17487/RFC1967",
  }

@misc{rfc1968,
  author="G. Meyer",
  title="{The PPP Encryption Control Protocol (ECP)}",
  howpublished="RFC 1968 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1968",
  pages="1--11",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1968.txt",
  key="RFC 1968",
  abstract={This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]},
  keywords="PPP-ECP, Point-to-Point, Protocol, data",
  doi="10.17487/RFC1968",
  }

@misc{rfc1969,
  author="K. Sklower and G. Meyer",
  title="{The PPP DES Encryption Protocol (DESE)}",
  howpublished="RFC 1969 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1969",
  pages="1--10",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2419",
url="https://www.rfc-editor.org/rfc/rfc1969.txt",
  key="RFC 1969",
  abstract={This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Point-to-Point, Protocol, encapsulated, packets",
  doi="10.17487/RFC1969",
  }

@misc{rfc1970,
  author="T. Narten and E. Nordmark and W. Simpson",
  title="{Neighbor Discovery for IP Version 6 (IPv6)}",
  howpublished="RFC 1970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1970",
  pages="1--82",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2461",
url="https://www.rfc-editor.org/rfc/rfc1970.txt",
  key="RFC 1970",
  abstract={This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]},
  keywords="Internet, Protocol",
  doi="10.17487/RFC1970",
  }

@misc{rfc1971,
  author="S. Thomson and T. Narten",
  title="{IPv6 Stateless Address Autoconfiguration}",
  howpublished="RFC 1971 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1971",
  pages="1--23",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2462",
url="https://www.rfc-editor.org/rfc/rfc1971.txt",
  key="RFC 1971",
  abstract={This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]},
  keywords="Internet, Protocol, link-local, address, Duplicate, Address, Detection, procedure",
  doi="10.17487/RFC1971",
  }

@misc{rfc1972,
  author="M. Crawford",
  title="{A Method for the Transmission of IPv6 Packets over Ethernet Networks}",
  howpublished="RFC 1972 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1972",
  pages="1--4",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2464",
url="https://www.rfc-editor.org/rfc/rfc1972.txt",
  key="RFC 1972",
  abstract={This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]},
  keywords="IPV6-ETHER, Internet, Protocol, frame, format, transmission",
  doi="10.17487/RFC1972",
  }

@misc{rfc1973,
  author="W. Simpson",
  title="{PPP in Frame Relay}",
  howpublished="RFC 1973 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1973",
  pages="1--10",
  year=1996,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1973.txt",
  key="RFC 1973",
  abstract={This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="PPP-FRAME, Point-to-Point, Protocol, encapsulated, packets",
  doi="10.17487/RFC1973",
  }

@misc{rfc1974,
  author="R. Friend and W. Simpson",
  title="{PPP Stac LZS Compression Protocol}",
  howpublished="RFC 1974 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1974",
  pages="1--20",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1974.txt",
  key="RFC 1974",
  abstract={This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-STAC, Point-to-Point, Protocol, Compression, Control, CCP",
  doi="10.17487/RFC1974",
  }

@misc{rfc1975,
  author="D. Schremp and J. Black and J. Weiss",
  title="{PPP Magnalink Variable Resource Compression}",
  howpublished="RFC 1975 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1975",
  pages="1--6",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1975.txt",
  key="RFC 1975",
  abstract={The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-MAG, Point-to-Point, Protocol, MVRCA",
  doi="10.17487/RFC1975",
  }

@misc{rfc1976,
  author="K. Schneider and S. Venters",
  title="{PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)}",
  howpublished="RFC 1976 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1976",
  pages="1--10",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1976.txt",
  key="RFC 1976",
  abstract={This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-DCE, Point-to-Point, Protocol, LCP, extension",
  doi="10.17487/RFC1976",
  }

@misc{rfc1977,
  author="V. Schryver",
  title="{PPP BSD Compression Protocol}",
  howpublished="RFC 1977 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1977",
  pages="1--25",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1977.txt",
  key="RFC 1977",
  abstract={This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-BSD, Point-to-Point, Protocol, Unix, Compress",
  doi="10.17487/RFC1977",
  }

@misc{rfc1978,
  author="D. Rand",
  title="{PPP Predictor Compression Protocol}",
  howpublished="RFC 1978 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1978",
  pages="1--9",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1978.txt",
  key="RFC 1978",
  abstract={This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-PRED, Point-to-Point, Protocol",
  doi="10.17487/RFC1978",
  }

@misc{rfc1979,
  author="J. Woods",
  title="{PPP Deflate Protocol}",
  howpublished="RFC 1979 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1979",
  pages="1--10",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1979.txt",
  key="RFC 1979",
  abstract={This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PPP-DEFL, Point-to-Point, Protocol, Compression, Control",
  doi="10.17487/RFC1979",
  }

@misc{rfc1980,
  author="J. Seidman",
  title="{A Proposed Extension to HTML : Client-Side Image Maps}",
  howpublished="RFC 1980 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="1980",
  pages="1--7",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2854",
url="https://www.rfc-editor.org/rfc/rfc1980.txt",
  key="RFC 1980",
  abstract={The markup language known as ``HTML/2.0'' provides for image maps.  Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs).  The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the ``HTTP'' protocol, and the lack of a viable fallback for users of text-only browsers.  This document specifies an extension to the HTML language, referred to as ``Client- Side Image Maps,'' which resolves these limitations.},
  keywords="HyperText, Markup, Language, Uniform, Identifier, URI",
  doi="10.17487/RFC1980",
  }

@misc{rfc1981,
  author="J. McCann and S. Deering and J. Mogul",
  title="{Path MTU Discovery for IP version 6}",
  howpublished="RFC 1981 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1981",
  pages="1--15",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1981.txt",
  key="RFC 1981",
  abstract={This document describes Path MTU Discovery for IP version 6.  It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]},
  keywords="MTU-IPV6, Internet, Protocol",
  doi="10.17487/RFC1981",
  }

@misc{rfc1982,
  author="R. Elz and R. Bush",
  title="{Serial Number Arithmetic}",
  howpublished="RFC 1982 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1982",
  pages="1--6",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1982.txt",
  key="RFC 1982",
  abstract={The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood.  This memo supplies the missing definition.  It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]},
  keywords="SNA, domain, name, system, DNS",
  doi="10.17487/RFC1982",
  }

@misc{rfc1983,
  author="G. Malkin",
  title="{Internet Users' Glossary}",
  howpublished="RFC 1983 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1983",
  pages="1--62",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1983.txt",
  key="RFC 1983",
  abstract={There are many networking glossaries in existence.  This glossary concentrates on terms which are specific to the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="basic, terms, acronyms",
  doi="10.17487/RFC1983",
  }

@misc{rfc1984,
  author="IAB and IESG",
  title="{IAB and IESG Statement on Cryptographic Technology and the Internet}",
  howpublished="RFC 1984 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="1984",
  pages="1--5",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1984.txt",
  key="RFC 1984",
  abstract={The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="security, privacy",
  doi="10.17487/RFC1984",
  }

@misc{rfc1985,
  author="J. De Winter",
  title="{SMTP Service Extension for Remote Message Queue Starting}",
  howpublished="RFC 1985 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1985",
  pages="1--7",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1985.txt",
  key="RFC 1985",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]},
  keywords="SMTP-ETRN, Simple, ETRN, Mail, Transfer, Protocol",
  doi="10.17487/RFC1985",
  }

@misc{rfc1986,
  author="W. Polites and W. Wollman and D. Woo and R. Langan",
  title="{Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)}",
  howpublished="RFC 1986 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="1986",
  pages="1--21",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1986.txt",
  key="RFC 1986",
  abstract={This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP).  This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ETFTP, TFTP, NETBLT",
  doi="10.17487/RFC1986",
  }

@misc{rfc1987,
  author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall",
  title="{Ipsilon's General Switch Management Protocol Specification Version 1.1}",
  howpublished="RFC 1987 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1987",
  pages="1--44",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2297",
url="https://www.rfc-editor.org/rfc/rfc1987.txt",
  key="RFC 1987",
  abstract={The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch.  GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="GSMP, ATM, switch",
  doi="10.17487/RFC1987",
  }

@misc{rfc1988,
  author="G. McAnally and D. Gilbert and J. Flick",
  title="{Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework}",
  howpublished="RFC 1988 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1988",
  pages="1--2",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1988.txt",
  key="RFC 1988",
  abstract={This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="HP",
  doi="10.17487/RFC1988",
  }

@misc{rfc1989,
  author="W. Simpson",
  title="{PPP Link Quality Monitoring}",
  howpublished="RFC 1989 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1989",
  pages="1--16",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1989.txt",
  key="RFC 1989",
  abstract={This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]},
  keywords="PPP-LINK, Point-to-Point, Protocol",
  doi="10.17487/RFC1989",
  }

@misc{rfc1990,
  author="K. Sklower and B. Lloyd and G. McGregor and D. Carr and T. Coradetti",
  title="{The PPP Multilink Protocol (MP)}",
  howpublished="RFC 1990 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1990",
  pages="1--24",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1990.txt",
  key="RFC 1990",
  abstract={This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]},
  keywords="PPP-MP, Point-to-Point, Protocol, datagrams",
  doi="10.17487/RFC1990",
  }

@misc{rfc1991,
  author="D. Atkins and W. Stallings and P. Zimmermann",
  title="{PGP Message Exchange Formats}",
  howpublished="RFC 1991 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1991",
  pages="1--21",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4880",
url="https://www.rfc-editor.org/rfc/rfc1991.txt",
  key="RFC 1991",
  abstract={This document describes the format of ``PGP files'', i.e., messages that have been encrypted and/or signed with PGP.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PGP-MEF, Pretty, Good, Privacy, encryption, electronic, mail",
  doi="10.17487/RFC1991",
  }

@misc{rfc1992,
  author="I. Castineyra and N. Chiappa and M. Steenstrup",
  title="{The Nimrod Routing Architecture}",
  howpublished="RFC 1992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1992",
  pages="1--27",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1992.txt",
  key="RFC 1992",
  abstract={Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork.  First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF.  In this document, we present a detailed description of this architecture.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="scalable, internetwork",
  doi="10.17487/RFC1992",
  }

@misc{rfc1993,
  author="A. Barbir and D. Carr and W. Simpson",
  title="{PPP Gandalf FZA Compression Protocol}",
  howpublished="RFC 1993 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1993",
  pages="1--7",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1993.txt",
  key="RFC 1993",
  abstract={This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  keywords="Point-to-Point, Protocol",
  doi="10.17487/RFC1993",
  }

@misc{rfc1994,
  author="W. Simpson",
  title="{PPP Challenge Handshake Authentication Protocol (CHAP)}",
  howpublished="RFC 1994 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1994",
  pages="1--13",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2484",
url="https://www.rfc-editor.org/rfc/rfc1994.txt",
  key="RFC 1994",
  abstract={This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]},
  keywords="PPP-CHAP, Point-to-Point, Protocol, cryptology",
  doi="10.17487/RFC1994",
  }

@misc{rfc1995,
  author="M. Ohta",
  title="{Incremental Zone Transfer in DNS}",
  howpublished="RFC 1995 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1995",
  pages="1--8",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1995.txt",
  key="RFC 1995",
  abstract={This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]},
  keywords="DNS-IZT, Domain, Name, System, IXFR",
  doi="10.17487/RFC1995",
  }

@misc{rfc1996,
  author="P. Vixie",
  title="{A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)}",
  howpublished="RFC 1996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1996",
  pages="1--7",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1996.txt",
  key="RFC 1996",
  abstract={This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]},
  keywords="DNS-NOTIFY, Domain, Name, System",
  doi="10.17487/RFC1996",
  }

@misc{rfc1997,
  author="R. Chandra and P. Traina and T. Li",
  title="{BGP Communities Attribute}",
  howpublished="RFC 1997 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="1997",
  pages="1--5",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7606",
url="https://www.rfc-editor.org/rfc/rfc1997.txt",
  key="RFC 1997",
  abstract={This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]},
  keywords="BGP-COMM, Border, Gateway, Protocol",
  doi="10.17487/RFC1997",
  }

@misc{rfc1998,
  author="E. Chen and T. Bates",
  title="{An Application of the BGP Community Attribute in Multi-home Routing}",
  howpublished="RFC 1998 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1998",
  pages="1--9",
  year=1996,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1998.txt",
  key="RFC 1998",
  abstract={This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Border, Gateway, Protocol",
  doi="10.17487/RFC1998",
  }

@misc{rfc1999,
  author="J. Elliott",
  title="{Request for Comments Summary RFC Numbers 1900-1999}",
  howpublished="RFC 1999 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1999",
  pages="1--20",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1999.txt",
  key="RFC 1999",
  keywords="Index",
  doi="10.17487/RFC1999",
  }

@misc{rfc2000,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2000 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2000",
  pages="1--56",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2200",
url="https://www.rfc-editor.org/rfc/rfc2000.txt",
  key="RFC 2000",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).  This memo is an Internet Standard.},
  keywords="status, procedure, index",
  doi="10.17487/RFC2000",
  }

@misc{rfc2001,
  author="W. Stevens",
  title="{TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms}",
  howpublished="RFC 2001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2001",
  pages="1--6",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2581",
url="https://www.rfc-editor.org/rfc/rfc2001.txt",
  key="RFC 2001",
  abstract={Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]},
  keywords="TCPSLOWSRT, Transmission, Control, Protocol",
  doi="10.17487/RFC2001",
  }

@misc{rfc2002,
  author="C. Perkins",
  title="{IP Mobility Support}",
  howpublished="RFC 2002 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2002",
  pages="1--79",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3220, updated by RFC 2290",
url="https://www.rfc-editor.org/rfc/rfc2002.txt",
  key="RFC 2002",
  abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]},
  keywords="MOBILEIPSUPIP, Internet, Protocol",
  doi="10.17487/RFC2002",
  }

@misc{rfc2003,
  author="C. Perkins",
  title="{IP Encapsulation within IP}",
  howpublished="RFC 2003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2003",
  pages="1--14",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3168, 6864",
url="https://www.rfc-editor.org/rfc/rfc2003.txt",
  key="RFC 2003",
  abstract={This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]},
  keywords="IPENCAPIP, Internet, Protocol",
  doi="10.17487/RFC2003",
  }

@misc{rfc2004,
  author="C. Perkins",
  title="{Minimal Encapsulation within IP}",
  howpublished="RFC 2004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2004",
  pages="1--6",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2004.txt",
  key="RFC 2004",
  abstract={This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than ``conventional'' IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]},
  keywords="MINI-IP, Internet, Protocol",
  doi="10.17487/RFC2004",
  }

@misc{rfc2005,
  author="J. Solomon",
  title="{Applicability Statement for IP Mobility Support}",
  howpublished="RFC 2005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2005",
  pages="1--5",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2005.txt",
  key="RFC 2005",
  abstract={As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet.  In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]},
  keywords="Internet, Protocol",
  doi="10.17487/RFC2005",
  }

@misc{rfc2006,
  author="D. Cong and M. Hamlen and C. Perkins",
  title="{The Definitions of Managed Objects for IP Mobility Support using SMIv2}",
  howpublished="RFC 2006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2006",
  pages="1--52",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2006.txt",
  key="RFC 2006",
  abstract={This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]},
  keywords="MOBILEIPMIB, Mobile, Internet, Protocol, MIB, Managed, Information, Base",
  doi="10.17487/RFC2006",
  }

@misc{rfc2007,
  author="J. Foster and M. Isaacs and M. Prior",
  title="{Catalogue of Network Training Materials}",
  howpublished="RFC 2007 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2007",
  pages="1--55",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2007.txt",
  key="RFC 2007",
  abstract={The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="TRAINMAT, IETF, TERENA",
  doi="10.17487/RFC2007",
  }

@misc{rfc2008,
  author="Y. Rekhter and T. Li",
  title="{Implications of Various Address Allocation Policies for Internet Routing}",
  howpublished="RFC 2008 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2008",
  pages="1--13",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2008.txt",
  key="RFC 2008",
  abstract={The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="IP, unicast",
  doi="10.17487/RFC2008",
  }

@misc{rfc2009,
  author="T. Imielinski and J. Navas",
  title="{GPS-Based Addressing and Routing}",
  howpublished="RFC 2009 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2009",
  pages="1--27",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2009.txt",
  key="RFC 2009",
  abstract={This document describes a possible experiment with geographic addresses.  It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="GPS-AR, domain, names, geographic",
  doi="10.17487/RFC2009",
  }

@misc{rfc2010,
  author="B. Manning and P. Vixie",
  title="{Operational Criteria for Root Name Servers}",
  howpublished="RFC 2010 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2010",
  pages="1--7",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2870",
url="https://www.rfc-editor.org/rfc/rfc2010.txt",
  key="RFC 2010",
  abstract={This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="host, hardware",
  doi="10.17487/RFC2010",
  }

@misc{rfc2011,
  author="K. McCloghrie",
  title="{SNMPv2 Management Information Base for the Internet Protocol using SMIv2}",
  howpublished="RFC 2011 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2011",
  pages="1--18",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4293",
url="https://www.rfc-editor.org/rfc/rfc2011.txt",
  key="RFC 2011",
  abstract={This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]},
  keywords="MIB-IP, IP, Simple, Network, Management, Protocol, MIB",
  doi="10.17487/RFC2011",
  }

@misc{rfc2012,
  author="K. McCloghrie",
  title="{SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2}",
  howpublished="RFC 2012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2012",
  pages="1--10",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4022",
url="https://www.rfc-editor.org/rfc/rfc2012.txt",
  key="RFC 2012",
  abstract={This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]},
  keywords="MIB-TCP, TCP, Simple, Network, Management, Protocol, MIB",
  doi="10.17487/RFC2012",
  }

@misc{rfc2013,
  author="K. McCloghrie",
  title="{SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2}",
  howpublished="RFC 2013 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2013",
  pages="1--6",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4113",
url="https://www.rfc-editor.org/rfc/rfc2013.txt",
  key="RFC 2013",
  abstract={This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]},
  keywords="MIB-UDP], Simple, Network, Management, Protocol, MIB, UDP",
  doi="10.17487/RFC2013",
  }

@misc{rfc2014,
  author="A. Weinrib and J. Postel",
  title="{IRTF Research Group Guidelines and Procedures}",
  howpublished="RFC 2014 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2014",
  pages="1--13",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2014.txt",
  key="RFC 2014",
  abstract={This document describes the guidelines and procedures for formation and operation of IRTF Research Groups.  It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Research, Task, Force",
  doi="10.17487/RFC2014",
  }

@misc{rfc2015,
  author="M. Elkins",
  title="{MIME Security with Pretty Good Privacy (PGP)}",
  howpublished="RFC 2015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2015",
  pages="1--8",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3156",
url="https://www.rfc-editor.org/rfc/rfc2015.txt",
  key="RFC 2015",
  abstract={This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]},
  keywords="MIME-PGP, Authentication, Encryption",
  doi="10.17487/RFC2015",
  }

@misc{rfc2016,
  author="L. Daigle and P. Deutsch and B. Heelan and C. Alpaugh and M. Maclachlan",
  title="{Uniform Resource Agents (URAs)}",
  howpublished="RFC 2016 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2016",
  pages="1--21",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2016.txt",
  key="RFC 2016",
  abstract={This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="URAS",
  doi="10.17487/RFC2016",
  }

@misc{rfc2017,
  author="N. Freed and K. Moore and A. Cargille",
  title="{Definition of the URL MIME External-Body Access-Type}",
  howpublished="RFC 2017 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2017",
  pages="1--5",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2017.txt",
  key="RFC 2017",
  abstract={This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]},
  keywords="URL-ACC, Uniform, Resource, Locators, Multipurpose, Internet, Message, Extensions",
  doi="10.17487/RFC2017",
  }

@misc{rfc2018,
  author="M. Mathis and J. Mahdavi and S. Floyd and A. Romanow",
  title="{TCP Selective Acknowledgment Options}",
  howpublished="RFC 2018 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2018",
  pages="1--12",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2018.txt",
  key="RFC 2018",
  abstract={This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]},
  keywords="TCP-ACK, Transmission, Control, Protocol, SACK",
  doi="10.17487/RFC2018",
  }

@misc{rfc2019,
  author="M. Crawford",
  title="{Transmission of IPv6 Packets Over FDDI}",
  howpublished="RFC 2019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2019",
  pages="1--6",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2467",
url="https://www.rfc-editor.org/rfc/rfc2019.txt",
  key="RFC 2019",
  abstract={This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]},
  keywords="IPV6-FDDI, frame, format, Fiber, Distributed, Data, Interface",
  doi="10.17487/RFC2019",
  }

@misc{rfc2020,
  author="J. Flick",
  title="{IEEE 802.12 Interface MIB}",
  howpublished="RFC 2020 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2020",
  pages="1--31",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2020.txt",
  key="RFC 2020",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]},
  keywords="802.12-MIB, Management, Information, Base",
  doi="10.17487/RFC2020",
  }

@misc{rfc2021,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base Version 2 using SMIv2}",
  howpublished="RFC 2021 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2021",
  pages="1--130",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4502",
url="https://www.rfc-editor.org/rfc/rfc2021.txt",
  key="RFC 2021",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]},
  keywords="RMON-MIB, RMON, MIB",
  doi="10.17487/RFC2021",
  }

@misc{rfc2022,
  author="G. Armitage",
  title="{Support for Multicast over UNI 3.0/3.1 based ATM Networks}",
  howpublished="RFC 2022 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2022",
  pages="1--82",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2022.txt",
  key="RFC 2022",
  abstract={This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]},
  keywords="MULTI-UNI, Asynchronous, Transfer, Mode",
  doi="10.17487/RFC2022",
  }

@misc{rfc2023,
  author="D. Haskin and E. Allen",
  title="{IP Version 6 over PPP}",
  howpublished="RFC 2023 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2023",
  pages="1--10",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2472",
url="https://www.rfc-editor.org/rfc/rfc2023.txt",
  key="RFC 2023",
  abstract={This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]},
  keywords="IPV6-PPP, Internet, Protocol, Point, IPv6",
  doi="10.17487/RFC2023",
  }

@misc{rfc2024,
  author="D. Chen and P. Gayek and S. Nix",
  title="{Definitions of Managed Objects for Data Link Switching using SMIv2}",
  howpublished="RFC 2024 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2024",
  pages="1--90",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2024.txt",
  key="RFC 2024",
  abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]},
  keywords="DLSW-MIB, MIB, DLSW, Management, Information, Base",
  doi="10.17487/RFC2024",
  }

@misc{rfc2025,
  author="C. Adams",
  title="{The Simple Public-Key GSS-API Mechanism (SPKM)}",
  howpublished="RFC 2025 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2025",
  pages="1--45",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2025.txt",
  key="RFC 2025",
  abstract={This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]},
  keywords="SPKM",
  doi="10.17487/RFC2025",
  }

@misc{rfc2026,
  author="S. Bradner",
  title="{The Internet Standards Process -- Revision 3}",
  howpublished="RFC 2026 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2026",
  pages="1--36",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3667, 3668, 3932, 3978, 3979, 5378, 5657, 5742, 6410, 7100, 7127, 7475",
url="https://www.rfc-editor.org/rfc/rfc2026.txt",
  key="RFC 2026",
  abstract={This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Protocols, copyrights, intellectual, property",
  doi="10.17487/RFC2026",
  }

@misc{rfc2027,
  author="J. Galvin",
  title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}",
  howpublished="RFC 2027 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2027",
  pages="1--11",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2282",
url="https://www.rfc-editor.org/rfc/rfc2027.txt",
  key="RFC 2027",
  abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation.  The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees.  This document is a self-consistent, organized compilation of the process as it is known today.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Architecture, Board, Engineering, Steering, Group",
  doi="10.17487/RFC2027",
  }

@misc{rfc2028,
  author="R. Hovey and S. Bradner",
  title="{The Organizations Involved in the IETF Standards Process}",
  howpublished="RFC 2028 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2028",
  pages="1--7",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3668, 3979",
url="https://www.rfc-editor.org/rfc/rfc2028.txt",
  key="RFC 2028",
  abstract={This document describes the individuals and organizations involved in the IETF.  This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Engineering, Task, Force",
  doi="10.17487/RFC2028",
  }

@misc{rfc2029,
  author="M. Speer and D. Hoffman",
  title="{RTP Payload Format of Sun's CellB Video Encoding}",
  howpublished="RFC 2029 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2029",
  pages="1--6",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2029.txt",
  key="RFC 2029",
  abstract={This memo describes a packetization scheme for the CellB video encoding.  The scheme proposed allows applications to transport CellB video flows over protocols used by RTP.  This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]},
  keywords="RTP-CELLB, Real, Time, Transport, Protocol",
  doi="10.17487/RFC2029",
  }

@misc{rfc2030,
  author="D. Mills",
  title="{Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI}",
  howpublished="RFC 2030 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2030",
  pages="1--18",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4330",
url="https://www.rfc-editor.org/rfc/rfc2030.txt",
  key="RFC 2030",
  abstract={This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="NTP, SNTP, time, computer, clock, synchronization",
  doi="10.17487/RFC2030",
  }

@misc{rfc2031,
  author="E. Huizer",
  title="{IETF-ISOC relationship}",
  howpublished="RFC 2031 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2031",
  pages="1--4",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2031.txt",
  key="RFC 2031",
  abstract={This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group.  The purpose of the document is to gauge consensus on these issues.  And to allow further discussions where necessary.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Society, Engineering, Task, Force",
  doi="10.17487/RFC2031",
  }

@misc{rfc2032,
  author="T. Turletti and C. Huitema",
  title="{RTP Payload Format for H.261 Video Streams}",
  howpublished="RFC 2032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2032",
  pages="1--11",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4587",
url="https://www.rfc-editor.org/rfc/rfc2032.txt",
  key="RFC 2032",
  abstract={This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]},
  keywords="RTP-H.261, Real, Time, Transport, Protocol",
  doi="10.17487/RFC2032",
  }

@misc{rfc2033,
  author="J. Myers",
  title="{Local Mail Transfer Protocol}",
  howpublished="RFC 2033 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2033",
  pages="1--7",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2033.txt",
  key="RFC 2033",
  abstract={SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently.  The design of the SMTP protocol effectively requires the server to manage a mail delivery queue.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="LMTP, SMTP, Simple, Mail, Transfer, Protocol",
  doi="10.17487/RFC2033",
  }

@misc{rfc2034,
  author="N. Freed",
  title="{SMTP Service Extension for Returning Enhanced Error Codes}",
  howpublished="RFC 2034 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2034",
  pages="1--6",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2034.txt",
  key="RFC 2034",
  abstract={This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]},
  keywords="SMTP-ENH, Simple, Mail, Transfer, Protocol",
  doi="10.17487/RFC2034",
  }

@misc{rfc2035,
  author="L. Berc and W. Fenner and R. Frederick and S. McCanne",
  title="{RTP Payload Format for JPEG-compressed Video}",
  howpublished="RFC 2035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2035",
  pages="1--16",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2435",
url="https://www.rfc-editor.org/rfc/rfc2035.txt",
  key="RFC 2035",
  abstract={This memo describes the RTP payload format for JPEG video streams.  The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]},
  keywords="RTP-JPEG, Real, Time, Transport, Protocol, Joint, Photographic, Experts, Group",
  doi="10.17487/RFC2035",
  }

@misc{rfc2036,
  author="G. Huston",
  title="{Observations on the use of Components of the Class A Address Space within the Internet}",
  howpublished="RFC 2036 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2036",
  pages="1--9",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2036.txt",
  key="RFC 2036",
  abstract={This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Assigned, Numbers, Authority, IANA",
  doi="10.17487/RFC2036",
  }

@misc{rfc2037,
  author="K. McCloghrie and A. Bierman",
  title="{Entity MIB using SMIv2}",
  howpublished="RFC 2037 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2037",
  pages="1--35",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2737",
url="https://www.rfc-editor.org/rfc/rfc2037.txt",
  key="RFC 2037",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]},
  keywords="ENTITY-MIB, Management, Information, Base, SNMP",
  doi="10.17487/RFC2037",
  }

@misc{rfc2038,
  author="D. Hoffman and G. Fernando and V. Goyal",
  title="{RTP Payload Format for MPEG1/MPEG2 Video}",
  howpublished="RFC 2038 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2038",
  pages="1--11",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2250",
url="https://www.rfc-editor.org/rfc/rfc2038.txt",
  key="RFC 2038",
  abstract={This memo describes a packetization scheme for MPEG video and audio streams.  The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]},
  keywords="Real, Time, Transport, Protocol",
  doi="10.17487/RFC2038",
  }

@misc{rfc2039,
  author="C. Kalbfleisch",
  title="{Applicability of Standards Track MIBs to Management of World Wide Web Servers}",
  howpublished="RFC 2039 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2039",
  pages="1--14",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2039.txt",
  key="RFC 2039",
  abstract={This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Management, Information, Base, HTTP",
  doi="10.17487/RFC2039",
  }

@misc{rfc2040,
  author="R. Baldwin and R. Rivest",
  title="{The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms}",
  howpublished="RFC 2040 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2040",
  pages="1--29",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2040.txt",
  key="RFC 2040",
  abstract={This document defines four ciphers with enough detail to ensure interoperability between different implementations.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RC5, Cipher, Block, Chaining, CBC",
  doi="10.17487/RFC2040",
  }

@misc{rfc2041,
  author="B. Noble and G. Nguyen and M. Satyanarayanan and R. Katz",
  title="{Mobile Network Tracing}",
  howpublished="RFC 2041 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2041",
  pages="1--27",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2041.txt",
  key="RFC 2041",
  abstract={This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Internet, Protocol",
  doi="10.17487/RFC2041",
  }

@misc{rfc2042,
  author="B. Manning",
  title="{Registering New BGP Attribute Types}",
  howpublished="RFC 2042 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2042",
  pages="1--3",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2042.txt",
  key="RFC 2042",
  abstract={This document describes the process for creating new BGP attribute type codes.  Basic attribute type codes are described in RFC 1771, pages 12 through 15.  These, and new attribute type codes that are used in the Internet are registered with the IANA.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Border, Gateway, Protocol",
  doi="10.17487/RFC2042",
  }

@misc{rfc2043,
  author="A. Fuqua",
  title="{The PPP SNA Control Protocol (SNACP)}",
  howpublished="RFC 2043 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2043",
  pages="1--7",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2043.txt",
  key="RFC 2043",
  abstract={This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]},
  keywords="PPP-SNACP, Point-to-point, protocol, systems, network, architecture",
  doi="10.17487/RFC2043",
  }

@misc{rfc2044,
  author="F. Yergeau",
  title="{UTF-8, a transformation format of Unicode and ISO 10646}",
  howpublished="RFC 2044 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2044",
  pages="1--6",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2279",
url="https://www.rfc-editor.org/rfc/rfc2044.txt",
  key="RFC 2044",
  abstract={The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems.  UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="UCS, Transformation, Format",
  doi="10.17487/RFC2044",
  }

@misc{rfc2045,
  author="N. Freed and N. Borenstein",
  title="{Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies}",
  howpublished="RFC 2045 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2045",
  pages="1--31",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2184, 2231, 5335, 6532",
url="https://www.rfc-editor.org/rfc/rfc2045.txt",
  key="RFC 2045",
  abstract={This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]},
  keywords="MIME, media, types, headers",
  doi="10.17487/RFC2045",
  }

@misc{rfc2046,
  author="N. Freed and N. Borenstein",
  title="{Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types}",
  howpublished="RFC 2046 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2046",
  pages="1--44",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2646, 3798, 5147, 6657, 8098",
url="https://www.rfc-editor.org/rfc/rfc2046.txt",
  key="RFC 2046",
  abstract={This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]},
  keywords="MIME-MEDIA, headers, structure",
  doi="10.17487/RFC2046",
  }

@misc{rfc2047,
  author="K. Moore",
  title="{MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text}",
  howpublished="RFC 2047 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2047",
  pages="1--15",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2184, 2231",
url="https://www.rfc-editor.org/rfc/rfc2047.txt",
  key="RFC 2047",
  abstract={This particular document is the third document in the series.  It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]},
  keywords="MIME-MSG, media, type",
  doi="10.17487/RFC2047",
  }

@misc{rfc2048,
  author="N. Freed and J. Klensin and J. Postel",
  title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}",
  howpublished="RFC 2048 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2048",
  pages="1--21",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4288, 4289, updated by RFC 3023",
url="https://www.rfc-editor.org/rfc/rfc2048.txt",
  key="RFC 2048",
  abstract={This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages.  This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="media, types, external, body, access, content-transfer-encodings",
  doi="10.17487/RFC2048",
  }

@misc{rfc2049,
  author="N. Freed and N. Borenstein",
  title="{Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples}",
  howpublished="RFC 2049 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2049",
  pages="1--24",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2049.txt",
  key="RFC 2049",
  abstract={This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages.  This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]},
  keywords="MIME-CONF, media, type, message, formats",
  doi="10.17487/RFC2049",
  }

@misc{rfc2050,
  author="K. Hubbard and M. Kosters and D. Conrad and D. Karrenberg and J. Postel",
  title="{Internet Registry IP Allocation Guidelines}",
  howpublished="RFC 2050 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2050",
  pages="1--13",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7020",
url="https://www.rfc-editor.org/rfc/rfc2050.txt",
  key="RFC 2050",
  abstract={This document describes the registry system for the distribution of globally unique Internet address space and registry operations.  Particularly this document describes the rules and guidelines governing the distribution of this address space.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Addresses, Network, Numbers",
  doi="10.17487/RFC2050",
  }

@misc{rfc2051,
  author="M. Allen and B. Clouston and Z. Kielczewski and W. Kwan and B. Moore",
  title="{Definitions of Managed Objects for APPC using SMIv2}",
  howpublished="RFC 2051 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2051",
  pages="1--124",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2051.txt",
  key="RFC 2051",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities.  This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]},
  keywords="SNANAU-APP",
  doi="10.17487/RFC2051",
  }

@misc{rfc2052,
  author="A. Gulbrandsen and P. Vixie",
  title="{A DNS RR for specifying the location of services (DNS SRV)}",
  howpublished="RFC 2052 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2052",
  pages="1--10",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2782",
url="https://www.rfc-editor.org/rfc/rfc2052.txt",
  key="RFC 2052",
  abstract={This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS-SRV, Domain, Name, System",
  doi="10.17487/RFC2052",
  }

@misc{rfc2053,
  author="E. Der-Danieliantz",
  title="{The AM (Armenia) Domain}",
  howpublished="RFC 2053 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2053",
  pages="1--3",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2053.txt",
  key="RFC 2053",
  abstract={The AM Domain is an official Internet top-level domain of Armenia.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Top, Level, Domain, Country, Code",
  doi="10.17487/RFC2053",
  }

@misc{rfc2054,
  author="B. Callaghan",
  title="{WebNFS Client Specification}",
  howpublished="RFC 2054 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2054",
  pages="1--16",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2054.txt",
  key="RFC 2054",
  abstract={This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Network, Fil, System",
  doi="10.17487/RFC2054",
  }

@misc{rfc2055,
  author="B. Callaghan",
  title="{WebNFS Server Specification}",
  howpublished="RFC 2055 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2055",
  pages="1--10",
  year=1996,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2055.txt",
  key="RFC 2055",
  abstract={This document describes the specifications for a server of WebNFS clients.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Network, Fil, System",
  doi="10.17487/RFC2055",
  }

@misc{rfc2056,
  author="R. Denenberg and J. Kunze and D. Lynch",
  title="{Uniform Resource Locators for Z39.50}",
  howpublished="RFC 2056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2056",
  pages="1--7",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2056.txt",
  key="RFC 2056",
  abstract={Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data.  Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]},
  keywords="URLZ39.50, URL, information, retrieval",
  doi="10.17487/RFC2056",
  }

@misc{rfc2057,
  author="S. Bradner",
  title="{Source Directed Access Control on the Internet}",
  howpublished="RFC 2057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2057",
  pages="1--20",
  year=1996,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2057.txt",
  key="RFC 2057",
  abstract={This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="content, regulation, deposition",
  doi="10.17487/RFC2057",
  }

@misc{rfc2058,
  author="C. Rigney and A. Rubens and W. Simpson and S. Willens",
  title="{Remote Authentication Dial In User Service (RADIUS)}",
  howpublished="RFC 2058 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2058",
  pages="1--64",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2138",
url="https://www.rfc-editor.org/rfc/rfc2058.txt",
  key="RFC 2058",
  abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]},
  keywords="encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2058",
  }

@misc{rfc2059,
  author="C. Rigney",
  title="{RADIUS Accounting}",
  howpublished="RFC 2059 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2059",
  pages="1--25",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2139",
url="https://www.rfc-editor.org/rfc/rfc2059.txt",
  key="RFC 2059",
  abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="remote, authentication, dial, in, user, service, encryption",
  doi="10.17487/RFC2059",
  }

@misc{rfc2060,
  author="M. Crispin",
  title="{Internet Message Access Protocol - Version 4rev1}",
  howpublished="RFC 2060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2060",
  pages="1--82",
  year=1996,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3501",
url="https://www.rfc-editor.org/rfc/rfc2060.txt",
  key="RFC 2060",
  abstract={The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]},
  keywords="IMAPV4, IMAP, electronic, mail, Internet, Message, Access, Protocol",
  doi="10.17487/RFC2060",
  }

@misc{rfc2061,
  author="M. Crispin",
  title="{IMAP4 Compatibility with IMAP2bis}",
  howpublished="RFC 2061 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2061",
  pages="1--3",
  year=1996,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2061.txt",
  key="RFC 2061",
  abstract={This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IMAP, electronic, mail, Internet, Message, Access, Protocol",
  doi="10.17487/RFC2061",
  }

@misc{rfc2062,
  author="M. Crispin",
  title="{Internet Message Access Protocol - Obsolete Syntax}",
  howpublished="RFC 2062 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2062",
  pages="1--8",
  year=1996,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2062.txt",
  key="RFC 2062",
  abstract={This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IMAP, electronic, mail",
  doi="10.17487/RFC2062",
  }

@misc{rfc2063,
  author="N. Brownlee and C. Mills and G. Ruth",
  title="{Traffic Flow Measurement:  Architecture}",
  howpublished="RFC 2063 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2063",
  pages="1--37",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2722",
url="https://www.rfc-editor.org/rfc/rfc2063.txt",
  key="RFC 2063",
  abstract={This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TFM-ARCH, network, data",
  doi="10.17487/RFC2063",
  }

@misc{rfc2064,
  author="N. Brownlee",
  title="{Traffic Flow Measurement:  Meter MIB}",
  howpublished="RFC 2064 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2064",
  pages="1--38",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2720",
url="https://www.rfc-editor.org/rfc/rfc2064.txt",
  key="RFC 2064",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="METER-MIB, Management, Information, Base, Network, Data",
  doi="10.17487/RFC2064",
  }

@misc{rfc2065,
  author="D. {Eastlake 3rd} and C. Kaufman",
  title="{Domain Name System Security Extensions}",
  howpublished="RFC 2065 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2065",
  pages="1--41",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2535",
url="https://www.rfc-editor.org/rfc/rfc2065.txt",
  key="RFC 2065",
  abstract={The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication.  Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]},
  keywords="DNS-SEC, DNS, authentication, encryption",
  doi="10.17487/RFC2065",
  }

@misc{rfc2066,
  author="R. Gellens",
  title="{TELNET CHARSET Option}",
  howpublished="RFC 2066 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2066",
  pages="1--12",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2066.txt",
  key="RFC 2066",
  abstract={This document specifies a mechanism for passing character set and translation information between a TELNET client and server.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TOPT-CHARSET, character, set, application",
  doi="10.17487/RFC2066",
  }

@misc{rfc2067,
  author="J. Renwick",
  title="{IP over HIPPI}",
  howpublished="RFC 2067 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2067",
  pages="1--30",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2067.txt",
  key="RFC 2067",
  abstract={ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI.  This memo is a revision of RFC 1374, ``IP and ARP on HIPPI'', and is intended to replace it in the Standards Track. [STANDARDS-TRACK]},
  keywords="IP-HIPPI, ANSI, High-Performance, Parallel, Interface, Internet, Protocol",
  doi="10.17487/RFC2067",
  }

@misc{rfc2068,
  author="R. Fielding and J. Gettys and J. Mogul and H. Frystyk and T. Berners-Lee",
  title="{Hypertext Transfer Protocol -- HTTP/1.1}",
  howpublished="RFC 2068 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2068",
  pages="1--162",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2616",
url="https://www.rfc-editor.org/rfc/rfc2068.txt",
  key="RFC 2068",
  abstract={The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]},
  keywords="HTTP-1.1, World, Wide, Web, WWW, hypermedia",
  doi="10.17487/RFC2068",
  }

@misc{rfc2069,
  author="J. Franks and P. Hallam-Baker and J. Hostetler and P. Leach and A. Luotonen and E. Sink and L. Stewart",
  title="{An Extension to HTTP : Digest Access Authentication}",
  howpublished="RFC 2069 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2069",
  pages="1--18",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2617",
url="https://www.rfc-editor.org/rfc/rfc2069.txt",
  key="RFC 2069",
  abstract={The protocol referred to as ``HTTP/1.0'' includes the specification for a Basic Access Authentication scheme.  This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text.  A specification for a different authentication scheme is needed to address this severe limitation.  This document provides specification for such a scheme, referred to as ``Digest Access Authentication''. [STANDARDS-TRACK]},
  keywords="DAA, Hypertext, Transfer, Protocol",
  doi="10.17487/RFC2069",
  }

@misc{rfc2070,
  author="F. Yergeau and G. Nicol and G. Adams and M. Duerst",
  title="{Internationalization of the Hypertext Markup Language}",
  howpublished="RFC 2070 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2070",
  pages="1--43",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2854",
url="https://www.rfc-editor.org/rfc/rfc2070.txt",
  key="RFC 2070",
  abstract={This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]},
  keywords="HTML-INT, HTML, WWW, World, Wide, Web",
  doi="10.17487/RFC2070",
  }

@misc{rfc2071,
  author="P. Ferguson and H. Berkowitz",
  title="{Network Renumbering Overview: Why would I want it and what is it anyway?}",
  howpublished="RFC 2071 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2071",
  pages="1--14",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2071.txt",
  key="RFC 2071",
  abstract={This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Enterprise, Connecting, Routers",
  doi="10.17487/RFC2071",
  }

@misc{rfc2072,
  author="H. Berkowitz",
  title="{Router Renumbering Guide}",
  howpublished="RFC 2072 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2072",
  pages="1--48",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4192",
url="https://www.rfc-editor.org/rfc/rfc2072.txt",
  key="RFC 2072",
  abstract={Routers interact with numerous network infrastructure servers, including DNS and SNMP.  These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Enterprise, Connecting, Routers",
  doi="10.17487/RFC2072",
  }

@misc{rfc2073,
  author="Y. Rekhter and P. Lothberg and R. Hinden and S. Deering and J. Postel",
  title="{An IPv6 Provider-Based Unicast Address Format}",
  howpublished="RFC 2073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2073",
  pages="1--7",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2374",
url="https://www.rfc-editor.org/rfc/rfc2073.txt",
  key="RFC 2073",
  abstract={This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]},
  keywords="IPV6-UNI",
  doi="10.17487/RFC2073",
  }

@misc{rfc2074,
  author="A. Bierman and R. Iddon",
  title="{Remote Network Monitoring MIB Protocol Identifiers}",
  howpublished="RFC 2074 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2074",
  pages="1--43",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2895",
url="https://www.rfc-editor.org/rfc/rfc2074.txt",
  key="RFC 2074",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]},
  keywords="RMON-MIB, RMON, Management, Information, Base",
  doi="10.17487/RFC2074",
  }

@misc{rfc2075,
  author="C. Partridge",
  title="{IP Echo Host Service}",
  howpublished="RFC 2075 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2075",
  pages="1--5",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2075.txt",
  key="RFC 2075",
  abstract={This memo describes how to implement an IP echo host.  IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IP-Echo, Internet, Protocol, datagram",
  doi="10.17487/RFC2075",
  }

@misc{rfc2076,
  author="J. Palme",
  title="{Common Internet Message Headers}",
  howpublished="RFC 2076 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2076",
  pages="1--27",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2076.txt",
  key="RFC 2076",
  abstract={This memo contains a table of commonly occurring headers in headings of e-mail messages.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="email",
  doi="10.17487/RFC2076",
  }

@misc{rfc2077,
  author="S. Nelson and C. Parks and Mitra",
  title="{The Model Primary Content Type for Multipurpose Internet Mail Extensions}",
  howpublished="RFC 2077 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2077",
  pages="1--13",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2077.txt",
  key="RFC 2077",
  abstract={The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as ``model''. [STANDARDS-TRACK]},
  keywords="MIME-MODEL, MIME, Media, Type, Content, Type",
  doi="10.17487/RFC2077",
  }

@misc{rfc2078,
  author="J. Linn",
  title="{Generic Security Service Application Program Interface, Version 2}",
  howpublished="RFC 2078 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2078",
  pages="1--85",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2743",
url="https://www.rfc-editor.org/rfc/rfc2078.txt",
  key="RFC 2078",
  abstract={The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]},
  keywords="GSSAP, Authentication, Cryptology, Data, integrity",
  doi="10.17487/RFC2078",
  }

@misc{rfc2079,
  author="M. Smith",
  title="{Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 2079 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2079",
  pages="1--5",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2079.txt",
  key="RFC 2079",
  abstract={This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]},
  keywords="URI-ATT, URL, Universal, Resource, Locators, Directory",
  doi="10.17487/RFC2079",
  }

@misc{rfc2080,
  author="G. Malkin and R. Minnear",
  title="{RIPng for IPv6}",
  howpublished="RFC 2080 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2080",
  pages="1--19",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2080.txt",
  key="RFC 2080",
  abstract={This document specifies a routing protocol for an IPv6 internet.  It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]},
  keywords="RIPNG-IPV6, Routing, Information, Protocol, Internet",
  doi="10.17487/RFC2080",
  }

@misc{rfc2081,
  author="G. Malkin",
  title="{RIPng Protocol Applicability Statement}",
  howpublished="RFC 2081 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2081",
  pages="1--4",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2081.txt",
  key="RFC 2081",
  abstract={As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Routing, Information, Protocol, Internet",
  doi="10.17487/RFC2081",
  }

@misc{rfc2082,
  author="F. Baker and R. Atkinson",
  title="{RIP-2 MD5 Authentication}",
  howpublished="RFC 2082 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2082",
  pages="1--12",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4822",
url="https://www.rfc-editor.org/rfc/rfc2082.txt",
  key="RFC 2082",
  abstract={Growth in the Internet has made us aware of the need for improved authentication of routing information.  RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]},
  keywords="RIP2-MD5, Routing, Information, Protocol, Encryption",
  doi="10.17487/RFC2082",
  }

@misc{rfc2083,
  author="T. Boutell",
  title="{PNG (Portable Network Graphics) Specification Version 1.0}",
  howpublished="RFC 2083 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2083",
  pages="1--102",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2083.txt",
  key="RFC 2083",
  abstract={This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="PNG, file, format, bitmap",
  doi="10.17487/RFC2083",
  }

@misc{rfc2084,
  author="G. Bossert and S. Cooper and W. Drummond",
  title="{Considerations for Web Transaction Security}",
  howpublished="RFC 2084 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2084",
  pages="1--6",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2084.txt",
  key="RFC 2084",
  abstract={This document specifies the requirements for the provision of security services to the HyperText Transport Protocol.  These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="authentication, encryption, World, Wide, Web, WWW",
  doi="10.17487/RFC2084",
  }

@misc{rfc2085,
  author="M. Oehler and R. Glenn",
  title="{HMAC-MD5 IP Authentication with Replay Prevention}",
  howpublished="RFC 2085 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2085",
  pages="1--6",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2085.txt",
  key="RFC 2085",
  abstract={This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826].  The particular transform is based on [HMAC-MD5].  An option is also specified to guard against replay attacks. [STANDARDS-TRACK]},
  keywords="HMAC-MD5, ipsec, Message, Digest, Security, Internet, Protocol, Encryption",
  doi="10.17487/RFC2085",
  }

@misc{rfc2086,
  author="J. Myers",
  title="{IMAP4 ACL extension}",
  howpublished="RFC 2086 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2086",
  pages="1--8",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4314",
url="https://www.rfc-editor.org/rfc/rfc2086.txt",
  key="RFC 2086",
  abstract={The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]},
  keywords="IMAP4-ACL, Internet, Message, Access, Protocol, Control, List",
  doi="10.17487/RFC2086",
  }

@misc{rfc2087,
  author="J. Myers",
  title="{IMAP4 QUOTA extension}",
  howpublished="RFC 2087 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2087",
  pages="1--5",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2087.txt",
  key="RFC 2087",
  abstract={The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]},
  keywords="IMAP4-QUO, Internet, Message, Access, Protocol",
  doi="10.17487/RFC2087",
  }

@misc{rfc2088,
  author="J. Myers",
  title="{IMAP4 non-synchronizing literals}",
  howpublished="RFC 2088 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2088",
  pages="1--2",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7888, updated by RFC 4466",
url="https://www.rfc-editor.org/rfc/rfc2088.txt",
  key="RFC 2088",
  abstract={The Internet Message Access Protocol [STANDARDS-TRACK]},
  keywords="IMAP4-LIT, Internet, Message, Access, Protocol",
  doi="10.17487/RFC2088",
  }

@misc{rfc2089,
  author="B. Wijnen and D. Levi",
  title="{V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent}",
  howpublished="RFC 2089 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2089",
  pages="1--12",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2576",
url="https://www.rfc-editor.org/rfc/rfc2089.txt",
  key="RFC 2089",
  abstract={The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2).  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2089",
  }

@misc{rfc2090,
  author="A. Emberson",
  title="{TFTP Multicast Option}",
  howpublished="RFC 2090 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2090",
  pages="1--6",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2090.txt",
  key="RFC 2090",
  abstract={This document describes a new TFTP option.  This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TFTP-MULTI, Trivial, File, Transfer, Protocol",
  doi="10.17487/RFC2090",
  }

@misc{rfc2091,
  author="G. Meyer and S. Sherry",
  title="{Triggered Extensions to RIP to Support Demand Circuits}",
  howpublished="RFC 2091 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2091",
  pages="1--22",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2091.txt",
  key="RFC 2091",
  abstract={This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]},
  keywords="RIP-TRIG",
  doi="10.17487/RFC2091",
  }

@misc{rfc2092,
  author="S. Sherry and G. Meyer",
  title="{Protocol Analysis for Triggered RIP}",
  howpublished="RFC 2092 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2092",
  pages="1--6",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2092.txt",
  key="RFC 2092",
  abstract={As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2092",
  }

@misc{rfc2093,
  author="H. Harney and C. Muckenhirn",
  title="{Group Key Management Protocol (GKMP) Specification}",
  howpublished="RFC 2093 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2093",
  pages="1--23",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2093.txt",
  key="RFC 2093",
  abstract={This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="GKMP-SPEC",
  doi="10.17487/RFC2093",
  }

@misc{rfc2094,
  author="H. Harney and C. Muckenhirn",
  title="{Group Key Management Protocol (GKMP) Architecture}",
  howpublished="RFC 2094 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2094",
  pages="1--22",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2094.txt",
  key="RFC 2094",
  abstract={This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="GKMP-ARCH",
  doi="10.17487/RFC2094",
  }

@misc{rfc2095,
  author="J. Klensin and R. Catoe and P. Krumviede",
  title="{IMAP/POP AUTHorize Extension for Simple Challenge/Response}",
  howpublished="RFC 2095 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2095",
  pages="1--5",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2195",
url="https://www.rfc-editor.org/rfc/rfc2095.txt",
  key="RFC 2095",
  abstract={This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]},
  keywords="Post, Office, Protocol, Internet, Message, Access",
  doi="10.17487/RFC2095",
  }

@misc{rfc2096,
  author="F. Baker",
  title="{IP Forwarding Table MIB}",
  howpublished="RFC 2096 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2096",
  pages="1--21",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4292",
url="https://www.rfc-editor.org/rfc/rfc2096.txt",
  key="RFC 2096",
  abstract={This memo defines an update to RFC 1354.  The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]},
  keywords="TABLE-MIB, Management, Information, Base, Internet, Protocol",
  doi="10.17487/RFC2096",
  }

@misc{rfc2097,
  author="G. Pall",
  title="{The PPP NetBIOS Frames Control Protocol (NBFCP)}",
  howpublished="RFC 2097 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2097",
  pages="1--13",
  year=1997,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2097.txt",
  key="RFC 2097",
  abstract={This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP.  The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]},
  keywords="PPP-NBFCP, Point-to-Point, Protocol",
  doi="10.17487/RFC2097",
  }

@misc{rfc2098,
  author="Y. Katsube and K. Nagami and H. Esaki",
  title="{Toshiba's Router Architecture Extensions for ATM : Overview}",
  howpublished="RFC 2098 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2098",
  pages="1--18",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2098.txt",
  key="RFC 2098",
  abstract={This memo describes a new internetworking architecture which makes better use of the property of ATM.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Asynchronis, Transfer, Mode, datagram, IP, Internet, Protocol",
  doi="10.17487/RFC2098",
  }

@misc{rfc2099,
  author="J. Elliott",
  title="{Request for Comments Summary RFC Numbers 2000-2099}",
  howpublished="RFC 2099 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2099",
  pages="1--21",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2099.txt",
  key="RFC 2099",
  doi="10.17487/RFC2099",
  }

@misc{rfc2100,
  author="J. Ashworth",
  title="{The Naming of Hosts}",
  howpublished="RFC 2100 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2100",
  pages="1--3",
  year=1997,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2100.txt",
  key="RFC 2100",
  abstract={This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="April, Fool's",
  doi="10.17487/RFC2100",
  }

@misc{rfc2101,
  author="B. Carpenter and J. Crowcroft and Y. Rekhter",
  title="{IPv4 Address Behaviour Today}",
  howpublished="RFC 2101 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2101",
  pages="1--13",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2101.txt",
  key="RFC 2101",
  abstract={The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, Internet, Architecture, Board",
  doi="10.17487/RFC2101",
  }

@misc{rfc2102,
  author="R. Ramanathan",
  title="{Multicast Support for Nimrod :  Requirements and Solution Approaches}",
  howpublished="RFC 2102 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2102",
  pages="1--23",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2102.txt",
  key="RFC 2102",
  abstract={Nimrod does not specify a particular solution for multicasting.  Rather, Nimrod may use any of a number of emerging multicast techniques.  We identify the requirements that Nimrod has of a solution for multicast support.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="scalable, routing, architecture",
  doi="10.17487/RFC2102",
  }

@misc{rfc2103,
  author="R. Ramanathan",
  title="{Mobility Support for Nimrod :  Challenges and Solution Approaches}",
  howpublished="RFC 2103 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2103",
  pages="1--17",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2103.txt",
  key="RFC 2103",
  abstract={We discuss the issue of mobility in Nimrod.  While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics.  We identify the requirements that Nimrod has of any solution for mobility support.  We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP, Internet, Protocol, routing, addressing",
  doi="10.17487/RFC2103",
  }

@misc{rfc2104,
  author="H. Krawczyk and M. Bellare and R. Canetti",
  title="{HMAC: Keyed-Hashing for Message Authentication}",
  howpublished="RFC 2104 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2104",
  pages="1--11",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6151",
url="https://www.rfc-editor.org/rfc/rfc2104.txt",
  key="RFC 2104",
  abstract={This document describes HMAC, a mechanism for message authentication using cryptographic hash functions.  HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key.  The cryptographic strength of HMAC depends on the properties of the underlying hash function.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind},
  keywords="ipsec, Message, Digest, Internet, Protocol, Security, encryption",
  doi="10.17487/RFC2104",
  }

@misc{rfc2105,
  author="Y. Rekhter and B. Davie and D. Katz and E. Rosen and G. Swallow",
  title="{Cisco Systems' Tag Switching Architecture Overview}",
  howpublished="RFC 2105 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2105",
  pages="1--13",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2105.txt",
  key="RFC 2105",
  abstract={This document provides an overview of a novel approach to network layer packet forwarding, called tag switching.  The two main components of the tag switching architecture - forwarding and control - are described.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="network, layer, packet, ATM, switches",
  doi="10.17487/RFC2105",
  }

@misc{rfc2106,
  author="S. Chiang and J. Lee and H. Yasuda",
  title="{Data Link Switching Remote Access Protocol}",
  howpublished="RFC 2106 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2106",
  pages="1--19",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2114",
url="https://www.rfc-editor.org/rfc/rfc2106.txt",
  key="RFC 2106",
  abstract={This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DLSRAP, NetBios, DLSW",
  doi="10.17487/RFC2106",
  }

@misc{rfc2107,
  author="K. Hamzeh",
  title="{Ascend Tunnel Management Protocol - ATMP}",
  howpublished="RFC 2107 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2107",
  pages="1--21",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2107.txt",
  key="RFC 2107",
  abstract={This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RADIUS, authentication",
  doi="10.17487/RFC2107",
  }

@misc{rfc2108,
  author="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie",
  title="{Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2}",
  howpublished="RFC 2108 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2108",
  pages="1--82",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2108.txt",
  key="RFC 2108",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 \&},
  keywords="802.3-MIB, MIB, Management, Information, Base",
  doi="10.17487/RFC2108",
  }

@misc{rfc2109,
  author="D. Kristol and L. Montulli",
  title="{HTTP State Management Mechanism}",
  howpublished="RFC 2109 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2109",
  pages="1--21",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2965",
url="https://www.rfc-editor.org/rfc/rfc2109.txt",
  key="RFC 2109",
  abstract={This document specifies a way to create a stateful session with HTTP requests and responses.  It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents.  The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]},
  keywords="HTTP-STATE, Hypertext, Transfer, Protocol, cookie",
  doi="10.17487/RFC2109",
  }

@misc{rfc2110,
  author="J. Palme and A. Hopmann",
  title="{MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)}",
  howpublished="RFC 2110 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2110",
  pages="1--19",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2557",
url="https://www.rfc-editor.org/rfc/rfc2110.txt",
  key="RFC 2110",
  abstract={This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]},
  keywords="MHTML, Hyper, Text, Markup, Language, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC2110",
  }

@misc{rfc2111,
  author="E. Levinson",
  title="{Content-ID and Message-ID Uniform Resource Locators}",
  howpublished="RFC 2111 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2111",
  pages="1--5",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2392",
url="https://www.rfc-editor.org/rfc/rfc2111.txt",
  key="RFC 2111",
  abstract={The Uniform Resource Locator (URL) schemes, ``cid:'' and ``mid:'' allow references to messages and the body parts of messages.  For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]},
  keywords="Hyper, Text, Markup, Language, URL, MIME",
  doi="10.17487/RFC2111",
  }

@misc{rfc2112,
  author="E. Levinson",
  title="{The MIME Multipart/Related Content-type}",
  howpublished="RFC 2112 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2112",
  pages="1--9",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2387",
url="https://www.rfc-editor.org/rfc/rfc2112.txt",
  key="RFC 2112",
  abstract={The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.  This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]},
  keywords="Hyper, Text, Markup, Language, Multipurpose, Internet,Mail, Extensions",
  doi="10.17487/RFC2112",
  }

@misc{rfc2113,
  author="D. Katz",
  title="{IP Router Alert Option}",
  howpublished="RFC 2113 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2113",
  pages="1--4",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5350, 6398",
url="https://www.rfc-editor.org/rfc/rfc2113.txt",
  key="RFC 2113",
  abstract={This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]},
  keywords="ROUT-ALERT",
  doi="10.17487/RFC2113",
  }

@misc{rfc2114,
  author="S. Chiang and J. Lee and H. Yasuda",
  title="{Data Link Switching Client Access Protocol}",
  howpublished="RFC 2114 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2114",
  pages="1--22",
  year=1997,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2114.txt",
  key="RFC 2114",
  abstract={This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="DLSCAP",
  doi="10.17487/RFC2114",
  }

@misc{rfc2115,
  author="C. Brown and F. Baker",
  title="{Management Information Base for Frame Relay DTEs Using SMIv2}",
  howpublished="RFC 2115 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2115",
  pages="1--32",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2115.txt",
  key="RFC 2115",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets.  In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]},
  keywords="FRAME-MIB, MIB",
  doi="10.17487/RFC2115",
  }

@misc{rfc2116,
  author="C. Apple and K. Rossen",
  title="{X.500 Implementations Catalog-96}",
  howpublished="RFC 2116 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2116",
  pages="1--164",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2116.txt",
  key="RFC 2116",
  abstract={This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292].  This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Directory, Services, DSA, DUA, Agent, Interfaces",
  doi="10.17487/RFC2116",
  }

@misc{rfc2117,
  author="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. Deering and M. Handley and V. Jacobson and C. Liu and P. Sharma and L. Wei",
  title="{Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification}",
  howpublished="RFC 2117 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2117",
  pages="1--66",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2362",
url="https://www.rfc-editor.org/rfc/rfc2117.txt",
  key="RFC 2117",
  abstract={This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets.  This memo defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC2117",
  }

@misc{rfc2118,
  author="G. Pall",
  title="{Microsoft Point-To-Point Compression (MPPC) Protocol}",
  howpublished="RFC 2118 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2118",
  pages="1--9",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2118.txt",
  key="RFC 2118",
  abstract={This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Point-to-Point, Protocol, PPP",
  doi="10.17487/RFC2118",
  }

@misc{rfc2119,
  author="S. Bradner",
  title="{Key words for use in RFCs to Indicate Requirement Levels}",
  howpublished="RFC 2119 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2119",
  pages="1--3",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2119.txt",
  key="RFC 2119",
  abstract={In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Standards, Track, Documents",
  doi="10.17487/RFC2119",
  }

@misc{rfc2120,
  author="D. Chadwick",
  title="{Managing the X.500 Root Naming Context}",
  howpublished="RFC 2120 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2120",
  pages="1--14",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2120.txt",
  key="RFC 2120",
  abstract={This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context.  Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="X.500-NAME, ISO, International, Standards, Organization",
  doi="10.17487/RFC2120",
  }

@misc{rfc2121,
  author="G. Armitage",
  title="{Issues affecting MARS Cluster Size}",
  howpublished="RFC 2121 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2121",
  pages="1--12",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2121.txt",
  key="RFC 2121",
  abstract={This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ATM, Asynchronous, Transfer, Mode, Multicast, IP, Internet, Protocol",
  doi="10.17487/RFC2121",
  }

@misc{rfc2122,
  author="D. Mavrakis and H. Layec and K. Kartmann",
  title="{VEMMI URL Specification}",
  howpublished="RFC 2122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2122",
  pages="1--11",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2122.txt",
  key="RFC 2122",
  abstract={A new URL scheme, ``vemmi'' is defined.  VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex.  CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]},
  keywords="VEMMI-URL, Uniform, Resource, Locator, Enhanced, Man-Machine, Interface Videotex",
  doi="10.17487/RFC2122",
  }

@misc{rfc2123,
  author="N. Brownlee",
  title="{Traffic Flow Measurement: Experiences with NeTraMet}",
  howpublished="RFC 2123 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2123",
  pages="1--34",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2123.txt",
  key="RFC 2123",
  abstract={This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB.  It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Meter, Reader, Network",
  doi="10.17487/RFC2123",
  }

@misc{rfc2124,
  author="P. Amsden and J. Amweg and P. Calato and S. Bensley and G. Lyons",
  title="{Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0}",
  howpublished="RFC 2124 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2124",
  pages="1--21",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2124.txt",
  key="RFC 2124",
  abstract={This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="LFAP",
  doi="10.17487/RFC2124",
  }

@misc{rfc2125,
  author="C. Richards and K. Smith",
  title="{The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)}",
  howpublished="RFC 2125 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2125",
  pages="1--24",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2125.txt",
  key="RFC 2125",
  abstract={This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol.  This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]},
  keywords="BAP-BACP, Point-to-Point, datagram, multilink",
  doi="10.17487/RFC2125",
  }

@misc{rfc2126,
  author="Y. Pouffary and A. Young",
  title="{ISO Transport Service on top of TCP (ITOT)}",
  howpublished="RFC 2126 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2126",
  pages="1--25",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2126.txt",
  key="RFC 2126",
  abstract={This document is a revision to STD35, RFC1006.  This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6.  It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]},
  keywords="ITOT, International, Standards, Organization, Transmission, Control, Protocol",
  doi="10.17487/RFC2126",
  }

@misc{rfc2127,
  author="G. Roeck",
  title="{ISDN Management Information Base using SMIv2}",
  howpublished="RFC 2127 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2127",
  pages="1--49",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2127.txt",
  key="RFC 2127",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]},
  keywords="ISDN-MIB, MIB, ISDN, Integrated, Services, Digital, Network",
  doi="10.17487/RFC2127",
  }

@misc{rfc2128,
  author="G. Roeck",
  title="{Dial Control Management Information Base using SMIv2}",
  howpublished="RFC 2128 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2128",
  pages="1--34",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2128.txt",
  key="RFC 2128",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]},
  keywords="DC-MIB, MIB, ISDN, Integrated, Services, Digital, Network",
  doi="10.17487/RFC2128",
  }

@misc{rfc2129,
  author="K. Nagami and Y. Katsube and Y. Shobatake and A. Mogi and S. Matsuzawa and T. Jinmei and H. Esaki",
  title="{Toshiba's Flow Attribute Notification Protocol (FANP) Specification}",
  howpublished="RFC 2129 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2129",
  pages="1--19",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2129.txt",
  key="RFC 2129",
  abstract={This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="packet, flow, datalink, mapping",
  doi="10.17487/RFC2129",
  }

@misc{rfc2130,
  author="C. Weider and C. Preston and K. Simonsen and H. Alvestrand and R. Atkinson and M. Crispin and P. Svanberg",
  title="{The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996}",
  howpublished="RFC 2130 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2130",
  pages="1--31",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6055",
url="https://www.rfc-editor.org/rfc/rfc2130.txt",
  key="RFC 2130",
  abstract={This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet.  It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Architecture, Board, interoperability",
  doi="10.17487/RFC2130",
  }

@misc{rfc2131,
  author="R. Droms",
  title="{Dynamic Host Configuration Protocol}",
  howpublished="RFC 2131 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2131",
  pages="1--45",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3396, 4361, 5494, 6842",
url="https://www.rfc-editor.org/rfc/rfc2131.txt",
  key="RFC 2131",
  abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.  DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]},
  keywords="DHCP, DHCPv4",
  doi="10.17487/RFC2131",
  }

@misc{rfc2132,
  author="S. Alexander and R. Droms",
  title="{DHCP Options and BOOTP Vendor Extensions}",
  howpublished="RFC 2132 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2132",
  pages="1--34",
  year=1997,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3442, 3942, 4361, 4833, 5494",
url="https://www.rfc-editor.org/rfc/rfc2132.txt",
  key="RFC 2132",
  abstract={This document specifies the current set of DHCP options.  Future options will be specified in separate RFCs.  The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]},
  keywords="DHCP-BOOTP, Dynamic, Host, Configuration, Protocol, Bootstrap",
  doi="10.17487/RFC2132",
  }

@misc{rfc2133,
  author="R. Gilligan and S. Thomson and J. Bound and W. Stevens",
  title="{Basic Socket Interface Extensions for IPv6}",
  howpublished="RFC 2133 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2133",
  pages="1--32",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2553",
url="https://www.rfc-editor.org/rfc/rfc2133.txt",
  key="RFC 2133",
  abstract={This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="application, program, interface, API, Internet, Protocol, addresses",
  doi="10.17487/RFC2133",
  }

@misc{rfc2134,
  author="ISOC Board of Trustees",
  title="{Articles of Incorporation of Internet Society}",
  howpublished="RFC 2134 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2134",
  pages="1--5",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2134.txt",
  key="RFC 2134",
  abstract={These are the articles of incorporation of the Internet Society.  They are published for the information of the IETF community at the request of the poisson working group.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ISOC",
  doi="10.17487/RFC2134",
  }

@misc{rfc2135,
  author="ISOC Board of Trustees",
  title="{Internet Society By-Laws}",
  howpublished="RFC 2135 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2135",
  pages="1--9",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2135.txt",
  key="RFC 2135",
  abstract={These are the by-laws of the Internet Society, as amended, as of June 1996.  They are published for the information of the IETF community at the request of the poisson working group.  Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ISOC",
  doi="10.17487/RFC2135",
  }

@misc{rfc2136,
  author="P. Vixie and S. Thomson and Y. Rekhter and J. Bound",
  title="{Dynamic Updates in the Domain Name System (DNS UPDATE)}",
  howpublished="RFC 2136 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2136",
  pages="1--26",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3007, 4035, 4033, 4034",
url="https://www.rfc-editor.org/rfc/rfc2136.txt",
  key="RFC 2136",
  abstract={Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone.  Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]},
  keywords="DNS-UPDATE, database, opcode, zone",
  doi="10.17487/RFC2136",
  }

@misc{rfc2137,
  author="D. {Eastlake 3rd}",
  title="{Secure Domain Name System Dynamic Update}",
  howpublished="RFC 2137 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2137",
  pages="1--11",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3007",
url="https://www.rfc-editor.org/rfc/rfc2137.txt",
  key="RFC 2137",
  abstract={This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]},
  keywords="SDNSDU, DNS, digital, signatures, cryptographic",
  doi="10.17487/RFC2137",
  }

@misc{rfc2138,
  author="C. Rigney and A. Rubens and W. Simpson and S. Willens",
  title="{Remote Authentication Dial In User Service (RADIUS)}",
  howpublished="RFC 2138 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2138",
  pages="1--65",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2865",
url="https://www.rfc-editor.org/rfc/rfc2138.txt",
  key="RFC 2138",
  abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]},
  keywords="RADIUS, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2138",
  }

@misc{rfc2139,
  author="C. Rigney",
  title="{RADIUS Accounting}",
  howpublished="RFC 2139 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2139",
  pages="1--25",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2866",
url="https://www.rfc-editor.org/rfc/rfc2139.txt",
  key="RFC 2139",
  abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RADIUS-ACC, remote, authentication, dial, in, user, service, encryption",
  doi="10.17487/RFC2139",
  }

@misc{rfc2140,
  author="J. Touch",
  title="{TCP Control Block Interdependence}",
  howpublished="RFC 2140 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2140",
  pages="1--11",
  year=1997,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2140.txt",
  key="RFC 2140",
  abstract={This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances.  TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2140",
  }

@misc{rfc2141,
  author="R. Moats",
  title="{URN Syntax}",
  howpublished="RFC 2141 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2141",
  pages="1--8",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8141",
url="https://www.rfc-editor.org/rfc/rfc2141.txt",
  key="RFC 2141",
  abstract={Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers.  This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]},
  keywords="URN-SYNTAX, Uniform, Resource, Names",
  doi="10.17487/RFC2141",
  }

@misc{rfc2142,
  author="D. Crocker",
  title="{Mailbox Names for Common Services, Roles and Functions}",
  howpublished="RFC 2142 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2142",
  pages="1--6",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2142.txt",
  key="RFC 2142",
  abstract={This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]},
  keywords="MAIL-SERV, email, internet, addresses",
  doi="10.17487/RFC2142",
  }

@misc{rfc2143,
  author="B. Elliston",
  title="{Encapsulating IP with the Small Computer System Interface}",
  howpublished="RFC 2143 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2143",
  pages="1--5",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2143.txt",
  key="RFC 2143",
  abstract={This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IP-SCSI, SCSI",
  doi="10.17487/RFC2143",
  }

@misc{rfc2144,
  author="C. Adams",
  title="{The CAST-128 Encryption Algorithm}",
  howpublished="RFC 2144 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2144",
  pages="1--15",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2144.txt",
  key="RFC 2144",
  abstract={There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.  This document describes an existing algorithm that can be used to satisfy this requirement.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="CAST-128",
  doi="10.17487/RFC2144",
  }

@misc{rfc2145,
  author="J. C. Mogul and R. Fielding and J. Gettys and H. Frystyk",
  title="{Use and Interpretation of HTTP Version Numbers}",
  howpublished="RFC 2145 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2145",
  pages="1--7",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7230",
url="https://www.rfc-editor.org/rfc/rfc2145.txt",
  key="RFC 2145",
  abstract={HTTP request and response messages include an HTTP protocol version number.  Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions.  This document is an attempt to clarify the situation.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2145",
  }

@misc{rfc2146,
  author="Federal Networking Council",
  title="{U.S. Government Internet Domain Names}",
  howpublished="RFC 2146 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2146",
  pages="1--12",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2146.txt",
  key="RFC 2146",
  abstract={This memo provides an update and clarification to RFC 1816.  This document describes the registration policies for the top-level domain ``.GOV''.  The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources.  This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public.  It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Gov, FED.US",
  doi="10.17487/RFC2146",
  }

@misc{rfc2147,
  author="D. Borman",
  title="{TCP and UDP over IPv6 Jumbograms}",
  howpublished="RFC 2147 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2147",
  pages="1--3",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2675",
url="https://www.rfc-editor.org/rfc/rfc2147.txt",
  key="RFC 2147",
  abstract={IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option.  The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits.  This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]},
  keywords="IPv6-Jumbo, User, Datagram, Protocol, Terminal, Control, Internet",
  doi="10.17487/RFC2147",
  }

@misc{rfc2148,
  author="H. Alvestrand and P. Jurg",
  title="{Deployment of the Internet White Pages Service}",
  howpublished="RFC 2148 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2148",
  pages="1--15",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2148.txt",
  key="RFC 2148",
  abstract={This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="X. 500, data structure, naming scheme, IWPS",
  doi="10.17487/RFC2148",
  }

@misc{rfc2149,
  author="R. Talpade and M. Ammar",
  title="{Multicast Server Architectures for MARS-based ATM multicasting}",
  howpublished="RFC 2149 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2149",
  pages="1--18",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2149.txt",
  key="RFC 2149",
  abstract={This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022.  It also provides a mechanism for using multiple MCSs per group for providing fault tolerance.  This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2149",
  }

@misc{rfc2150,
  author="J. Max and W. Stickle",
  title="{Humanities and Arts: Sharing Center Stage on the Internet}",
  howpublished="RFC 2150 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2150",
  pages="1--62",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2150.txt",
  key="RFC 2150",
  abstract={The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="informational, infrastructure, guide, introduction",
  doi="10.17487/RFC2150",
  }

@misc{rfc2151,
  author="G. Kessler and S. Shepard",
  title="{A Primer On Internet and TCP/IP Tools and Utilities}",
  howpublished="RFC 2151 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2151",
  pages="1--52",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2151.txt",
  key="RFC 2151",
  abstract={This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities.  It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="resource, guide, user",
  doi="10.17487/RFC2151",
  }

@misc{rfc2152,
  author="D. Goldsmith and M. Davis",
  title="{UTF-7 A Mail-Safe Transformation Format of Unicode}",
  howpublished="RFC 2152 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2152",
  pages="1--15",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2152.txt",
  key="RFC 2152",
  abstract={This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire.  It also specifies how this transformation format is used in the context of MIME and RFC 1641, ``Using Unicode with MIME''.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="UTF-7",
  doi="10.17487/RFC2152",
  }

@misc{rfc2153,
  author="W. Simpson",
  title="{PPP Vendor Extensions}",
  howpublished="RFC 2153 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2153",
  pages="1--6",
  year=1997,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5342, 7042",
url="https://www.rfc-editor.org/rfc/rfc2153.txt",
  key="RFC 2153",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.  This document provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="PPP-EXT, Point-to-Point, Protocol",
  doi="10.17487/RFC2153",
  }

@misc{rfc2154,
  author="S. Murphy and M. Badger and B. Wellington",
  title="{OSPF with Digital Signatures}",
  howpublished="RFC 2154 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2154",
  pages="1--29",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2154.txt",
  key="RFC 2154",
  abstract={This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data.  Added LSA processing and key management is detailed.  A method for migration from, or co-existence with, standard OSPF V2 is described.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="OSPF-DIG",
  doi="10.17487/RFC2154",
  }

@misc{rfc2155,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for APPN using SMIv2}",
  howpublished="RFC 2155 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2155",
  pages="1--124",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2455",
url="https://www.rfc-editor.org/rfc/rfc2155.txt",
  key="RFC 2155",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities.  This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]},
  keywords="APPN-MIB",
  doi="10.17487/RFC2155",
  }

@misc{rfc2156,
  author="S. Kille",
  title="{MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME}",
  howpublished="RFC 2156 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2156",
  pages="1--144",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2156.txt",
  key="RFC 2156",
  abstract={This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard.  This ISO/ITU-T standard is referred to in this document as ``X.400'', which is a convenient shorthand. [STANDARDS-TRACK]},
  keywords="MIXER, multipurpose, internet, mail, extensions, message, transfer, protocol",
  doi="10.17487/RFC2156",
  }

@misc{rfc2157,
  author="H. Alvestrand",
  title="{Mapping between X.400 and RFC-822/MIME Message Bodies}",
  howpublished="RFC 2157 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2157",
  pages="1--49",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2157.txt",
  key="RFC 2157",
  abstract={This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]},
  keywords="mixer, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2157",
  }

@misc{rfc2158,
  author="H. Alvestrand",
  title="{X.400 Image Body Parts}",
  howpublished="RFC 2158 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2158",
  pages="1--4",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2158.txt",
  key="RFC 2158",
  abstract={This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]},
  keywords="mixer, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2158",
  }

@misc{rfc2159,
  author="H. Alvestrand",
  title="{A MIME Body Part for FAX}",
  howpublished="RFC 2159 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2159",
  pages="1--7",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2159.txt",
  key="RFC 2159",
  abstract={This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]},
  keywords="mixer, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2159",
  }

@misc{rfc2160,
  author="H. Alvestrand",
  title="{Carrying PostScript in X.400 and MIME}",
  howpublished="RFC 2160 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2160",
  pages="1--5",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2160.txt",
  key="RFC 2160",
  abstract={This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]},
  keywords="mixer, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2160",
  }

@misc{rfc2161,
  author="H. Alvestrand",
  title="{A MIME Body Part for ODA}",
  howpublished="RFC 2161 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2161",
  pages="1--5",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2161.txt",
  key="RFC 2161",
  abstract={This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIME-ODA, mixer, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2161",
  }

@misc{rfc2162,
  author="C. Allocchio",
  title="{MaXIM-11 - Mapping between X.400 / Internet mail and  Mail-11 mail}",
  howpublished="RFC 2162 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2162",
  pages="1--34",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2162.txt",
  key="RFC 2162",
  abstract={The standard referred shortly into this document as ``X.400'' relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS).  This document covers the Inter Personal Messaging System (IPMS) only.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MAP-MAIL, mixer, multipurpose, internet, mail, extensions, mime",
  doi="10.17487/RFC2162",
  }

@misc{rfc2163,
  author="C. Allocchio",
  title="{Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)}",
  howpublished="RFC 2163 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2163",
  pages="1--26",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3597",
url="https://www.rfc-editor.org/rfc/rfc2163.txt",
  key="RFC 2163",
  abstract={This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]},
  keywords="DNS-MCGAM, mime, internet, enhanced, Relay, Multipurpose, internet, mail, extensions, x.400, mixer",
  doi="10.17487/RFC2163",
  }

@misc{rfc2164,
  author="S. Kille",
  title="{Use of an X.500/LDAP directory to support MIXER address mapping}",
  howpublished="RFC 2164 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2164",
  pages="1--10",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2164.txt",
  key="RFC 2164",
  abstract={This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, mime, internet, x,.400, enhanced, relay",
  doi="10.17487/RFC2164",
  }

@misc{rfc2165,
  author="J. Veizades and E. Guttman and C. Perkins and S. Kaplan",
  title="{Service Location Protocol}",
  howpublished="RFC 2165 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2165",
  pages="1--72",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2608, 2609",
url="https://www.rfc-editor.org/rfc/rfc2165.txt",
  key="RFC 2165",
  abstract={The Service Location Protocol provides a scalable framework for the discovery and selection of network services.  Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.  This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]},
  keywords="SLP",
  doi="10.17487/RFC2165",
  }

@misc{rfc2166,
  author="D. Bryant and P. Brittain",
  title="{APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements}",
  howpublished="RFC 2166 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2166",
  pages="1--34",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2166.txt",
  key="RFC 2166",
  abstract={This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2166",
  }

@misc{rfc2167,
  author="S. Williamson and M. Kosters and D. Blacka and J. Singh and K. Zeilstra",
  title="{Referral Whois (RWhois) Protocol V1.5}",
  howpublished="RFC 2167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2167",
  pages="1--69",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2167.txt",
  key="RFC 2167",
  abstract={This memo describes Version 1.5 of the client/server interaction of RWhois.  RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="RWHOIS",
  doi="10.17487/RFC2167",
  }

@misc{rfc2168,
  author="R. Daniel and M. Mealling",
  title="{Resolution of Uniform Resource Identifiers using the Domain Name System}",
  howpublished="RFC 2168 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2168",
  pages="1--20",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3401, 3402, 3403, 3404, updated by RFC 2915",
url="https://www.rfc-editor.org/rfc/rfc2168.txt",
  key="RFC 2168",
  abstract={The requirements document for URN resolution systems defines the concept of a ``resolver discovery service''.  This document describes the first, experimental, RDS.  It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names.  This memo defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC2168",
  }

@misc{rfc2169,
  author="R. Daniel",
  title="{A Trivial Convention for using HTTP in URN Resolution}",
  howpublished="RFC 2169 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2169",
  pages="1--9",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2169.txt",
  key="RFC 2169",
  abstract={This document specifies the ``THTTP'' resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="",
  doi="10.17487/RFC2169",
  }

@misc{rfc2170,
  author="W. Almesberger and J. Le Boudec and P. Oechslin",
  title="{Application REQuested IP over ATM (AREQUIPA)}",
  howpublished="RFC 2170 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2170",
  pages="1--10",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2170.txt",
  key="RFC 2170",
  abstract={This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol",
  doi="10.17487/RFC2170",
  }

@misc{rfc2171,
  author="K. Murakami and M. Maruyama",
  title="{MAPOS - Multiple Access Protocol over SONET/SDH Version 1}",
  howpublished="RFC 2171 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2171",
  pages="1--9",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2171.txt",
  key="RFC 2171",
  abstract={This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="MAPOS-SONET",
  doi="10.17487/RFC2171",
  }

@misc{rfc2172,
  author="M. Maruyama and K. Murakami",
  title="{MAPOS Version 1 Assigned Numbers}",
  howpublished="RFC 2172 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2172",
  pages="1--3",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2172.txt",
  key="RFC 2172",
  abstract={This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2172",
  }

@misc{rfc2173,
  author="K. Murakami and M. Maruyama",
  title="{A MAPOS version 1 Extension - Node Switch Protocol}",
  howpublished="RFC 2173 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2173",
  pages="1--6",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2173.txt",
  key="RFC 2173",
  abstract={This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2173",
  }

@misc{rfc2174,
  author="K. Murakami and M. Maruyama",
  title="{A MAPOS version 1 Extension - Switch-Switch Protocol}",
  howpublished="RFC 2174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2174",
  pages="1--22",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2174.txt",
  key="RFC 2174",
  abstract={This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2174",
  }

@misc{rfc2175,
  author="K. Murakami and M. Maruyama",
  title="{MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing}",
  howpublished="RFC 2175 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2175",
  pages="1--6",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2175.txt",
  key="RFC 2175",
  abstract={This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2175",
  }

@misc{rfc2176,
  author="K. Murakami and M. Maruyama",
  title="{IPv4 over MAPOS Version 1}",
  howpublished="RFC 2176 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2176",
  pages="1--6",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc2176.txt",
  key="RFC 2176",
  abstract={This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="IPV4-MAPOS",
  doi="10.17487/RFC2176",
  }

@misc{rfc2177,
  author="B. Leiba",
  title="{IMAP4 IDLE command}",
  howpublished="RFC 2177 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2177",
  pages="1--4",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2177.txt",
  key="RFC 2177",
  abstract={This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]},
  keywords="IMAP4-IDLE",
  doi="10.17487/RFC2177",
  }

@misc{rfc2178,
  author="J. Moy",
  title="{OSPF Version 2}",
  howpublished="RFC 2178 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2178",
  pages="1--211",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2328",
url="https://www.rfc-editor.org/rfc/rfc2178.txt",
  key="RFC 2178",
  abstract={This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]},
  keywords="Open, Shortest, Path, First, routing, Autonomous, system, AS",
  doi="10.17487/RFC2178",
  }

@misc{rfc2179,
  author="A. Gwinn",
  title="{Network Security For Trade Shows}",
  howpublished="RFC 2179 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2179",
  pages="1--10",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2179.txt",
  key="RFC 2179",
  abstract={This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="network, system, attacks",
  doi="10.17487/RFC2179",
  }

@misc{rfc2180,
  author="M. Gahrns",
  title="{IMAP4 Multi-Accessed Mailbox Practice}",
  howpublished="RFC 2180 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2180",
  pages="1--14",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2180.txt",
  key="RFC 2180",
  abstract={The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable.  The behavior described within this document is believed to be [RFC-2060] compliant.  However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Message, Access, Protocol, Client, Server",
  doi="10.17487/RFC2180",
  }

@misc{rfc2181,
  author="R. Elz and R. Bush",
  title="{Clarifications to the DNS Specification}",
  howpublished="RFC 2181 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2181",
  pages="1--14",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4035, 2535, 4343, 4033, 4034, 5452",
url="https://www.rfc-editor.org/rfc/rfc2181.txt",
  key="RFC 2181",
  abstract={This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]},
  keywords="DNS-CLAR, Domain, Name, System",
  doi="10.17487/RFC2181",
  }

@misc{rfc2182,
  author="R. Elz and R. Bush and S. Bradner and M. Patton",
  title="{Selection and Operation of Secondary DNS Servers}",
  howpublished="RFC 2182 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2182",
  pages="1--11",
  year=1997,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2182.txt",
  key="RFC 2182",
  abstract={This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Domain, Name, System, delegated, zone",
  doi="10.17487/RFC2182",
  }

@misc{rfc2183,
  author="R. Troost and S. Dorner and K. Moore",
  title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field}",
  howpublished="RFC 2183 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2183",
  pages="1--12",
  year=1997,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2184, 2231",
url="https://www.rfc-editor.org/rfc/rfc2183.txt",
  key="RFC 2183",
  abstract={This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information.  It specifies the ``Content- Disposition'' header field, which is optional and valid for any MIME entity (``message'' or ``body part''). [STANDARDS-TRACK]},
  keywords="inline, attachment, MIME, Mail, Multimedia, EMail",
  doi="10.17487/RFC2183",
  }

@misc{rfc2184,
  author="N. Freed and K. Moore",
  title="{MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations}",
  howpublished="RFC 2184 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2184",
  pages="1--9",
  year=1997,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2231",
url="https://www.rfc-editor.org/rfc/rfc2184.txt",
  key="RFC 2184",
  abstract={This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]},
  keywords="mail, Multimedia, EMail",
  doi="10.17487/RFC2184",
  }

@misc{rfc2185,
  author="R. Callon and D. Haskin",
  title="{Routing Aspects of IPv6 Transition}",
  howpublished="RFC 2185 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2185",
  pages="1--13",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2185.txt",
  key="RFC 2185",
  abstract={This document gives an overview of the routing aspects of the IPv6 transition.  It is based on the protocols defined in the document ``Transition Mechanisms for IPv6 Hosts and Routers.'' Readers should be familiar with the transition mechanisms before reading this document.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="address, network, tunneling",
  doi="10.17487/RFC2185",
  }

@misc{rfc2186,
  author="D. Wessels and K. Claffy",
  title="{Internet Cache Protocol (ICP), version 2}",
  howpublished="RFC 2186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2186",
  pages="1--9",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2186.txt",
  key="RFC 2186",
  abstract={This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ICP, www, web, http, hypertext, transfer, protocol",
  doi="10.17487/RFC2186",
  }

@misc{rfc2187,
  author="D. Wessels and K. Claffy",
  title="{Application of Internet Cache Protocol (ICP), version 2}",
  howpublished="RFC 2187 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2187",
  pages="1--24",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2187.txt",
  key="RFC 2187",
  abstract={This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="web, www, url, uniform, resource, identifier",
  doi="10.17487/RFC2187",
  }

@misc{rfc2188,
  author="M. Banan and M. Taylor and J. Cheng",
  title="{AT\&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2}",
  howpublished="RFC 2188 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2188",
  pages="1--57",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2188.txt",
  key="RFC 2188",
  abstract={This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO).  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ESRO, RPC, Remote, Procedure, Call, Wireless",
  doi="10.17487/RFC2188",
  }

@misc{rfc2189,
  author="A. Ballardie",
  title="{Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --}",
  howpublished="RFC 2189 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2189",
  pages="1--23",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2189.txt",
  key="RFC 2189",
  abstract={This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol.  CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Inter-Domain-Protocol, IDMR",
  doi="10.17487/RFC2189",
  }

@misc{rfc2190,
  author="C. Zhu",
  title="{RTP Payload Format for H.263 Video Streams}",
  howpublished="RFC 2190 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2190",
  pages="1--12",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2190.txt",
  key="RFC 2190",
  abstract={This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]},
  keywords="real-time, transfer",
  doi="10.17487/RFC2190",
  }

@misc{rfc2191,
  author="G. Armitage",
  title="{VENUS - Very Extensive Non-Unicast Service}",
  howpublished="RFC 2191 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2191",
  pages="1--12",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2191.txt",
  key="RFC 2191",
  abstract={This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet.  It describes a hypothetical solution, dubbed ``Very Extensive NonUnicast Service'' (VENUS), and shows how complex such a service would be.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="multicast, IP, ATM",
  doi="10.17487/RFC2191",
  }

@misc{rfc2192,
  author="C. Newman",
  title="{IMAP URL Scheme}",
  howpublished="RFC 2192 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2192",
  pages="1--16",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5092",
url="https://www.rfc-editor.org/rfc/rfc2192.txt",
  key="RFC 2192",
  abstract={This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]},
  keywords="IMAP-URL, Internet, Message, Access, Protocol, Uniform, Resource, Identifiers",
  doi="10.17487/RFC2192",
  }

@misc{rfc2193,
  author="M. Gahrns",
  title="{IMAP4 Mailbox Referrals}",
  howpublished="RFC 2193 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2193",
  pages="1--9",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2193.txt",
  key="RFC 2193",
  abstract={Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]},
  keywords="IMAP4MAIL, Internet, Mail, Access, Protocol, messages",
  doi="10.17487/RFC2193",
  }

@misc{rfc2194,
  author="B. Aboba and J. Lu and J. Alsop and J. Ding and W. Wang",
  title="{Review of Roaming Implementations}",
  howpublished="RFC 2194 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2194",
  pages="1--35",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2194.txt",
  key="RFC 2194",
  abstract={This document reviews the design and functionality of existing roaming implementations.  Examples of cases where roaming capability might be required include ISP ``confederations'' and ISP-provided corporate network access support.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="ISP, Internet, Server, Provider",
  doi="10.17487/RFC2194",
  }

@misc{rfc2195,
  author="J. Klensin and R. Catoe and P. Krumviede",
  title="{IMAP/POP AUTHorize Extension for Simple Challenge/Response}",
  howpublished="RFC 2195 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2195",
  pages="1--5",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2195.txt",
  key="RFC 2195",
  abstract={This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]},
  keywords="IMAPPOPAU, Post, Office, Protocol, Internet, Message, Access",
  doi="10.17487/RFC2195",
  }

@misc{rfc2196,
  author="B. Fraser",
  title="{Site Security Handbook}",
  howpublished="RFC 2196 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2196",
  pages="1--75",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2196.txt",
  key="RFC 2196",
  abstract={This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet.  The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services.  The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2196",
  }

@misc{rfc2197,
  author="N. Freed",
  title="{SMTP Service Extension for Command Pipelining}",
  howpublished="RFC 2197 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2197",
  pages="1--8",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2920",
url="https://www.rfc-editor.org/rfc/rfc2197.txt",
  key="RFC 2197",
  abstract={This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]},
  keywords="SMTP-Pipe, simple, mail, transfer, TCP, transmission, control, protocol",
  doi="10.17487/RFC2197",
  }

@misc{rfc2198,
  author="C. Perkins and I. Kouvelas and O. Hodson and V. Hardman and M. Handley and J.C. Bolot and A. Vega-Garcia and S. Fosse-Parisis",
  title="{RTP Payload for Redundant Audio Data}",
  howpublished="RFC 2198 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2198",
  pages="1--11",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6354",
url="https://www.rfc-editor.org/rfc/rfc2198.txt",
  key="RFC 2198",
  abstract={This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]},
  keywords="RTP-RAD",
  doi="10.17487/RFC2198",
  }

@misc{rfc2199,
  author="A. Ramos",
  title="{Request for Comments Summary RFC Numbers 2100-2199}",
  howpublished="RFC 2199 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2199",
  pages="1--23",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2199.txt",
  key="RFC 2199",
  doi="10.17487/RFC2199",
  }

@misc{rfc2200,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2200 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2200",
  pages="1--39",
  year=1997,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2300",
url="https://www.rfc-editor.org/rfc/rfc2200.txt",
  key="RFC 2200",
  abstract={A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms.  Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization.  Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC2200",
  }

@misc{rfc2201,
  author="A. Ballardie",
  title="{Core Based Trees (CBT) Multicast Routing Architecture}",
  howpublished="RFC 2201 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2201",
  pages="1--15",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2201.txt",
  key="RFC 2201",
  abstract={CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IP, Internet, Protocol, IDMR, Inter-Domain",
  doi="10.17487/RFC2201",
  }

@misc{rfc2202,
  author="P. Cheng and R. Glenn",
  title="{Test Cases for HMAC-MD5 and HMAC-SHA-1}",
  howpublished="RFC 2202 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2202",
  pages="1--9",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2202.txt",
  key="RFC 2202",
  abstract={This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively.  HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Hash, Message, Authentications, Codes, message, digest, secure",
  doi="10.17487/RFC2202",
  }

@misc{rfc2203,
  author="M. Eisler and A. Chiu and L. Ling",
  title="{RPCSEC\_GSS Protocol Specification}",
  howpublished="RFC 2203 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2203",
  pages="1--23",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5403",
url="https://www.rfc-editor.org/rfc/rfc2203.txt",
  key="RFC 2203",
  abstract={This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]},
  keywords="RPCSEC-GSS, Remote, Procedure, Call, Generic, Security, Services, API, Application, Programming, Interface",
  doi="10.17487/RFC2203",
  }

@misc{rfc2204,
  author="D. Nash",
  title="{ODETTE File Transfer Protocol}",
  howpublished="RFC 2204 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2204",
  pages="1--74",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5024",
url="https://www.rfc-editor.org/rfc/rfc2204.txt",
  key="RFC 2204",
  abstract={This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ODETTE, FTP, Internet, Motor, Industry, data, exchange",
  doi="10.17487/RFC2204",
  }

@misc{rfc2205,
  author="R. Braden and L. Zhang and S. Berson and S. Herzog and S. Jamin",
  title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification}",
  howpublished="RFC 2205 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2205",
  pages="1--112",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2750, 3936, 4495, 5946, 6437, 6780",
url="https://www.rfc-editor.org/rfc/rfc2205.txt",
  key="RFC 2205",
  abstract={This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet.  RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]},
  keywords="RSVP, integrated, services, multicast, unicast, QoS, signaling",
  doi="10.17487/RFC2205",
  }

@misc{rfc2206,
  author="F. Baker and J. Krawczyk and A. Sastry",
  title="{RSVP Management Information Base using SMIv2}",
  howpublished="RFC 2206 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2206",
  pages="1--64",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2206.txt",
  key="RFC 2206",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]},
  keywords="RSVP-MIB",
  doi="10.17487/RFC2206",
  }

@misc{rfc2207,
  author="L. Berger and T. O'Malley",
  title="{RSVP Extensions for IPSEC Data Flows}",
  howpublished="RFC 2207 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2207",
  pages="1--14",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2207.txt",
  key="RFC 2207",
  abstract={This document presents extensions to Version 1 of RSVP.  These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="RSVP-IPSEC, resource, reservation, QoS, IP, Security",
  doi="10.17487/RFC2207",
  }

@misc{rfc2208,
  author="A. Mankin and F. Baker and B. Braden and S. Bradner and M. O'Dell and A. Romanow and A. Weinrib and L. Zhang",
  title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment}",
  howpublished="RFC 2208 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2208",
  pages="1--6",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2208.txt",
  key="RFC 2208",
  abstract={This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="RSVP",
  doi="10.17487/RFC2208",
  }

@misc{rfc2209,
  author="R. Braden and L. Zhang",
  title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules}",
  howpublished="RFC 2209 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2209",
  pages="1--25",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2209.txt",
  key="RFC 2209",
  abstract={This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages.  It is intended to clarify the version 1 RSVP protocol specification.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="RSVP-MPR, QoS, implementation, algorithms",
  doi="10.17487/RFC2209",
  }

@misc{rfc2210,
  author="J. Wroclawski",
  title="{The Use of RSVP with IETF Integrated Services}",
  howpublished="RFC 2210 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2210",
  pages="1--33",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2210.txt",
  key="RFC 2210",
  abstract={This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]},
  keywords="RSVP-IS, Resource, Reservation, Controlled, Load, QOS: Quality of Service",
  doi="10.17487/RFC2210",
  }

@misc{rfc2211,
  author="J. Wroclawski",
  title="{Specification of the Controlled-Load Network Element Service}",
  howpublished="RFC 2211 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2211",
  pages="1--19",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2211.txt",
  key="RFC 2211",
  abstract={This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]},
  keywords="QOS: Quality of Service, integrated services",
  doi="10.17487/RFC2211",
  }

@misc{rfc2212,
  author="S. Shenker and C. Partridge and R. Guerin",
  title="{Specification of Guaranteed Quality of Service}",
  howpublished="RFC 2212 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2212",
  pages="1--20",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2212.txt",
  key="RFC 2212",
  abstract={This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]},
  keywords="GQOS, QOS, quality of service, integrated services",
  doi="10.17487/RFC2212",
  }

@misc{rfc2213,
  author="F. Baker and J. Krawczyk and A. Sastry",
  title="{Integrated Services Management Information Base using SMIv2}",
  howpublished="RFC 2213 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2213",
  pages="1--21",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2213.txt",
  key="RFC 2213",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC2213",
  }

@misc{rfc2214,
  author="F. Baker and J. Krawczyk and A. Sastry",
  title="{Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2}",
  howpublished="RFC 2214 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2214",
  pages="1--9",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2214.txt",
  key="RFC 2214",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]},
  keywords="MIB, attributes, interface, network, protocol",
  doi="10.17487/RFC2214",
  }

@misc{rfc2215,
  author="S. Shenker and J. Wroclawski",
  title="{General Characterization Parameters for Integrated Service Network Elements}",
  howpublished="RFC 2215 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2215",
  pages="1--16",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2215.txt",
  key="RFC 2215",
  abstract={This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]},
  keywords="QOS, Quality of service",
  doi="10.17487/RFC2215",
  }

@misc{rfc2216,
  author="S. Shenker and J. Wroclawski",
  title="{Network Element Service Specification Template}",
  howpublished="RFC 2216 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2216",
  pages="1--22",
  year=1997,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2216.txt",
  key="RFC 2216",
  abstract={This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service.  The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a ``template'' which service specification documents should follow.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="QOS, Quality, of, Service, Control",
  doi="10.17487/RFC2216",
  }

@misc{rfc2217,
  author="G. Clark",
  title="{Telnet Com Port Control Option}",
  howpublished="RFC 2217 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2217",
  pages="1--14",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2217.txt",
  key="RFC 2217",
  abstract={This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TOPT-COMPORT, remote, login, host",
  doi="10.17487/RFC2217",
  }

@misc{rfc2218,
  author="T. Genovese and B. Jennings",
  title="{A Common Schema for the Internet White Pages Service}",
  howpublished="RFC 2218 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2218",
  pages="1--8",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2218.txt",
  key="RFC 2218",
  abstract={This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]},
  keywords="IWPS, information, user",
  doi="10.17487/RFC2218",
  }

@misc{rfc2219,
  author="M. Hamilton and R. Wright",
  title="{Use of DNS Aliases for Network Services}",
  howpublished="RFC 2219 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2219",
  pages="1--8",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2219.txt",
  key="RFC 2219",
  abstract={It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers.  This is desirable for a number of reasons.  It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server.  Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names.  This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="domain, name, system, symbolic",
  doi="10.17487/RFC2219",
  }

@misc{rfc2220,
  author="R. Guenther",
  title="{The Application/MARC Content-type}",
  howpublished="RFC 2220 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2220",
  pages="1--4",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2220.txt",
  key="RFC 2220",
  abstract={This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC).  The MARC formats are standards for the representation and communication of bibliographic and related information.  A MARC record contains metadata for an information resource following MARC format specifications.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="APP-MARC, media-type, machine, readable, cataloging, records",
  doi="10.17487/RFC2220",
  }

@misc{rfc2221,
  author="M. Gahrns",
  title="{IMAP4 Login Referrals}",
  howpublished="RFC 2221 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2221",
  pages="1--5",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2221.txt",
  key="RFC 2221",
  abstract={When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another.  Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]},
  keywords="IMAP4LOGIN, Internet, Message, Access, Protocol, server",
  doi="10.17487/RFC2221",
  }

@misc{rfc2222,
  author="J. Myers",
  title="{Simple Authentication and Security Layer (SASL)}",
  howpublished="RFC 2222 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2222",
  pages="1--16",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4422, 4752, updated by RFC 2444",
url="https://www.rfc-editor.org/rfc/rfc2222.txt",
  key="RFC 2222",
  abstract={This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]},
  keywords="SASL, encryption, protocol, specific",
  doi="10.17487/RFC2222",
  }

@misc{rfc2223,
  author="J. Postel and J. Reynolds",
  title="{Instructions to RFC Authors}",
  howpublished="RFC 2223 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2223",
  pages="1--20",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7322, updated by RFCs 5741, 6949",
url="https://www.rfc-editor.org/rfc/rfc2223.txt",
  key="RFC 2223",
  abstract={This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Request, For, Comment",
  doi="10.17487/RFC2223",
  }

@misc{rfc2224,
  author="B. Callaghan",
  title="{NFS URL Scheme}",
  howpublished="RFC 2224 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2224",
  pages="1--11",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2224.txt",
  key="RFC 2224",
  abstract={A new URL scheme, 'nfs' is defined.  It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, ``Uniform Resource Locators (URL)''.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="NFS-URL, Universal, Resource, Locators, Network, File, System, syntax, directories",
  doi="10.17487/RFC2224",
  }

@misc{rfc2225,
  author="M. Laubach and J. Halpern",
  title="{Classical IP and ARP over ATM}",
  howpublished="RFC 2225 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2225",
  pages="1--28",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc2225.txt",
  key="RFC 2225",
  abstract={This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]},
  keywords="IP-ATM, Internet, protocol, address, resolution, asynchronous,transfer, mode",
  doi="10.17487/RFC2225",
  }

@misc{rfc2226,
  author="T. Smith and G. Armitage",
  title="{IP Broadcast over ATM Networks}",
  howpublished="RFC 2226 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2226",
  pages="1--14",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2226.txt",
  key="RFC 2226",
  abstract={This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]},
  keywords="Internet, Protocol, Asynchronous, Transfer, Mode",
  doi="10.17487/RFC2226",
  }

@misc{rfc2227,
  author="J. Mogul and P. Leach",
  title="{Simple Hit-Metering and Usage-Limiting for HTTP}",
  howpublished="RFC 2227 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2227",
  pages="1--37",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2227.txt",
  key="RFC 2227",
  abstract={This document proposes a simple extension to HTTP, using a new ``Meter'' header. [STANDARDS-TRACK]},
  keywords="Hypertext, Transfer, Protocol, extension",
  doi="10.17487/RFC2227",
  }

@misc{rfc2228,
  author="M. Horowitz and S. Lunt",
  title="{FTP Security Extensions}",
  howpublished="RFC 2228 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2228",
  pages="1--27",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2228.txt",
  key="RFC 2228",
  abstract={This document defines extensions to the FTP specification STD 9, RFC},
  keywords="FTPSECEXT, file, transfer, protocol, authentication, encoding",
  doi="10.17487/RFC2228",
  }

@misc{rfc2229,
  author="R. Faith and B. Martin",
  title="{A Dictionary Server Protocol}",
  howpublished="RFC 2229 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2229",
  pages="1--30",
  year=1997,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2229.txt",
  key="RFC 2229",
  abstract={The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="DSP, DICT, TCP, Transmission, Control, Protocol, database, definitions",
  doi="10.17487/RFC2229",
  }

@misc{rfc2230,
  author="R. Atkinson",
  title="{Key Exchange Delegation Record for the DNS}",
  howpublished="RFC 2230 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2230",
  pages="1--11",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2230.txt",
  key="RFC 2230",
  abstract={This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS.  This mechanism is intended to be used only with the Secure DNS.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="KEYX-DNS, Domain, Name, System, RR, Resource, Record, KX",
  doi="10.17487/RFC2230",
  }

@misc{rfc2231,
  author="N. Freed and K. Moore",
  title="{MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations}",
  howpublished="RFC 2231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2231",
  pages="1--10",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2231.txt",
  key="RFC 2231",
  abstract={This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms.  This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]},
  keywords="MIME-EXT, Mail, Multimedia, EMail",
  doi="10.17487/RFC2231",
  }

@misc{rfc2232,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for DLUR using SMIv2}",
  howpublished="RFC 2232 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2232",
  pages="1--21",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2232.txt",
  key="RFC 2232",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities.  This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]},
  keywords="DLUR-MIB, Management, Information Base, MIB, Dependent LU Requester, APPN, Advanced, Peek, to Peek Networking",
  doi="10.17487/RFC2232",
  }

@misc{rfc2233,
  author="K. McCloghrie and F. Kastenholz",
  title="{The Interfaces Group MIB using SMIv2}",
  howpublished="RFC 2233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2233",
  pages="1--66",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2863",
url="https://www.rfc-editor.org/rfc/rfc2233.txt",
  key="RFC 2233",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]},
  keywords="INTERGRMIB, Management, Information, Base, Network",
  doi="10.17487/RFC2233",
  }

@misc{rfc2234,
  author="D. Crocker and P. Overell",
  title="{Augmented BNF for Syntax Specifications: ABNF}",
  howpublished="RFC 2234 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2234",
  pages="1--14",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4234",
url="https://www.rfc-editor.org/rfc/rfc2234.txt",
  key="RFC 2234",
  abstract={In the early days of the Arpanet, each specification contained its own definition of ABNF.  This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF.  The current document separates out that definition, to permit selective reference.  Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]},
  keywords="ABNF, Augmented, Backus-Naur, Form, electronic, mail",
  doi="10.17487/RFC2234",
  }

@misc{rfc2235,
  author="R. Zakon",
  title="{Hobbes' Internet Timeline}",
  howpublished="RFC 2235 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2235",
  pages="1--22",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2235.txt",
  key="RFC 2235",
  abstract={This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today.  A growth summary of the Internet and some associated technologies is also included.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="events, technologies, history",
  doi="10.17487/RFC2235",
  }

@misc{rfc2236,
  author="W. Fenner",
  title="{Internet Group Management Protocol, Version 2}",
  howpublished="RFC 2236 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2236",
  pages="1--24",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3376",
url="https://www.rfc-editor.org/rfc/rfc2236.txt",
  key="RFC 2236",
  abstract={This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers.  It updates STD 5, RFC 1112. [STANDARDS-TRACK]},
  keywords="IGMP, IGMP, multicast, routing, IP, Internet, Protocol",
  doi="10.17487/RFC2236",
  }

@misc{rfc2237,
  author="K. Tamaru",
  title="{Japanese Character Encoding for Internet Messages}",
  howpublished="RFC 2237 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2237",
  pages="1--6",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2237.txt",
  key="RFC 2237",
  abstract={This memo defines an encoding scheme for the Japanese Characters, describes ``ISO-2022-JP-1'', which is used in electronic mail [RFC-822], and network news [RFC 1036].  Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="eletronic, mail, character, set, scheme",
  doi="10.17487/RFC2237",
  }

@misc{rfc2238,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for HPR using SMIv2}",
  howpublished="RFC 2238 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2238",
  pages="1--35",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2238.txt",
  key="RFC 2238",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities.  This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]},
  keywords="HPR-MIB, MIB, Management, Information, Base, high, performance, routing",
  doi="10.17487/RFC2238",
  }

@misc{rfc2239,
  author="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie and S. Roberts",
  title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2}",
  howpublished="RFC 2239 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2239",
  pages="1--43",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2668",
url="https://www.rfc-editor.org/rfc/rfc2239.txt",
  key="RFC 2239",
  abstract={This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, ``10 \& 100 Mb/s Management,'' October 26, 1995. [STANDARDS-TRACK]},
  keywords="MAUS-MIB",
  doi="10.17487/RFC2239",
  }

@misc{rfc2240,
  author="O. Vaughan",
  title="{A Legal Basis for Domain Name Allocation}",
  howpublished="RFC 2240 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2240",
  pages="1--7",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2352",
url="https://www.rfc-editor.org/rfc/rfc2240.txt",
  key="RFC 2240",
  abstract={The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="DNS",
  doi="10.17487/RFC2240",
  }

@misc{rfc2241,
  author="D. Provan",
  title="{DHCP Options for Novell Directory Services}",
  howpublished="RFC 2241 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2241",
  pages="1--5",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2241.txt",
  key="RFC 2241",
  abstract={This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services.  This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]},
  keywords="DHCP-NDS, NDS",
  doi="10.17487/RFC2241",
  }

@misc{rfc2242,
  author="R. Droms and K. Fong",
  title="{NetWare/IP Domain Name and Information}",
  howpublished="RFC 2242 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2242",
  pages="1--6",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2242.txt",
  key="RFC 2242",
  abstract={This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]},
  keywords="NETWAREIP, DHCP",
  doi="10.17487/RFC2242",
  }

@misc{rfc2243,
  author="C. Metz",
  title="{OTP Extended Responses}",
  howpublished="RFC 2243 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2243",
  pages="1--10",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2243.txt",
  key="RFC 2243",
  abstract={This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding.  This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]},
  keywords="OTP-ER, One, Time, Password",
  doi="10.17487/RFC2243",
  }

@misc{rfc2244,
  author="C. Newman and J. G. Myers",
  title="{ACAP -- Application Configuration Access Protocol}",
  howpublished="RFC 2244 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2244",
  pages="1--71",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6075",
url="https://www.rfc-editor.org/rfc/rfc2244.txt",
  key="RFC 2244",
  abstract={The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]},
  keywords="ACAP, URL, Uniform, Resource, Locator",
  doi="10.17487/RFC2244",
  }

@misc{rfc2245,
  author="C. Newman",
  title="{Anonymous SASL Mechanism}",
  howpublished="RFC 2245 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2245",
  pages="1--5",
  year=1997,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4505",
url="https://www.rfc-editor.org/rfc/rfc2245.txt",
  key="RFC 2245",
  abstract={As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]},
  keywords="SASL-ANON, Simple, Authentication, Security, Layer",
  doi="10.17487/RFC2245",
  }

@misc{rfc2246,
  author="T. Dierks and C. Allen",
  title="{The TLS Protocol Version 1.0}",
  howpublished="RFC 2246 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2246",
  pages="1--80",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4346, updated by RFCs 3546, 5746, 6176, 7465, 7507, 7919",
url="https://www.rfc-editor.org/rfc/rfc2246.txt",
  key="RFC 2246",
  abstract={This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications privacy over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]},
  keywords="transport, protocol, layer, authentication, privacy",
  doi="10.17487/RFC2246",
  }

@misc{rfc2247,
  author="S. Kille and M. Wahl and A. Grimstad and R. Huber and S. Sataluri",
  title="{Using Domains in LDAP/X.500 Distinguished Names}",
  howpublished="RFC 2247 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2247",
  pages="1--7",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4519, 4524",
url="https://www.rfc-editor.org/rfc/rfc2247.txt",
  key="RFC 2247",
  abstract={This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, DNS, Domain, name, system",
  doi="10.17487/RFC2247",
  }

@misc{rfc2248,
  author="N. Freed and S. Kille",
  title="{Network Services Monitoring MIB}",
  howpublished="RFC 2248 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2248",
  pages="1--19",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2788",
url="https://www.rfc-editor.org/rfc/rfc2248.txt",
  key="RFC 2248",
  abstract={This MIB may be used on its own for any application, and for most simple applications this will suffice.  This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]},
  keywords="NSM-MIB, Management, Information, Base, SNMP, Simple, Network, Management, Protocol",
  doi="10.17487/RFC2248",
  }

@misc{rfc2249,
  author="N. Freed and S. Kille",
  title="{Mail Monitoring MIB}",
  howpublished="RFC 2249 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2249",
  pages="1--28",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2789",
url="https://www.rfc-editor.org/rfc/rfc2249.txt",
  key="RFC 2249",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]},
  keywords="MAIL-MIB, Management, Information, Base, Message, Transfer, Agents",
  doi="10.17487/RFC2249",
  }

@misc{rfc2250,
  author="D. Hoffman and G. Fernando and V. Goyal and M. Civanlar",
  title="{RTP Payload Format for MPEG1/MPEG2 Video}",
  howpublished="RFC 2250 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2250",
  pages="1--16",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2250.txt",
  key="RFC 2250",
  abstract={This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs).  It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="RTP-MPEG, Real-Time, Transport, Protocol, Audio, System, Streams",
  doi="10.17487/RFC2250",
  }

@misc{rfc2251,
  author="M. Wahl and T. Howes and S. Kille",
  title="{Lightweight Directory Access Protocol (v3)}",
  howpublished="RFC 2251 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2251",
  pages="1--50",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4510, 4511, 4513, 4512, updated by RFCs 3377, 3771",
url="https://www.rfc-editor.org/rfc/rfc2251.txt",
  key="RFC 2251",
  abstract={The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]},
  keywords="LDAPV3, LDAv3, x.500",
  doi="10.17487/RFC2251",
  }

@misc{rfc2252,
  author="M. Wahl and A. Coulbeck and T. Howes and S. Kille",
  title="{Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions}",
  howpublished="RFC 2252 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2252",
  pages="1--32",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4510, 4517, 4523, 4512, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2252.txt",
  key="RFC 2252",
  abstract={This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]},
  keywords="LDAP3-ATD, LDAv3, x.500, syntax",
  doi="10.17487/RFC2252",
  }

@misc{rfc2253,
  author="M. Wahl and S. Kille and T. Howes",
  title="{Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names}",
  howpublished="RFC 2253 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2253",
  pages="1--10",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4510, 4514, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2253.txt",
  key="RFC 2253",
  abstract={This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]},
  keywords="LDAP3-UTF8, LDAPv3, x.500, ASN.1, string, format",
  doi="10.17487/RFC2253",
  }

@misc{rfc2254,
  author="T. Howes",
  title="{The String Representation of LDAP Search Filters}",
  howpublished="RFC 2254 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2254",
  pages="1--8",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4510, 4515, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2254.txt",
  key="RFC 2254",
  abstract={This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]},
  keywords="STR-LDAP, LDAPv3, x.500, ASN.1, string, format",
  doi="10.17487/RFC2254",
  }

@misc{rfc2255,
  author="T. Howes and M. Smith",
  title="{The LDAP URL Format}",
  howpublished="RFC 2255 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2255",
  pages="1--10",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4510, 4516, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2255.txt",
  key="RFC 2255",
  abstract={This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]},
  keywords="LDAP-URL, Lightweight, Directory, Access, Protocol, Universal, Resource, Locator",
  doi="10.17487/RFC2255",
  }

@misc{rfc2256,
  author="M. Wahl",
  title="{A Summary of the X.500(96) User Schema for use with LDAPv3}",
  howpublished="RFC 2256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2256",
  pages="1--20",
  year=1997,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4517, 4519, 4523, 4512, 4510, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2256.txt",
  key="RFC 2256",
  abstract={This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]},
  keywords="Lightweight, Directory, Access, Protocol, syntax",
  doi="10.17487/RFC2256",
  }

@misc{rfc2257,
  author="M. Daniele and B. Wijnen and D. Francisco",
  title="{Agent Extensibility (AgentX) Protocol Version 1}",
  howpublished="RFC 2257 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2257",
  pages="1--80",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2741",
url="https://www.rfc-editor.org/rfc/rfc2257.txt",
  key="RFC 2257",
  abstract={This memo defines a standardized framework for extensible SNMP agents.  It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]},
  keywords="AGENTX, SNMP, Simple, Network, Management, Protocol, MIB, Information, Base",
  doi="10.17487/RFC2257",
  }

@misc{rfc2258,
  author="J. Ordille",
  title="{Internet Nomenclator Project}",
  howpublished="RFC 2258 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2258",
  pages="1--15",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2258.txt",
  key="RFC 2258",
  abstract={The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world.  This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Database, Server, CCSO, Computer, Communications, Services, Office",
  doi="10.17487/RFC2258",
  }

@misc{rfc2259,
  author="J. Elliott and J. Ordille",
  title="{Simple Nomenclator Query Protocol (SNQP)}",
  howpublished="RFC 2259 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2259",
  pages="1--30",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2259.txt",
  key="RFC 2259",
  abstract={The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind},
  keywords="SNQP, Data, Repositories, Client, Server",
  doi="10.17487/RFC2259",
  }

@misc{rfc2260,
  author="T. Bates and Y. Rekhter",
  title="{Scalable Support for Multi-homed Multi-provider Connectivity}",
  howpublished="RFC 2260 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2260",
  pages="1--12",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2260.txt",
  key="RFC 2260",
  abstract={This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ISP, Internet, Service, Provider, Routing",
  doi="10.17487/RFC2260",
  }

@misc{rfc2261,
  author="D. Harrington and R. Presuhn and B. Wijnen",
  title="{An Architecture for Describing SNMP Management Frameworks}",
  howpublished="RFC 2261 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2261",
  pages="1--56",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2271",
url="https://www.rfc-editor.org/rfc/rfc2261.txt",
  key="RFC 2261",
  abstract={This document describes an architecture for describing SNMP Management Frameworks.  The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, Message, Network, Management, Protocol, security, access, control, snmpv3",
  doi="10.17487/RFC2261",
  }

@misc{rfc2262,
  author="J. Case and D. Harrington and R. Presuhn and B. Wijnen",
  title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2262 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2262",
  pages="1--39",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2272",
url="https://www.rfc-editor.org/rfc/rfc2262.txt",
  key="RFC 2262",
  abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261].  It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications.  This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]},
  keywords="architecture, SNMPv3, multiple, versions",
  doi="10.17487/RFC2262",
  }

@misc{rfc2263,
  author="D. Levi and P. Meyer and B. Stewart",
  title="{SNMPv3 Applications}",
  howpublished="RFC 2263 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2263",
  pages="1--70",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2273",
url="https://www.rfc-editor.org/rfc/rfc2263.txt",
  key="RFC 2263",
  abstract={This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261].  The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.  This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, operations, notification, filtering, proxy, forwarding",
  doi="10.17487/RFC2263",
  }

@misc{rfc2264,
  author="U. Blumenthal and B. Wijnen",
  title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}",
  howpublished="RFC 2264 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2264",
  pages="1--76",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2274",
url="https://www.rfc-editor.org/rfc/rfc2264.txt",
  key="RFC 2264",
  abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261].  It defines the Elements of Procedure for providing SNMP message level security.  This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]},
  keywords="architecture, message, level",
  doi="10.17487/RFC2264",
  }

@misc{rfc2265,
  author="B. Wijnen and R. Presuhn and K. McCloghrie",
  title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2265",
  pages="1--36",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2275",
url="https://www.rfc-editor.org/rfc/rfc2265.txt",
  key="RFC 2265",
  abstract={This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261].  It defines the Elements of Procedure for controlling access to management information.  This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]},
  keywords="SNMPV3, Architecture",
  doi="10.17487/RFC2265",
  }

@misc{rfc2266,
  author="J. Flick",
  title="{Definitions of Managed Objects for IEEE 802.12 Repeater Devices}",
  howpublished="RFC 2266 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2266",
  pages="1--56",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2266.txt",
  key="RFC 2266",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK]},
  keywords="MIB, Management, Information, Base",
  doi="10.17487/RFC2266",
  }

@misc{rfc2267,
  author="P. Ferguson and D. Senie",
  title="{Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing}",
  howpublished="RFC 2267 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2267",
  pages="1--10",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2827",
url="https://www.rfc-editor.org/rfc/rfc2267.txt",
  key="RFC 2267",
  abstract={This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ISP, Internet, Service, Provider, Internet, Protocol, DOS",
  doi="10.17487/RFC2267",
  }

@misc{rfc2268,
  author="R. Rivest",
  title="{A Description of the RC2(r) Encryption Algorithm}",
  howpublished="RFC 2268 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2268",
  pages="1--11",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2268.txt",
  key="RFC 2268",
  abstract={This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="RC2-ENCRP, encryption, secre, key rsa",
  doi="10.17487/RFC2268",
  }

@misc{rfc2269,
  author="G. Armitage",
  title="{Using the MARS Model in non-ATM NBMA Networks}",
  howpublished="RFC 2269 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2269",
  pages="1--6",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2269.txt",
  key="RFC 2269",
  abstract={This document is intended to state the obvious equivalences, and explain the less obvious implications.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Asynchronous, Transfer, Mode, Multicast, Address, Resolution, Server, IP, Internet, Protocol",
  doi="10.17487/RFC2269",
  }

@misc{rfc2270,
  author="J. Stewart and T. Bates and R. Chandra and E. Chen",
  title="{Using a Dedicated AS for Sites  Homed to a Single Provider}",
  howpublished="RFC 2270 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2270",
  pages="1--6",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2270.txt",
  key="RFC 2270",
  abstract={With the increased growth of the Internet, the number of customers using BGP4 has grown significantly.  RFC1930 outlines a set of guidelines for when one needs and should use an AS.  However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP.  This paper proposes a solution to this problem in line with recommendations set forth in RFC1930.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Autonomous, System, BGP4, Border, Gateway, Protocol, ISP, Internet, Service",
  doi="10.17487/RFC2270",
  }

@misc{rfc2271,
  author="D. Harrington and R. Presuhn and B. Wijnen",
  title="{An Architecture for Describing SNMP Management Frameworks}",
  howpublished="RFC 2271 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2271",
  pages="1--56",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2571",
url="https://www.rfc-editor.org/rfc/rfc2271.txt",
  key="RFC 2271",
  abstract={This document describes an architecture for describing SNMP Management Frameworks.  The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, Message, Network, Management, Protocol, security, access, control, snmpv3",
  doi="10.17487/RFC2271",
  }

@misc{rfc2272,
  author="J. Case and D. Harrington and R. Presuhn and B. Wijnen",
  title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2272 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2272",
  pages="1--39",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2572",
url="https://www.rfc-editor.org/rfc/rfc2272.txt",
  key="RFC 2272",
  abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271].  It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications.  This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]},
  keywords="SNMPv3, architecture, SNMPv3, multiple, versions",
  doi="10.17487/RFC2272",
  }

@misc{rfc2273,
  author="D. Levi and P. Meyer and B. Stewart",
  title="{SNMPv3 Applications}",
  howpublished="RFC 2273 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2273",
  pages="1--70",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2573",
url="https://www.rfc-editor.org/rfc/rfc2273.txt",
  key="RFC 2273",
  abstract={This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261].  The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.  This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]},
  keywords="Simple, Network, Management, Protocol, operations, notification, filtering, proxy, forwarding",
  doi="10.17487/RFC2273",
  }

@misc{rfc2274,
  author="U. Blumenthal and B. Wijnen",
  title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}",
  howpublished="RFC 2274 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2274",
  pages="1--76",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2574",
url="https://www.rfc-editor.org/rfc/rfc2274.txt",
  key="RFC 2274",
  abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261].  It defines the Elements of Procedure for providing SNMP message level security.  This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]},
  keywords="architecture, message, level",
  doi="10.17487/RFC2274",
  }

@misc{rfc2275,
  author="B. Wijnen and R. Presuhn and K. McCloghrie",
  title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2275 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2275",
  pages="1--36",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2575",
url="https://www.rfc-editor.org/rfc/rfc2275.txt",
  key="RFC 2275",
  abstract={This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261].  It defines the Elements of Procedure for controlling access to management information.  This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]},
  keywords="SNMPV3, Architecture",
  doi="10.17487/RFC2275",
  }

@misc{rfc2276,
  author="K. Sollins",
  title="{Architectural Principles of Uniform Resource Name Resolution}",
  howpublished="RFC 2276 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2276",
  pages="1--24",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3401",
url="https://www.rfc-editor.org/rfc/rfc2276.txt",
  key="RFC 2276",
  abstract={This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics).  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="URCs, URN, URLs, Uniform, Resource, Locators, Characteristics",
  doi="10.17487/RFC2276",
  }

@misc{rfc2277,
  author="H. Alvestrand",
  title="{IETF Policy on Character Sets and Languages}",
  howpublished="RFC 2277 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2277",
  pages="1--9",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2277.txt",
  key="RFC 2277",
  abstract={This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="charset",
  doi="10.17487/RFC2277",
  }

@misc{rfc2278,
  author="N. Freed and J. Postel",
  title="{IANA Charset Registration Procedures}",
  howpublished="RFC 2278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2278",
  pages="1--10",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2978",
url="https://www.rfc-editor.org/rfc/rfc2278.txt",
  key="RFC 2278",
  abstract={MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets.  This in turn means that the ability to label different charsets is essential.  This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="character, set, mime, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2278",
  }

@misc{rfc2279,
  author="F. Yergeau",
  title="{UTF-8, a transformation format of ISO 10646}",
  howpublished="RFC 2279 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2279",
  pages="1--10",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3629",
url="https://www.rfc-editor.org/rfc/rfc2279.txt",
  key="RFC 2279",
  abstract={UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]},
  keywords="UTF-8, UCS, Transformation, Format",
  doi="10.17487/RFC2279",
  }

@misc{rfc2280,
  author="C. Alaettinoglu and T. Bates and E. Gerich and D. Karrenberg and D. Meyer and M. Terpstra and C. Villamizar",
  title="{Routing Policy Specification Language (RPSL)}",
  howpublished="RFC 2280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2280",
  pages="1--53",
  year=1998,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2622",
url="https://www.rfc-editor.org/rfc/rfc2280.txt",
  key="RFC 2280",
  abstract={This memo is the reference document for the Routing Policy Specification Language (RPSL).  RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level.  At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them.  RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]},
  keywords="RPSL, network, operator, AS, autonomous, system, database",
  doi="10.17487/RFC2280",
  }

@misc{rfc2281,
  author="T. Li and B. Cole and P. Morton and D. Li",
  title="{Cisco Hot Standby Router Protocol (HSRP)}",
  howpublished="RFC 2281 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2281",
  pages="1--17",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2281.txt",
  key="RFC 2281",
  abstract={The memo specifies the Hot Standby Router Protocol (HSRP).  The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="HSRP",
  doi="10.17487/RFC2281",
  }

@misc{rfc2282,
  author="J. Galvin",
  title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}",
  howpublished="RFC 2282 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2282",
  pages="1--14",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2727",
url="https://www.rfc-editor.org/rfc/rfc2282.txt",
  key="RFC 2282",
  abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Architecture, Board, Engineering, Steering, Group",
  doi="10.17487/RFC2282",
  }

@misc{rfc2283,
  author="T. Bates and R. Chandra and D. Katz and Y. Rekhter",
  title="{Multiprotocol Extensions for BGP-4}",
  howpublished="RFC 2283 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2283",
  pages="1--9",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2858",
url="https://www.rfc-editor.org/rfc/rfc2283.txt",
  key="RFC 2283",
  abstract={This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...).  The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]},
  keywords="MEXT-BGP4, Border, gateway, protocol, router, network, layer",
  doi="10.17487/RFC2283",
  }

@misc{rfc2284,
  author="L. Blunk and J. Vollbrecht",
  title="{PPP Extensible Authentication Protocol (EAP)}",
  howpublished="RFC 2284 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2284",
  pages="1--15",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3748, updated by RFC 2484",
url="https://www.rfc-editor.org/rfc/rfc2284.txt",
  key="RFC 2284",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.  This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]},
  keywords="PPP-EAP, point-to-point, authentication",
  doi="10.17487/RFC2284",
  }

@misc{rfc2285,
  author="R. Mandeville",
  title="{Benchmarking Terminology for LAN Switching Devices}",
  howpublished="RFC 2285 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2285",
  pages="1--25",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2285.txt",
  key="RFC 2285",
  abstract={This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices.  It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="local, area, network, MAC, Medium, Access, Control, layer",
  doi="10.17487/RFC2285",
  }

@misc{rfc2286,
  author="J. Kapp",
  title="{Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128}",
  howpublished="RFC 2286 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2286",
  pages="1--7",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2286.txt",
  key="RFC 2286",
  abstract={This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="has, authentication, message, IP, Internet, Protocol, codes",
  doi="10.17487/RFC2286",
  }

@misc{rfc2287,
  author="C. Krupczak and J. Saperia",
  title="{Definitions of System-Level Managed Objects for Applications}",
  howpublished="RFC 2287 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2287",
  pages="1--44",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2287.txt",
  key="RFC 2287",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]},
  keywords="SLM-APP, mib, management, information, base",
  doi="10.17487/RFC2287",
  }

@misc{rfc2288,
  author="C. Lynch and C. Preston and R. Daniel",
  title="{Using Existing Bibliographic Identifiers as Uniform Resource Names}",
  howpublished="RFC 2288 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2288",
  pages="1--10",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2288.txt",
  key="RFC 2288",
  abstract={This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="URNs, Syntax, framework",
  doi="10.17487/RFC2288",
  }

@misc{rfc2289,
  author="N. Haller and C. Metz and P. Nesser and M. Straw",
  title="{A One-Time Password System}",
  howpublished="RFC 2289 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2289",
  pages="1--25",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2289.txt",
  key="RFC 2289",
  abstract={This document describes a one-time password authentication system (OTP).  The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]},
  keywords="ONE-PASS, authentication, OTP, replay, attach",
  doi="10.17487/RFC2289",
  }

@misc{rfc2290,
  author="J. Solomon and S. Glass",
  title="{Mobile-IPv4 Configuration Option for PPP IPCP}",
  howpublished="RFC 2290 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2290",
  pages="1--17",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2794",
url="https://www.rfc-editor.org/rfc/rfc2290.txt",
  key="RFC 2290",
  abstract={Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address.  PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links.  As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents.  This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332].  Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP.  Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]},
  keywords="Internet, protocol, point-to-point, control, address",
  doi="10.17487/RFC2290",
  }

@misc{rfc2291,
  author="J. Slein and F. Vitali and E. Whitehead and D. Durand",
  title="{Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web}",
  howpublished="RFC 2291 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2291",
  pages="1--21",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2291.txt",
  key="RFC 2291",
  abstract={This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="WWW, remote, editing, locking, mechanism",
  doi="10.17487/RFC2291",
  }

@misc{rfc2292,
  author="W. Stevens and M. Thomas",
  title="{Advanced Sockets API for IPv6}",
  howpublished="RFC 2292 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2292",
  pages="1--67",
  year=1998,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3542",
url="https://www.rfc-editor.org/rfc/rfc2292.txt",
  key="RFC 2292",
  abstract={The current document defines some the ``advanced'' features of the sockets API that are required for applications to take advantage of additional features of IPv6.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="application, program, interface",
  doi="10.17487/RFC2292",
  }

@misc{rfc2293,
  author="S. Kille",
  title="{Representing Tables and Subtrees in the X.500 Directory}",
  howpublished="RFC 2293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2293",
  pages="1--8",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2293.txt",
  key="RFC 2293",
  abstract={This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry.  This is achieved by use of a directory subtree. [STANDARDS-TRCK]},
  keywords="SUBTABLE, mapping, distinguished, name",
  doi="10.17487/RFC2293",
  }

@misc{rfc2294,
  author="S. Kille",
  title="{Representing the O/R Address hierarchy in the X.500 Directory Information Tree}",
  howpublished="RFC 2294 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2294",
  pages="1--13",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2294.txt",
  key="RFC 2294",
  abstract={This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]},
  keywords="OR-ADD, routing, mapping, dit",
  doi="10.17487/RFC2294",
  }

@misc{rfc2295,
  author="K. Holtman and A. Mutz",
  title="{Transparent Content Negotiation in HTTP}",
  howpublished="RFC 2295 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2295",
  pages="1--58",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2295.txt",
  key="RFC 2295",
  abstract={HTTP allows web site authors to put multiple versions of the same information under a single URL.  Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed.  This enables the smooth deployment of new web data formats and markup tags.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="TCN-HTTP, Hyper, Text, Transfer, protocol, URL, Uniform, Resource, Locators",
  doi="10.17487/RFC2295",
  }

@misc{rfc2296,
  author="K. Holtman and A. Mutz",
  title="{HTTP Remote Variant Selection Algorithm -- RVSA/1.0}",
  howpublished="RFC 2296 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2296",
  pages="1--13",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2296.txt",
  key="RFC 2296",
  abstract={HTTP allows web site authors to put multiple versions of the same information under a single URL.  Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed.  A remote variant selection algorithm can be used to speed up the transparent negotiation process.  This document defines the remote variant selection algorithm with the version number 1.0.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="HTTP-RVSA, Hyper, Text, Transfer, protocol, URL, Uniform, Resource, Locators",
  doi="10.17487/RFC2296",
  }

@misc{rfc2297,
  author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall",
  title="{Ipsilon's General Switch Management Protocol Specification Version 2.0}",
  howpublished="RFC 2297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2297",
  pages="1--109",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2297.txt",
  key="RFC 2297",
  abstract={This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987].  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="GSMP, gsmp, atm, asynchronous, transfer, mode",
  doi="10.17487/RFC2297",
  }

@misc{rfc2298,
  author="R. Fajman",
  title="{An Extensible Message Format for Message Disposition Notifications}",
  howpublished="RFC 2298 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2298",
  pages="1--28",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3798",
url="https://www.rfc-editor.org/rfc/rfc2298.txt",
  key="RFC 2298",
  abstract={This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]},
  keywords="EMF-MDN, MDN, media-type, MIME, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2298",
  }

@misc{rfc2299,
  author="A. Ramos",
  title="{Request for Comments Summary}",
  howpublished="RFC 2299 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2299",
  pages="1--24",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2299.txt",
  key="RFC 2299",
  doi="10.17487/RFC2299",
  }

@misc{rfc2300,
  author="J. Postel",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2300 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2300",
  pages="1--59",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2400",
url="https://www.rfc-editor.org/rfc/rfc2300.txt",
  key="RFC 2300",
  abstract={A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms.  Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization.  Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC2300",
  }

@misc{rfc2301,
  author="L. McIntyre and S. Zilles and R. Buckley and D. Venable and G. Parsons and J. Rafferty",
  title="{File Format for Internet Fax}",
  howpublished="RFC 2301 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2301",
  pages="1--77",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3949",
url="https://www.rfc-editor.org/rfc/rfc2301.txt",
  key="RFC 2301",
  abstract={This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]},
  keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions",
  doi="10.17487/RFC2301",
  }

@misc{rfc2302,
  author="G. Parsons and J. Rafferty and S. Zilles",
  title="{Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration}",
  howpublished="RFC 2302 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2302",
  pages="1--8",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3302",
url="https://www.rfc-editor.org/rfc/rfc2302.txt",
  key="RFC 2302",
  abstract={This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]},
  keywords="TIFF, Multipurpose, Internet, Mail, extensions",
  doi="10.17487/RFC2302",
  }

@misc{rfc2303,
  author="C. Allocchio",
  title="{Minimal PSTN address format in Internet Mail}",
  howpublished="RFC 2303 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2303",
  pages="1--8",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3191",
url="https://www.rfc-editor.org/rfc/rfc2303.txt",
  key="RFC 2303",
  abstract={This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]},
  keywords="MIN-PSTN, e-mail, service",
  doi="10.17487/RFC2303",
  }

@misc{rfc2304,
  author="C. Allocchio",
  title="{Minimal FAX address format in Internet Mail}",
  howpublished="RFC 2304 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2304",
  pages="1--8",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3192",
url="https://www.rfc-editor.org/rfc/rfc2304.txt",
  key="RFC 2304",
  abstract={This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]},
  keywords="MINFAX-IM, encoding, facsimile, e-mail",
  doi="10.17487/RFC2304",
  }

@misc{rfc2305,
  author="K. Toyoda and H. Ohno and J. Murai and D. Wing",
  title="{A Simple Mode of Facsimile Using Internet Mail}",
  howpublished="RFC 2305 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2305",
  pages="1--13",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3965",
url="https://www.rfc-editor.org/rfc/rfc2305.txt",
  key="RFC 2305",
  abstract={This specification provides for ``simple mode'' carriage of facsimile data over the Internet. [STANDARDS-TRACK]},
  keywords="SMFAX-IM, data, file, format, e-mail",
  doi="10.17487/RFC2305",
  }

@misc{rfc2306,
  author="G. Parsons and J. Rafferty",
  title="{Tag Image File Format (TIFF) - F Profile for Facsimile}",
  howpublished="RFC 2306 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2306",
  pages="1--25",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2306.txt",
  key="RFC 2306",
  abstract={This document describes in detail the definition of TIFF-F that is used to store facsimile images.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="file, format, storage",
  doi="10.17487/RFC2306",
  }

@misc{rfc2307,
  author="L. Howard",
  title="{An Approach for Using LDAP as a Network Information Service}",
  howpublished="RFC 2307 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2307",
  pages="1--21",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2307.txt",
  key="RFC 2307",
  abstract={This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251].  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="LDAP-NIS, lightweight, directory, access, protocol, unix, mapping",
  doi="10.17487/RFC2307",
  }

@misc{rfc2308,
  author="M. Andrews",
  title="{Negative Caching of DNS Queries (DNS NCACHE)}",
  howpublished="RFC 2308 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2308",
  pages="1--19",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4035, 4033, 4034, 6604, 8020",
url="https://www.rfc-editor.org/rfc/rfc2308.txt",
  key="RFC 2308",
  abstract={RFC1034 provided a description of how to cache negative responses.  It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching.  This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]},
  keywords="DNS-NCACHE, Domain, Name, System, negative",
  doi="10.17487/RFC2308",
  }

@misc{rfc2309,
  author="B. Braden and D. Clark and J. Crowcroft and B. Davie and S. Deering and D. Estrin and S. Floyd and V. Jacobson and G. Minshall and C. Partridge and L. Peterson and K. Ramakrishnan and S. Shenker and J. Wroclawski and L. Zhang",
  title="{Recommendations on Queue Management and Congestion Avoidance in the Internet}",
  howpublished="RFC 2309 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2309",
  pages="1--17",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7567, updated by RFC 7141",
url="https://www.rfc-editor.org/rfc/rfc2309.txt",
  key="RFC 2309",
  abstract={This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.  It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet.  It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="performance, router, deployment",
  doi="10.17487/RFC2309",
  }

@misc{rfc2310,
  author="K. Holtman",
  title="{The Safe Response Header Field}",
  howpublished="RFC 2310 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2310",
  pages="1--5",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2310.txt",
  key="RFC 2310",
  abstract={This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="http, hyper, text, transfer, protocol",
  doi="10.17487/RFC2310",
  }

@misc{rfc2311,
  author="S. Dusse and P. Hoffman and B. Ramsdell and L. Lundblade and L. Repka",
  title="{S/MIME Version 2 Message Specification}",
  howpublished="RFC 2311 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2311",
  pages="1--37",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2311.txt",
  key="RFC 2311",
  abstract={This document describes a protocol for adding cryptographic signature and encryption services to MIME data.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="SMIME-MSG, secure, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2311",
  }

@misc{rfc2312,
  author="S. Dusse and P. Hoffman and B. Ramsdell and J. Weinstein",
  title="{S/MIME Version 2 Certificate Handling}",
  howpublished="RFC 2312 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2312",
  pages="1--20",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2312.txt",
  key="RFC 2312",
  abstract={This memo describes the mechanisms S/MIME uses to create and validate keys using certificates.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="SMIME-CERT, secure, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2312",
  }

@misc{rfc2313,
  author="B. Kaliski",
  title="{PKCS \#1: RSA Encryption Version 1.5}",
  howpublished="RFC 2313 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2313",
  pages="1--19",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2437",
url="https://www.rfc-editor.org/rfc/rfc2313.txt",
  key="RFC 2313",
  abstract={This document describes a method for encrypting data using the RSA public-key cryptosystem.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="PKCS-1, data, public, key, cryptosystem",
  doi="10.17487/RFC2313",
  }

@misc{rfc2314,
  author="B. Kaliski",
  title="{PKCS \#10: Certification Request Syntax Version 1.5}",
  howpublished="RFC 2314 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2314",
  pages="1--8",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2986",
url="https://www.rfc-editor.org/rfc/rfc2314.txt",
  key="RFC 2314",
  abstract={This document describes a syntax for certification requests.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="PKCS-10, public, key, distinguished, name, encryption, data",
  doi="10.17487/RFC2314",
  }

@misc{rfc2315,
  author="B. Kaliski",
  title="{PKCS \#7: Cryptographic Message Syntax Version 1.5}",
  howpublished="RFC 2315 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2315",
  pages="1--32",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2315.txt",
  key="RFC 2315",
  abstract={This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="PKCS-7, data, authentication, PEM, privacy, enhanced, mail",
  doi="10.17487/RFC2315",
  }

@misc{rfc2316,
  author="S. Bellovin",
  title="{Report of the IAB Security Architecture Workshop}",
  howpublished="RFC 2316 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2316",
  pages="1--9",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2316.txt",
  key="RFC 2316",
  abstract={On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ.  We identified the core security components of the architecture, and specified several documents that need to be written.  Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Internet, Board, protocols, tools",
  doi="10.17487/RFC2316",
  }

@misc{rfc2317,
  author="H. Eidnes and G. de Groot and P. Vixie",
  title="{Classless IN-ADDR.ARPA delegation}",
  howpublished="RFC 2317 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2317",
  pages="1--10",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2317.txt",
  key="RFC 2317",
  abstract={This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="routing, mapping, addresses, zone, files",
  doi="10.17487/RFC2317",
  }

@misc{rfc2318,
  author="H. Lie and B. Bos and C. Lilley",
  title="{The text/css Media Type}",
  howpublished="RFC 2318 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2318",
  pages="1--5",
  year=1998,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2318.txt",
  key="RFC 2318",
  abstract={This memo provides information about the text/css Media Type.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="TEXT-CSS, MIME, multipurpose, Internet, mail, extension",
  doi="10.17487/RFC2318",
  }

@misc{rfc2319,
  author="KOI8-U Working Group",
  title="{Ukrainian Character Set KOI8-U}",
  howpublished="RFC 2319 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2319",
  pages="1--9",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2319.txt",
  key="RFC 2319",
  abstract={This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="KOI8-U, encoding, mail, information, resources",
  doi="10.17487/RFC2319",
  }

@misc{rfc2320,
  author="M. Greene and J. Luciani and K. White and T. Kuo",
  title="{Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)}",
  howpublished="RFC 2320 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2320",
  pages="1--52",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2320.txt",
  key="RFC 2320",
  abstract={The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]},
  keywords="IPOA-MIB, management, information, base, internet, protocol, address, resolution, asynchronous, transfer, mode",
  doi="10.17487/RFC2320",
  }

@misc{rfc2321,
  author="A. Bressen",
  title="{RITA -- The Reliable Internetwork Troubleshooting Agent}",
  howpublished="RFC 2321 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2321",
  pages="1--6",
  year=1998,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2321.txt",
  key="RFC 2321",
  abstract={A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="networking, environments",
  doi="10.17487/RFC2321",
  }

@misc{rfc2322,
  author="K. van den Hout and A. Koopal and R. van Mook",
  title="{Management of IP numbers by peg-dhcp}",
  howpublished="RFC 2322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2322",
  pages="1--7",
  year=1998,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2322.txt",
  key="RFC 2322",
  abstract={This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, HIP, Hacking, in, progress",
  doi="10.17487/RFC2322",
  }

@misc{rfc2323,
  author="A. Ramos",
  title="{IETF Identification and Security Guidelines}",
  howpublished="RFC 2323 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2323",
  pages="1--5",
  year=1998,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2323.txt",
  key="RFC 2323",
  abstract={This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: ``facial hairius extremis''.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="facial, hairius, extremis, FHE",
  doi="10.17487/RFC2323",
  }

@misc{rfc2324,
  author="L. Masinter",
  title="{Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)}",
  howpublished="RFC 2324 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2324",
  pages="1--10",
  year=1998,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7168",
url="https://www.rfc-editor.org/rfc/rfc2324.txt",
  key="RFC 2324",
  abstract={This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="controlling, monitoring, diagnosing",
  doi="10.17487/RFC2324",
  }

@misc{rfc2325,
  author="M. Slavitch",
  title="{Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2}",
  howpublished="RFC 2325 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2325",
  pages="1--8",
  year=1998,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2325.txt",
  key="RFC 2325",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for the management of coffee-brewing and maintenance devices.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="MIB, management, information, base, coffee, brewing",
  doi="10.17487/RFC2325",
  }

@misc{rfc2326,
  author="H. Schulzrinne and A. Rao and R. Lanphier",
  title="{Real Time Streaming Protocol (RTSP)}",
  howpublished="RFC 2326 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2326",
  pages="1--92",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7826",
url="https://www.rfc-editor.org/rfc/rfc2326.txt",
  key="RFC 2326",
  abstract={The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties.  RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK]},
  keywords="RTSP, audio, video, data, delivery, application, level,",
  doi="10.17487/RFC2326",
  }

@misc{rfc2327,
  author="M. Handley and V. Jacobson",
  title="{SDP: Session Description Protocol}",
  howpublished="RFC 2327 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2327",
  pages="1--42",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4566, updated by RFC 3266",
url="https://www.rfc-editor.org/rfc/rfc2327.txt",
  key="RFC 2327",
  abstract={This document defines the Session Description Protocol, SDP.  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]},
  keywords="SDP, mbone, internet, multicast, backbone, multimedia",
  doi="10.17487/RFC2327",
  }

@misc{rfc2328,
  author="J. Moy",
  title="{OSPF Version 2}",
  howpublished="RFC 2328 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2328",
  pages="1--244",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5709, 6549, 6845, 6860, 7474, 8042",
url="https://www.rfc-editor.org/rfc/rfc2328.txt",
  key="RFC 2328",
  abstract={This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol. [STANDARDS-TRACK]},
  keywords="OSPF2, Open, Shortest, Path, First, routing, Autonomous, system, AS",
  doi="10.17487/RFC2328",
  }

@misc{rfc2329,
  author="J. Moy",
  title="{OSPF Standardization Report}",
  howpublished="RFC 2329 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2329",
  pages="1--9",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2329.txt",
  key="RFC 2329",
  abstract={This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="open, shortest, path, first",
  doi="10.17487/RFC2329",
  }

@misc{rfc2330,
  author="V. Paxson and G. Almes and J. Mahdavi and M. Mathis",
  title="{Framework for IP Performance Metrics}",
  howpublished="RFC 2330 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2330",
  pages="1--40",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7312",
url="https://www.rfc-editor.org/rfc/rfc2330.txt",
  key="RFC 2330",
  abstract={The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, measurement, statistics",
  doi="10.17487/RFC2330",
  }

@misc{rfc2331,
  author="M. Maher",
  title="{ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update}",
  howpublished="RFC 2331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2331",
  pages="1--26",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2331.txt",
  key="RFC 2331",
  abstract={This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]},
  keywords="UNI-SIG, asynchronous, transfer, mode, internet, protocol",
  doi="10.17487/RFC2331",
  }

@misc{rfc2332,
  author="J. Luciani and D. Katz and D. Piscitello and B. Cole and N. Doraswamy",
  title="{NBMA Next Hop Resolution Protocol (NHRP)}",
  howpublished="RFC 2332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2332",
  pages="1--52",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2332.txt",
  key="RFC 2332",
  abstract={This document describes the NBMA Next Hop Resolution Protocol (NHRP).  NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the ``NBMA next hop'' towards a destination station. [STANDARDS-TRACK]},
  keywords="NHRP, internetworking, layer, address, subnetwork, multiprotocol, non-broadcast, multiple, access",
  doi="10.17487/RFC2332",
  }

@misc{rfc2333,
  author="D. Cansever",
  title="{NHRP Protocol Applicability Statement}",
  howpublished="RFC 2333 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2333",
  pages="1--9",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2333.txt",
  key="RFC 2333",
  abstract={As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]},
  keywords="next, hop, resolution, protocol, routing, internet, protocol",
  doi="10.17487/RFC2333",
  }

@misc{rfc2334,
  author="J. Luciani and G. Armitage and J. Halpern and N. Doraswamy",
  title="{Server Cache Synchronization Protocol (SCSP)}",
  howpublished="RFC 2334 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2334",
  pages="1--40",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2334.txt",
  key="RFC 2334",
  abstract={This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]},
  keywords="SCSP, cache, synchronization, replication, NBMA, non, broadcast, multiple, access",
  doi="10.17487/RFC2334",
  }

@misc{rfc2335,
  author="J. Luciani",
  title="{A Distributed NHRP Service Using SCSP}",
  howpublished="RFC 2335 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2335",
  pages="1--7",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2335.txt",
  key="RFC 2335",
  abstract={This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]},
  keywords="NHRP-SCSP, next, hop, resolution, protocol, server, cache, sychronization, protocol",
  doi="10.17487/RFC2335",
  }

@misc{rfc2336,
  author="J. Luciani",
  title="{Classical IP and ARP over ATM to NHRP Transition}",
  howpublished="RFC 2336 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2336",
  pages="1--5",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2336.txt",
  key="RFC 2336",
  abstract={This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2336",
  }

@misc{rfc2337,
  author="D. Farinacci and D. Meyer and Y. Rekhter",
  title="{Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM}",
  howpublished="RFC 2337 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2337",
  pages="1--8",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2337.txt",
  key="RFC 2337",
  abstract={This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS).  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="internet, protocol, asynchronous, transfer, mode",
  doi="10.17487/RFC2337",
  }

@misc{rfc2338,
  author="S. Knight and D. Weaver and D. Whipple and R. Hinden and D. Mitzel and P. Hunt and P. Higginson and M. Shand and A. Lindem",
  title="{Virtual Router Redundancy Protocol}",
  howpublished="RFC 2338 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2338",
  pages="1--27",
  year=1998,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3768",
url="https://www.rfc-editor.org/rfc/rfc2338.txt",
  key="RFC 2338",
  abstract={This memo defines the Virtual Router Redundancy Protocol (VRRP).  VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]},
  keywords="VRRP, vrrp, lan, local, area, network, ip, internet, protocol",
  doi="10.17487/RFC2338",
  }

@misc{rfc2339,
  author="The Internet Society and Sun Microsystems",
  title="{An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols}",
  howpublished="RFC 2339 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2339",
  pages="1--5",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2339.txt",
  key="RFC 2339",
  abstract={This Request for Comments records an agreement between Sun Microsystems, Inc.  and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="ISOC, network, file, system, internet, engineering, task, force",
  doi="10.17487/RFC2339",
  }

@misc{rfc2340,
  author="B. Jamoussi and D. Jamieson and D. Williston and S. Gabe",
  title="{Nortel's Virtual Network Switching (VNS) Overview}",
  howpublished="RFC 2340 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2340",
  pages="1--14",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2340.txt",
  key="RFC 2340",
  abstract={This document provides an overview of Virtual Network Switching (VNS).  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="routing, packet, switching, multi-protocol",
  doi="10.17487/RFC2340",
  }

@misc{rfc2341,
  author="A. Valencia and M. Littlewood and T. Kolar",
  title="{Cisco Layer Two Forwarding (Protocol) ``L2F''}",
  howpublished="RFC 2341 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2341",
  pages="1--29",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2341.txt",
  key="RFC 2341",
  abstract={This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols.  This memo describes a historic protocol for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="L2F, tunneling, dial-up, network",
  doi="10.17487/RFC2341",
  }

@misc{rfc2342,
  author="M. Gahrns and C. Newman",
  title="{IMAP4 Namespace}",
  howpublished="RFC 2342 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2342",
  pages="1--10",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4466",
url="https://www.rfc-editor.org/rfc/rfc2342.txt",
  key="RFC 2342",
  abstract={This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]},
  keywords="IMAP4NAME, internet, message, access, protocol, mailbox",
  doi="10.17487/RFC2342",
  }

@misc{rfc2343,
  author="M. Civanlar and G. Cash and B. Haskell",
  title="{RTP Payload Format for Bundled MPEG}",
  howpublished="RFC 2343 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2343",
  pages="1--8",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2343.txt",
  key="RFC 2343",
  abstract={This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2.  This memo defines an Experimental Protocol for the Internet community.  This memo does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="RTP-MPEG, real-time, transport, protocol, audio, video",
  doi="10.17487/RFC2343",
  }

@misc{rfc2344,
  author="G. Montenegro",
  title="{Reverse Tunneling for Mobile IP}",
  howpublished="RFC 2344 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2344",
  pages="1--19",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3024",
url="https://www.rfc-editor.org/rfc/rfc2344.txt",
  key="RFC 2344",
  abstract={This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]},
  keywords="MOBILIPREV, internet, protocol, extensions, home, foreign, agent, encapsulating, delivery, style",
  doi="10.17487/RFC2344",
  }

@misc{rfc2345,
  author="J. Klensin and T. Wolf and G. Oglesby",
  title="{Domain Names and Company Name Retrieval}",
  howpublished="RFC 2345 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2345",
  pages="1--14",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2345.txt",
  key="RFC 2345",
  abstract={This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="URL, mapping, service, whois, dns",
  doi="10.17487/RFC2345",
  }

@misc{rfc2346,
  author="J. Palme",
  title="{Making Postscript and PDF International}",
  howpublished="RFC 2346 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2346",
  pages="1--6",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2346.txt",
  key="RFC 2346",
  abstract={Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document.  The commonly used paper format is different in North America and the rest of the world.  North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format.  This means that documents formatted on one continent may not be easily printable on another continent.  This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="portable, document, format, document",
  doi="10.17487/RFC2346",
  }

@misc{rfc2347,
  author="G. Malkin and A. Harkin",
  title="{TFTP Option Extension}",
  howpublished="RFC 2347 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2347",
  pages="1--7",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2347.txt",
  key="RFC 2347",
  abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]},
  keywords="TFTP-Ext, trivial, file, transfer, booting, client, server",
  doi="10.17487/RFC2347",
  }

@misc{rfc2348,
  author="G. Malkin and A. Harkin",
  title="{TFTP Blocksize Option}",
  howpublished="RFC 2348 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2348",
  pages="1--5",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2348.txt",
  key="RFC 2348",
  abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]},
  keywords="TFTP-Blk, trivial, file, transfer, booting, client, server, extension",
  doi="10.17487/RFC2348",
  }

@misc{rfc2349,
  author="G. Malkin and A. Harkin",
  title="{TFTP Timeout Interval and Transfer Size Options}",
  howpublished="RFC 2349 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2349",
  pages="1--5",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2349.txt",
  key="RFC 2349",
  abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  This document describes two TFTP options. [STANDARDS-TRACK]},
  keywords="TFTP-Opt, trivial, file, transfer, booting, client, server, extension",
  doi="10.17487/RFC2349",
  }

@misc{rfc2350,
  author="N. Brownlee and E. Guttman",
  title="{Expectations for Computer Security Incident Response}",
  howpublished="RFC 2350 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2350",
  pages="1--38",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2350.txt",
  key="RFC 2350",
  keywords="CSIRT, guidelines, user",
  doi="10.17487/RFC2350",
  }

@misc{rfc2351,
  author="A. Robert",
  title="{Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP}",
  howpublished="RFC 2351 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2351",
  pages="1--23",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2351.txt",
  key="RFC 2351",
  abstract={This memo specifies a protocol for the encapsulation of the airline specific protocol over IP.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords=", internet, protocol, encapsulation, transactional, traffic, messaging",
  doi="10.17487/RFC2351",
  }

@misc{rfc2352,
  author="O. Vaughan",
  title="{A Convention For Using Legal Names as Domain Names}",
  howpublished="RFC 2352 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2352",
  pages="1--8",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2352.txt",
  key="RFC 2352",
  abstract={The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="DNS",
  doi="10.17487/RFC2352",
  }

@misc{rfc2353,
  author="G. Dudley",
  title="{APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document}",
  howpublished="RFC 2353 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2353",
  pages="1--48",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2353.txt",
  key="RFC 2353",
  abstract={This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method.  This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, protocol, advanced, peer-to-peer, networking, high, performance, routing",
  doi="10.17487/RFC2353",
  }

@misc{rfc2354,
  author="C. Perkins and O. Hodson",
  title="{Options for Repair of Streaming Media}",
  howpublished="RFC 2354 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2354",
  pages="1--12",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2354.txt",
  key="RFC 2354",
  abstract={This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="packets, UDP, user, datagram, protocol",
  doi="10.17487/RFC2354",
  }

@misc{rfc2355,
  author="B. Kelly",
  title="{TN3270 Enhancements}",
  howpublished="RFC 2355 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2355",
  pages="1--38",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6270",
url="https://www.rfc-editor.org/rfc/rfc2355.txt",
  key="RFC 2355",
  abstract={This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]},
  keywords="TN3270E, Telnet, option, client",
  doi="10.17487/RFC2355",
  }

@misc{rfc2356,
  author="G. Montenegro and V. Gupta",
  title="{Sun's SKIP Firewall Traversal for Mobile IP}",
  howpublished="RFC 2356 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2356",
  pages="1--24",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2356.txt",
  key="RFC 2356",
  abstract={The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network.  The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, security, traffic",
  doi="10.17487/RFC2356",
  }

@misc{rfc2357,
  author="A. Mankin and A. Romanow and S. Bradner and V. Paxson",
  title="{IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols}",
  howpublished="RFC 2357 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2357",
  pages="1--11",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2357.txt",
  key="RFC 2357",
  abstract={This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF.  Within today's Internet, important applications exist for a reliable multicast service.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, engineering, task, force, rmtp, procedures",
  doi="10.17487/RFC2357",
  }

@misc{rfc2358,
  author="J. Flick and J. Johnson",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 2358 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2358",
  pages="1--39",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2665",
url="https://www.rfc-editor.org/rfc/rfc2358.txt",
  key="RFC 2358",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  This memo obsoletes RFC 1650 ``Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2''.  This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]},
  keywords="MIB, Management, Information, Base, 802.3",
  doi="10.17487/RFC2358",
  }

@misc{rfc2359,
  author="J. Myers",
  title="{IMAP4 UIDPLUS extension}",
  howpublished="RFC 2359 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2359",
  pages="1--6",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4315",
url="https://www.rfc-editor.org/rfc/rfc2359.txt",
  key="RFC 2359",
  abstract={The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]},
  keywords="IMAP4UIDPL, internet, message, access, protocol, disconnected, operation",
  doi="10.17487/RFC2359",
  }

@misc{rfc2360,
  author="G. Scott",
  title="{Guide for Internet Standards Writers}",
  howpublished="RFC 2360 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2360",
  pages="1--20",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2360.txt",
  key="RFC 2360",
  abstract={This document is a guide for Internet standard writers.  It defines those characteristics that make standards coherent, unambiguous, and easy to interpret.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="specification, multiple, implementations",
  doi="10.17487/RFC2360",
  }

@misc{rfc2361,
  author="E. Fleischman",
  title="{WAVE and AVI Codec Registries}",
  howpublished="RFC 2361 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2361",
  pages="1--71",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2361.txt",
  key="RFC 2361",
  abstract={The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="multimedia, parameter, audio, video, microsoft",
  doi="10.17487/RFC2361",
  }

@misc{rfc2362,
  author="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. Deering and M. Handley and V. Jacobson and C. Liu and P. Sharma and L. Wei",
  title="{Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification}",
  howpublished="RFC 2362 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2362",
  pages="1--66",
  year=1998,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4601, 5059",
url="https://www.rfc-editor.org/rfc/rfc2362.txt",
  key="RFC 2362",
  abstract={This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets.  This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.},
  keywords="PIM-SM], routing, message, type, timers, flags",
  doi="10.17487/RFC2362",
  }

@misc{rfc2363,
  author="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens",
  title="{PPP Over FUNI}",
  howpublished="RFC 2363 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2363",
  pages="1--12",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2363.txt",
  key="RFC 2363",
  abstract={This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="PPP-FUNI, point-to-point, protocol, atm, synchronous, transfer, mode, frame, user, network, interface",
  doi="10.17487/RFC2363",
  }

@misc{rfc2364,
  author="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens",
  title="{PPP Over AAL5}",
  howpublished="RFC 2364 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2364",
  pages="1--12",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2364.txt",
  key="RFC 2364",
  abstract={This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="PPP-AAL, point-to-point, protocol, link, control, network-layer, authentication, compression",
  doi="10.17487/RFC2364",
  }

@misc{rfc2365,
  author="D. Meyer",
  title="{Administratively Scoped IP Multicast}",
  howpublished="RFC 2365 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2365",
  pages="1--8",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2365.txt",
  key="RFC 2365",
  abstract={This document defines the ``administratively scoped IPv4 multicast space'' to be the range 239.0.0.0 to 239.255.255.255.  In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast.  Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, protocol, IPv4, ipv6, address, classes",
  doi="10.17487/RFC2365",
  }

@misc{rfc2366,
  author="C. Chung and M. Greene",
  title="{Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks}",
  howpublished="RFC 2366 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2366",
  pages="1--76",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2417",
url="https://www.rfc-editor.org/rfc/rfc2366.txt",
  key="RFC 2366",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base, asynchronous, transfer, mode",
  doi="10.17487/RFC2366",
  }

@misc{rfc2367,
  author="D. McDonald and C. Metz and B. Phan",
  title="{PF\_KEY Key Management API, Version 2}",
  howpublished="RFC 2367 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2367",
  pages="1--68",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2367.txt",
  key="RFC 2367",
  abstract={A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="IP, internet, protocol, security, application, programming, interface",
  doi="10.17487/RFC2367",
  }

@misc{rfc2368,
  author="P. Hoffman and L. Masinter and J. Zawinski",
  title="{The mailto URL scheme}",
  howpublished="RFC 2368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2368",
  pages="1--10",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6068",
url="https://www.rfc-editor.org/rfc/rfc2368.txt",
  key="RFC 2368",
  abstract={This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]},
  keywords="URLMAILTO, uniform, resource, locator, electronic, mail, addresses",
  doi="10.17487/RFC2368",
  }

@misc{rfc2369,
  author="G. Neufeld and J. Baer",
  title="{The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields}",
  howpublished="RFC 2369 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2369",
  pages="1--15",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2369.txt",
  key="RFC 2369",
  abstract={The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists.  By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions.  This could take the form of a menu item, push button, or other user interface element.  The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]},
  keywords="uniform, resource, locator, email, header, fields",
  doi="10.17487/RFC2369",
  }

@misc{rfc2370,
  author="R. Coltun",
  title="{The OSPF Opaque LSA Option}",
  howpublished="RFC 2370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2370",
  pages="1--15",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5250, updated by RFC 3630",
url="https://www.rfc-editor.org/rfc/rfc2370.txt",
  key="RFC 2370",
  abstract={This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]},
  keywords="OSPF-LSA], open shortest path first, link state advertisement",
  doi="10.17487/RFC2370",
  }

@misc{rfc2371,
  author="J. Lyon and K. Evans and J. Klein",
  title="{Transaction Internet Protocol Version 3.0}",
  howpublished="RFC 2371 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2371",
  pages="1--31",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2371.txt",
  key="RFC 2371",
  abstract={In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically.  That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures.  This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]},
  keywords="TIPV3, TIP, commit, protocol, electronic, commerce",
  doi="10.17487/RFC2371",
  }

@misc{rfc2372,
  author="K. Evans and J. Klein and J. Lyon",
  title="{Transaction Internet Protocol - Requirements and Supplemental Information}",
  howpublished="RFC 2372 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2372",
  pages="1--24",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2372.txt",
  key="RFC 2372",
  abstract={This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="TIP, commit, protocol, electronic, commerce",
  doi="10.17487/RFC2372",
  }

@misc{rfc2373,
  author="R. Hinden and S. Deering",
  title="{IP Version 6 Addressing Architecture}",
  howpublished="RFC 2373 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2373",
  pages="1--26",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3513",
url="https://www.rfc-editor.org/rfc/rfc2373.txt",
  key="RFC 2373",
  abstract={This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]},
  keywords="internet, protocol, unicast, anycast, multicast, node",
  doi="10.17487/RFC2373",
  }

@misc{rfc2374,
  author="R. Hinden and M. O'Dell and S. Deering",
  title="{An IPv6 Aggregatable Global Unicast Address Format}",
  howpublished="RFC 2374 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2374",
  pages="1--12",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3587",
url="https://www.rfc-editor.org/rfc/rfc2374.txt",
  key="RFC 2374",
  abstract={This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]},
  keywords="internet, protocol, architecture, routing",
  doi="10.17487/RFC2374",
  }

@misc{rfc2375,
  author="R. Hinden and S. Deering",
  title="{IPv6 Multicast Address Assignments}",
  howpublished="RFC 2375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2375",
  pages="1--8",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2375.txt",
  key="RFC 2375",
  abstract={This document defines the initial assignment of IPv6 multicast addresses.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, protocol, multicast, scope, value",
  doi="10.17487/RFC2375",
  }

@misc{rfc2376,
  author="E. Whitehead and M. Murata",
  title="{XML Media Types}",
  howpublished="RFC 2376 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2376",
  pages="1--15",
  year=1998,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3023",
url="https://www.rfc-editor.org/rfc/rfc2376.txt",
  key="RFC 2376",
  abstract={This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML).  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="extensible, markup, language, web, authority, hypertext, transfer, protocol",
  doi="10.17487/RFC2376",
  }

@misc{rfc2377,
  author="A. Grimstad and R. Huber and S. Sataluri and M. Wahl",
  title="{Naming Plan for Internet Directory-Enabled Applications}",
  howpublished="RFC 2377 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2377",
  pages="1--18",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4519",
url="https://www.rfc-editor.org/rfc/rfc2377.txt",
  key="RFC 2377",
  abstract={Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet.  We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="x.500, applications, iwps, white, pages, service",
  doi="10.17487/RFC2377",
  }

@misc{rfc2378,
  author="R. Hedberg and P. Pomes",
  title="{The CCSO Nameserver (Ph) Architecture}",
  howpublished="RFC 2378 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2378",
  pages="1--22",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2378.txt",
  key="RFC 2378",
  abstract={The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things.  This document provides a formal definition of the client-server protocol.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="computing, communications, services, office, database",
  doi="10.17487/RFC2378",
  }

@misc{rfc2379,
  author="L. Berger",
  title="{RSVP over ATM Implementation Guidelines}",
  howpublished="RFC 2379 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2379",
  pages="1--8",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2379.txt",
  key="RFC 2379",
  abstract={This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="asynchronous, transfer, mode, resource, reservation, protocol, switched, circuits",
  doi="10.17487/RFC2379",
  }

@misc{rfc2380,
  author="L. Berger",
  title="{RSVP over ATM Implementation Requirements}",
  howpublished="RFC 2380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2380",
  pages="1--14",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2380.txt",
  key="RFC 2380",
  abstract={This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs).  It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, asynchronous, transfer, mode, switched, circuits",
  doi="10.17487/RFC2380",
  }

@misc{rfc2381,
  author="M. Garrett and M. Borden",
  title="{Interoperation of Controlled-Load Service and Guaranteed Service with ATM}",
  howpublished="RFC 2381 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2381",
  pages="1--43",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2381.txt",
  key="RFC 2381",
  abstract={This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]},
  keywords="asynchronous, transfer, mode, mapping, traffic, parameters",
  doi="10.17487/RFC2381",
  }

@misc{rfc2382,
  author="E. Crawley and L. Berger and S. Berson and F. Baker and M. Borden and J. Krawczyk",
  title="{A Framework for Integrated Services and RSVP over ATM}",
  howpublished="RFC 2382 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2382",
  pages="1--30",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2382.txt",
  key="RFC 2382",
  abstract={This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  doi="10.17487/RFC2382",
  }

@misc{rfc2383,
  author="M. Suzuki",
  title="{ST2+ over ATM Protocol Specification - UNI 3.1 Version}",
  howpublished="RFC 2383 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2383",
  pages="1--50",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2383.txt",
  key="RFC 2383",
  abstract={This document specifies an ATM-based protocol for communication between ST2+ agents.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="asynchronous, transfer, mode, stream, resource, reservation",
  doi="10.17487/RFC2383",
  }

@misc{rfc2384,
  author="R. Gellens",
  title="{POP URL Scheme}",
  howpublished="RFC 2384 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2384",
  pages="1--8",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2384.txt",
  key="RFC 2384",
  abstract={This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]},
  keywords="POP-URL, post, office, protocol, uniform, resource, identifier, string, encapsulation",
  doi="10.17487/RFC2384",
  }

@misc{rfc2385,
  author="A. Heffernan",
  title="{Protection of BGP Sessions via the TCP MD5 Signature Option}",
  howpublished="RFC 2385 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2385",
  pages="1--6",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5925, updated by RFC 6691",
url="https://www.rfc-editor.org/rfc/rfc2385.txt",
  key="RFC 2385",
  abstract={This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]},
  keywords="border, gateway, protocol, transmission, control, message, digest, algorithm",
  doi="10.17487/RFC2385",
  }

@misc{rfc2386,
  author="E. Crawley and R. Nair and B. Rajagopalan and H. Sandick",
  title="{A Framework for QoS-based Routing in the Internet}",
  howpublished="RFC 2386 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2386",
  pages="1--37",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2386.txt",
  key="RFC 2386",
  abstract={This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="quality of service, interdomain, intradomain",
  doi="10.17487/RFC2386",
  }

@misc{rfc2387,
  author="E. Levinson",
  title="{The MIME Multipart/Related Content-type}",
  howpublished="RFC 2387 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2387",
  pages="1--10",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2387.txt",
  key="RFC 2387",
  abstract={This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]},
  keywords="MIME-RELAT, multipurpose, internet, mail, extensions, body, parts, media-type",
  doi="10.17487/RFC2387",
  }

@misc{rfc2388,
  author="L. Masinter",
  title="{Returning Values from Forms: multipart/form-data}",
  howpublished="RFC 2388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2388",
  pages="1--9",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7578",
url="https://www.rfc-editor.org/rfc/rfc2388.txt",
  key="RFC 2388",
  abstract={This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]},
  keywords="media-type, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2388",
  }

@misc{rfc2389,
  author="P. Hethmon and R. Elz",
  title="{Feature negotiation mechanism for the File Transfer Protocol}",
  howpublished="RFC 2389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2389",
  pages="1--9",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2389.txt",
  key="RFC 2389",
  abstract={This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]},
  keywords="FTP, catalogue",
  doi="10.17487/RFC2389",
  }

@misc{rfc2390,
  author="T. Bradley and C. Brown and A. Malis",
  title="{Inverse Address Resolution Protocol}",
  howpublished="RFC 2390 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2390",
  pages="1--10",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2390.txt",
  key="RFC 2390",
  abstract={This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]},
  keywords="IARP, iarp, hardware, frame, relay",
  doi="10.17487/RFC2390",
  }

@misc{rfc2391,
  author="P. Srisuresh and D. Gan",
  title="{Load Sharing using IP Network Address Translation (LSNAT)}",
  howpublished="RFC 2391 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2391",
  pages="1--18",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2391.txt",
  key="RFC 2391",
  abstract={In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, protocol, datagram, server",
  doi="10.17487/RFC2391",
  }

@misc{rfc2392,
  author="E. Levinson",
  title="{Content-ID and Message-ID Uniform Resource Locators}",
  howpublished="RFC 2392 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2392",
  pages="1--6",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2392.txt",
  key="RFC 2392",
  abstract={The Uniform Resource Locator (URL) schemes, ``cid:'' and ``mid:'' allow references to messages and the body parts of messages.  For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]},
  keywords="CIDMID-URL, Hyper, Text, Markup, Language, URL, MIME",
  doi="10.17487/RFC2392",
  }

@misc{rfc2393,
  author="A. Shacham and R. Monsour and R. Pereira and M. Thomas",
  title="{IP Payload Compression Protocol (IPComp)}",
  howpublished="RFC 2393 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2393",
  pages="1--10",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3173",
url="https://www.rfc-editor.org/rfc/rfc2393.txt",
  key="RFC 2393",
  abstract={This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]},
  keywords="IPCOMP, internet, protocol, datagram, lossless",
  doi="10.17487/RFC2393",
  }

@misc{rfc2394,
  author="R. Pereira",
  title="{IP Payload Compression Using DEFLATE}",
  howpublished="RFC 2394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2394",
  pages="1--6",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2394.txt",
  key="RFC 2394",
  abstract={This document describes a compression method based on the DEFLATE compression algorithm.  This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, protocol, algorithm, datagram, format",
  doi="10.17487/RFC2394",
  }

@misc{rfc2395,
  author="R. Friend and R. Monsour",
  title="{IP Payload Compression Using LZS}",
  howpublished="RFC 2395 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2395",
  pages="1--9",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2395.txt",
  key="RFC 2395",
  abstract={This document describes a compression method based on the LZS compression algorithm.  This document defines the application of the LZS algorithm to the IP Payload Compression Protocol.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="internet, protocol, algorithm, datagram, lossless",
  doi="10.17487/RFC2395",
  }

@misc{rfc2396,
  author="T. Berners-Lee and R. Fielding and L. Masinter",
  title="{Uniform Resource Identifiers (URI): Generic Syntax}",
  howpublished="RFC 2396 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2396",
  pages="1--40",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3986, updated by RFC 2732",
url="https://www.rfc-editor.org/rfc/rfc2396.txt",
  key="RFC 2396",
  abstract={This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]},
  keywords="URI-GEN, characters, string, absolute, relative",
  doi="10.17487/RFC2396",
  }

@misc{rfc2397,
  author="L. Masinter",
  title="{The ``data'' URL scheme}",
  howpublished="RFC 2397 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2397",
  pages="1--5",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2397.txt",
  key="RFC 2397",
  abstract={A new URL scheme, ``data'', is defined.  It allows inclusion of small data items as ``immediate'' data, as if it had been included externally. [STANDARDS-TRACK]},
  keywords="DATA-URL, uniform, resource, identifiers, media, type",
  doi="10.17487/RFC2397",
  }

@misc{rfc2398,
  author="S. Parker and C. Schmechel",
  title="{Some Testing Tools for TCP Implementors}",
  howpublished="RFC 2398 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2398",
  pages="1--15",
  year=1998,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2398.txt",
  key="RFC 2398",
  abstract={This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="transmission, control, protocol, catalogue",
  doi="10.17487/RFC2398",
  }

@misc{rfc2399,
  author="A. Ramos",
  title="{Request for Comments Summary}",
  howpublished="RFC 2399 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2399",
  pages="1--23",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2399.txt",
  key="RFC 2399",
  doi="10.17487/RFC2399",
  }

@misc{rfc2400,
  author="J. Postel and J. Reynolds",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2400 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2400",
  pages="1--47",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2500",
url="https://www.rfc-editor.org/rfc/rfc2400.txt",
  key="RFC 2400",
  abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).  This memo is an Internet Standard. [STANDARDS-TRACK]},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC2400",
  }

@misc{rfc2401,
  author="S. Kent and R. Atkinson",
  title="{Security Architecture for the Internet Protocol}",
  howpublished="RFC 2401 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2401",
  pages="1--66",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4301, updated by RFC 3168",
url="https://www.rfc-editor.org/rfc/rfc2401.txt",
  key="RFC 2401",
  abstract={This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]},
  keywords="IPSEC, ipsec, authentication, encapsulation, IP, IPv4, IPv6, IP-layer",
  doi="10.17487/RFC2401",
  }

@misc{rfc2402,
  author="S. Kent and R. Atkinson",
  title="{IP Authentication Header}",
  howpublished="RFC 2402 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2402",
  pages="1--22",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4302, 4305",
url="https://www.rfc-editor.org/rfc/rfc2402.txt",
  key="RFC 2402",
  abstract={The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just ``authentication''), and to provide protection against replays. [STANDARDS-TRACK]},
  keywords="IP-AUTH, ipsec, Internet, Protocol, AH, security, IPv4, IPv6",
  doi="10.17487/RFC2402",
  }

@misc{rfc2403,
  author="C. Madson and R. Glenn",
  title="{The Use of HMAC-MD5-96 within ESP and AH}",
  howpublished="RFC 2403 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2403",
  pages="1--7",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2403.txt",
  key="RFC 2403",
  abstract={This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]},
  keywords="ipsec, authentication, mechanism, header, security, architecture",
  doi="10.17487/RFC2403",
  }

@misc{rfc2404,
  author="C. Madson and R. Glenn",
  title="{The Use of HMAC-SHA-1-96 within ESP and AH}",
  howpublished="RFC 2404 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2404",
  pages="1--7",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2404.txt",
  key="RFC 2404",
  abstract={This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]},
  keywords="ipsec, authentication, mechanism, header, security, architecture, payload",
  doi="10.17487/RFC2404",
  }

@misc{rfc2405,
  author="C. Madson and N. Doraswamy",
  title="{The ESP DES-CBC Cipher Algorithm With Explicit IV}",
  howpublished="RFC 2405 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2405",
  pages="1--10",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2405.txt",
  key="RFC 2405",
  abstract={This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="ESPDES-CBC, ipsec, payload, security, architecture, encryption",
  doi="10.17487/RFC2405",
  }

@misc{rfc2406,
  author="S. Kent and R. Atkinson",
  title="{IP Encapsulating Security Payload (ESP)}",
  howpublished="RFC 2406 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2406",
  pages="1--22",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4303, 4305",
url="https://www.rfc-editor.org/rfc/rfc2406.txt",
  key="RFC 2406",
  abstract={The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]},
  keywords="ESP, ipsec, internet, protocol, encapsulating, security, ipv4, ipv6",
  doi="10.17487/RFC2406",
  }

@misc{rfc2407,
  author="D. Piper",
  title="{The Internet IP Security Domain of Interpretation for ISAKMP}",
  howpublished="RFC 2407 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2407",
  pages="1--32",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4306",
url="https://www.rfc-editor.org/rfc/rfc2407.txt",
  key="RFC 2407",
  abstract={This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]},
  keywords="ISAKMPSEC, ipsec, internet, protocol, security, association, key, management",
  doi="10.17487/RFC2407",
  }

@misc{rfc2408,
  author="D. Maughan and M. Schertler and M. Schneider and J. Turner",
  title="{Internet Security Association and Key Management Protocol (ISAKMP)}",
  howpublished="RFC 2408 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2408",
  pages="1--86",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4306",
url="https://www.rfc-editor.org/rfc/rfc2408.txt",
  key="RFC 2408",
  abstract={This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]},
  keywords="ISAKMP, ipsec, cryptography, authentication",
  doi="10.17487/RFC2408",
  }

@misc{rfc2409,
  author="D. Harkins and D. Carrel",
  title="{The Internet Key Exchange (IKE)}",
  howpublished="RFC 2409 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2409",
  pages="1--41",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4306, updated by RFC 4109",
url="https://www.rfc-editor.org/rfc/rfc2409.txt",
  key="RFC 2409",
  abstract={This memo describes a hybrid protocol.  The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]},
  keywords="IKE, ipsec, oakley, authentication, isakmp, internet, security, key, management",
  doi="10.17487/RFC2409",
  }

@misc{rfc2410,
  author="R. Glenn and S. Kent",
  title="{The NULL Encryption Algorithm and Its Use With IPsec}",
  howpublished="RFC 2410 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2410",
  pages="1--6",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2410.txt",
  key="RFC 2410",
  abstract={This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="ipsec, internet, protocol, security, esp, encapsulating, payload",
  doi="10.17487/RFC2410",
  }

@misc{rfc2411,
  author="R. Thayer and N. Doraswamy and R. Glenn",
  title="{IP Security Document Roadmap}",
  howpublished="RFC 2411 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2411",
  pages="1--11",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6071",
url="https://www.rfc-editor.org/rfc/rfc2411.txt",
  key="RFC 2411",
  abstract={This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol.  This memo provides information for the Internet community.},
  keywords="ipsec, internet, protocol, privacy, authentication",
  doi="10.17487/RFC2411",
  }

@misc{rfc2412,
  author="H. Orman",
  title="{The OAKLEY Key Determination Protocol}",
  howpublished="RFC 2412 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2412",
  pages="1--55",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2412.txt",
  key="RFC 2412",
  abstract={This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material.  The basic mechanism is the Diffie-Hellman key exchange algorithm.  This memo provides information for the Internet community.},
  keywords="ipsec, authentication, crytographic, secure, scalable",
  doi="10.17487/RFC2412",
  }

@misc{rfc2413,
  author="S. Weibel and J. Kunze and C. Lagoze and M. Wolf",
  title="{Dublin Core Metadata for Resource Discovery}",
  howpublished="RFC 2413 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2413",
  pages="1--8",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5013",
url="https://www.rfc-editor.org/rfc/rfc2413.txt",
  key="RFC 2413",
  abstract={This is the first of a set of Informational RFCs describing the Dublin Core.  Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements.  This memo provides information for the Internet community.},
  keywords="workshop, electronic, librarians, network",
  doi="10.17487/RFC2413",
  }

@misc{rfc2414,
  author="M. Allman and S. Floyd and C. Partridge",
  title="{Increasing TCP's Initial Window}",
  howpublished="RFC 2414 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2414",
  pages="1--14",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3390",
url="https://www.rfc-editor.org/rfc/rfc2414.txt",
  key="RFC 2414",
  abstract={This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TCP-WIN, transmission, control, protocol",
  doi="10.17487/RFC2414",
  }

@misc{rfc2415,
  author="K. Poduri and K. Nichols",
  title="{Simulation Studies of Increased Initial TCP Window Size}",
  howpublished="RFC 2415 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2415",
  pages="1--11",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2415.txt",
  key="RFC 2415",
  abstract={This document covers some simulation studies of the effects of increasing the initial window size of TCP.  This memo provides information for the Internet community.},
  keywords="transmission, control, protocol, file, transfer",
  doi="10.17487/RFC2415",
  }

@misc{rfc2416,
  author="T. Shepard and C. Partridge",
  title="{When TCP Starts Up With Four Packets Into Only Three Buffers}",
  howpublished="RFC 2416 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2416",
  pages="1--7",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2416.txt",
  key="RFC 2416",
  abstract={This memo is to document a simple experiment.  The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).  This memo provides information for the Internet community.},
  keywords="transmission, control, protocol, performance",
  doi="10.17487/RFC2416",
  }

@misc{rfc2417,
  author="C. Chung and M. Greene",
  title="{Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks}",
  howpublished="RFC 2417 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2417",
  pages="1--76",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2417.txt",
  key="RFC 2417",
  abstract={This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base, asynchronous, transfer, mode",
  doi="10.17487/RFC2417",
  }

@misc{rfc2418,
  author="S. Bradner",
  title="{IETF Working Group Guidelines and Procedures}",
  howpublished="RFC 2418 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2418",
  pages="1--26",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3934, 7475, 7776",
url="https://www.rfc-editor.org/rfc/rfc2418.txt",
  key="RFC 2418",
  abstract={This document describes the guidelines and procedures for formation and operation of IETF working groups.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="BCP, WG, escape, clause, procedures",
  doi="10.17487/RFC2418",
  }

@misc{rfc2419,
  author="K. Sklower and G. Meyer",
  title="{The PPP DES Encryption Protocol, Version 2 (DESE-bis)}",
  howpublished="RFC 2419 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2419",
  pages="1--12",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2419.txt",
  key="RFC 2419",
  abstract={This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="DESE-bis, point-to-point, protocol, ecp, control",
  doi="10.17487/RFC2419",
  }

@misc{rfc2420,
  author="H. Kummert",
  title="{The PPP Triple-DES Encryption Protocol (3DESE)}",
  howpublished="RFC 2420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2420",
  pages="1--8",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2420.txt",
  key="RFC 2420",
  abstract={This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]},
  keywords="3DESE, point-to-point, protocol, ecp, control",
  doi="10.17487/RFC2420",
  }

@misc{rfc2421,
  author="G. Vaudreuil and G. Parsons",
  title="{Voice Profile for Internet Mail - version 2}",
  howpublished="RFC 2421 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2421",
  pages="1--56",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3801",
url="https://www.rfc-editor.org/rfc/rfc2421.txt",
  key="RFC 2421",
  abstract={This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]},
  keywords="MIME-VP2, vpim, messaging",
  doi="10.17487/RFC2421",
  }

@misc{rfc2422,
  author="G. Vaudreuil and G. Parsons",
  title="{Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration}",
  howpublished="RFC 2422 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2422",
  pages="1--6",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3802",
url="https://www.rfc-editor.org/rfc/rfc2422.txt",
  key="RFC 2422",
  abstract={This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]},
  keywords="MIME-ADPCM, multipurpose, internet, mail, extensions, audio",
  doi="10.17487/RFC2422",
  }

@misc{rfc2423,
  author="G. Vaudreuil and G. Parsons",
  title="{VPIM Voice Message MIME Sub-type Registration}",
  howpublished="RFC 2423 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2423",
  pages="1--6",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3801",
url="https://www.rfc-editor.org/rfc/rfc2423.txt",
  key="RFC 2423",
  abstract={This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]},
  keywords="MIME-VPIM, multipurpose, internet, mail, extensions, profiles",
  doi="10.17487/RFC2423",
  }

@misc{rfc2424,
  author="G. Vaudreuil and G. Parsons",
  title="{Content Duration MIME Header Definition}",
  howpublished="RFC 2424 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2424",
  pages="1--4",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3803",
url="https://www.rfc-editor.org/rfc/rfc2424.txt",
  key="RFC 2424",
  abstract={This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]},
  keywords="CONT-DUR, multipurpose, internet, mail, extensions, time, media",
  doi="10.17487/RFC2424",
  }

@misc{rfc2425,
  author="T. Howes and M. Smith and F. Dawson",
  title="{A MIME Content-Type for Directory Information}",
  howpublished="RFC 2425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2425",
  pages="1--33",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6350",
url="https://www.rfc-editor.org/rfc/rfc2425.txt",
  key="RFC 2425",
  abstract={This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]},
  keywords="TXT-DIR, multipurpose, internet, mail, extensions, profiles",
  doi="10.17487/RFC2425",
  }

@misc{rfc2426,
  author="F. Dawson and T. Howes",
  title="{vCard MIME Directory Profile}",
  howpublished="RFC 2426 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2426",
  pages="1--42",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6350",
url="https://www.rfc-editor.org/rfc/rfc2426.txt",
  key="RFC 2426",
  abstract={This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]},
  keywords="MIME-VCARD, multipurpose, internet, mail, extensions, white-pages, electronic, business, card",
  doi="10.17487/RFC2426",
  }

@misc{rfc2427,
  author="C. Brown and A. Malis",
  title="{Multiprotocol Interconnect over Frame Relay}",
  howpublished="RFC 2427 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2427",
  pages="1--34",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2427.txt",
  key="RFC 2427",
  abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone.  It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]},
  keywords="IP-FR, standard, standards, IP, over",
  doi="10.17487/RFC2427",
  }

@misc{rfc2428,
  author="M. Allman and S. Ostermann and C. Metz",
  title="{FTP Extensions for IPv6 and NATs}",
  howpublished="RFC 2428 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2428",
  pages="1--8",
  year=1998,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2428.txt",
  key="RFC 2428",
  abstract={This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]},
  keywords="file, transfer, protocol, internet, network, address, translators",
  doi="10.17487/RFC2428",
  }

@misc{rfc2429,
  author="C. Bormann and L. Cline and G. Deisher and T. Gardos and C. Maciocco and D. Newell and J. Ott and G. Sullivan and S. Wenger and C. Zhu",
  title="{RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)}",
  howpublished="RFC 2429 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2429",
  pages="1--17",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4629",
url="https://www.rfc-editor.org/rfc/rfc2429.txt",
  key="RFC 2429",
  abstract={This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]},
  keywords="real, time, transport, protocol, multicast, unicast",
  doi="10.17487/RFC2429",
  }

@misc{rfc2430,
  author="T. Li and Y. Rekhter",
  title="{A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)}",
  howpublished="RFC 2430 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2430",
  pages="1--16",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2430.txt",
  key="RFC 2430",
  abstract={This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs).  This memo provides information for the Internet community.},
  keywords="isp, internet, service, provider, packet, flow, multiprotocol, label, switching, mpls, resource, reservation, protocol, rsvp",
  doi="10.17487/RFC2430",
  }

@misc{rfc2431,
  author="D. Tynan",
  title="{RTP Payload Format for BT.656 Video Encoding}",
  howpublished="RFC 2431 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2431",
  pages="1--10",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2431.txt",
  key="RFC 2431",
  abstract={This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]},
  keywords="real, time, transport, protocol, itu, multicast, unicast",
  doi="10.17487/RFC2431",
  }

@misc{rfc2432,
  author="K. Dubray",
  title="{Terminology for IP Multicast Benchmarking}",
  howpublished="RFC 2432 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2432",
  pages="1--16",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2432.txt",
  key="RFC 2432",
  abstract={The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices.  This memo provides information for the Internet community.},
  keywords="internet, protocol, network, forwarding, devices",
  doi="10.17487/RFC2432",
  }

@misc{rfc2433,
  author="G. Zorn and S. Cobb",
  title="{Microsoft PPP CHAP Extensions}",
  howpublished="RFC 2433 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2433",
  pages="1--20",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2433.txt",
  key="RFC 2433",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.  This memo provides information for the Internet community.},
  keywords="point to point, protocol, challenge, handshake, authentication",
  doi="10.17487/RFC2433",
  }

@misc{rfc2434,
  author="T. Narten and H. Alvestrand",
  title="{Guidelines for Writing an IANA Considerations Section in RFCs}",
  howpublished="RFC 2434 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2434",
  pages="1--11",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5226, updated by RFC 3692",
url="https://www.rfc-editor.org/rfc/rfc2434.txt",
  key="RFC 2434",
  abstract={This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, assigned, numbers, authority, values, implementations",
  doi="10.17487/RFC2434",
  }

@misc{rfc2435,
  author="L. Berc and W. Fenner and R. Frederick and S. McCanne and P. Stewart",
  title="{RTP Payload Format for JPEG-compressed Video}",
  howpublished="RFC 2435 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2435",
  pages="1--27",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2435.txt",
  key="RFC 2435",
  abstract={This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]},
  keywords="Real, Time, Transport, Protocol, Joint, Photographic, Experts, Group",
  doi="10.17487/RFC2435",
  }

@misc{rfc2436,
  author="R. Brett and S. Bradner and G. Parsons",
  title="{Collaboration between ISOC/IETF and ITU-T}",
  howpublished="RFC 2436 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2436",
  pages="1--14",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3356",
url="https://www.rfc-editor.org/rfc/rfc2436.txt",
  key="RFC 2436",
  abstract={This document describes the collaboration process between the ITU-T and ISOC/IETF.  This memo provides information for the Internet community.},
  keywords="internet, society, engineering, task, force",
  doi="10.17487/RFC2436",
  }

@misc{rfc2437,
  author="B. Kaliski and J. Staddon",
  title="{PKCS \#1: RSA Cryptography Specifications Version 2.0}",
  howpublished="RFC 2437 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2437",
  pages="1--39",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3447",
url="https://www.rfc-editor.org/rfc/rfc2437.txt",
  key="RFC 2437",
  abstract={This memo is the successor to RFC 2313.  This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm.  This memo provides information for the Internet community.},
  keywords="data, public, key, cryptosystem",
  doi="10.17487/RFC2437",
  }

@misc{rfc2438,
  author="M. O'Dell and H. Alvestrand and B. Wijnen and S. Bradner",
  title="{Advancement of MIB specifications on the IETF Standards Track}",
  howpublished="RFC 2438 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2438",
  pages="1--7",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2438.txt",
  key="RFC 2438",
  abstract={This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements.  It also discusses the rationale for this process.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="management, information, base, internet, engineering, task, force",
  doi="10.17487/RFC2438",
  }

@misc{rfc2439,
  author="C. Villamizar and R. Chandra and R. Govindan",
  title="{BGP Route Flap Damping}",
  howpublished="RFC 2439 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2439",
  pages="1--37",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2439.txt",
  key="RFC 2439",
  abstract={A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]},
  keywords="Border, Gateway, Protocol, IDRP, Internet-Domain, Routing",
  doi="10.17487/RFC2439",
  }

@misc{rfc2440,
  author="J. Callas and L. Donnerhacke and H. Finney and R. Thayer",
  title="{OpenPGP Message Format}",
  howpublished="RFC 2440 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2440",
  pages="1--65",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4880",
url="https://www.rfc-editor.org/rfc/rfc2440.txt",
  key="RFC 2440",
  abstract={This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]},
  keywords="pretty, good, privacy, encryption, authentication",
  doi="10.17487/RFC2440",
  }

@misc{rfc2441,
  author="D. Cohen",
  title="{Working with Jon, Tribute delivered at UCLA, October 30, 1998}",
  howpublished="RFC 2441 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2441",
  pages="1--6",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2441.txt",
  key="RFC 2441",
  abstract={This memo provides information for the Internet community.},
  keywords="Jonathan B Postel",
  doi="10.17487/RFC2441",
  }

@misc{rfc2442,
  author="N. Freed and D. Newman and J. Belissent and M. Hoy",
  title="{The Batch SMTP Media Type}",
  howpublished="RFC 2442 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2442",
  pages="1--9",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2442.txt",
  key="RFC 2442",
  abstract={This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport.  This memo provides information for the Internet community},
  keywords="simple, transfer, protocol, mime, multipurpose, internet, mail, extensions, tunneling",
  doi="10.17487/RFC2442",
  }

@misc{rfc2443,
  author="J. Luciani and A. Gallo",
  title="{A Distributed MARS Service Using SCSP}",
  howpublished="RFC 2443 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2443",
  pages="1--18",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2443.txt",
  key="RFC 2443",
  abstract={This document describes a method for distributing a MARS service within a LIS.  This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS.  When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]},
  keywords="MARS-SCSP, server, cache, syncronization, protocol, atm, asynchronous, transfer, mode",
  doi="10.17487/RFC2443",
  }

@misc{rfc2444,
  author="C. Newman",
  title="{The One-Time-Password SASL Mechanism}",
  howpublished="RFC 2444 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2444",
  pages="1--7",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2444.txt",
  key="RFC 2444",
  abstract={OTP provides a useful authentication mechanism for situations where there is limited client or server trust.  Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing.  This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]},
  keywords="OTP-SASL, otp, simple, authentication, security, layer",
  doi="10.17487/RFC2444",
  }

@misc{rfc2445,
  author="F. Dawson and D. Stenerson",
  title="{Internet Calendaring and Scheduling Core Object Specification (iCalendar)}",
  howpublished="RFC 2445 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2445",
  pages="1--148",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5545",
url="https://www.rfc-editor.org/rfc/rfc2445.txt",
  key="RFC 2445",
  abstract={This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]},
  keywords="ICALENDAR, internet, interoperable, mime, multipurpose, mail, extensions",
  doi="10.17487/RFC2445",
  }

@misc{rfc2446,
  author="S. Silverberg and S. Mansour and F. Dawson and R. Hopson",
  title="{iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries}",
  howpublished="RFC 2446 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2446",
  pages="1--109",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5546",
url="https://www.rfc-editor.org/rfc/rfc2446.txt",
  key="RFC 2446",
  abstract={This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems.  It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]},
  keywords="ITIP, internet, systems, interoperability",
  doi="10.17487/RFC2446",
  }

@misc{rfc2447,
  author="F. Dawson and S. Mansour and S. Silverberg",
  title="{iCalendar Message-Based Interoperability Protocol (iMIP)}",
  howpublished="RFC 2447 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2447",
  pages="1--18",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6047",
url="https://www.rfc-editor.org/rfc/rfc2447.txt",
  key="RFC 2447",
  abstract={This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]},
  keywords="IMIP, internet, electronic, mail, transport",
  doi="10.17487/RFC2447",
  }

@misc{rfc2448,
  author="M. Civanlar and G. Cash and B. Haskell",
  title="{AT\&T's Error Resilient Video Transmission Technique}",
  howpublished="RFC 2448 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2448",
  pages="1--7",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2448.txt",
  key="RFC 2448",
  abstract={This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments.  This memo provides information for the Internet community.},
  keywords="packets, network, bitstreams",
  doi="10.17487/RFC2448",
  }

@misc{rfc2449,
  author="R. Gellens and C. Newman and L. Lundblade",
  title="{POP3 Extension Mechanism}",
  howpublished="RFC 2449 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2449",
  pages="1--19",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5034",
url="https://www.rfc-editor.org/rfc/rfc2449.txt",
  key="RFC 2449",
  abstract={This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]},
  keywords="POP3-EXT, post, office, protocol, server",
  doi="10.17487/RFC2449",
  }

@misc{rfc2450,
  author="R. Hinden",
  title="{Proposed TLA and NLA Assignment Rule}",
  howpublished="RFC 2450 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2450",
  pages="1--11",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2450.txt",
  key="RFC 2450",
  abstract={This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID).  This memo provides information for the Internet community.},
  keywords="top-level, aggregation, identifiers, next-level, ipv6, internet, protocols, addresses",
  doi="10.17487/RFC2450",
  }

@misc{rfc2451,
  author="R. Pereira and R. Adams",
  title="{The ESP CBC-Mode Cipher Algorithms}",
  howpublished="RFC 2451 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2451",
  pages="1--14",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2451.txt",
  key="RFC 2451",
  abstract={This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol.  It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]},
  keywords="ipsec, encapsulating, security, payload",
  doi="10.17487/RFC2451",
  }

@misc{rfc2452,
  author="M. Daniele",
  title="{IP Version 6 Management Information Base for the Transmission Control Protocol}",
  howpublished="RFC 2452 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2452",
  pages="1--10",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4022, 8096",
url="https://www.rfc-editor.org/rfc/rfc2452.txt",
  key="RFC 2452",
  abstract={This document is one in the series of documents that define various MIB objects for IPv6.  Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]},
  keywords="mib, internet, protocol, tcp, ipv6",
  doi="10.17487/RFC2452",
  }

@misc{rfc2453,
  author="G. Malkin",
  title="{RIP Version 2}",
  howpublished="RFC 2453 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2453",
  pages="1--39",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4822",
url="https://www.rfc-editor.org/rfc/rfc2453.txt",
  key="RFC 2453",
  abstract={This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]},
  keywords="RIP2, RIP-2",
  doi="10.17487/RFC2453",
  }

@misc{rfc2454,
  author="M. Daniele",
  title="{IP Version 6 Management Information Base for the User Datagram Protocol}",
  howpublished="RFC 2454 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2454",
  pages="1--9",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4113, 8096",
url="https://www.rfc-editor.org/rfc/rfc2454.txt",
  key="RFC 2454",
  abstract={This document is one in the series of documents that define various MIB objects for IPv6.  Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]},
  keywords="mib, internet, protocol, udp, ipv6",
  doi="10.17487/RFC2454",
  }

@misc{rfc2455,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for APPN}",
  howpublished="RFC 2455 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2455",
  pages="1--140",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2455.txt",
  key="RFC 2455",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities.  This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]},
  keywords="APPN-MIB, mib, management, information, base, advanced, peer-to-peer, networking",
  doi="10.17487/RFC2455",
  }

@misc{rfc2456,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for APPN TRAPS}",
  howpublished="RFC 2456 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2456",
  pages="1--21",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2456.txt",
  key="RFC 2456",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities.  This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]},
  keywords="mib, management, information, base, advanced, peer-to-peer, networking",
  doi="10.17487/RFC2456",
  }

@misc{rfc2457,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for Extended Border Node}",
  howpublished="RFC 2457 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2457",
  pages="1--28",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2457.txt",
  key="RFC 2457",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities.  This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]},
  keywords="EBN-MIB, mib, management, information, base, ebn",
  doi="10.17487/RFC2457",
  }

@misc{rfc2458,
  author="H. Lu and M. Krishnaswamy and L. Conroy and S. Bellovin and F. Burg and A. DeSimone and K. Tewani and P. Davidson and H. Schulzrinne and K. Vishwanathan",
  title="{Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations}",
  howpublished="RFC 2458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2458",
  pages="1--60",
  year=1998,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2458.txt",
  key="RFC 2458",
  abstract={This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group.  This memo provides information for the Internet community.},
  doi="10.17487/RFC2458",
  }

@misc{rfc2459,
  author="R. Housley and W. Ford and W. Polk and D. Solo",
  title="{Internet X.509 Public Key Infrastructure Certificate and CRL Profile}",
  howpublished="RFC 2459 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2459",
  pages="1--129",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3280",
url="https://www.rfc-editor.org/rfc/rfc2459.txt",
  key="RFC 2459",
  abstract={This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]},
  keywords="digital, signatures, encryption, authentication",
  doi="10.17487/RFC2459",
  }

@misc{rfc2460,
  author="S. Deering and R. Hinden",
  title="{Internet Protocol, Version 6 (IPv6) Specification}",
  howpublished="RFC 2460 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2460",
  pages="1--39",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045, 7112",
url="https://www.rfc-editor.org/rfc/rfc2460.txt",
  key="RFC 2460",
  abstract={This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]},
  keywords="IPV6, internet, protocol, next, generation, ipng",
  doi="10.17487/RFC2460",
  }

@misc{rfc2461,
  author="T. Narten and E. Nordmark and W. Simpson",
  title="{Neighbor Discovery for IP Version 6 (IPv6)}",
  howpublished="RFC 2461 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2461",
  pages="1--93",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4861, updated by RFC 4311",
url="https://www.rfc-editor.org/rfc/rfc2461.txt",
  key="RFC 2461",
  abstract={This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]},
  keywords="IPV6-ND, internet, protocol, link-layer",
  doi="10.17487/RFC2461",
  }

@misc{rfc2462,
  author="S. Thomson and T. Narten",
  title="{IPv6 Stateless Address Autoconfiguration}",
  howpublished="RFC 2462 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2462",
  pages="1--25",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4862",
url="https://www.rfc-editor.org/rfc/rfc2462.txt",
  key="RFC 2462",
  abstract={This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]},
  keywords="IPV6-AUTO, internet, protocol, host, link-local",
  doi="10.17487/RFC2462",
  }

@misc{rfc2463,
  author="A. Conta and S. Deering",
  title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification}",
  howpublished="RFC 2463 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2463",
  pages="1--18",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4443",
url="https://www.rfc-editor.org/rfc/rfc2463.txt",
  key="RFC 2463",
  abstract={This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]},
  keywords="ICMPv6, internet, protocol, link-local, autoconfigured, addresses",
  doi="10.17487/RFC2463",
  }

@misc{rfc2464,
  author="M. Crawford",
  title="{Transmission of IPv6 Packets over Ethernet Networks}",
  howpublished="RFC 2464 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2464",
  pages="1--7",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6085, 8064",
url="https://www.rfc-editor.org/rfc/rfc2464.txt",
  key="RFC 2464",
  abstract={This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks.  It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]},
  keywords="internet, protocol, link-local, autoconfigured, addresses",
  doi="10.17487/RFC2464",
  }

@misc{rfc2465,
  author="D. Haskin and S. Onishi",
  title="{Management Information Base for IP Version 6: Textual Conventions and General Group}",
  howpublished="RFC 2465 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2465",
  pages="1--38",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4293, 8096",
url="https://www.rfc-editor.org/rfc/rfc2465.txt",
  key="RFC 2465",
  abstract={This document is one in the series of documents that provide MIB definitions for for IP Version 6.  Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]},
  keywords="mib, internet, protocol, ipv6",
  doi="10.17487/RFC2465",
  }

@misc{rfc2466,
  author="D. Haskin and S. Onishi",
  title="{Management Information Base for IP Version 6: ICMPv6 Group}",
  howpublished="RFC 2466 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2466",
  pages="1--16",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4293, 8096",
url="https://www.rfc-editor.org/rfc/rfc2466.txt",
  key="RFC 2466",
  abstract={This document is one in the series of documents that define various MIB object groups for IPv6.  Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]},
  keywords="ICMPv6-MIB, mib, internet, protocol, ipv6",
  doi="10.17487/RFC2466",
  }

@misc{rfc2467,
  author="M. Crawford",
  title="{Transmission of IPv6 Packets over FDDI Networks}",
  howpublished="RFC 2467 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2467",
  pages="1--9",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2467.txt",
  key="RFC 2467",
  abstract={This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]},
  keywords="internet, protocol, link-local, addresses, autoconfiguration",
  doi="10.17487/RFC2467",
  }

@misc{rfc2468,
  author="V. Cerf",
  title="{I REMEMBER IANA}",
  howpublished="RFC 2468 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2468",
  pages="1--4",
  year=1998,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2468.txt",
  key="RFC 2468",
  abstract={A long time ago, in a network, far far away, a great adventure took place!.  This memo provides information for the Internet community.},
  keywords="jonathan b postel",
  doi="10.17487/RFC2468",
  }

@misc{rfc2469,
  author="T. Narten and C. Burton",
  title="{A Caution On The Canonical Ordering Of Link-Layer Addresses}",
  howpublished="RFC 2469 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2469",
  pages="1--5",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2469.txt",
  key="RFC 2469",
  abstract={Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses.  In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly.  In most cases, such fields must be in ``canonical form''.  Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format.  This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.  This memo provides information for the Internet community.},
  keywords="address, resolution, protocol, data, fields",
  doi="10.17487/RFC2469",
  }

@misc{rfc2470,
  author="M. Crawford and T. Narten and S. Thomas",
  title="{Transmission of IPv6 Packets over Token Ring Networks}",
  howpublished="RFC 2470 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2470",
  pages="1--11",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2470.txt",
  key="RFC 2470",
  abstract={This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]},
  keywords="internet, protocol, frame, format, link-local, addresses",
  doi="10.17487/RFC2470",
  }

@misc{rfc2471,
  author="R. Hinden and R. Fink and J. Postel",
  title="{IPv6 Testing Address Allocation}",
  howpublished="RFC 2471 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2471",
  pages="1--5",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3701",
url="https://www.rfc-editor.org/rfc/rfc2471.txt",
  key="RFC 2471",
  abstract={This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="internet, protocol, protocotype, software, architecture",
  doi="10.17487/RFC2471",
  }

@misc{rfc2472,
  author="D. Haskin and E. Allen",
  title="{IP Version 6 over PPP}",
  howpublished="RFC 2472 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2472",
  pages="1--14",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5072, 5172",
url="https://www.rfc-editor.org/rfc/rfc2472.txt",
  key="RFC 2472",
  abstract={This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP.  It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]},
  keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6",
  doi="10.17487/RFC2472",
  }

@misc{rfc2473,
  author="A. Conta and S. Deering",
  title="{Generic Packet Tunneling in IPv6 Specification}",
  howpublished="RFC 2473 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2473",
  pages="1--36",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2473.txt",
  key="RFC 2473",
  abstract={This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]},
  keywords="internet, protocol, encapsulation",
  doi="10.17487/RFC2473",
  }

@misc{rfc2474,
  author="K. Nichols and S. Blake and F. Baker and D. Black",
  title="{Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers}",
  howpublished="RFC 2474 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2474",
  pages="1--20",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3168, 3260",
url="https://www.rfc-editor.org/rfc/rfc2474.txt",
  key="RFC 2474",
  abstract={This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]},
  keywords="internet, protocol, network, nodes",
  doi="10.17487/RFC2474",
  }

@misc{rfc2475,
  author="S. Blake and D. Black and M. Carlson and E. Davies and Z. Wang and W. Weiss",
  title="{An Architecture for Differentiated Services}",
  howpublished="RFC 2475 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2475",
  pages="1--36",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3260",
url="https://www.rfc-editor.org/rfc/rfc2475.txt",
  key="RFC 2475",
  abstract={This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information for the Internet community.},
  keywords="DIFFSRV], scalability, IP, internet, protocol",
  doi="10.17487/RFC2475",
  }

@misc{rfc2476,
  author="R. Gellens and J. Klensin",
  title="{Message Submission}",
  howpublished="RFC 2476 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2476",
  pages="1--15",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4409",
url="https://www.rfc-editor.org/rfc/rfc2476.txt",
  key="RFC 2476",
  abstract={This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]},
  keywords="smtp, simple, mail, transfer, protocol, user, agent",
  doi="10.17487/RFC2476",
  }

@misc{rfc2477,
  author="B. Aboba and G. Zorn",
  title="{Criteria for Evaluating Roaming Protocols}",
  howpublished="RFC 2477 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2477",
  pages="1--12",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2477.txt",
  key="RFC 2477",
  abstract={This document describes requirements for the provisioning of ``roaming capability'' for dialup Internet users. ``Roaming capability'' is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one.  This memo provides information for the Internet community.},
  keywords="ISP, internet, service, providers, operations",
  doi="10.17487/RFC2477",
  }

@misc{rfc2478,
  author="E. Baize and D. Pinkas",
  title="{The Simple and Protected GSS-API Negotiation Mechanism}",
  howpublished="RFC 2478 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2478",
  pages="1--18",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4178",
url="https://www.rfc-editor.org/rfc/rfc2478.txt",
  key="RFC 2478",
  abstract={This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]},
  keywords="generic, service, application, security, program, interface",
  doi="10.17487/RFC2478",
  }

@misc{rfc2479,
  author="C. Adams",
  title="{Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)}",
  howpublished="RFC 2479 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2479",
  pages="1--70",
  year=1998,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2479.txt",
  key="RFC 2479",
  abstract={The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated ``receivers'' of the data unit.  This memo provides information for the Internet community.},
  keywords="data, unit, authentication",
  doi="10.17487/RFC2479",
  }

@misc{rfc2480,
  author="N. Freed",
  title="{Gateways and MIME Security Multiparts}",
  howpublished="RFC 2480 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2480",
  pages="1--6",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2480.txt",
  key="RFC 2480",
  abstract={This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]},
  keywords="mutltipurpose, internet, mail, extensions",
  doi="10.17487/RFC2480",
  }

@misc{rfc2481,
  author="K. Ramakrishnan and S. Floyd",
  title="{A Proposal to add Explicit Congestion Notification (ECN) to IP}",
  howpublished="RFC 2481 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2481",
  pages="1--25",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3168",
url="https://www.rfc-editor.org/rfc/rfc2481.txt",
  key="RFC 2481",
  abstract={This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ECN-IP, internet, protocol, tcp, transmission, control, transport",
  doi="10.17487/RFC2481",
  }

@misc{rfc2482,
  author="K. Whistler and G. Adams",
  title="{Language Tagging in Unicode Plain Text}",
  howpublished="RFC 2482 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2482",
  pages="1--14",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6082",
url="https://www.rfc-editor.org/rfc/rfc2482.txt",
  key="RFC 2482",
  abstract={This document proposed a mechanism for language tagging in plain text.  This memo provides information for the Internet community.},
  keywords="characters, strings, ASCII",
  doi="10.17487/RFC2482",
  }

@misc{rfc2483,
  author="M. Mealling and R. Daniel",
  title="{URI Resolution Services Necessary for URN Resolution}",
  howpublished="RFC 2483 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2483",
  pages="1--16",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2483.txt",
  key="RFC 2483",
  abstract={Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI.  One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example.  This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).  Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="uniform, resource, identifier, names, locators, characteristics",
  doi="10.17487/RFC2483",
  }

@misc{rfc2484,
  author="G. Zorn",
  title="{PPP LCP Internationalization Configuration Option}",
  howpublished="RFC 2484 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2484",
  pages="1--5",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2484.txt",
  key="RFC 2484",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]},
  keywords="point-to-point, protocol, link, control, authentication",
  doi="10.17487/RFC2484",
  }

@misc{rfc2485,
  author="S. Drach",
  title="{DHCP Option for The Open Group's User Authentication Protocol}",
  howpublished="RFC 2485 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2485",
  pages="1--4",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2485.txt",
  key="RFC 2485",
  abstract={This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, UAP",
  doi="10.17487/RFC2485",
  }

@misc{rfc2486,
  author="B. Aboba and M. Beadles",
  title="{The Network Access Identifier}",
  howpublished="RFC 2486 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2486",
  pages="1--8",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4282",
url="https://www.rfc-editor.org/rfc/rfc2486.txt",
  key="RFC 2486",
  abstract={This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]},
  keywords="NAI, tunneling, roaming",
  doi="10.17487/RFC2486",
  }

@misc{rfc2487,
  author="P. Hoffman",
  title="{SMTP Service Extension for Secure SMTP over TLS}",
  howpublished="RFC 2487 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2487",
  pages="1--8",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3207",
url="https://www.rfc-editor.org/rfc/rfc2487.txt",
  key="RFC 2487",
  abstract={This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.  This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]},
  keywords="simple, mail, transfer, protocol, transport, layer, security, ssl",
  doi="10.17487/RFC2487",
  }

@misc{rfc2488,
  author="M. Allman and D. Glover and L. Sanchez",
  title="{Enhancing TCP Over Satellite Channels using Standard Mechanisms}",
  howpublished="RFC 2488 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2488",
  pages="1--19",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2488.txt",
  key="RFC 2488",
  abstract={The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels.  While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path.  This document outlines some of these TCP mitigations.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="transmission, control, protocol, network",
  doi="10.17487/RFC2488",
  }

@misc{rfc2489,
  author="R. Droms",
  title="{Procedure for Defining New DHCP Options}",
  howpublished="RFC 2489 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2489",
  pages="1--5",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2939",
url="https://www.rfc-editor.org/rfc/rfc2489.txt",
  key="RFC 2489",
  abstract={This document describes the procedure for defining new DHCP options.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="mutipurpose, internet, mail, extensions",
  doi="10.17487/RFC2489",
  }

@misc{rfc2490,
  author="M. Pullen and R. Malghan and L. Lavu and G. Duan and J. Ma and H. Nah",
  title="{A Simulation Model for IP Multicast with RSVP}",
  howpublished="RFC 2490 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2490",
  pages="1--31",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2490.txt",
  key="RFC 2490",
  abstract={This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language.  This memo provides information for the Internet community.},
  keywords="internet, protocol, resource, reservation, ipv4",
  doi="10.17487/RFC2490",
  }

@misc{rfc2491,
  author="G. Armitage and P. Schulter and M. Jork and G. Harter",
  title="{IPv6 over Non-Broadcast Multiple Access (NBMA) networks}",
  howpublished="RFC 2491 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2491",
  pages="1--44",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2491.txt",
  key="RFC 2491",
  abstract={This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]},
  keywords="IPv6-NBMA, internet, protocol, routing, host",
  doi="10.17487/RFC2491",
  }

@misc{rfc2492,
  author="G. Armitage and P. Schulter and M. Jork",
  title="{IPv6 over ATM Networks}",
  howpublished="RFC 2492 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2492",
  pages="1--12",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2492.txt",
  key="RFC 2492",
  abstract={This document is a companion to the ION working group's architecture document, ``IPv6 over Non Broadcast Multiple Access (NBMA) networks''.  It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks.  This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs).  Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]},
  keywords="IPv6ATMNET, internet, protocol, asynchronous, transfer, mode, host",
  doi="10.17487/RFC2492",
  }

@misc{rfc2493,
  author="K. Tesink",
  title="{Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}",
  howpublished="RFC 2493 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2493",
  pages="1--9",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3593",
url="https://www.rfc-editor.org/rfc/rfc2493.txt",
  key="RFC 2493",
  abstract={This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]},
  keywords="management, information, base, data",
  doi="10.17487/RFC2493",
  }

@misc{rfc2494,
  author="D. Fowler",
  title="{Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type}",
  howpublished="RFC 2494 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2494",
  pages="1--25",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2494.txt",
  key="RFC 2494",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces.  This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2494",
  }

@misc{rfc2495,
  author="D. Fowler",
  title="{Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types}",
  howpublished="RFC 2495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2495",
  pages="1--75",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3895",
url="https://www.rfc-editor.org/rfc/rfc2495.txt",
  key="RFC 2495",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces.  This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2495",
  }

@misc{rfc2496,
  author="D. Fowler",
  title="{Definitions of Managed Object for the DS3/E3 Interface Type}",
  howpublished="RFC 2496 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2496",
  pages="1--60",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3896",
url="https://www.rfc-editor.org/rfc/rfc2496.txt",
  key="RFC 2496",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing DS3 and E3 interfaces.  This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]},
  keywords="DS3-E3-MIB, management, information, base",
  doi="10.17487/RFC2496",
  }

@misc{rfc2497,
  author="I. Souvatzis",
  title="{Transmission of IPv6 Packets over ARCnet Networks}",
  howpublished="RFC 2497 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2497",
  pages="1--6",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2497.txt",
  key="RFC 2497",
  abstract={This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks.  It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]},
  keywords="internet, protocol, frame, format, link-local",
  doi="10.17487/RFC2497",
  }

@misc{rfc2498,
  author="J. Mahdavi and V. Paxson",
  title="{IPPM Metrics for Measuring Connectivity}",
  howpublished="RFC 2498 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2498",
  pages="1--10",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2678",
url="https://www.rfc-editor.org/rfc/rfc2498.txt",
  key="RFC 2498",
  abstract={This memo defines a series of metrics for connectivity between a pair of Internet hosts.  It builds on notions introduced and discussed in RFC 2330, the IPPM framework document.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IPPM-MET, internet, protocol, performance, metrics",
  doi="10.17487/RFC2498",
  }

@misc{rfc2499,
  author="A. Ramos",
  title="{Request for Comments Summary}",
  howpublished="RFC 2499 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2499",
  pages="1--22",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2499.txt",
  key="RFC 2499",
  doi="10.17487/RFC2499",
  }

@misc{rfc2500,
  author="J. Reynolds and R. Braden",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2500 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2500",
  pages="1--28",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2600",
url="https://www.rfc-editor.org/rfc/rfc2500.txt",
  key="RFC 2500",
  abstract={This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC2500",
  }

@misc{rfc2501,
  author="S. Corson and J. Macker",
  title="{Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations}",
  howpublished="RFC 2501 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2501",
  pages="1--12",
  year=1999,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2501.txt",
  key="RFC 2501",
  abstract={This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks.  It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations.  This memo provides information for the Internet community.},
  keywords="MANET, packet, network, hardwire, wireless",
  doi="10.17487/RFC2501",
  }

@misc{rfc2502,
  author="M. Pullen and M. Myjak and C. Bouwens",
  title="{Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment}",
  howpublished="RFC 2502 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2502",
  pages="1--11",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2502.txt",
  key="RFC 2502",
  abstract={This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements.  This memo provides information for the Internet community.},
  keywords="IP, DIS, distributed, applications",
  doi="10.17487/RFC2502",
  }

@misc{rfc2503,
  author="R. Moulton and M. Needleman",
  title="{MIME Types for Use with the ISO ILL Protocol}",
  howpublished="RFC 2503 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2503",
  pages="1--6",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2503.txt",
  key="RFC 2503",
  abstract={This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161).  This memo provides information for the Internet community.},
  keywords="multipurpose, mail, internet, extensions, media, type, interlibrary, loan",
  doi="10.17487/RFC2503",
  }

@misc{rfc2504,
  author="E. Guttman and L. Leong and G. Malkin",
  title="{Users' Security Handbook}",
  howpublished="RFC 2504 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2504",
  pages="1--33",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2504.txt",
  key="RFC 2504",
  abstract={The Users' Security Handbook is the companion to the Site Security Handbook (SSH).  It is intended to provide users with the information they need to help keep their networks and systems secure.  This memo provides information for the Internet community.},
  keywords="encryption, networks, systems",
  doi="10.17487/RFC2504",
  }

@misc{rfc2505,
  author="G. Lindberg",
  title="{Anti-Spam Recommendations for SMTP MTAs}",
  howpublished="RFC 2505 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2505",
  pages="1--24",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2505.txt",
  key="RFC 2505",
  abstract={This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g.  sendmail,) to make them more capable of reducing the impact of spam.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="simple, mail, transfer, protocol, agents, sendmail",
  doi="10.17487/RFC2505",
  }

@misc{rfc2506,
  author="K. Holtman and A. Mutz and T. Hardie",
  title="{Media Feature Tag Registration Procedure}",
  howpublished="RFC 2506 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2506",
  pages="1--12",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2506.txt",
  key="RFC 2506",
  abstract={This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="data, formats, vocabulary, negotiation, mechanism",
  doi="10.17487/RFC2506",
  }

@misc{rfc2507,
  author="M. Degermark and B. Nordgren and S. Pink",
  title="{IP Header Compression}",
  howpublished="RFC 2507 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2507",
  pages="1--47",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2507.txt",
  key="RFC 2507",
  abstract={This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]},
  keywords="internet, protocol, tcp, transmission, control, bandwidth",
  doi="10.17487/RFC2507",
  }

@misc{rfc2508,
  author="S. Casner and V. Jacobson",
  title="{Compressing IP/UDP/RTP Headers for Low-Speed Serial Links}",
  howpublished="RFC 2508 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2508",
  pages="1--24",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2508.txt",
  key="RFC 2508",
  abstract={This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]},
  keywords="internet, protocol, user, datagram, real-timetransport, interoperability",
  doi="10.17487/RFC2508",
  }

@misc{rfc2509,
  author="M. Engan and S. Casner and C. Bormann",
  title="{IP Header Compression over PPP}",
  howpublished="RFC 2509 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2509",
  pages="1--10",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3544",
url="https://www.rfc-editor.org/rfc/rfc2509.txt",
  key="RFC 2509",
  abstract={This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol.  It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]},
  keywords="IPCOM-PPP, internet, protocol, point-to-point, datagrams",
  doi="10.17487/RFC2509",
  }

@misc{rfc2510,
  author="C. Adams and S. Farrell",
  title="{Internet X.509 Public Key Infrastructure Certificate Management Protocols}",
  howpublished="RFC 2510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2510",
  pages="1--72",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4210",
url="https://www.rfc-editor.org/rfc/rfc2510.txt",
  key="RFC 2510",
  abstract={This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]},
  keywords="PKICMP, pki, security, cryptographic, authentication",
  doi="10.17487/RFC2510",
  }

@misc{rfc2511,
  author="M. Myers and C. Adams and D. Solo and D. Kemp",
  title="{Internet X.509 Certificate Request Message Format}",
  howpublished="RFC 2511 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2511",
  pages="1--25",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4211",
url="https://www.rfc-editor.org/rfc/rfc2511.txt",
  key="RFC 2511",
  abstract={This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]},
  keywords="X.509-CRMF, crmf, security, encryption, authenticaion",
  doi="10.17487/RFC2511",
  }

@misc{rfc2512,
  author="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
  title="{Accounting Information for ATM Networks}",
  howpublished="RFC 2512 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2512",
  pages="1--15",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2512.txt",
  key="RFC 2512",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]},
  keywords="mib, management, information, base, autonomous, transfer, mode",
  doi="10.17487/RFC2512",
  }

@misc{rfc2513,
  author="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
  title="{Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks}",
  howpublished="RFC 2513 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2513",
  pages="1--29",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2513.txt",
  key="RFC 2513",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]},
  keywords="mib, management, information, base",
  doi="10.17487/RFC2513",
  }

@misc{rfc2514,
  author="M. Noto and E. Spiegel and K. Tesink",
  title="{Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management}",
  howpublished="RFC 2514 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2514",
  pages="1--20",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2514.txt",
  key="RFC 2514",
  abstract={This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]},
  keywords="ATM-TC-OID, asynchronous, transfer, mode, MIB, management, information, base",
  doi="10.17487/RFC2514",
  }

@misc{rfc2515,
  author="K. Tesink and Ed",
  title="{Definitions of Managed Objects for ATM Management}",
  howpublished="RFC 2515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2515",
  pages="1--87",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2515.txt",
  key="RFC 2515",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]},
  keywords="ATM-MIBMAN, asynchronous, transfer, mode, MIB, management, information, base",
  doi="10.17487/RFC2515",
  }

@misc{rfc2516,
  author="L. Mamakos and K. Lidl and J. Evarts and D. Carrel and D. Simone and R. Wheeler",
  title="{A Method for Transmitting PPP Over Ethernet (PPPoE)}",
  howpublished="RFC 2516 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2516",
  pages="1--17",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2516.txt",
  key="RFC 2516",
  abstract={This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.  This memo provides information for the Internet community.},
  keywords="PPPOE, point-to-point, protocol, link, control, network, layer",
  doi="10.17487/RFC2516",
  }

@misc{rfc2517,
  author="R. Moats and R. Huber",
  title="{Building Directories from DNS: Experiences from WWWSeeker}",
  howpublished="RFC 2517 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2517",
  pages="1--7",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2517.txt",
  key="RFC 2517",
  abstract={This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization.  This memo provides information for the Internet community.},
  keywords="domain, name, system, internet, world, wide, web",
  doi="10.17487/RFC2517",
  }

@misc{rfc2518,
  author="Y. Goland and E. Whitehead and A. Faizi and S. Carter and D. Jensen",
  title="{HTTP Extensions for Distributed Authoring -- WEBDAV}",
  howpublished="RFC 2518 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2518",
  pages="1--94",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4918",
url="https://www.rfc-editor.org/rfc/rfc2518.txt",
  key="RFC 2518",
  abstract={This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]},
  keywords="WEBDAV, hypertext, transfer, protocol, web, content",
  doi="10.17487/RFC2518",
  }

@misc{rfc2519,
  author="E. Chen and J. Stewart",
  title="{A Framework for Inter-Domain Route Aggregation}",
  howpublished="RFC 2519 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2519",
  pages="1--13",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2519.txt",
  key="RFC 2519",
  abstract={This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework.  This memo provides information for the Internet community},
  keywords="IDRA, bgp, border, gateway, protocol, address, ip, internet",
  doi="10.17487/RFC2519",
  }

@misc{rfc2520,
  author="J. Luciani and H. Suzuki and N. Doraswamy and D. Horton",
  title="{NHRP with Mobile NHCs}",
  howpublished="RFC 2520 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2520",
  pages="1--8",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2520.txt",
  key="RFC 2520",
  abstract={is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="NHRP-MNHCS, next, hop, resolution, protocol, authentication, extension",
  doi="10.17487/RFC2520",
  }

@misc{rfc2521,
  author="P. Karn and W. Simpson",
  title="{ICMP Security Failures Messages}",
  howpublished="RFC 2521 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2521",
  pages="1--9",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2521.txt",
  key="RFC 2521",
  abstract={This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP).  This document defines an Experimental Protocol for the Internet community.},
  keywords="ICMP-SEC, internet, control, message, protocol, ip",
  doi="10.17487/RFC2521",
  }

@misc{rfc2522,
  author="P. Karn and W. Simpson",
  title="{Photuris: Session-Key Management Protocol}",
  howpublished="RFC 2522 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2522",
  pages="1--80",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2522.txt",
  key="RFC 2522",
  abstract={This document defines the basic protocol mechanisms.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PHOTURIS-S, ip, internet, protocol, ah, esp",
  doi="10.17487/RFC2522",
  }

@misc{rfc2523,
  author="P. Karn and W. Simpson",
  title="{Photuris: Extended Schemes and Attributes}",
  howpublished="RFC 2523 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2523",
  pages="1--21",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2523.txt",
  key="RFC 2523",
  abstract={Photuris is a session-key management protocol.  Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PHOTURIS-E, ip, internet, protocol, security",
  doi="10.17487/RFC2523",
  }

@misc{rfc2524,
  author="M. Banan",
  title="{Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3}",
  howpublished="RFC 2524 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2524",
  pages="1--83",
  year=1999,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2524.txt",
  key="RFC 2524",
  abstract={This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency.  This memo provides information for the Internet community.},
  keywords="EMSD, wireless, IP, internet, protocol",
  doi="10.17487/RFC2524",
  }

@misc{rfc2525,
  author="V. Paxson and M. Allman and S. Dawson and W. Fenner and J. Griner and I. Heavens and K. Lahey and J. Semke and B. Volz",
  title="{Known TCP Implementation Problems}",
  howpublished="RFC 2525 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2525",
  pages="1--61",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2525.txt",
  key="RFC 2525",
  abstract={This memo catalogs a number of known TCP implementation problems.  This memo provides information for the Internet community.},
  keywords="transmission, control, protocol",
  doi="10.17487/RFC2525",
  }

@misc{rfc2526,
  author="D. Johnson and S. Deering",
  title="{Reserved IPv6 Subnet Anycast Addresses}",
  howpublished="RFC 2526 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2526",
  pages="1--7",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2526.txt",
  key="RFC 2526",
  abstract={This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]},
  keywords="internet, protocol, routing, architecture",
  doi="10.17487/RFC2526",
  }

@misc{rfc2527,
  author="S. Chokhani and W. Ford",
  title="{Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework}",
  howpublished="RFC 2527 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2527",
  pages="1--45",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3647",
url="https://www.rfc-editor.org/rfc/rfc2527.txt",
  key="RFC 2527",
  abstract={This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures.  In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.  This memo provides information for the Internet community.},
  keywords="pkix, encryption, security, authentication",
  doi="10.17487/RFC2527",
  }

@misc{rfc2528,
  author="R. Housley and W. Polk",
  title="{Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates}",
  howpublished="RFC 2528 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2528",
  pages="1--9",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2528.txt",
  key="RFC 2528",
  abstract={This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys.  This memo provides information for the Internet community.},
  keywords="security, authentication, cryptology",
  doi="10.17487/RFC2528",
  }

@misc{rfc2529,
  author="B. Carpenter and C. Jung",
  title="{Transmission of IPv6 over IPv4 Domains without Explicit Tunnels}",
  howpublished="RFC 2529 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2529",
  pages="1--10",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2529.txt",
  key="RFC 2529",
  abstract={This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains.  It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]},
  keywords="link-local, link, local, addresses, internet, protocol, ip",
  doi="10.17487/RFC2529",
  }

@misc{rfc2530,
  author="D. Wing",
  title="{Indicating Supported Media Features Using Extensions to DSN and MDN}",
  howpublished="RFC 2530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2530",
  pages="1--5",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2530.txt",
  key="RFC 2530",
  abstract={This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]},
  keywords="message, disposition, notification, delivery, status",
  doi="10.17487/RFC2530",
  }

@misc{rfc2531,
  author="G. Klyne and L. McIntyre",
  title="{Content Feature Schema for Internet Fax}",
  howpublished="RFC 2531 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2531",
  pages="1--51",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2879",
url="https://www.rfc-editor.org/rfc/rfc2531.txt",
  key="RFC 2531",
  abstract={This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]},
  keywords="media, features, mechanism",
  doi="10.17487/RFC2531",
  }

@misc{rfc2532,
  author="L. Masinter and D. Wing",
  title="{Extended Facsimile Using Internet Mail}",
  howpublished="RFC 2532 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2532",
  pages="1--12",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2532.txt",
  key="RFC 2532",
  abstract={This document describes extensions to ``Simple Mode of Facsimile Using Internet Mail'', and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]},
  keywords="mail, user, fax",
  doi="10.17487/RFC2532",
  }

@misc{rfc2533,
  author="G. Klyne",
  title="{A Syntax for Describing Media Feature Sets}",
  howpublished="RFC 2533 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2533",
  pages="1--37",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2738, 2938",
url="https://www.rfc-editor.org/rfc/rfc2533.txt",
  key="RFC 2533",
  abstract={This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]},
  keywords="message, senders, recipients, file, format",
  doi="10.17487/RFC2533",
  }

@misc{rfc2534,
  author="L. Masinter and D. Wing and A. Mutz and K. Holtman",
  title="{Media Features for Display, Print, and Fax}",
  howpublished="RFC 2534 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2534",
  pages="1--9",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2534.txt",
  key="RFC 2534",
  abstract={This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]},
  keywords="data, format, vocabulary, negotiation, mechanisms",
  doi="10.17487/RFC2534",
  }

@misc{rfc2535,
  author="D. {Eastlake 3rd}",
  title="{Domain Name System Security Extensions}",
  howpublished="RFC 2535 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2535",
  pages="1--47",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFCs 2931, 3007, 3008, 3090, 3226, 3445, 3597, 3655, 3658, 3755, 3757, 3845",
url="https://www.rfc-editor.org/rfc/rfc2535.txt",
  key="RFC 2535",
  abstract={This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]},
  keywords="DNS-SECEXT, dns, authentication",
  doi="10.17487/RFC2535",
  }

@misc{rfc2536,
  author="D. {Eastlake 3rd}",
  title="{DSA KEYs and SIGs in the Domain Name System (DNS)}",
  howpublished="RFC 2536 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2536",
  pages="1--6",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc2536.txt",
  key="RFC 2536",
  abstract={A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]},
  keywords="digital, signature, algorithm, signatures, cryptology",
  doi="10.17487/RFC2536",
  }

@misc{rfc2537,
  author="D. {Eastlake 3rd}",
  title="{RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)}",
  howpublished="RFC 2537 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2537",
  pages="1--6",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3110",
url="https://www.rfc-editor.org/rfc/rfc2537.txt",
  key="RFC 2537",
  abstract={A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]},
  keywords="message, digest, signatures, cryptology, security",
  doi="10.17487/RFC2537",
  }

@misc{rfc2538,
  author="D. {Eastlake 3rd} and O. Gudmundsson",
  title="{Storing Certificates in the Domain Name System (DNS)}",
  howpublished="RFC 2538 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2538",
  pages="1--10",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4398",
url="https://www.rfc-editor.org/rfc/rfc2538.txt",
  key="RFC 2538",
  abstract={Cryptographic public key are frequently published and their authenticity demonstrated by certificates.  A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]},
  keywords="SC-DNS, cryptology, authenticity",
  doi="10.17487/RFC2538",
  }

@misc{rfc2539,
  author="D. {Eastlake 3rd}",
  title="{Storage of Diffie-Hellman Keys in the Domain Name System (DNS)}",
  howpublished="RFC 2539 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2539",
  pages="1--7",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc2539.txt",
  key="RFC 2539",
  abstract={A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]},
  keywords="DHK-DNS, cryptology, authentication, security, signatures, digital",
  doi="10.17487/RFC2539",
  }

@misc{rfc2540,
  author="D. {Eastlake 3rd}",
  title="{Detached Domain Name System (DNS) Information}",
  howpublished="RFC 2540 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2540",
  pages="1--6",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2540.txt",
  key="RFC 2540",
  abstract={A standard format is defined for representing detached DNS information.  This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS-INFO, security, digital, signatures, authentication",
  doi="10.17487/RFC2540",
  }

@misc{rfc2541,
  author="D. {Eastlake 3rd}",
  title="{DNS Security Operational Considerations}",
  howpublished="RFC 2541 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2541",
  pages="1--7",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4641",
url="https://www.rfc-editor.org/rfc/rfc2541.txt",
  key="RFC 2541",
  abstract={This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.  This memo provides information for the Internet community.},
  keywords="DNS-SOC, domain, name, system, cryptology, resource, records, rrs",
  doi="10.17487/RFC2541",
  }

@misc{rfc2542,
  author="L. Masinter",
  title="{Terminology and Goals for Internet Fax}",
  howpublished="RFC 2542 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2542",
  pages="1--20",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2542.txt",
  key="RFC 2542",
  abstract={This document defines a number of terms useful for the discussion of Internet Fax.  In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged.  This memo provides information for the Internet community.},
  keywords="real-time, real, time, session, store, forward",
  doi="10.17487/RFC2542",
  }

@misc{rfc2543,
  author="M. Handley and H. Schulzrinne and E. Schooler and J. Rosenberg",
  title="{SIP: Session Initiation Protocol}",
  howpublished="RFC 2543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2543",
  pages="1--151",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3261, 3262, 3263, 3264, 3265",
url="https://www.rfc-editor.org/rfc/rfc2543.txt",
  key="RFC 2543",
  abstract={The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC2543",
  }

@misc{rfc2544,
  author="S. Bradner and J. McQuaid",
  title="{Benchmarking Methodology for Network Interconnect Devices}",
  howpublished="RFC 2544 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2544",
  pages="1--31",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6201, 6815",
url="https://www.rfc-editor.org/rfc/rfc2544.txt",
  key="RFC 2544",
  abstract={This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment.  This memo provides information for the Internet community.},
  keywords="testing, performance",
  doi="10.17487/RFC2544",
  }

@misc{rfc2545,
  author="P. Marques and F. Dupont",
  title="{Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing}",
  howpublished="RFC 2545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2545",
  pages="1--5",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2545.txt",
  key="RFC 2545",
  abstract={BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP\_REACH\_NLRI and MP\_UNREACH\_NLRI) that can be used to announce and withdraw the announcement of reachability information.  This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]},
  keywords="border, gateway, protocol, idr, internet, routing",
  doi="10.17487/RFC2545",
  }

@misc{rfc2546,
  author="A. Durand and B. Buclin",
  title="{6Bone Routing Practice}",
  howpublished="RFC 2546 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2546",
  pages="1--10",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2772",
url="https://www.rfc-editor.org/rfc/rfc2546.txt",
  key="RFC 2546",
  abstract={This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past.  It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols.  This memo provides information for the Internet community.},
  keywords="IPv6, internet protocol",
  doi="10.17487/RFC2546",
  }

@misc{rfc2547,
  author="E. Rosen and Y. Rekhter",
  title="{BGP/MPLS VPNs}",
  howpublished="RFC 2547 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2547",
  pages="1--25",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4364",
url="https://www.rfc-editor.org/rfc/rfc2547.txt",
  key="RFC 2547",
  abstract={This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers.  This memo provides information for the Internet community.},
  keywords="border, gateway, protocol, multiprotocol, label, switching, architecture, virtual, private, networks",
  doi="10.17487/RFC2547",
  }

@misc{rfc2548,
  author="G. Zorn",
  title="{Microsoft Vendor-specific RADIUS Attributes}",
  howpublished="RFC 2548 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2548",
  pages="1--41",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2548.txt",
  key="RFC 2548",
  abstract={This document describes the set of Microsoft vendor-specific RADIUS attributes.  This memo provides information for the Internet community.},
  keywords="attributes, remote, access, dialin, user, service, dial-in",
  doi="10.17487/RFC2548",
  }

@misc{rfc2549,
  author="D. Waitzman",
  title="{IP over Avian Carriers with Quality of Service}",
  howpublished="RFC 2549 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2549",
  pages="1--6",
  year=1999,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2549.txt",
  key="RFC 2549",
  abstract={This memo amends RFC 1149, ``A Standard for the Transmission of IP Datagrams on Avian Carriers'', with Quality of Service information.  This is an experimental, not recommended standard.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="avian, carrier, april, fools, qos",
  doi="10.17487/RFC2549",
  }

@misc{rfc2550,
  author="S. Glassman and M. Manasse and J. Mogul",
  title="{Y10K and Beyond}",
  howpublished="RFC 2550 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2550",
  pages="1--14",
  year=1999,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2550.txt",
  key="RFC 2550",
  abstract={This specification provides a solution to the ``Y10K'' problem which has also been called the ``YAK'' problem (hex) and the ``YXK'' problem (Roman numerals).  This memo provides information for the Internet community.},
  keywords="years, dates, formats, april, fools",
  doi="10.17487/RFC2550",
  }

@misc{rfc2551,
  author="S. Bradner",
  title="{The Roman Standards Process -- Revision III}",
  howpublished="RFC 2551 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2551",
  pages="1--37",
  year=1999,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2551.txt",
  key="RFC 2551",
  abstract={This memo documents the process used by the Roman community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.},
  keywords="numerals, protocols, procedures, april, fools",
  doi="10.17487/RFC2551",
  }

@misc{rfc2552,
  author="M. Blinov and M. Bessonov and C. Clissmann",
  title="{Architecture for the Information Brokerage in the ACTS Project GAIA}",
  howpublished="RFC 2552 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2552",
  pages="1--30",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2552.txt",
  key="RFC 2552",
  abstract={This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability).  This memo provides information for the Internet community.},
  keywords="electronic, systems, products",
  doi="10.17487/RFC2552",
  }

@misc{rfc2553,
  author="R. Gilligan and S. Thomson and J. Bound and W. Stevens",
  title="{Basic Socket Interface Extensions for IPv6}",
  howpublished="RFC 2553 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2553",
  pages="1--41",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3493, updated by RFC 3152",
url="https://www.rfc-editor.org/rfc/rfc2553.txt",
  key="RFC 2553",
  abstract={TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications.  But changes are required to the sockets API to support IPv6 and this memo describes these changes.  These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options.  This memo provides information for the Internet community.},
  keywords="internet, protocol, api, application, program, interface, tcp, transmission control",
  doi="10.17487/RFC2553",
  }

@misc{rfc2554,
  author="J. Myers",
  title="{SMTP Service Extension for Authentication}",
  howpublished="RFC 2554 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2554",
  pages="1--11",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4954",
url="https://www.rfc-editor.org/rfc/rfc2554.txt",
  key="RFC 2554",
  abstract={This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]},
  keywords="simple, mail, transfer, protocol, security, layer, sasl",
  doi="10.17487/RFC2554",
  }

@misc{rfc2555,
  author="RFC Editor and et al.",
  title="{30 Years of RFCs}",
  howpublished="RFC 2555 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2555",
  pages="1--18",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2555.txt",
  key="RFC 2555",
  abstract={The rest of this document contains a brief recollection from the present RFC Editor Joyce K.  Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series.  This memo provides information for the Internet community.},
  keywords="request, for, comments, series, documents, publication",
  doi="10.17487/RFC2555",
  }

@misc{rfc2556,
  author="S. Bradner",
  title="{OSI connectionless transport services on top of UDP Applicability Statement for Historic Status}",
  howpublished="RFC 2556 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2556",
  pages="1--4",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2556.txt",
  key="RFC 2556",
  abstract={RFC 1240, ``OSI connectionless transport services on top of UDP'', was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240.  In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.},
  keywords="user, datagram, protocol, ISO, international, organization for standardization",
  doi="10.17487/RFC2556",
  }

@misc{rfc2557,
  author="J. Palme and A. Hopmann and N. Shelness",
  title="{MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)}",
  howpublished="RFC 2557 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2557",
  pages="1--28",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2557.txt",
  key="RFC 2557",
  abstract={This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]},
  keywords="MHTML, multipurpose, internet, mail, extensions, multimedia, uri, uniform, resource, identifiers",
  doi="10.17487/RFC2557",
  }

@misc{rfc2558,
  author="K. Tesink",
  title="{Definitions of Managed Objects for the SONET/SDH Interface Type}",
  howpublished="RFC 2558 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2558",
  pages="1--74",
  year=1999,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3592",
url="https://www.rfc-editor.org/rfc/rfc2558.txt",
  key="RFC 2558",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.  This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]},
  keywords="MIB, Management, SNMP",
  doi="10.17487/RFC2558",
  }

@misc{rfc2559,
  author="S. Boeyen and T. Howes and P. Richard",
  title="{Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2}",
  howpublished="RFC 2559 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2559",
  pages="1--13",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3494",
url="https://www.rfc-editor.org/rfc/rfc2559.txt",
  key="RFC 2559",
  abstract={Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]},
  keywords="X.500, LDAP, lightweight directory protocol",
  doi="10.17487/RFC2559",
  }

@misc{rfc2560,
  author="M. Myers and R. Ankney and A. Malpani and S. Galperin and C. Adams",
  title="{X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP}",
  howpublished="RFC 2560 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2560",
  pages="1--23",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6960, updated by RFC 6277",
url="https://www.rfc-editor.org/rfc/rfc2560.txt",
  key="RFC 2560",
  abstract={This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]},
  keywords="PKIX, digital, security",
  doi="10.17487/RFC2560",
  }

@misc{rfc2561,
  author="K. White and R. Moore",
  title="{Base Definitions of Managed Objects for TN3270E Using SMIv2}",
  howpublished="RFC 2561 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2561",
  pages="1--56",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2561.txt",
  key="RFC 2561",
  abstract={This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers.  The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base, structure, telnet",
  doi="10.17487/RFC2561",
  }

@misc{rfc2562,
  author="K. White and R. Moore",
  title="{Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)}",
  howpublished="RFC 2562 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2562",
  pages="1--49",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2562.txt",
  key="RFC 2562",
  abstract={This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]},
  keywords="TN2370E-RT-MIB, MIB, management, information, base, structure, telnet",
  doi="10.17487/RFC2562",
  }

@misc{rfc2563,
  author="R. Troll",
  title="{DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients}",
  howpublished="RFC 2563 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2563",
  pages="1--9",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2563.txt",
  key="RFC 2563",
  abstract={This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol, internet, address",
  doi="10.17487/RFC2563",
  }

@misc{rfc2564,
  author="C. Kalbfleisch and C. Krupczak and R. Presuhn and J. Saperia",
  title="{Application Management MIB}",
  howpublished="RFC 2564 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2564",
  pages="1--86",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2564.txt",
  key="RFC 2564",
  abstract={This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community.  In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]},
  keywords="APP-MIB, management, information, base",
  doi="10.17487/RFC2564",
  }

@misc{rfc2565,
  author="R. Herriot and S. Butler and P. Moore and R. Turner",
  title="{Internet Printing Protocol/1.0: Encoding and Transport}",
  howpublished="RFC 2565 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2565",
  pages="1--37",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2910",
url="https://www.rfc-editor.org/rfc/rfc2565.txt",
  key="RFC 2565",
  abstract={This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called ``application/ipp''.  This document also defines the rules for transporting over HTTP a message body whose Content-Type is ``application/ipp''.  This document defines an Experimental protocol for the Internet community.},
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC2565",
  }

@misc{rfc2566,
  author="R. deBry and T. Hastings and R. Herriot and S. Isaacson and P. Powell",
  title="{Internet Printing Protocol/1.0: Model and Semantics}",
  howpublished="RFC 2566 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2566",
  pages="1--173",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2911",
url="https://www.rfc-editor.org/rfc/rfc2566.txt",
  key="RFC 2566",
  abstract={This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.  This document also addresses security, internationalization, and directory issues.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IPP-M-S, IPP, application, media-type, job",
  doi="10.17487/RFC2566",
  }

@misc{rfc2567,
  author="F. Wright",
  title="{Design Goals for an Internet Printing Protocol}",
  howpublished="RFC 2567 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2567",
  pages="1--43",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2567.txt",
  key="RFC 2567",
  abstract={This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet.  It identifies requirements for three types of users: end users, operators, and administrators.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IPP-DG, IPP, application, media-type, media, type",
  doi="10.17487/RFC2567",
  }

@misc{rfc2568,
  author="S. Zilles",
  title="{Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol}",
  howpublished="RFC 2568 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2568",
  pages="1--10",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2568.txt",
  key="RFC 2568",
  abstract={This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="IPP-RAT, IPP, application, media-type, media, type",
  doi="10.17487/RFC2568",
  }

@misc{rfc2569,
  author="R. Herriot and T. Hastings and N. Jacobs and J. Martin",
  title="{Mapping between LPD and IPP Protocols}",
  howpublished="RFC 2569 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2569",
  pages="1--28",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2569.txt",
  key="RFC 2569",
  abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).  One of the purposes of this document is to compare the functionality of the two protocols.  Another purpose is to facilitate implementation of gateways between LPD and IPP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="application, media-type, media, type, internet, printing, protocol, line, printer, daemon",
  doi="10.17487/RFC2569",
  }

@misc{rfc2570,
  author="J. Case and R. Mundy and D. Partain and B. Stewart",
  title="{Introduction to Version 3 of the Internet-standard Network Management Framework}",
  howpublished="RFC 2570 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2570",
  pages="1--23",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3410",
url="https://www.rfc-editor.org/rfc/rfc2570.txt",
  key="RFC 2570",
  abstract={The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3).  This memo provides information for the Internet community.},
  keywords="snmp, simple, protocol",
  doi="10.17487/RFC2570",
  }

@misc{rfc2571,
  author="B. Wijnen and D. Harrington and R. Presuhn",
  title="{An Architecture for Describing SNMP Management Frameworks}",
  howpublished="RFC 2571 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2571",
  pages="1--62",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3411",
url="https://www.rfc-editor.org/rfc/rfc2571.txt",
  key="RFC 2571",
  abstract={This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]},
  keywords="ARCH-SNMP, simple, protocol, network, management",
  doi="10.17487/RFC2571",
  }

@misc{rfc2572,
  author="J. Case and D. Harrington and R. Presuhn and B. Wijnen",
  title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2572 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2572",
  pages="1--44",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3412",
url="https://www.rfc-editor.org/rfc/rfc2572.txt",
  key="RFC 2572",
  abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture.  It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications.  This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]},
  keywords="MPD-SNMP, processing, models, multiple",
  doi="10.17487/RFC2572",
  }

@misc{rfc2573,
  author="D. Levi and P. Meyer and B. Stewart",
  title="{SNMP Applications}",
  howpublished="RFC 2573 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2573",
  pages="1--72",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3413",
url="https://www.rfc-editor.org/rfc/rfc2573.txt",
  key="RFC 2573",
  abstract={This memo describes five types of SNMP applications which make use of an SNMP engine.  This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]},
  keywords="SNMP-APP, simple, network, management, protocol, proxy, operations, command",
  doi="10.17487/RFC2573",
  }

@misc{rfc2574,
  author="U. Blumenthal and B. Wijnen",
  title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}",
  howpublished="RFC 2574 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2574",
  pages="1--86",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3414",
url="https://www.rfc-editor.org/rfc/rfc2574.txt",
  key="RFC 2574",
  abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture.  It defines the Elements of Procedure for providing SNMP message level security.  This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]},
  keywords="USM-SNMPV3, message, level, mib, information, base",
  doi="10.17487/RFC2574",
  }

@misc{rfc2575,
  author="B. Wijnen and R. Presuhn and K. McCloghrie",
  title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 2575 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2575",
  pages="1--38",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3415",
url="https://www.rfc-editor.org/rfc/rfc2575.txt",
  key="RFC 2575",
  abstract={This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571).  It defines the Elements of Procedure for controlling access to management information.  This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]},
  keywords="VACM-SNMP, mib, information, base",
  doi="10.17487/RFC2575",
  }

@misc{rfc2576,
  author="R. Frye and D. Levi and S. Routhier and B. Wijnen",
  title="{Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework}",
  howpublished="RFC 2576 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2576",
  pages="1--44",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3584",
url="https://www.rfc-editor.org/rfc/rfc2576.txt",
  key="RFC 2576",
  abstract={The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]},
  keywords="SNMP, simple network, management protocol, mib, information, base",
  doi="10.17487/RFC2576",
  }

@misc{rfc2577,
  author="M. Allman and S. Ostermann",
  title="{FTP Security Considerations}",
  howpublished="RFC 2577 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2577",
  pages="1--8",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2577.txt",
  key="RFC 2577",
  abstract={This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP.  This memo provides information for the Internet community.},
  keywords="FTP-SEC, file, transfer, protocol, bounce, attack, password, server",
  doi="10.17487/RFC2577",
  }

@misc{rfc2578,
  author="K. McCloghrie and D. Perkins and J. Schoenwaelder",
  title="{Structure of Management Information Version 2 (SMIv2)}",
  howpublished="RFC 2578 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2578",
  pages="1--42",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2578.txt",
  key="RFC 2578",
  abstract={It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]},
  keywords="SMIv2, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC2578",
  }

@misc{rfc2579,
  author="K. McCloghrie and D. Perkins and J. Schoenwaelder",
  title="{Textual Conventions for SMIv2}",
  howpublished="RFC 2579 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2579",
  pages="1--25",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2579.txt",
  key="RFC 2579",
  abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]},
  keywords="CONV-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC2579",
  }

@misc{rfc2580,
  author="K. McCloghrie and D. Perkins and J. Schoenwaelder",
  title="{Conformance Statements for SMIv2}",
  howpublished="RFC 2580 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2580",
  pages="1--29",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2580.txt",
  key="RFC 2580",
  abstract={Collections of related objects are defined in MIB modules.  It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved.  It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]},
  keywords="CONF-MIB, simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC2580",
  }

@misc{rfc2581,
  author="M. Allman and V. Paxson and W. Stevens",
  title="{TCP Congestion Control}",
  howpublished="RFC 2581 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2581",
  pages="1--14",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5681, updated by RFC 3390",
url="https://www.rfc-editor.org/rfc/rfc2581.txt",
  key="RFC 2581",
  abstract={This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]},
  keywords="TCP-CC",
  doi="10.17487/RFC2581",
  }

@misc{rfc2582,
  author="S. Floyd and T. Henderson",
  title="{The NewReno Modification to TCP's Fast Recovery Algorithm}",
  howpublished="RFC 2582 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2582",
  pages="1--12",
  year=1999,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3782",
url="https://www.rfc-editor.org/rfc/rfc2582.txt",
  key="RFC 2582",
  abstract={This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Transmission, Control, Protocol",
  doi="10.17487/RFC2582",
  }

@misc{rfc2583,
  author="R. Carlson and L. Winkler",
  title="{Guidelines for Next Hop Client (NHC) Developers}",
  howpublished="RFC 2583 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2583",
  pages="1--9",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2583.txt",
  key="RFC 2583",
  abstract={This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC).  The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system.  This memo provides information for the Internet community.},
  keywords="NHRP, resolution, protocol, IP, internet",
  doi="10.17487/RFC2583",
  }

@misc{rfc2584,
  author="B. Clouston and B. Moore",
  title="{Definitions of Managed Objects for APPN/HPR in IP Networks}",
  howpublished="RFC 2584 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2584",
  pages="1--21",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2584.txt",
  key="RFC 2584",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]},
  keywords="internet, protocol, MIB, management, information, base, high, performance, routing",
  doi="10.17487/RFC2584",
  }

@misc{rfc2585,
  author="R. Housley and P. Hoffman",
  title="{Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP}",
  howpublished="RFC 2585 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2585",
  pages="1--8",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2585.txt",
  key="RFC 2585",
  abstract={The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI).  This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]},
  keywords="file, transfer, hypertext, PKI",
  doi="10.17487/RFC2585",
  }

@misc{rfc2586,
  author="J. Salsman and H. Alvestrand",
  title="{The Audio/L16 MIME content type}",
  howpublished="RFC 2586 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2586",
  pages="1--5",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2586.txt",
  key="RFC 2586",
  abstract={This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications.  This memo provides information for the Internet community.},
  keywords="AUDIO/L16, media-type, application, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2586",
  }

@misc{rfc2587,
  author="S. Boeyen and T. Howes and P. Richard",
  title="{Internet X.509 Public Key Infrastructure LDAPv2 Schema}",
  howpublished="RFC 2587 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2587",
  pages="1--8",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4523",
url="https://www.rfc-editor.org/rfc/rfc2587.txt",
  key="RFC 2587",
  abstract={The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559.  Only PKIX-specific components are specified here. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, pkix",
  doi="10.17487/RFC2587",
  }

@misc{rfc2588,
  author="R. Finlayson",
  title="{IP Multicast and Firewalls}",
  howpublished="RFC 2588 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2588",
  pages="1--12",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2588.txt",
  key="RFC 2588",
  abstract={In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal.  We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast.  This memo provides information for the Internet community.},
  keywords="Internet, Protocol, security, gateway, traffic",
  doi="10.17487/RFC2588",
  }

@misc{rfc2589,
  author="Y. Yaacovi and M. Wahl and T. Genovese",
  title="{Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services}",
  howpublished="RFC 2589 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2589",
  pages="1--12",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2589.txt",
  key="RFC 2589",
  abstract={This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]},
  keywords="LDAPv3, request, response, operations",
  doi="10.17487/RFC2589",
  }

@misc{rfc2590,
  author="A. Conta and A. Malis and M. Mueller",
  title="{Transmission of IPv6 Packets over Frame Relay Networks Specification}",
  howpublished="RFC 2590 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2590",
  pages="1--19",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc2590.txt",
  key="RFC 2590",
  abstract={This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]},
  keywords="internet, Protocol, format, link-local",
  doi="10.17487/RFC2590",
  }

@misc{rfc2591,
  author="D. Levi and J. Schoenwaelder",
  title="{Definitions of Managed Objects for Scheduling Management Operations}",
  howpublished="RFC 2591 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2591",
  pages="1--25",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3231",
url="https://www.rfc-editor.org/rfc/rfc2591.txt",
  key="RFC 2591",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="mib, information, base",
  doi="10.17487/RFC2591",
  }

@misc{rfc2592,
  author="D. Levi and J. Schoenwaelder",
  title="{Definitions of Managed Objects for the Delegation of Management Script}",
  howpublished="RFC 2592 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2592",
  pages="1--53",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3165",
url="https://www.rfc-editor.org/rfc/rfc2592.txt",
  key="RFC 2592",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]},
  keywords="mib, information, base",
  doi="10.17487/RFC2592",
  }

@misc{rfc2593,
  author="J. Schoenwaelder and J. Quittek",
  title="{Script MIB Extensibility Protocol Version 1.0}",
  howpublished="RFC 2593 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2593",
  pages="1--22",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3179",
url="https://www.rfc-editor.org/rfc/rfc2593.txt",
  key="RFC 2593",
  abstract={The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="management, information, base, smx, language, specific",
  doi="10.17487/RFC2593",
  }

@misc{rfc2594,
  author="H. Hazewinkel and C. Kalbfleisch and J. Schoenwaelder",
  title="{Definitions of Managed Objects for WWW Services}",
  howpublished="RFC 2594 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2594",
  pages="1--43",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2594.txt",
  key="RFC 2594",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community.  In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]},
  keywords="management, information, base, mib, world, wide, web",
  doi="10.17487/RFC2594",
  }

@misc{rfc2595,
  author="C. Newman",
  title="{Using TLS with IMAP, POP3 and ACAP}",
  howpublished="RFC 2595 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2595",
  pages="1--15",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4616, 7817",
url="https://www.rfc-editor.org/rfc/rfc2595.txt",
  key="RFC 2595",
  abstract={Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]},
  keywords="application, configuration, access, protocol, post, office, internet, message, transport, layer, security",
  doi="10.17487/RFC2595",
  }

@misc{rfc2596,
  author="M. Wahl and T. Howes",
  title="{Use of Language Codes in LDAP}",
  howpublished="RFC 2596 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2596",
  pages="1--9",
  year=1999,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3866",
url="https://www.rfc-editor.org/rfc/rfc2596.txt",
  key="RFC 2596",
  abstract={This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, servers",
  doi="10.17487/RFC2596",
  }

@misc{rfc2597,
  author="J. Heinanen and F. Baker and W. Weiss and J. Wroclawski",
  title="{Assured Forwarding PHB Group}",
  howpublished="RFC 2597 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2597",
  pages="1--11",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3260",
url="https://www.rfc-editor.org/rfc/rfc2597.txt",
  key="RFC 2597",
  abstract={This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]},
  keywords="per-hop-behaviour, differentiated, services, af, assumed, forwarding",
  doi="10.17487/RFC2597",
  }

@misc{rfc2598,
  author="V. Jacobson and K. Nichols and K. Poduri",
  title="{An Expedited Forwarding PHB}",
  howpublished="RFC 2598 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2598",
  pages="1--11",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3246",
url="https://www.rfc-editor.org/rfc/rfc2598.txt",
  key="RFC 2598",
  abstract={The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group.  This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]},
  keywords="per-hop-forwarding, behavior, differentiated, services, ef",
  doi="10.17487/RFC2598",
  }

@misc{rfc2599,
  author="A. DeLaCruz",
  title="{Request for Comments Summary RFC Numbers 2500-2599}",
  howpublished="RFC 2599 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2599",
  pages="1--23",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2599.txt",
  key="RFC 2599",
  doi="10.17487/RFC2599",
  }

@misc{rfc2600,
  author="J. Reynolds and R. Braden",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2600 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2600",
  pages="1--31",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2700",
url="https://www.rfc-editor.org/rfc/rfc2600.txt",
  key="RFC 2600",
  abstract={This memo is published by the RFC Editor in accordance with Section 2.1 of ``The Internet Standards Process -- Revision 3'', RFC 2026, which specifies the rules and procedures by which all Internet standards are set.  This memo is prepared by the RFC Editor for the IESG and IAB.  Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]},
  keywords="IAB, official, protocol, standards",
  doi="10.17487/RFC2600",
  }

@misc{rfc2601,
  author="M. Davison",
  title="{ILMI-Based Server Discovery for ATMARP}",
  howpublished="RFC 2601 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2601",
  pages="1--6",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2601.txt",
  key="RFC 2601",
  abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]},
  keywords="integrated, local, management, interface, asynchronous, transfer, mode, address, resolution, protocol",
  doi="10.17487/RFC2601",
  }

@misc{rfc2602,
  author="M. Davison",
  title="{ILMI-Based Server Discovery for MARS}",
  howpublished="RFC 2602 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2602",
  pages="1--6",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2602.txt",
  key="RFC 2602",
  abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]},
  keywords="integrated, local, management, interface, asynchronous, transfer, mode, address, resolution, protocol",
  doi="10.17487/RFC2602",
  }

@misc{rfc2603,
  author="M. Davison",
  title="{ILMI-Based Server Discovery for NHRP}",
  howpublished="RFC 2603 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2603",
  pages="1--6",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2603.txt",
  key="RFC 2603",
  abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]},
  keywords="integrated, local, management, interface, next, hop, resolution, protocol",
  doi="10.17487/RFC2603",
  }

@misc{rfc2604,
  author="R. Gellens",
  title="{Wireless Device Configuration (OTASP/OTAPA) via ACAP}",
  howpublished="RFC 2604 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2604",
  pages="1--29",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2636",
url="https://www.rfc-editor.org/rfc/rfc2604.txt",
  key="RFC 2604",
  abstract={This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol.  This memo provides information for the Internet community.},
  keywords="over-the-air, ota, application, configuration, access, protocol",
  doi="10.17487/RFC2604",
  }

@misc{rfc2605,
  author="G. Mansfield and S. Kille",
  title="{Directory Server Monitoring MIB}",
  howpublished="RFC 2605 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2605",
  pages="1--26",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2605.txt",
  key="RFC 2605",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="management information base, network, services",
  doi="10.17487/RFC2605",
  }

@misc{rfc2606,
  author="D. {Eastlake 3rd} and A. Panitz",
  title="{Reserved Top Level DNS Names}",
  howpublished="RFC 2606 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2606",
  pages="1--5",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6761",
url="https://www.rfc-editor.org/rfc/rfc2606.txt",
  key="RFC 2606",
  abstract={To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like.  In addition, a few second level domain names reserved for use as examples are documented.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="domain, name, system, private",
  doi="10.17487/RFC2606",
  }

@misc{rfc2607,
  author="B. Aboba and J. Vollbrecht",
  title="{Proxy Chaining and Policy Implementation in Roaming}",
  howpublished="RFC 2607 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2607",
  pages="1--15",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2607.txt",
  key="RFC 2607",
  abstract={This document describes how proxy chaining and policy implementation can be supported in roaming systems.  This memo provides information for the Internet community.},
  keywords="network, access, server, identifier, radius",
  doi="10.17487/RFC2607",
  }

@misc{rfc2608,
  author="E. Guttman and C. Perkins and J. Veizades and M. Day",
  title="{Service Location Protocol, Version 2}",
  howpublished="RFC 2608 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2608",
  pages="1--54",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3224",
url="https://www.rfc-editor.org/rfc/rfc2608.txt",
  key="RFC 2608",
  abstract={The Service Location Protocol provides a scalable framework for the discovery and selection of network services.  Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications.  This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]},
  keywords="SLP, network, services",
  doi="10.17487/RFC2608",
  }

@misc{rfc2609,
  author="E. Guttman and C. Perkins and J. Kempf",
  title="{Service Templates and Service: Schemes}",
  howpublished="RFC 2609 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2609",
  pages="1--33",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2609.txt",
  key="RFC 2609",
  abstract={This document describes a formal procedure for defining and standardizing new service types and attributes for use with the ``service:'' scheme. [STANDARDS-TRACK]},
  keywords="service, location, protocol, slp, url, universal, resource, locator",
  doi="10.17487/RFC2609",
  }

@misc{rfc2610,
  author="C. Perkins and E. Guttman",
  title="{DHCP Options for Service Location Protocol}",
  howpublished="RFC 2610 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2610",
  pages="1--6",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2610.txt",
  key="RFC 2610",
  abstract={The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.  Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages.  Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]},
  keywords="slp, dynamic, host, configuration, protocol",
  doi="10.17487/RFC2610",
  }

@misc{rfc2611,
  author="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom",
  title="{URN Namespace Definition Mechanisms}",
  howpublished="RFC 2611 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2611",
  pages="1--14",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3406",
url="https://www.rfc-editor.org/rfc/rfc2611.txt",
  key="RFC 2611",
  abstract={This document lays out general definitions of and mechanisms for establishing URN ``namespaces''.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="uniform, resource, names, namespaces, syntax",
  doi="10.17487/RFC2611",
  }

@misc{rfc2612,
  author="C. Adams and J. Gilchrist",
  title="{The CAST-256 Encryption Algorithm}",
  howpublished="RFC 2612 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2612",
  pages="1--19",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2612.txt",
  key="RFC 2612",
  abstract={This document describes an existing algorithm that can be used to satisfy this requirement.  Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).  This memo provides information for the Internet community.},
  keywords="security, cryptology",
  doi="10.17487/RFC2612",
  }

@misc{rfc2613,
  author="R. Waterman and B. Lahaye and D. Romascanu and S. Waldbusser",
  title="{Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0}",
  howpublished="RFC 2613 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2613",
  pages="1--44",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2613.txt",
  key="RFC 2613",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]},
  keywords="smon, management, information, base",
  doi="10.17487/RFC2613",
  }

@misc{rfc2614,
  author="J. Kempf and E. Guttman",
  title="{An API for Service Location}",
  howpublished="RFC 2614 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2614",
  pages="1--91",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2614.txt",
  key="RFC 2614",
  abstract={This document describes standardized APIs for SLP in C and Java.  This memo provides information for the Internet community.},
  keywords="slp, application, program, interface",
  doi="10.17487/RFC2614",
  }

@misc{rfc2615,
  author="A. Malis and W. Simpson",
  title="{PPP over SONET/SDH}",
  howpublished="RFC 2615 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2615",
  pages="1--10",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2615.txt",
  key="RFC 2615",
  abstract={This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]},
  keywords="point-to-point protocol, synchronous, optical, network, digital, heirarchy",
  doi="10.17487/RFC2615",
  }

@misc{rfc2616,
  author="R. Fielding and J. Gettys and J. Mogul and H. Frystyk and L. Masinter and P. Leach and T. Berners-Lee",
  title="{Hypertext Transfer Protocol -- HTTP/1.1}",
  howpublished="RFC 2616 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2616",
  pages="1--176",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 7230, 7231, 7232, 7233, 7234, 7235, updated by RFCs 2817, 5785, 6266, 6585",
url="https://www.rfc-editor.org/rfc/rfc2616.txt",
  key="RFC 2616",
  abstract={HTTP has been in use by the World-Wide Web global information initiative since 1990.  This specification defines the protocol referred to as ``HTTP/1.1'', and is an update to RFC 2068. [STANDARDS-TRACK]},
  keywords="HTTP, World Wide Web, WWW, hypermedia",
  doi="10.17487/RFC2616",
  }

@misc{rfc2617,
  author="J. Franks and P. Hallam-Baker and J. Hostetler and S. Lawrence and P. Leach and A. Luotonen and L. Stewart",
  title="{HTTP Authentication: Basic and Digest Access Authentication}",
  howpublished="RFC 2617 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2617",
  pages="1--34",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 7235, 7615, 7616, 7617",
url="https://www.rfc-editor.org/rfc/rfc2617.txt",
  key="RFC 2617",
  abstract={This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as ``Digest Access Authentication''. [STANDARDS-TRACK]},
  keywords="security, encryption, hypertext, transfer, protocol",
  doi="10.17487/RFC2617",
  }

@misc{rfc2618,
  author="B. Aboba and G. Zorn",
  title="{RADIUS Authentication Client MIB}",
  howpublished="RFC 2618 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2618",
  pages="1--14",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4668",
url="https://www.rfc-editor.org/rfc/rfc2618.txt",
  key="RFC 2618",
  abstract={This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]},
  keywords="management, information, base, security, remote, access, dialin, user, service",
  doi="10.17487/RFC2618",
  }

@misc{rfc2619,
  author="G. Zorn and B. Aboba",
  title="{RADIUS Authentication Server MIB}",
  howpublished="RFC 2619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2619",
  pages="1--16",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4669",
url="https://www.rfc-editor.org/rfc/rfc2619.txt",
  key="RFC 2619",
  abstract={This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]},
  keywords="management, information, base, security, remote, access, dialin, user, service",
  doi="10.17487/RFC2619",
  }

@misc{rfc2620,
  author="B. Aboba and G. Zorn",
  title="{RADIUS Accounting Client MIB}",
  howpublished="RFC 2620 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2620",
  pages="1--13",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4670",
url="https://www.rfc-editor.org/rfc/rfc2620.txt",
  key="RFC 2620",
  abstract={This memo defines a set of extensions which instrument RADIUS accounting client functions.  This memo provides information for the Internet community.},
  keywords="management, information, base, security, remote, access, dialin, user, service",
  doi="10.17487/RFC2620",
  }

@misc{rfc2621,
  author="G. Zorn and B. Aboba",
  title="{RADIUS Accounting Server MIB}",
  howpublished="RFC 2621 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2621",
  pages="1--15",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4671",
url="https://www.rfc-editor.org/rfc/rfc2621.txt",
  key="RFC 2621",
  abstract={This memo defines a set of extensions which instrument RADIUS accounting server functions.  This memo provides information for the Internet community.},
  keywords="management, information, base, security, remote, access,dialin, user, service",
  doi="10.17487/RFC2621",
  }

@misc{rfc2622,
  author="C. Alaettinoglu and C. Villamizar and E. Gerich and D. Kessens and D. Meyer and T. Bates and D. Karrenberg and M. Terpstra",
  title="{Routing Policy Specification Language (RPSL)}",
  howpublished="RFC 2622 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2622",
  pages="1--69",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4012, 7909",
url="https://www.rfc-editor.org/rfc/rfc2622.txt",
  key="RFC 2622",
  abstract={RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level.  At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them.  RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]},
  keywords="RPSL, internet, policy, hierarchy, network, configuration",
  doi="10.17487/RFC2622",
  }

@misc{rfc2623,
  author="M. Eisler",
  title="{NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC\_GSS and Kerberos V5}",
  howpublished="RFC 2623 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2623",
  pages="1--19",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2623.txt",
  key="RFC 2623",
  abstract={This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC\_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]},
  keywords="network, file, system, remote, procedure, call, architecture",
  doi="10.17487/RFC2623",
  }

@misc{rfc2624,
  author="S. Shepler",
  title="{NFS Version 4 Design Considerations}",
  howpublished="RFC 2624 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2624",
  pages="1--22",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2624.txt",
  key="RFC 2624",
  abstract={This design considerations document is meant to present more detail than the working group charter.  Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4.  This memo provides information for the Internet community.},
  keywords="network, file, system",
  doi="10.17487/RFC2624",
  }

@misc{rfc2625,
  author="M. Rajagopal and R. Bhagwat and W. Rickard",
  title="{IP and ARP over Fibre Channel}",
  howpublished="RFC 2625 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2625",
  pages="1--63",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4338",
url="https://www.rfc-editor.org/rfc/rfc2625.txt",
  key="RFC 2625",
  abstract={The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]},
  keywords="internet, protocal, address, resolution",
  doi="10.17487/RFC2625",
  }

@misc{rfc2626,
  author="P. Nesser II",
  title="{The Internet and the Millennium Problem (Year 2000)}",
  howpublished="RFC 2626 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2626",
  pages="1--275",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2626.txt",
  key="RFC 2626",
  abstract={The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.  This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs).  This investigation discovered little reason for concern with regards to the functionality of the protocols.  A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health.  Several cases of ``period'' problems were discovered, where a time field would ``roll over'' as the size of field was reached.  In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038.  Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation.  This memo provides information for the Internet community.},
  keywords="Y2K",
  doi="10.17487/RFC2626",
  }

@misc{rfc2627,
  author="D. Wallner and E. Harder and R. Agee",
  title="{Key Management for Multicast: Issues and Architectures}",
  howpublished="RFC 2627 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2627",
  pages="1--23",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2627.txt",
  key="RFC 2627",
  abstract={This report contains a discussion of the difficult problem of key management for multicast communication sessions.  It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group.  This memo provides information for the Internet community.},
  keywords="communication, sessions, net key, rekey",
  doi="10.17487/RFC2627",
  }

@misc{rfc2628,
  author="V. Smyslov",
  title="{Simple Cryptographic Program Interface (Crypto API)}",
  howpublished="RFC 2628 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2628",
  pages="1--30",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2628.txt",
  key="RFC 2628",
  abstract={This document describes a simple Application Program Interface to cryptographic functions.  This memo provides information for the Internet community.},
  keywords="application, security",
  doi="10.17487/RFC2628",
  }

@misc{rfc2629,
  author="M. Rose",
  title="{Writing I-Ds and RFCs using XML}",
  howpublished="RFC 2629 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2629",
  pages="1--31",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7749",
url="https://www.rfc-editor.org/rfc/rfc2629.txt",
  key="RFC 2629",
  abstract={This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series.  This memo provides information for the Internet community.},
  keywords="internet-drafts, extensible markup, language, source format",
  doi="10.17487/RFC2629",
  }

@misc{rfc2630,
  author="R. Housley",
  title="{Cryptographic Message Syntax}",
  howpublished="RFC 2630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2630",
  pages="1--60",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3369, 3370",
url="https://www.rfc-editor.org/rfc/rfc2630.txt",
  key="RFC 2630",
  abstract={This document describes the Cryptographic Message Syntax.  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]},
  keywords="encryption, certificate, key, management",
  doi="10.17487/RFC2630",
  }

@misc{rfc2631,
  author="E. Rescorla",
  title="{Diffie-Hellman Key Agreement Method}",
  howpublished="RFC 2631 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2631",
  pages="1--13",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2631.txt",
  key="RFC 2631",
  abstract={This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]},
  keywords="encryption, management, certificate",
  doi="10.17487/RFC2631",
  }

@misc{rfc2632,
  author="B. Ramsdell",
  title="{S/MIME Version 3 Certificate Handling}",
  howpublished="RFC 2632 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2632",
  pages="1--13",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3850",
url="https://www.rfc-editor.org/rfc/rfc2632.txt",
  key="RFC 2632",
  abstract={S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages.  Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid.  S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]},
  keywords="encryption, certificate, multipurpose, internet, mail, extensions, secure",
  doi="10.17487/RFC2632",
  }

@misc{rfc2633,
  author="B. Ramsdell",
  title="{S/MIME Version 3 Message Specification}",
  howpublished="RFC 2633 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2633",
  pages="1--32",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3851",
url="https://www.rfc-editor.org/rfc/rfc2633.txt",
  key="RFC 2633",
  abstract={This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]},
  keywords="secure, multipurpose, internet, mail, extensions, encryption",
  doi="10.17487/RFC2633",
  }

@misc{rfc2634,
  author="P. Hoffman",
  title="{Enhanced Security Services for S/MIME}",
  howpublished="RFC 2634 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2634",
  pages="1--58",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5035",
url="https://www.rfc-editor.org/rfc/rfc2634.txt",
  key="RFC 2634",
  abstract={This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]},
  keywords="secure, multipurpose, internet, mail, extensions, encryption",
  doi="10.17487/RFC2634",
  }

@misc{rfc2635,
  author="S. Hambridge and A. Lunde",
  title="{DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)}",
  howpublished="RFC 2635 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2635",
  pages="1--18",
  year=1999,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2635.txt",
  key="RFC 2635",
  abstract={This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community.  This memo provides information for the Internet community.},
  keywords="electronic, mail, email, users, administrators, managers",
  doi="10.17487/RFC2635",
  }

@misc{rfc2636,
  author="R. Gellens",
  title="{Wireless Device Configuration (OTASP/OTAPA) via ACAP}",
  howpublished="RFC 2636 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2636",
  pages="1--29",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2636.txt",
  key="RFC 2636",
  abstract={This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol.  This memo provides information for the Internet community.},
  keywords="over-the-air, ota, application, configuration, access, protocol",
  doi="10.17487/RFC2636",
  }

@misc{rfc2637,
  author="K. Hamzeh and G. Pall and W. Verthein and J. Taarud and W. Little and G. Zorn",
  title="{Point-to-Point Tunneling Protocol (PPTP)}",
  howpublished="RFC 2637 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2637",
  pages="1--57",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2637.txt",
  key="RFC 2637",
  abstract={This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network.  This memo provides information for the Internet community.},
  keywords="IP, tunnel, encapsulation",
  doi="10.17487/RFC2637",
  }

@misc{rfc2638,
  author="K. Nichols and V. Jacobson and L. Zhang",
  title="{A Two-bit Differentiated Services Architecture for the Internet}",
  howpublished="RFC 2638 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2638",
  pages="1--26",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2638.txt",
  key="RFC 2638",
  abstract={This document presents a differentiated services architecture for the internet.  This memo provides information for the Internet community.},
  keywords="IP, internet protocol, header, packets",
  doi="10.17487/RFC2638",
  }

@misc{rfc2639,
  author="T. Hastings and C. Manros",
  title="{Internet Printing Protocol/1.0: Implementer's Guide}",
  howpublished="RFC 2639 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2639",
  pages="1--64",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3196",
url="https://www.rfc-editor.org/rfc/rfc2639.txt",
  key="RFC 2639",
  abstract={This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents.  It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations.  This memo provides information for the Internet community.},
  keywords="IPP, client, object",
  doi="10.17487/RFC2639",
  }

@misc{rfc2640,
  author="B. Curtin",
  title="{Internationalization of the File Transfer Protocol}",
  howpublished="RFC 2640 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2640",
  pages="1--27",
  year=1999,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2640.txt",
  key="RFC 2640",
  abstract={This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community.  This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]},
  keywords="ftp, character sets, languages",
  doi="10.17487/RFC2640",
  }

@misc{rfc2641,
  author="D. Hamilton and D. Ruffen",
  title="{Cabletron's VlanHello Protocol Specification Version 4}",
  howpublished="RFC 2641 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2641",
  pages="1--17",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2641.txt",
  key="RFC 2641",
  abstract={The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product.  Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric.  This memo provides information for the Internet community.},
  keywords="ISMP, inter switch, message, protocol, switches",
  doi="10.17487/RFC2641",
  }

@misc{rfc2642,
  author="L. Kane",
  title="{Cabletron's VLS Protocol Specification}",
  howpublished="RFC 2642 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2642",
  pages="1--95",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2642.txt",
  key="RFC 2642",
  abstract={VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.  This memo provides information for the Internet community.},
  keywords="Virtual, LAN, link, ISMP, inter switch, message, routing",
  doi="10.17487/RFC2642",
  }

@misc{rfc2643,
  author="D. Ruffen and T. Len and J. Yanacek",
  title="{Cabletron's SecureFast VLAN Operational Model}",
  howpublished="RFC 2643 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2643",
  pages="1--60",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2643.txt",
  key="RFC 2643",
  abstract={Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer.  The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.  This memo provides information for the Internet community.},
  keywords="SFVLAN, switching, data packets, vitrual LANs",
  doi="10.17487/RFC2643",
  }

@misc{rfc2644,
  author="D. Senie",
  title="{Changing the Default for Directed Broadcasts in Routers}",
  howpublished="RFC 2644 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2644",
  pages="1--4",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2644.txt",
  key="RFC 2644",
  abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device.  In addition to defining the tests this document also describes specific formats for reporting the results of the tests.  This memo provides information for the Internet community.},
  keywords="smurf, amplifiers, denial of service",
  doi="10.17487/RFC2644",
  }

@misc{rfc2645,
  author="R. Gellens",
  title="{ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses}",
  howpublished="RFC 2645 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2645",
  pages="1--9",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2645.txt",
  key="RFC 2645",
  abstract={This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]},
  keywords="ODMR-SMTP, simple mail, transfer, protocol, internet",
  doi="10.17487/RFC2645",
  }

@misc{rfc2646,
  author="R. Gellens",
  title="{The Text/Plain Format Parameter}",
  howpublished="RFC 2646 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2646",
  pages="1--14",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3676",
url="https://www.rfc-editor.org/rfc/rfc2646.txt",
  key="RFC 2646",
  abstract={This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines.  This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]},
  keywords="media type, mime, multipurpose, internet, mail, extension",
  doi="10.17487/RFC2646",
  }

@misc{rfc2647,
  author="D. Newman",
  title="{Benchmarking Terminology for Firewall Performance}",
  howpublished="RFC 2647 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2647",
  pages="1--26",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2647.txt",
  key="RFC 2647",
  abstract={This document defines terms used in measuring the performance of firewalls.  It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]},
  keywords="routers, switches, measurement",
  doi="10.17487/RFC2647",
  }

@misc{rfc2648,
  author="R. Moats",
  title="{A URN Namespace for IETF Documents}",
  howpublished="RFC 2648 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2648",
  pages="1--30",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6924",
url="https://www.rfc-editor.org/rfc/rfc2648.txt",
  key="RFC 2648",
  abstract={This document proposes the ``ietf'' namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]},
  keywords="uniform, resource, names, internet, engineering, task, force",
  doi="10.17487/RFC2648",
  }

@misc{rfc2649,
  author="B. Greenblatt and P. Richard",
  title="{An LDAP Control and Schema for Holding Operation Signatures}",
  howpublished="RFC 2649 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2649",
  pages="1--10",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2649.txt",
  key="RFC 2649",
  abstract={This document describes an LDAP message control which allows for the retrieval of digitally signed information.  This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="lightweight, directory, access protocol, client, server",
  doi="10.17487/RFC2649",
  }

@misc{rfc2650,
  author="D. Meyer and J. Schmitz and C. Orange and M. Prior and C. Alaettinoglu",
  title="{Using RPSL in Practice}",
  howpublished="RFC 2650 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2650",
  pages="1--26",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2650.txt",
  key="RFC 2650",
  abstract={This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR).  This memo provides information for the Internet community.},
  keywords="routing policy, specification language, IRR, internet routing, registry, configurations",
  doi="10.17487/RFC2650",
  }

@misc{rfc2651,
  author="J. Allen and M. Mealling",
  title="{The Architecture of the Common Indexing Protocol (CIP)}",
  howpublished="RFC 2651 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2651",
  pages="1--19",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2651.txt",
  key="RFC 2651",
  abstract={This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]},
  keywords="CIP, query, routing, database, servers",
  doi="10.17487/RFC2651",
  }

@misc{rfc2652,
  author="J. Allen and M. Mealling",
  title="{MIME Object Definitions for the Common Indexing Protocol (CIP)}",
  howpublished="RFC 2652 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2652",
  pages="1--22",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2652.txt",
  key="RFC 2652",
  abstract={This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]},
  keywords="multipurpose, internet, mail, extensions, database",
  doi="10.17487/RFC2652",
  }

@misc{rfc2653,
  author="J. Allen and P. Leach and R. Hedberg",
  title="{CIP Transport Protocols}",
  howpublished="RFC 2653 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2653",
  pages="1--11",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2653.txt",
  key="RFC 2653",
  abstract={This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]},
  keywords="common indexing, message, formats",
  doi="10.17487/RFC2653",
  }

@misc{rfc2654,
  author="R. Hedberg and B. Greenblatt and R. Moats and M. Wahl",
  title="{A Tagged Index Object for use in the Common Indexing Protocol}",
  howpublished="RFC 2654 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2654",
  pages="1--24",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2654.txt",
  key="RFC 2654",
  abstract={This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP).  This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="CIP, information, servers, database",
  doi="10.17487/RFC2654",
  }

@misc{rfc2655,
  author="T. Hardie and M. Bowman and D. Hardy and M. Schwartz and D. Wessels",
  title="{CIP Index Object Format for SOIF Objects}",
  howpublished="RFC 2655 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2655",
  pages="1--17",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2655.txt",
  key="RFC 2655",
  abstract={This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="summary, object, interchange, format, common, indexing, protocol",
  doi="10.17487/RFC2655",
  }

@misc{rfc2656,
  author="T. Hardie",
  title="{Registration Procedures for SOIF Template Types}",
  howpublished="RFC 2656 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2656",
  pages="1--9",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2656.txt",
  key="RFC 2656",
  abstract={The registration procedure described in this document is specific to SOIF template types.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="summary, object, interchange, format, stream",
  doi="10.17487/RFC2656",
  }

@misc{rfc2657,
  author="R. Hedberg",
  title="{LDAPv2 Client vs. the Index Mesh}",
  howpublished="RFC 2657 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2657",
  pages="1--12",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2657.txt",
  key="RFC 2657",
  abstract={LDAPv2 clients as implemented according to RFC 1777 have no notion on referral.  The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way.  This document defines one possible way of doing this.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="lightweight, directory, access, protocol, CIP, common, indexing",
  doi="10.17487/RFC2657",
  }

@misc{rfc2658,
  author="K. McKay",
  title="{RTP Payload Format for PureVoice(tm) Audio}",
  howpublished="RFC 2658 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2658",
  pages="1--10",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2658.txt",
  key="RFC 2658",
  abstract={This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]},
  keywords="real-time, transport, protocol, packet, end-to-end",
  doi="10.17487/RFC2658",
  }

@misc{rfc2659,
  author="E. Rescorla and A. Schiffman",
  title="{Security Extensions For HTML}",
  howpublished="RFC 2659 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2659",
  pages="1--4",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2659.txt",
  key="RFC 2659",
  abstract={This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hyper-text, markup language, cryptology",
  doi="10.17487/RFC2659",
  }

@misc{rfc2660,
  author="E. Rescorla and A. Schiffman",
  title="{The Secure HyperText Transfer Protocol}",
  howpublished="RFC 2660 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2660",
  pages="1--45",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2660.txt",
  key="RFC 2660",
  abstract={This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="WWW, world wide web, http, authentication",
  doi="10.17487/RFC2660",
  }

@misc{rfc2661,
  author="W. Townsley and A. Valencia and A. Rubens and G. Pall and G. Zorn and B. Palter",
  title="{Layer Two Tunneling Protocol ``L2TP''}",
  howpublished="RFC 2661 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2661",
  pages="1--80",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2661.txt",
  key="RFC 2661",
  abstract={This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]},
  keywords="L2TP, ppp, point-to-point, protocol, packets",
  doi="10.17487/RFC2661",
  }

@misc{rfc2662,
  author="G. Bathrick and F. Ly",
  title="{Definitions of Managed Objects for the ADSL Lines}",
  howpublished="RFC 2662 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2662",
  pages="1--115",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2662.txt",
  key="RFC 2662",
  abstract={This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]},
  keywords="MIB, management information, base",
  doi="10.17487/RFC2662",
  }

@misc{rfc2663,
  author="P. Srisuresh and M. Holdrege",
  title="{IP Network Address Translator (NAT) Terminology and Considerations}",
  howpublished="RFC 2663 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2663",
  pages="1--30",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2663.txt",
  key="RFC 2663",
  abstract={This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.  This memo provides information for the Internet community.},
  keywords="network address, translator, IP, internet protocol, addresses",
  doi="10.17487/RFC2663",
  }

@misc{rfc2664,
  author="R. Plzak and A. Wells and E. Krol",
  title="{FYI on Questions and Answers - Answers to Commonly Asked ``New Internet User'' Questions}",
  howpublished="RFC 2664 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2664",
  pages="1--11",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2664.txt",
  key="RFC 2664",
  abstract={This memo provides an overview to the new Internet User.  The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic.  This memo provides information for the Internet community.},
  keywords="documentation, help, information, FAQ",
  doi="10.17487/RFC2664",
  }

@misc{rfc2665,
  author="J. Flick and J. Johnson",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 2665 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2665",
  pages="1--47",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3635",
url="https://www.rfc-editor.org/rfc/rfc2665.txt",
  key="RFC 2665",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base",
  doi="10.17487/RFC2665",
  }

@misc{rfc2666,
  author="J. Flick",
  title="{Definitions of Object Identifiers for Identifying Ethernet Chip Sets}",
  howpublished="RFC 2666 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2666",
  pages="1--18",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2666.txt",
  key="RFC 2666",
  abstract={This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community.  This memo provides information for the Internet community.},
  keywords="mib, management, information, base",
  doi="10.17487/RFC2666",
  }

@misc{rfc2667,
  author="D. Thaler",
  title="{IP Tunnel MIB}",
  howpublished="RFC 2667 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2667",
  pages="1--16",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4087",
url="https://www.rfc-editor.org/rfc/rfc2667.txt",
  key="RFC 2667",
  abstract={This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]},
  keywords="internet, protocol, management, information, base",
  doi="10.17487/RFC2667",
  }

@misc{rfc2668,
  author="A. Smith and J. Flick and K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie and S. Roberts",
  title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}",
  howpublished="RFC 2668 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2668",
  pages="1--56",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3636",
url="https://www.rfc-editor.org/rfc/rfc2668.txt",
  key="RFC 2668",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="MAU-MIB, management, information, base",
  doi="10.17487/RFC2668",
  }

@misc{rfc2669,
  author="M. St. Johns",
  title="{DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems}",
  howpublished="RFC 2669 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2669",
  pages="1--55",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4639",
url="https://www.rfc-editor.org/rfc/rfc2669.txt",
  key="RFC 2669",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2669",
  }

@misc{rfc2670,
  author="M. St. Johns",
  title="{Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces}",
  howpublished="RFC 2670 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2670",
  pages="1--72",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4546",
url="https://www.rfc-editor.org/rfc/rfc2670.txt",
  key="RFC 2670",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]},
  keywords="MIB",
  doi="10.17487/RFC2670",
  }

@misc{rfc2671,
  author="P. Vixie",
  title="{Extension Mechanisms for DNS (EDNS0)}",
  howpublished="RFC 2671 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2671",
  pages="1--7",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6891",
url="https://www.rfc-editor.org/rfc/rfc2671.txt",
  key="RFC 2671",
  abstract={The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers.  This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]},
  keywords="EDNS0, domain, name, system, resource, records, opt",
  doi="10.17487/RFC2671",
  }

@misc{rfc2672,
  author="M. Crawford",
  title="{Non-Terminal DNS Name Redirection}",
  howpublished="RFC 2672 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2672",
  pages="1--9",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6672, updated by RFCs 4592, 6604",
url="https://www.rfc-editor.org/rfc/rfc2672.txt",
  key="RFC 2672",
  abstract={This document defines a new DNS Resource Record called ``DNAME'', which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]},
  keywords="domain, name, system, dname, resource, records",
  doi="10.17487/RFC2672",
  }

@misc{rfc2673,
  author="M. Crawford",
  title="{Binary Labels in the Domain Name System}",
  howpublished="RFC 2673 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2673",
  pages="1--7",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6891, updated by RFCs 3363, 3364",
url="https://www.rfc-editor.org/rfc/rfc2673.txt",
  key="RFC 2673",
  abstract={This document defines a ``Bit-String Label'' which may appear within domain names.  This new label type compactly represents a sequence of ``One-Bit Labels'' and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]},
  keywords="DNS, data",
  doi="10.17487/RFC2673",
  }

@misc{rfc2674,
  author="E. Bell and A. Smith and P. Langille and A. Rijhsinghani and K. McCloghrie",
  title="{Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions}",
  howpublished="RFC 2674 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2674",
  pages="1--86",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4363",
url="https://www.rfc-editor.org/rfc/rfc2674.txt",
  key="RFC 2674",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base, local, area, network",
  doi="10.17487/RFC2674",
  }

@misc{rfc2675,
  author="D. Borman and S. Deering and R. Hinden",
  title="{IPv6 Jumbograms}",
  howpublished="RFC 2675 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2675",
  pages="1--9",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2675.txt",
  key="RFC 2675",
  abstract={This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths.  It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]},
  keywords="internet, protocol, packet, payload, link",
  doi="10.17487/RFC2675",
  }

@misc{rfc2676,
  author="G. Apostolopoulos and S. Kama and D. Williams and R. Guerin and A. Orda and T. Przygienda",
  title="{QoS Routing Mechanisms and OSPF Extensions}",
  howpublished="RFC 2676 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2676",
  pages="1--50",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2676.txt",
  key="RFC 2676",
  abstract={This memo describes extensions to the OSPF protocol to support QoS routes.  The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="quality of service, open shortest, path first, routing",
  doi="10.17487/RFC2676",
  }

@misc{rfc2677,
  author="M. Greene and J. Cucchiara and J. Luciani",
  title="{Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)}",
  howpublished="RFC 2677 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2677",
  pages="1--67",
  year=1999,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2677.txt",
  key="RFC 2677",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="NHRP-MIB, management, information, base",
  doi="10.17487/RFC2677",
  }

@misc{rfc2678,
  author="J. Mahdavi and V. Paxson",
  title="{IPPM Metrics for Measuring Connectivity}",
  howpublished="RFC 2678 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2678",
  pages="1--10",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2678.txt",
  key="RFC 2678",
  abstract={This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]},
  keywords="IPPM-MET, internet, protocol, performance, metrics",
  doi="10.17487/RFC2678",
  }

@misc{rfc2679,
  author="G. Almes and S. Kalidindi and M. Zekauskas",
  title="{A One-way Delay Metric for IPPM}",
  howpublished="RFC 2679 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2679",
  pages="1--20",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7679",
url="https://www.rfc-editor.org/rfc/rfc2679.txt",
  key="RFC 2679",
  abstract={This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]},
  keywords="internet, protocol, performance, metrics, packets",
  doi="10.17487/RFC2679",
  }

@misc{rfc2680,
  author="G. Almes and S. Kalidindi and M. Zekauskas",
  title="{A One-way Packet Loss Metric for IPPM}",
  howpublished="RFC 2680 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2680",
  pages="1--15",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7680",
url="https://www.rfc-editor.org/rfc/rfc2680.txt",
  key="RFC 2680",
  abstract={This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]},
  keywords="internet, protocol, performance, metrics",
  doi="10.17487/RFC2680",
  }

@misc{rfc2681,
  author="G. Almes and S. Kalidindi and M. Zekauskas",
  title="{A Round-trip Delay Metric for IPPM}",
  howpublished="RFC 2681 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2681",
  pages="1--20",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2681.txt",
  key="RFC 2681",
  abstract={This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]},
  keywords="internet, protocol, performance, metrics, packets",
  doi="10.17487/RFC2681",
  }

@misc{rfc2682,
  author="I. Widjaja and A. Elwalid",
  title="{Performance Issues in VC-Merge Capable ATM LSRs}",
  howpublished="RFC 2682 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2682",
  pages="1--12",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2682.txt",
  key="RFC 2682",
  abstract={This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers.  This memo provides information for the Internet community.},
  keywords="asynchronous, transfer mode, routing",
  doi="10.17487/RFC2682",
  }

@misc{rfc2683,
  author="B. Leiba",
  title="{IMAP4 Implementation Recommendations}",
  howpublished="RFC 2683 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2683",
  pages="1--23",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7162",
url="https://www.rfc-editor.org/rfc/rfc2683.txt",
  key="RFC 2683",
  abstract={The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail.  Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers.  This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.  This memo provides information for the Internet community.},
  keywords="internet, message, access, protocol, clients, servers",
  doi="10.17487/RFC2683",
  }

@misc{rfc2684,
  author="D. Grossman and J. Heinanen",
  title="{Multiprotocol Encapsulation over ATM Adaptation Layer 5}",
  howpublished="RFC 2684 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2684",
  pages="1--23",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2684.txt",
  key="RFC 2684",
  abstract={This memo replaces RFC 1483.  It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]},
  keywords="asynchronous,transfer, mode, multiplexing",
  doi="10.17487/RFC2684",
  }

@misc{rfc2685,
  author="B. Fox and B. Gleeson",
  title="{Virtual Private Networks Identifier}",
  howpublished="RFC 2685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2685",
  pages="1--6",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2685.txt",
  key="RFC 2685",
  abstract={This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]},
  keywords="VPNI, IP, internet, protocol, VPN",
  doi="10.17487/RFC2685",
  }

@misc{rfc2686,
  author="C. Bormann",
  title="{The Multi-Class Extension to Multi-Link PPP}",
  howpublished="RFC 2686 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2686",
  pages="1--11",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2686.txt",
  key="RFC 2686",
  abstract={This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]},
  keywords="point-to-point protocol, encapsulation",
  doi="10.17487/RFC2686",
  }

@misc{rfc2687,
  author="C. Bormann",
  title="{PPP in a Real-time Oriented HDLC-like Framing}",
  howpublished="RFC 2687 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2687",
  pages="1--13",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2687.txt",
  key="RFC 2687",
  abstract={This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]},
  keywords="point-to-point protocol, encapsulation, high-level, data link, control",
  doi="10.17487/RFC2687",
  }

@misc{rfc2688,
  author="S. Jackowski and D. Putzolu and E. Crawley and B. Davie",
  title="{Integrated Services Mappings for Low Speed Networks}",
  howpublished="RFC 2688 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2688",
  pages="1--16",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2688.txt",
  key="RFC 2688",
  abstract={This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]},
  keywords="controlled, load, guaranteed, services",
  doi="10.17487/RFC2688",
  }

@misc{rfc2689,
  author="C. Bormann",
  title="{Providing Integrated Services over Low-bitrate Links}",
  howpublished="RFC 2689 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2689",
  pages="1--14",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2689.txt",
  key="RFC 2689",
  abstract={This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links.  This memo provides information for the Internet community.},
  keywords="asynchronous, synchronous, real-time",
  doi="10.17487/RFC2689",
  }

@misc{rfc2690,
  author="S. Bradner",
  title="{A Proposal for an MOU-Based ICANN Protocol Support Organization}",
  howpublished="RFC 2690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2690",
  pages="1--8",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2690.txt",
  key="RFC 2690",
  abstract={This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999.  This memo provides information for the Internet community.},
  keywords="pso, memorandum of understanding, internet, corporation for assigned names and numbers",
  doi="10.17487/RFC2690",
  }

@misc{rfc2691,
  author="S. Bradner",
  title="{A Memorandum of Understanding for an ICANN Protocol Support Organization}",
  howpublished="RFC 2691 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2691",
  pages="1--9",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2691.txt",
  key="RFC 2691",
  abstract={This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo.  This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN).  This memo provides information for the Internet community.},
  keywords="mou, pso, internet, corporation for assigned names and numbers",
  doi="10.17487/RFC2691",
  }

@misc{rfc2692,
  author="C. Ellison",
  title="{SPKI Requirements}",
  howpublished="RFC 2692 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2692",
  pages="1--14",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2692.txt",
  key="RFC 2692",
  abstract={The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements.  This document presents that summary of requirements.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SPKI, simple public, key, infrastructure, authentication",
  doi="10.17487/RFC2692",
  }

@misc{rfc2693,
  author="C. Ellison and B. Frantz and B. Lampson and R. Rivest and B. Thomas and T. Ylonen",
  title="{SPKI Certificate Theory}",
  howpublished="RFC 2693 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2693",
  pages="1--43",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2693.txt",
  key="RFC 2693",
  abstract={This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SPKI, simple, public, key, infrastructure, authentication",
  doi="10.17487/RFC2693",
  }

@misc{rfc2694,
  author="P. Srisuresh and G. Tsirtsis and P. Akkiraju and A. Heffernan",
  title="{DNS extensions to Network Address Translators (DNS\_ALG)}",
  howpublished="RFC 2694 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2694",
  pages="1--29",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2694.txt",
  key="RFC 2694",
  abstract={This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS\_ALG) can meet the need.  This memo provides information for the Internet community.},
  keywords="domain name, system, NATs, mapping",
  doi="10.17487/RFC2694",
  }

@misc{rfc2695,
  author="A. Chiu",
  title="{Authentication Mechanisms for ONC RPC}",
  howpublished="RFC 2695 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2695",
  pages="1--18",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2695.txt",
  key="RFC 2695",
  abstract={This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol.  This memo provides information for the Internet community.},
  keywords="remote procedure, call, open network, computing",
  doi="10.17487/RFC2695",
  }

@misc{rfc2696,
  author="C. Weider and A. Herron and A. Anantha and T. Howes",
  title="{LDAP Control Extension for Simple Paged Results Manipulation}",
  howpublished="RFC 2696 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2696",
  pages="1--7",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2696.txt",
  key="RFC 2696",
  abstract={This document describes an LDAPv3 control extension for simple paging of search results.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol, client, server",
  doi="10.17487/RFC2696",
  }

@misc{rfc2697,
  author="J. Heinanen and R. Guerin",
  title="{A Single Rate Three Color Marker}",
  howpublished="RFC 2697 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2697",
  pages="1--6",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2697.txt",
  key="RFC 2697",
  abstract={This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner.  This memo provides information for the Internet community.},
  keywords="srtcm, stream, ip, internet, protocol, packet",
  doi="10.17487/RFC2697",
  }

@misc{rfc2698,
  author="J. Heinanen and R. Guerin",
  title="{A Two Rate Three Color Marker}",
  howpublished="RFC 2698 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2698",
  pages="1--5",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2698.txt",
  key="RFC 2698",
  abstract={This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner.  This memo provides information for the Internet community.},
  keywords="trTCM, stream, ip, internet, protocol, packet",
  doi="10.17487/RFC2698",
  }

@misc{rfc2699,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 2600-2699}",
  howpublished="RFC 2699 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2699",
  pages="1--22",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2699.txt",
  key="RFC 2699",
  doi="10.17487/RFC2699",
  }

@misc{rfc2700,
  author="J. Reynolds and R. Braden",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2700 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2700",
  pages="1--32",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2800",
url="https://www.rfc-editor.org/rfc/rfc2700.txt",
  key="RFC 2700",
  abstract={This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]},
  doi="10.17487/RFC2700",
  }

@misc{rfc2701,
  author="G. Malkin",
  title="{Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol}",
  howpublished="RFC 2701 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2701",
  pages="1--9",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2701.txt",
  key="RFC 2701",
  abstract={This document specifies a standard way for Multi-link PPP to operate across multiple nodes.  This memo provides information for the Internet community.},
  keywords="point-to-point, POP, presence, RAS, remote access, server",
  doi="10.17487/RFC2701",
  }

@misc{rfc2702,
  author="D. Awduche and J. Malcolm and J. Agogbua and M. O'Dell and J. McManus",
  title="{Requirements for Traffic Engineering Over MPLS}",
  howpublished="RFC 2702 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2702",
  pages="1--29",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2702.txt",
  key="RFC 2702",
  abstract={This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS).  It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain.  This memo provides information for the Internet community.},
  keywords="multiprotocol, label, switching",
  doi="10.17487/RFC2702",
  }

@misc{rfc2703,
  author="G. Klyne",
  title="{Protocol-independent Content Negotiation Framework}",
  howpublished="RFC 2703 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2703",
  pages="1--20",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2703.txt",
  key="RFC 2703",
  abstract={This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.  This memo provides information for the Internet community.},
  keywords="feature, resource, media, syntax",
  doi="10.17487/RFC2703",
  }

@misc{rfc2704,
  author="M. Blaze and J. Feigenbaum and J. Ioannidis and A. Keromytis",
  title="{The KeyNote Trust-Management System Version 2}",
  howpublished="RFC 2704 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2704",
  pages="1--37",
  year=1999,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2704.txt",
  key="RFC 2704",
  abstract={This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit.  This memo provides information for the Internet community.},
  keywords="security, policy maker, system, credentials",
  doi="10.17487/RFC2704",
  }

@misc{rfc2705,
  author="M. Arango and A. Dugan and I. Elliott and C. Huitema and S. Pickett",
  title="{Media Gateway Control Protocol (MGCP) Version 1.0}",
  howpublished="RFC 2705 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2705",
  pages="1--134",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3435, updated by RFC 3660",
url="https://www.rfc-editor.org/rfc/rfc2705.txt",
  key="RFC 2705",
  abstract={This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements.  MGCP assumes a call control architecture where the call control ``intelligence'' is outside the gateways and handled by external call control elements.  This memo provides information for the Internet community.},
  keywords="voice, IP, internet, VoIP",
  doi="10.17487/RFC2705",
  }

@misc{rfc2706,
  author="D. {Eastlake 3rd} and T. Goldstein",
  title="{ECML v1: Field Names for E-Commerce}",
  howpublished="RFC 2706 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2706",
  pages="1--13",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3106",
url="https://www.rfc-editor.org/rfc/rfc2706.txt",
  key="RFC 2706",
  abstract={A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields.  This memo provides information for the Internet community.},
  keywords="electronic, commerce, modeling, language, merchant, site. web",
  doi="10.17487/RFC2706",
  }

@misc{rfc2707,
  author="R. Bergman and T. Hastings and S. Isaacson and H. Lewis",
  title="{Job Monitoring MIB - V1.0}",
  howpublished="RFC 2707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2707",
  pages="1--114",
  year=1999,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2707.txt",
  key="RFC 2707",
  abstract={This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job.  This memo provides information for the Internet community.},
  keywords="management, information, base",
  doi="10.17487/RFC2707",
  }

@misc{rfc2708,
  author="R. Bergman",
  title="{Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB}",
  howpublished="RFC 2708 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2708",
  pages="1--26",
  year=1999,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2708.txt",
  key="RFC 2708",
  abstract={This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB.  This memo provides information for the Internet community.},
  keywords="management, information, base",
  doi="10.17487/RFC2708",
  }

@misc{rfc2709,
  author="P. Srisuresh",
  title="{Security Model with Tunnel-mode IPsec for NAT Domains}",
  howpublished="RFC 2709 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2709",
  pages="1--11",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2709.txt",
  key="RFC 2709",
  abstract={This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices.  This memo provides information for the Internet community.},
  keywords="internet protocol, network address, translator",
  doi="10.17487/RFC2709",
  }

@misc{rfc2710,
  author="S. Deering and W. Fenner and B. Haberman",
  title="{Multicast Listener Discovery (MLD) for IPv6}",
  howpublished="RFC 2710 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2710",
  pages="1--22",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3590, 3810",
url="https://www.rfc-editor.org/rfc/rfc2710.txt",
  key="RFC 2710",
  abstract={This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]},
  keywords="MLD-IPv6, internet protocol, routher, packets",
  doi="10.17487/RFC2710",
  }

@misc{rfc2711,
  author="C. Partridge and A. Jackson",
  title="{IPv6 Router Alert Option}",
  howpublished="RFC 2711 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2711",
  pages="1--6",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6398",
url="https://www.rfc-editor.org/rfc/rfc2711.txt",
  key="RFC 2711",
  abstract={This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]},
  keywords="internet protocol, datagram, routher, hop-by-hop",
  doi="10.17487/RFC2711",
  }

@misc{rfc2712,
  author="A. Medvinsky and M. Hur",
  title="{Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)}",
  howpublished="RFC 2712 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2712",
  pages="1--7",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2712.txt",
  key="RFC 2712",
  abstract={This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]},
  keywords="TLS, authentication, cryptography",
  doi="10.17487/RFC2712",
  }

@misc{rfc2713,
  author="V. Ryan and S. Seligman and R. Lee",
  title="{Schema for Representing Java(tm) Objects in an LDAP Directory}",
  howpublished="RFC 2713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2713",
  pages="1--21",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2713.txt",
  key="RFC 2713",
  abstract={This document defines the schema for representing Java(tm) objects in an LDAP directory.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC2713",
  }

@misc{rfc2714,
  author="V. Ryan and R. Lee and S. Seligman",
  title="{Schema for Representing CORBA Object References in an LDAP Directory}",
  howpublished="RFC 2714 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2714",
  pages="1--10",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2714.txt",
  key="RFC 2714",
  abstract={This document defines the schema for representing CORBA object references in an LDAP directory.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC2714",
  }

@misc{rfc2715,
  author="D. Thaler",
  title="{Interoperability Rules for Multicast Routing Protocols}",
  howpublished="RFC 2715 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2715",
  pages="1--22",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2715.txt",
  key="RFC 2715",
  abstract={The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.  This memo provides information for the Internet community.},
  keywords="border, router, MBRs, autonomous",
  doi="10.17487/RFC2715",
  }

@misc{rfc2716,
  author="B. Aboba and D. Simon",
  title="{PPP EAP TLS Authentication Protocol}",
  howpublished="RFC 2716 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2716",
  pages="1--24",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5216",
url="https://www.rfc-editor.org/rfc/rfc2716.txt",
  key="RFC 2716",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="point-to-point, link control compression, extensible, transport level security",
  doi="10.17487/RFC2716",
  }

@misc{rfc2717,
  author="R. Petke and I. King",
  title="{Registration Procedures for URL Scheme Names}",
  howpublished="RFC 2717 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2717",
  pages="1--10",
  year=1999,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4395",
url="https://www.rfc-editor.org/rfc/rfc2717.txt",
  key="RFC 2717",
  abstract={This document defines the process by which new URL scheme names are registered.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="uniform, resource, locator, syntax, semantics",
  doi="10.17487/RFC2717",
  }

@misc{rfc2718,
  author="L. Masinter and H. Alvestrand and D. Zigmond and R. Petke",
  title="{Guidelines for new URL Schemes}",
  howpublished="RFC 2718 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2718",
  pages="1--10",
  year=1999,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4395",
url="https://www.rfc-editor.org/rfc/rfc2718.txt",
  key="RFC 2718",
  abstract={This document provides guidelines for the definition of new URL schemes.  This memo provides information for the Internet community.},
  keywords="uniform, resource, locator, syntax, semantics",
  doi="10.17487/RFC2718",
  }

@misc{rfc2719,
  author="L. Ong and I. Rytina and M. Garcia and H. Schwarzbauer and L. Coene and H. Lin and I. Juhasz and M. Holdrege and C. Sharp",
  title="{Framework Architecture for Signaling Transport}",
  howpublished="RFC 2719 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2719",
  pages="1--24",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2719.txt",
  key="RFC 2719",
  abstract={This document defines an architecture framework and functional requirements for transport of signaling information over IP.  This memo provides information for the Internet community.},
  keywords="IP, Internet Protocol, gateway, media, circuit",
  doi="10.17487/RFC2719",
  }

@misc{rfc2720,
  author="N. Brownlee",
  title="{Traffic Flow Measurement: Meter MIB}",
  howpublished="RFC 2720 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2720",
  pages="1--55",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2720.txt",
  key="RFC 2720",
  abstract={This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured.  It also provides an efficient mechanism for retrieving flow data from the meter using SNMP.  Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2720",
  }

@misc{rfc2721,
  author="N. Brownlee",
  title="{RTFM: Applicability Statement}",
  howpublished="RFC 2721 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2721",
  pages="1--10",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2721.txt",
  key="RFC 2721",
  abstract={This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations.  This memo provides information for the Internet community.},
  keywords="real-time, traffic flow, measurement",
  doi="10.17487/RFC2721",
  }

@misc{rfc2722,
  author="N. Brownlee and C. Mills and G. Ruth",
  title="{Traffic Flow Measurement: Architecture}",
  howpublished="RFC 2722 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2722",
  pages="1--48",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2722.txt",
  key="RFC 2722",
  abstract={This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet.  This memo provides information for the Internet community.},
  keywords="network, meters, data",
  doi="10.17487/RFC2722",
  }

@misc{rfc2723,
  author="N. Brownlee",
  title="{SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups}",
  howpublished="RFC 2723 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2723",
  pages="1--22",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2723.txt",
  key="RFC 2723",
  abstract={This document describes a language for specifying rulesets, i.e.  configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.  This memo provides information for the Internet community.},
  keywords="simple, ruleset, RTFM, real-time, network, measurement",
  doi="10.17487/RFC2723",
  }

@misc{rfc2724,
  author="S. Handelman and S. Stibler and N. Brownlee and G. Ruth",
  title="{RTFM: New Attributes for Traffic Flow Measurement}",
  howpublished="RFC 2724 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2724",
  pages="1--18",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2724.txt",
  key="RFC 2724",
  abstract={This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="real-time, network",
  doi="10.17487/RFC2724",
  }

@misc{rfc2725,
  author="C. Villamizar and C. Alaettinoglu and D. Meyer and S. Murphy",
  title="{Routing Policy System Security}",
  howpublished="RFC 2725 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2725",
  pages="1--41",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4012",
url="https://www.rfc-editor.org/rfc/rfc2725.txt",
  key="RFC 2725",
  abstract={The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use.  This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]},
  keywords="RPSL, database, registry, authentication",
  doi="10.17487/RFC2725",
  }

@misc{rfc2726,
  author="J. Zsako",
  title="{PGP Authentication for RIPE Database Updates}",
  howpublished="RFC 2726 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2726",
  pages="1--11",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2726.txt",
  key="RFC 2726",
  abstract={This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]},
  keywords="pretty good, privacy, security, digital, signatures",
  doi="10.17487/RFC2726",
  }

@misc{rfc2727,
  author="J. Galvin",
  title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}",
  howpublished="RFC 2727 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2727",
  pages="1--15",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3777",
url="https://www.rfc-editor.org/rfc/rfc2727.txt",
  key="RFC 2727",
  abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified.  This document is a self- consistent, organized compilation of the process as it was known at the time of publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet, Architecture, Board, Engineering, Steering, Group",
  doi="10.17487/RFC2727",
  }

@misc{rfc2728,
  author="R. Panabaker and S. Wegerif and D. Zigmond",
  title="{The Transmission of IP Over the Vertical Blanking Interval of a Television Signal}",
  howpublished="RFC 2728 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2728",
  pages="1--23",
  year=1999,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2728.txt",
  key="RFC 2728",
  abstract={This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]},
  keywords="internet, protocol, IPVBI",
  doi="10.17487/RFC2728",
  }

@misc{rfc2729,
  author="P. Bagnall and R. Briscoe and A. Poppitt",
  title="{Taxonomy of Communication Requirements for Large-scale Multicast Applications}",
  howpublished="RFC 2729 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2729",
  pages="1--27",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2729.txt",
  key="RFC 2729",
  abstract={The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA).  This memo provides information for the Internet community.},
  keywords="LSMA, dynamic, protocol, mapping",
  doi="10.17487/RFC2729",
  }

@misc{rfc2730,
  author="S. Hanna and B. Patel and M. Shah",
  title="{Multicast Address Dynamic Client Allocation Protocol (MADCAP)}",
  howpublished="RFC 2730 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2730",
  pages="1--53",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2730.txt",
  key="RFC 2730",
  abstract={This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]},
  keywords="MADCAP, client, server, scope, zone, host",
  doi="10.17487/RFC2730",
  }

@misc{rfc2731,
  author="J. Kunze",
  title="{Encoding Dublin Core Metadata in HTML}",
  howpublished="RFC 2731 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2731",
  pages="1--23",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5791",
url="https://www.rfc-editor.org/rfc/rfc2731.txt",
  key="RFC 2731",
  abstract={The Dublin Core is a small set of metadata elements for describing information resources.  This document explains how these elements are expressed using the META and LINK tags of HTML.  This memo provides information for the Internet community.},
  keywords="hypertext, markup, language, xml, extensible",
  doi="10.17487/RFC2731",
  }

@misc{rfc2732,
  author="R. Hinden and B. Carpenter and L. Masinter",
  title="{Format for Literal IPv6 Addresses in URL's}",
  howpublished="RFC 2732 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2732",
  pages="1--5",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3986",
url="https://www.rfc-editor.org/rfc/rfc2732.txt",
  key="RFC 2732",
  abstract={This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]},
  keywords="Internet, protocol, uniform, resource, identifier, www, world wide web",
  doi="10.17487/RFC2732",
  }

@misc{rfc2733,
  author="J. Rosenberg and H. Schulzrinne",
  title="{An RTP Payload Format for Generic Forward Error Correction}",
  howpublished="RFC 2733 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2733",
  pages="1--26",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5109",
url="https://www.rfc-editor.org/rfc/rfc2733.txt",
  key="RFC 2733",
  abstract={This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]},
  keywords="FEC, real-time, protocol, stream",
  doi="10.17487/RFC2733",
  }

@misc{rfc2734,
  author="P. Johansson",
  title="{IPv4 over IEEE 1394}",
  howpublished="RFC 2734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2734",
  pages="1--29",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2734.txt",
  key="RFC 2734",
  abstract={This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]},
  keywords="internet, protocol, datagrams, packet, encapsulation, ARP, address, resolution, multicast",
  doi="10.17487/RFC2734",
  }

@misc{rfc2735,
  author="B. Fox and B. Petri",
  title="{NHRP Support for Virtual Private Networks}",
  howpublished="RFC 2735 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2735",
  pages="1--12",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2735.txt",
  key="RFC 2735",
  abstract={The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the ``NBMA next hop'' towards a public internetworking layer address.  This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]},
  keywords="next hop, resolution, protocol, VPN, addresses",
  doi="10.17487/RFC2735",
  }

@misc{rfc2736,
  author="M. Handley and C. Perkins",
  title="{Guidelines for Writers of RTP Payload Format Specifications}",
  howpublished="RFC 2736 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2736",
  pages="1--10",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8088",
url="https://www.rfc-editor.org/rfc/rfc2736.txt",
  key="RFC 2736",
  abstract={This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="real-time, transport, protocol, data types, audio, video, codecs",
  doi="10.17487/RFC2736",
  }

@misc{rfc2737,
  author="K. McCloghrie and A. Bierman",
  title="{Entity MIB (Version 2)}",
  howpublished="RFC 2737 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2737",
  pages="1--56",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4133",
url="https://www.rfc-editor.org/rfc/rfc2737.txt",
  key="RFC 2737",
  abstract={This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]},
  keywords="management, information, base, SNMP, simple, network, protocol",
  doi="10.17487/RFC2737",
  }

@misc{rfc2738,
  author="G. Klyne",
  title="{Corrections to ``A Syntax for Describing Media Feature Sets''}",
  howpublished="RFC 2738 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2738",
  pages="1--5",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2738.txt",
  key="RFC 2738",
  abstract={In RFC 2533, ``A Syntax for Describing Media Feature Sets'', an expression format is presented for describing media feature capabilities using simple media feature tags.  This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]},
  keywords="FEC, real-time, protocol, stream",
  doi="10.17487/RFC2738",
  }

@misc{rfc2739,
  author="T. Small and D. Hennessy and F. Dawson",
  title="{Calendar Attributes for vCard and LDAP}",
  howpublished="RFC 2739 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2739",
  pages="1--16",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6350",
url="https://www.rfc-editor.org/rfc/rfc2739.txt",
  key="RFC 2739",
  abstract={This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC2739",
  }

@misc{rfc2740,
  author="R. Coltun and D. Ferguson and J. Moy",
  title="{OSPF for IPv6}",
  howpublished="RFC 2740 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2740",
  pages="1--80",
  year=1999,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5340",
url="https://www.rfc-editor.org/rfc/rfc2740.txt",
  key="RFC 2740",
  abstract={This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]},
  keywords="internet, protocol, open shortest, path first",
  doi="10.17487/RFC2740",
  }

@misc{rfc2741,
  author="M. Daniele and B. Wijnen and M. Ellison and D. Francisco",
  title="{Agent Extensibility (AgentX) Protocol Version 1}",
  howpublished="RFC 2741 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2741",
  pages="1--91",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2741.txt",
  key="RFC 2741",
  abstract={This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]},
  keywords="SNMP, simple, network, management",
  doi="10.17487/RFC2741",
  }

@misc{rfc2742,
  author="L. Heintz and S. Gudur and M. Ellison",
  title="{Definitions of Managed Objects for Extensible SNMP Agents}",
  howpublished="RFC 2742 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2742",
  pages="1--20",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2742.txt",
  key="RFC 2742",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]},
  keywords="SNMP, management, information, base, simple, network, protocol",
  doi="10.17487/RFC2742",
  }

@misc{rfc2743,
  author="J. Linn",
  title="{Generic Security Service Application Program Interface Version 2, Update 1}",
  howpublished="RFC 2743 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2743",
  pages="1--101",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5554",
url="https://www.rfc-editor.org/rfc/rfc2743.txt",
  key="RFC 2743",
  abstract={This memo obsoletes [STANDARDS-TRACK]},
  keywords="GSS-API, portability, application, authentication, cryptology",
  doi="10.17487/RFC2743",
  }

@misc{rfc2744,
  author="J. Wray",
  title="{Generic Security Service API Version 2 : C-bindings}",
  howpublished="RFC 2744 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2744",
  pages="1--101",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2744.txt",
  key="RFC 2744",
  abstract={This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]},
  keywords="GSS-API, cryptology, authentication",
  doi="10.17487/RFC2744",
  }

@misc{rfc2745,
  author="A. Terzis and B. Braden and S. Vincent and L. Zhang",
  title="{RSVP Diagnostic Messages}",
  howpublished="RFC 2745 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2745",
  pages="1--23",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2745.txt",
  key="RFC 2745",
  abstract={This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, network, management",
  doi="10.17487/RFC2745",
  }

@misc{rfc2746,
  author="A. Terzis and J. Krawczyk and J. Wroclawski and L. Zhang",
  title="{RSVP Operation Over IP Tunnels}",
  howpublished="RFC 2746 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2746",
  pages="1--25",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2746.txt",
  key="RFC 2746",
  abstract={This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, internet",
  doi="10.17487/RFC2746",
  }

@misc{rfc2747,
  author="F. Baker and B. Lindell and M. Talwar",
  title="{RSVP Cryptographic Authentication}",
  howpublished="RFC 2747 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2747",
  pages="1--21",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3097",
url="https://www.rfc-editor.org/rfc/rfc2747.txt",
  key="RFC 2747",
  abstract={This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, security",
  doi="10.17487/RFC2747",
  }

@misc{rfc2748,
  author="D. Durham and J. Boyle and R. Cohen and S. Herzog and R. Rajan and A. Sastry",
  title="{The COPS (Common Open Policy Service) Protocol}",
  howpublished="RFC 2748 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2748",
  pages="1--38",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4261",
url="https://www.rfc-editor.org/rfc/rfc2748.txt",
  key="RFC 2748",
  abstract={This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]},
  keywords="COPS, qos, quality of service, signaling",
  doi="10.17487/RFC2748",
  }

@misc{rfc2749,
  author="S. Herzog and J. Boyle and R. Cohen and D. Durham and R. Rajan and A. Sastry",
  title="{COPS usage for RSVP}",
  howpublished="RFC 2749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2749",
  pages="1--17",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2749.txt",
  key="RFC 2749",
  abstract={This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]},
  keywords="common, open, policy, resource, reservation, protocol",
  doi="10.17487/RFC2749",
  }

@misc{rfc2750,
  author="S. Herzog",
  title="{RSVP Extensions for Policy Control}",
  howpublished="RFC 2750 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2750",
  pages="1--13",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2750.txt",
  key="RFC 2750",
  abstract={This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, admission",
  doi="10.17487/RFC2750",
  }

@misc{rfc2751,
  author="S. Herzog",
  title="{Signaled Preemption Priority Policy Element}",
  howpublished="RFC 2751 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2751",
  pages="1--12",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3181",
url="https://www.rfc-editor.org/rfc/rfc2751.txt",
  key="RFC 2751",
  abstract={This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]},
  keywords="RSVP, COPS, resource, reservation, protocol, common, open, service",
  doi="10.17487/RFC2751",
  }

@misc{rfc2752,
  author="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. Moore and S. Herzog",
  title="{Identity Representation for RSVP}",
  howpublished="RFC 2752 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2752",
  pages="1--17",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3182",
url="https://www.rfc-editor.org/rfc/rfc2752.txt",
  key="RFC 2752",
  abstract={This document describes the representation of identity information in POLICY\_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, admission, authentication",
  doi="10.17487/RFC2752",
  }

@misc{rfc2753,
  author="R. Yavatkar and D. Pendarakis and R. Guerin",
  title="{A Framework for Policy-based Admission Control}",
  howpublished="RFC 2753 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2753",
  pages="1--20",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2753.txt",
  key="RFC 2753",
  abstract={This document is concerned with specifying a framework for providing policy-based control over admission control decisions.  This memo provides information for the Internet community.},
  doi="10.17487/RFC2753",
  }

@misc{rfc2754,
  author="C. Alaettinoglu and C. Villamizar and R. Govindan",
  title="{RPS IANA Issues}",
  howpublished="RFC 2754 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2754",
  pages="1--7",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6254",
url="https://www.rfc-editor.org/rfc/rfc2754.txt",
  key="RFC 2754",
  abstract={RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated.  The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA.  This paper presents these seed objects and lists operations required from IANA.  This memo provides information for the Internet community.},
  keywords="internet, assigned, numbers, authority, routing, policy, specification, system, security",
  doi="10.17487/RFC2754",
  }

@misc{rfc2755,
  author="A. Chiu and M. Eisler and B. Callaghan",
  title="{Security Negotiation for WebNFS}",
  howpublished="RFC 2755 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2755",
  pages="1--12",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2755.txt",
  key="RFC 2755",
  abstract={This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813).  This document is provided so that people can write compatible implementations.  This memo provides information for the Internet community.},
  keywords="RSVP, QOS, resource reservation, protocol, quality of service",
  doi="10.17487/RFC2755",
  }

@misc{rfc2756,
  author="P. Vixie and D. Wessels",
  title="{Hyper Text Caching Protocol (HTCP/0.0)}",
  howpublished="RFC 2756 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2756",
  pages="1--15",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2756.txt",
  key="RFC 2756",
  abstract={This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity.  This is an experimental protocol, one among several proposals to perform these functions.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="HTCP, hypertext, transfer protocol, caches, data",
  doi="10.17487/RFC2756",
  }

@misc{rfc2757,
  author="G. Montenegro and S. Dawkins and M. Kojo and V. Magret and N. Vaidya",
  title="{Long Thin Networks}",
  howpublished="RFC 2757 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2757",
  pages="1--46",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2757.txt",
  key="RFC 2757",
  abstract={Our goal is to identify a TCP that works for all users, including users of long thin networks.  This memo provides information for the Internet community.},
  keywords="wireless, WAN, wide area, networks, TCP, transmission, control, protocol",
  doi="10.17487/RFC2757",
  }

@misc{rfc2758,
  author="K. White",
  title="{Definitions of Managed Objects for Service Level Agreements Performance Monitoring}",
  howpublished="RFC 2758 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2758",
  pages="1--71",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2758.txt",
  key="RFC 2758",
  abstract={This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MIB, management, information, base, SLAs",
  doi="10.17487/RFC2758",
  }

@misc{rfc2759,
  author="G. Zorn",
  title="{Microsoft PPP CHAP Extensions, Version 2}",
  howpublished="RFC 2759 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2759",
  pages="1--20",
  year=2000,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2759.txt",
  key="RFC 2759",
  abstract={This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2).  MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1).  This memo provides information for the Internet community.},
  keywords="point-to-point, protocol, challenge, handshake, authentication",
  doi="10.17487/RFC2759",
  }

@misc{rfc2760,
  author="M. Allman and S. Dawkins and D. Glover and J. Griner and D. Tran and T. Henderson and J. Heidemann and J. Touch and H. Kruse and S. Ostermann and K. Scott and J. Semke",
  title="{Ongoing TCP Research Related to Satellites}",
  howpublished="RFC 2760 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2760",
  pages="1--46",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2760.txt",
  key="RFC 2760",
  abstract={This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links.  This memo provides information for the Internet community.},
  keywords="transmission, control, protocol, bandwidth, network, links",
  doi="10.17487/RFC2760",
  }

@misc{rfc2761,
  author="J. Dunn and C. Martin",
  title="{Terminology for ATM Benchmarking}",
  howpublished="RFC 2761 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2761",
  pages="1--32",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2761.txt",
  key="RFC 2761",
  abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices.  This memo provides information for the Internet community.},
  keywords="asynchronous, transfer, mode, performance",
  doi="10.17487/RFC2761",
  }

@misc{rfc2762,
  author="J. Rosenberg and H. Schulzrinne",
  title="{Sampling of the Group Membership in RTP}",
  howpublished="RFC 2762 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2762",
  pages="1--12",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2762.txt",
  key="RFC 2762",
  abstract={This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="real-time, transport, protocol, packets",
  doi="10.17487/RFC2762",
  }

@misc{rfc2763,
  author="N. Shen and H. Smit",
  title="{Dynamic Hostname Exchange Mechanism for IS-IS}",
  howpublished="RFC 2763 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2763",
  pages="1--5",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5301",
url="https://www.rfc-editor.org/rfc/rfc2763.txt",
  key="RFC 2763",
  abstract={This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network.  This memo provides information for the Internet community.},
  keywords="intermediate, system, routers, TLV",
  doi="10.17487/RFC2763",
  }

@misc{rfc2764,
  author="B. Gleeson and A. Lin and J. Heinanen and G. Armitage and A. Malis",
  title="{A Framework for IP Based Virtual Private Networks}",
  howpublished="RFC 2764 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2764",
  pages="1--62",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2764.txt",
  key="RFC 2764",
  abstract={This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones.  This memo provides information for the Internet community.},
  keywords="VPN, internet protocol, backbone",
  doi="10.17487/RFC2764",
  }

@misc{rfc2765,
  author="E. Nordmark",
  title="{Stateless IP/ICMP Translation Algorithm (SIIT)}",
  howpublished="RFC 2765 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2765",
  pages="1--26",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6145",
url="https://www.rfc-editor.org/rfc/rfc2765.txt",
  key="RFC 2765",
  abstract={This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]},
  keywords="SIIT, internet, protocol, control, message, IPv4, IPv6",
  doi="10.17487/RFC2765",
  }

@misc{rfc2766,
  author="G. Tsirtsis and P. Srisuresh",
  title="{Network Address Translation - Protocol Translation (NAT-PT)}",
  howpublished="RFC 2766 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2766",
  pages="1--21",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4966, updated by RFC 3152",
url="https://www.rfc-editor.org/rfc/rfc2766.txt",
  key="RFC 2766",
  abstract={This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]},
  keywords="NAT-PT, IPv4, IPv6, internet",
  doi="10.17487/RFC2766",
  }

@misc{rfc2767,
  author="K. Tsuchiya and H. Higuchi and Y. Atarashi",
  title="{Dual Stack Hosts using the ``Bump-In-the-Stack'' Technique (BIS)}",
  howpublished="RFC 2767 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2767",
  pages="1--13",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6535",
url="https://www.rfc-editor.org/rfc/rfc2767.txt",
  key="RFC 2767",
  abstract={This memo proposes a mechanism of dual stack hosts using the technique called ``Bump-in-the-Stack'' in the IP security area.  This memo provides information for the Internet community.},
  keywords="IPv4, IPv6, internet, protocol, applications",
  doi="10.17487/RFC2767",
  }

@misc{rfc2768,
  author="B. Aiken and J. Strassner and B. Carpenter and I. Foster and C. Lynch and J. Mambretti and R. Moore and B. Teitelbaum",
  title="{Network Policy and Services: A Report of a Workshop on Middleware}",
  howpublished="RFC 2768 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2768",
  pages="1--29",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2768.txt",
  key="RFC 2768",
  abstract={An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998.  The need for a more organized framework for middleware R\&D was recognized, and a list of specific topics needing further work was identified.  This memo provides information for the Internet community.},
  keywords="protocols, internet, applications",
  doi="10.17487/RFC2768",
  }

@misc{rfc2769,
  author="C. Villamizar and C. Alaettinoglu and R. Govindan and D. Meyer",
  title="{Routing Policy System Replication}",
  howpublished="RFC 2769 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2769",
  pages="1--42",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2769.txt",
  key="RFC 2769",
  abstract={This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]},
  keywords="RPSL, database, language",
  doi="10.17487/RFC2769",
  }

@misc{rfc2770,
  author="D. Meyer and P. Lothberg",
  title="{GLOP Addressing in 233/8}",
  howpublished="RFC 2770 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2770",
  pages="1--5",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3180",
url="https://www.rfc-editor.org/rfc/rfc2770.txt",
  key="RFC 2770",
  abstract={This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="multicast, allocation, global",
  doi="10.17487/RFC2770",
  }

@misc{rfc2771,
  author="R. Finlayson",
  title="{An Abstract API for Multicast Address Allocation}",
  howpublished="RFC 2771 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2771",
  pages="1--11",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2771.txt",
  key="RFC 2771",
  abstract={This document describes the ``abstract service interface'' for the dynamic multicast address allocation service, as seen by applications.  This memo provides information for the Internet community.},
  keywords="application, programming, interfaces, service",
  doi="10.17487/RFC2771",
  }

@misc{rfc2772,
  author="R. Rockell and R. Fink",
  title="{6Bone Backbone Routing Guidelines}",
  howpublished="RFC 2772 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2772",
  pages="1--14",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3152",
url="https://www.rfc-editor.org/rfc/rfc2772.txt",
  key="RFC 2772",
  abstract={This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems.  This memo provides information for the Internet community.},
  keywords="IP, internet protocol, routing",
  doi="10.17487/RFC2772",
  }

@misc{rfc2773,
  author="R. Housley and P. Yee and W. Nace",
  title="{Encryption using KEA and SKIPJACK}",
  howpublished="RFC 2773 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2773",
  pages="1--9",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2773.txt",
  key="RFC 2773",
  abstract={This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, ``File Transfer Protocol (FTP)'', (October},
  keywords="key exchange algorithm, symmetric",
  doi="10.17487/RFC2773",
  }

@misc{rfc2774,
  author="H. Nielsen and P. Leach and S. Lawrence",
  title="{An HTTP Extension Framework}",
  howpublished="RFC 2774 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2774",
  pages="1--20",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2774.txt",
  key="RFC 2774",
  abstract={This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hyper-text, transfer, protocol",
  doi="10.17487/RFC2774",
  }

@misc{rfc2775,
  author="B. Carpenter",
  title="{Internet Transparency}",
  howpublished="RFC 2775 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2775",
  pages="1--18",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2775.txt",
  key="RFC 2775",
  abstract={This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.},
  keywords="end-to-end, network layer, connectivity",
  doi="10.17487/RFC2775",
  }

@misc{rfc2776,
  author="M. Handley and D. Thaler and R. Kermode",
  title="{Multicast-Scope Zone Announcement Protocol (MZAP)}",
  howpublished="RFC 2776 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2776",
  pages="1--27",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2776.txt",
  key="RFC 2776",
  abstract={This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]},
  keywords="MZAP, packets, addresses, service, location",
  doi="10.17487/RFC2776",
  }

@misc{rfc2777,
  author="D. {Eastlake 3rd}",
  title="{Publicly Verifiable Nomcom Random Selection}",
  howpublished="RFC 2777 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2777",
  pages="1--16",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3797",
url="https://www.rfc-editor.org/rfc/rfc2777.txt",
  key="RFC 2777",
  abstract={This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.  This memo provides information for the Internet community.},
  keywords="Internet, Engineering, Task Force, IETF",
  doi="10.17487/RFC2777",
  }

@misc{rfc2778,
  author="M. Day and J. Rosenberg and H. Sugano",
  title="{A Model for Presence and Instant Messaging}",
  howpublished="RFC 2778 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2778",
  pages="1--17",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2778.txt",
  key="RFC 2778",
  abstract={This document defines an abstract model for a presence and instant messaging system.  It defines the various entities involved, defines terminology, and outlines the services provided by the system.  This memo provides information for the Internet community.},
  keywords="service users, MIME, multipurpose, Internet, mail, extensions",
  doi="10.17487/RFC2778",
  }

@misc{rfc2779,
  author="M. Day and S. Aggarwal and G. Mohr and J. Vincent",
  title="{Instant Messaging / Presence Protocol Requirements}",
  howpublished="RFC 2779 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2779",
  pages="1--26",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2779.txt",
  key="RFC 2779",
  abstract={This document defines a minimal set of requirements that IMPP must meet.  This memo provides information for the Internet community.},
  keywords="MIME, multipurpose, Internet, mail extensions, service, users",
  doi="10.17487/RFC2779",
  }

@misc{rfc2780,
  author="S. Bradner and V. Paxson",
  title="{IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers}",
  howpublished="RFC 2780 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2780",
  pages="1--10",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4443, 5237, 5771, 6335, 7045",
url="https://www.rfc-editor.org/rfc/rfc2780.txt",
  key="RFC 2780",
  abstract={This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, assigned, numbers, authority, IP",
  doi="10.17487/RFC2780",
  }

@misc{rfc2781,
  author="P. Hoffman and F. Yergeau",
  title="{UTF-16, an encoding of ISO 10646}",
  howpublished="RFC 2781 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2781",
  pages="1--14",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2781.txt",
  key="RFC 2781",
  abstract={This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16.  This memo provides information for the Internet community.},
  keywords="unicode, character, data, code, point",
  doi="10.17487/RFC2781",
  }

@misc{rfc2782,
  author="A. Gulbrandsen and P. Vixie and L. Esibov",
  title="{A DNS RR for specifying the location of services (DNS SRV)}",
  howpublished="RFC 2782 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2782",
  pages="1--12",
  year=2000,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6335",
url="https://www.rfc-editor.org/rfc/rfc2782.txt",
  key="RFC 2782",
  abstract={This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]},
  keywords="DNS-SRV, domain, name, system, resource, record",
  doi="10.17487/RFC2782",
  }

@misc{rfc2783,
  author="J. Mogul and D. Mills and J. Brittenson and J. Stone and U. Windl",
  title="{Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0}",
  howpublished="RFC 2783 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2783",
  pages="1--31",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2783.txt",
  key="RFC 2783",
  abstract={RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources.  This document specifies such an API.  This memo provides information for the Internet community.},
  keywords="NTP, time, clock, synchronization",
  doi="10.17487/RFC2783",
  }

@misc{rfc2784,
  author="D. Farinacci and T. Li and S. Hanks and D. Meyer and P. Traina",
  title="{Generic Routing Encapsulation (GRE)}",
  howpublished="RFC 2784 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2784",
  pages="1--9",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 2890",
url="https://www.rfc-editor.org/rfc/rfc2784.txt",
  key="RFC 2784",
  abstract={This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]},
  keywords="GRE, packet, size, payload",
  doi="10.17487/RFC2784",
  }

@misc{rfc2785,
  author="R. Zuccherato",
  title="{Methods for Avoiding the ``Small-Subgroup'' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME}",
  howpublished="RFC 2785 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2785",
  pages="1--11",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2785.txt",
  key="RFC 2785",
  abstract={This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.  This memo provides information for the Internet community.},
  keywords="security, multipurpose, internet, mail extensions",
  doi="10.17487/RFC2785",
  }

@misc{rfc2786,
  author="M. St. Johns",
  title="{Diffie-Helman USM Key Management Information Base and Textual Convention}",
  howpublished="RFC 2786 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2786",
  pages="1--20",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2786.txt",
  key="RFC 2786",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community.  In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mib, security, user-based, model, Hellman",
  doi="10.17487/RFC2786",
  }

@misc{rfc2787,
  author="B. Jewell and D. Chuang",
  title="{Definitions of Managed Objects for the Virtual Router Redundancy Protocol}",
  howpublished="RFC 2787 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2787",
  pages="1--31",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6527",
url="https://www.rfc-editor.org/rfc/rfc2787.txt",
  key="RFC 2787",
  abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2787",
  }

@misc{rfc2788,
  author="N. Freed and S. Kille",
  title="{Network Services Monitoring MIB}",
  howpublished="RFC 2788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2788",
  pages="1--22",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2788.txt",
  key="RFC 2788",
  abstract={This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2788",
  }

@misc{rfc2789,
  author="N. Freed and S. Kille",
  title="{Mail Monitoring MIB}",
  howpublished="RFC 2789 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2789",
  pages="1--33",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2789.txt",
  key="RFC 2789",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2789",
  }

@misc{rfc2790,
  author="S. Waldbusser and P. Grillo",
  title="{Host Resources MIB}",
  howpublished="RFC 2790 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2790",
  pages="1--50",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2790.txt",
  key="RFC 2790",
  abstract={This memo obsoletes RFC 1514, the ``Host Resources MIB''.  This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2790",
  }

@misc{rfc2791,
  author="J. Yu",
  title="{Scalable Routing Design Principles}",
  howpublished="RFC 2791 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2791",
  pages="1--26",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2791.txt",
  key="RFC 2791",
  abstract={This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks.  This memo provides information for the Internet community.},
  keywords="network, packets",
  doi="10.17487/RFC2791",
  }

@misc{rfc2792,
  author="M. Blaze and J. Ioannidis and A. Keromytis",
  title="{DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System}",
  howpublished="RFC 2792 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2792",
  pages="1--7",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2792.txt",
  key="RFC 2792",
  abstract={This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system.  This memo provides information for the Internet community.},
  keywords="cryptology, digial, signatures",
  doi="10.17487/RFC2792",
  }

@misc{rfc2793,
  author="G. Hellstrom",
  title="{RTP Payload for Text Conversation}",
  howpublished="RFC 2793 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2793",
  pages="1--10",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4103",
url="https://www.rfc-editor.org/rfc/rfc2793.txt",
  key="RFC 2793",
  abstract={This memo describes how to carry text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]},
  keywords="real-time, applications, video, audio, packets",
  doi="10.17487/RFC2793",
  }

@misc{rfc2794,
  author="P. Calhoun and C. Perkins",
  title="{Mobile IP Network Access Identifier Extension for IPv4}",
  howpublished="RFC 2794 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2794",
  pages="1--9",
  year=2000,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2794.txt",
  key="RFC 2794",
  abstract={Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request.  This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]},
  keywords="internet, protocol, NAI",
  doi="10.17487/RFC2794",
  }

@misc{rfc2795,
  author="S. Christey",
  title="{The Infinite Monkey Protocol Suite (IMPS)}",
  howpublished="RFC 2795 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2795",
  pages="1--20",
  year=2000,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2795.txt",
  key="RFC 2795",
  abstract={This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show.  This memo provides information for the Internet community.},
  keywords="control, packet, client",
  doi="10.17487/RFC2795",
  }

@misc{rfc2796,
  author="T. Bates and R. Chandra and E. Chen",
  title="{BGP Route Reflection - An Alternative to Full Mesh IBGP}",
  howpublished="RFC 2796 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2796",
  pages="1--11",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4456",
url="https://www.rfc-editor.org/rfc/rfc2796.txt",
  key="RFC 2796",
  abstract={This document describes the use and design of a method known as ``Route Reflection'' to alleviate the the need for ``full mesh'' IBGP. [STANDARDS-TRACK]},
  keywords="border, gateway, protocol",
  doi="10.17487/RFC2796",
  }

@misc{rfc2797,
  author="M. Myers and X. Liu and J. Schaad and J. Weinstein",
  title="{Certificate Management Messages over CMS}",
  howpublished="RFC 2797 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2797",
  pages="1--47",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5272",
url="https://www.rfc-editor.org/rfc/rfc2797.txt",
  key="RFC 2797",
  abstract={This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]},
  keywords="certificate, management, protocol, cryptology, syntax",
  doi="10.17487/RFC2797",
  }

@misc{rfc2798,
  author="M. Smith",
  title="{Definition of the inetOrgPerson LDAP Object Class}",
  howpublished="RFC 2798 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2798",
  pages="1--20",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3698, 4519, 4524",
url="https://www.rfc-editor.org/rfc/rfc2798.txt",
  key="RFC 2798",
  abstract={We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol, directory services",
  doi="10.17487/RFC2798",
  }

@misc{rfc2799,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 2700-2799}",
  howpublished="RFC 2799 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2799",
  pages="1--23",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2799.txt",
  key="RFC 2799",
  doi="10.17487/RFC2799",
  }

@misc{rfc2800,
  author="J. Reynolds and R. Braden and S. Ginoza",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2800 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2800",
  pages="1--38",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 2900",
url="https://www.rfc-editor.org/rfc/rfc2800.txt",
  key="RFC 2800",
  abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001.  It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]},
  doi="10.17487/RFC2800",
  }

@misc{rfc2801,
  author="D. Burdett",
  title="{Internet Open Trading Protocol - IOTP Version 1.0}",
  howpublished="RFC 2801 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2801",
  pages="1--290",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2801.txt",
  key="RFC 2801",
  abstract={This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce.  This memo provides information for the Internet community.},
  keywords="commerce, payment, system, merchant",
  doi="10.17487/RFC2801",
  }

@misc{rfc2802,
  author="K. Davidson and Y. Kawatsura",
  title="{Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)}",
  howpublished="RFC 2802 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2802",
  pages="1--29",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2802.txt",
  key="RFC 2802",
  abstract={This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP).  This memo provides information for the Internet community.},
  keywords="commerce, payment system, xml, extensible, markup, language, security",
  doi="10.17487/RFC2802",
  }

@misc{rfc2803,
  author="H. Maruyama and K. Tamura and N. Uramoto",
  title="{Digest Values for DOM (DOMHASH)}",
  howpublished="RFC 2803 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2803",
  pages="1--11",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2803.txt",
  key="RFC 2803",
  abstract={This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML.  This memo provides information for the Internet community.},
  keywords="xml, extensible, markup, language, secruity",
  doi="10.17487/RFC2803",
  }

@misc{rfc2804,
  author="IAB and IESG",
  title="{IETF Policy on Wiretapping}",
  howpublished="RFC 2804 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2804",
  pages="1--10",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2804.txt",
  key="RFC 2804",
  abstract={This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping.  This memo explains what the IETF thinks the question means, why its answer is ``no'', and what that answer means.  This memo provides information for the Internet community.},
  keywords="internet, engineering, task force",
  doi="10.17487/RFC2804",
  }

@misc{rfc2805,
  author="N. Greene and M. Ramalho and B. Rosen",
  title="{Media Gateway Control Protocol Architecture and Requirements}",
  howpublished="RFC 2805 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2805",
  pages="1--45",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2805.txt",
  key="RFC 2805",
  abstract={This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway.  This memo provides information for the Internet community.},
  keywords="MG, mapping, transcoding, network",
  doi="10.17487/RFC2805",
  }

@misc{rfc2806,
  author="A. Vaha-Sipila",
  title="{URLs for Telephone Calls}",
  howpublished="RFC 2806 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2806",
  pages="1--21",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3966",
url="https://www.rfc-editor.org/rfc/rfc2806.txt",
  key="RFC 2806",
  abstract={This document specifies URL (Uniform Resource Locator) schemes ``tel'', ``fax'' and ``modem'' for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]},
  keywords="uniform, resource, locator, schemes",
  doi="10.17487/RFC2806",
  }

@misc{rfc2807,
  author="J. Reagle",
  title="{XML Signature Requirements}",
  howpublished="RFC 2807 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2807",
  pages="1--9",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2807.txt",
  key="RFC 2807",
  abstract={This document lists the design principles, scope, and requirements for the XML Digital Signature specification.  It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.  This memo provides information for the Internet community.},
  keywords="digital, extensible, markup, language",
  doi="10.17487/RFC2807",
  }

@misc{rfc2808,
  author="M. Nystrom",
  title="{The SecurID(r) SASL Mechanism}",
  howpublished="RFC 2808 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2808",
  pages="1--11",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2808.txt",
  key="RFC 2808",
  abstract={This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments.  This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.  This memo provides information for the Internet community.},
  keywords="simple, authentication, security, layer",
  doi="10.17487/RFC2808",
  }

@misc{rfc2809,
  author="B. Aboba and G. Zorn",
  title="{Implementation of L2TP Compulsory Tunneling via RADIUS}",
  howpublished="RFC 2809 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2809",
  pages="1--23",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2809.txt",
  key="RFC 2809",
  abstract={This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol.  This memo provides information for the Internet community.},
  keywords="remote, authentication, dial-in, user, service, layer, two",
  doi="10.17487/RFC2809",
  }

@misc{rfc2810,
  author="C. Kalt",
  title="{Internet Relay Chat: Architecture}",
  howpublished="RFC 2810 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2810",
  pages="1--10",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2810.txt",
  key="RFC 2810",
  abstract={This document is an update describing the architecture of the current IRC protocol and the role of its different components.  Other documents describe in detail the protocol used between the various components defined here.  This memo provides information for the Internet community.},
  keywords="IRC, text based, conferencing",
  doi="10.17487/RFC2810",
  }

@misc{rfc2811,
  author="C. Kalt",
  title="{Internet Relay Chat: Channel Management}",
  howpublished="RFC 2811 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2811",
  pages="1--19",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2811.txt",
  key="RFC 2811",
  abstract={This document specifies how channels, their characteristics and properties are managed by IRC servers.  This memo provides information for the Internet community.},
  keywords="IRC, text based, conferencing",
  doi="10.17487/RFC2811",
  }

@misc{rfc2812,
  author="C. Kalt",
  title="{Internet Relay Chat: Client Protocol}",
  howpublished="RFC 2812 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2812",
  pages="1--63",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2812.txt",
  key="RFC 2812",
  abstract={This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture.  This memo provides information for the Internet community.},
  keywords="IRC, text based, conferencing",
  doi="10.17487/RFC2812",
  }

@misc{rfc2813,
  author="C. Kalt",
  title="{Internet Relay Chat: Server Protocol}",
  howpublished="RFC 2813 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2813",
  pages="1--26",
  year=2000,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2813.txt",
  key="RFC 2813",
  abstract={This document defines the protocol used by servers to talk to each other.  This memo provides information for the Internet community.},
  keywords="IRC, text based, conferencing",
  doi="10.17487/RFC2813",
  }

@misc{rfc2814,
  author="R. Yavatkar and D. Hoffman and Y. Bernet and F. Baker and M. Speer",
  title="{SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks}",
  howpublished="RFC 2814 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2814",
  pages="1--60",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2814.txt",
  key="RFC 2814",
  abstract={This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]},
  keywords="LAN, local area, resource, reservation",
  doi="10.17487/RFC2814",
  }

@misc{rfc2815,
  author="M. Seaman and A. Smith and E. Crawley and J. Wroclawski",
  title="{Integrated Service Mappings on IEEE 802 Networks}",
  howpublished="RFC 2815 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2815",
  pages="1--17",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2815.txt",
  key="RFC 2815",
  abstract={This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]},
  keywords="LAN, local area, resource, reservation",
  doi="10.17487/RFC2815",
  }

@misc{rfc2816,
  author="A. Ghanwani and J. Pace and V. Srinivasan and A. Smith and M. Seaman",
  title="{A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies}",
  howpublished="RFC 2816 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2816",
  pages="1--47",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2816.txt",
  key="RFC 2816",
  abstract={This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure.  This memo provides information for the Internet community.},
  keywords="LAN, local area, network, parameter, switches",
  doi="10.17487/RFC2816",
  }

@misc{rfc2817,
  author="R. Khare and S. Lawrence",
  title="{Upgrading to TLS Within HTTP/1.1}",
  howpublished="RFC 2817 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2817",
  pages="1--13",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7230, 7231",
url="https://www.rfc-editor.org/rfc/rfc2817.txt",
  key="RFC 2817",
  abstract={This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]},
  keywords="hypertext, transfer, protocol, transport, layer, security",
  doi="10.17487/RFC2817",
  }

@misc{rfc2818,
  author="E. Rescorla",
  title="{HTTP Over TLS}",
  howpublished="RFC 2818 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2818",
  pages="1--7",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5785, 7230",
url="https://www.rfc-editor.org/rfc/rfc2818.txt",
  key="RFC 2818",
  abstract={This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.},
  keywords="hypertext, transfer, protocol, transport, layer, security",
  doi="10.17487/RFC2818",
  }

@misc{rfc2819,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base}",
  howpublished="RFC 2819 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2819",
  pages="1--98",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2819.txt",
  key="RFC 2819",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]},
  keywords="RMON-MIB, MIB, RMON",
  doi="10.17487/RFC2819",
  }

@misc{rfc2820,
  author="E. Stokes and D. Byrne and B. Blakley and P. Behera",
  title="{Access Control Requirements for LDAP}",
  howpublished="RFC 2820 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2820",
  pages="1--9",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2820.txt",
  key="RFC 2820",
  abstract={This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC2820",
  }

@misc{rfc2821,
  author="J. Klensin",
  title="{Simple Mail Transfer Protocol}",
  howpublished="RFC 2821 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2821",
  pages="1--79",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5321, updated by RFC 5336",
url="https://www.rfc-editor.org/rfc/rfc2821.txt",
  key="RFC 2821",
  abstract={This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]},
  keywords="SMTP",
  doi="10.17487/RFC2821",
  }

@misc{rfc2822,
  author="P. Resnick",
  title="{Internet Message Format}",
  howpublished="RFC 2822 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2822",
  pages="1--51",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5322, updated by RFCs 5335, 5336",
url="https://www.rfc-editor.org/rfc/rfc2822.txt",
  key="RFC 2822",
  abstract={This document specifies a syntax for text messages that are sent between computer users, within the framework of ``electronic mail'' messages. [STANDARDS-TRACK]},
  keywords="MAIL",
  doi="10.17487/RFC2822",
  }

@misc{rfc2823,
  author="J. Carlson and P. Langner and E. Hernandez-Valencia and J. Manchester",
  title="{PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing}",
  howpublished="RFC 2823 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2823",
  pages="1--28",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2823.txt",
  key="RFC 2823",
  abstract={This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL).  SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.  SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="PPP-SDL, point-to-point, protocol, synchronous, optical, network, digital, hierarchy, data link, simple",
  doi="10.17487/RFC2823",
  }

@misc{rfc2824,
  author="J. Lennox and H. Schulzrinne",
  title="{Call Processing Language Framework and Requirements}",
  howpublished="RFC 2824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2824",
  pages="1--25",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2824.txt",
  key="RFC 2824",
  abstract={This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony.  A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete.  It also outlines requirements for such a language.  This memo provides information for the Internet community.},
  keywords="CPL-F, telephony, signalling, network, devices",
  doi="10.17487/RFC2824",
  }

@misc{rfc2825,
  author="IAB and L. Daigle",
  title="{A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols}",
  howpublished="RFC 2825 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2825",
  pages="1--7",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2825.txt",
  key="RFC 2825",
  abstract={This document is a statement by the Internet Architecture Board.  It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.  This memo provides information for the Internet community.},
  keywords="character sets, e-commerce, interoperability",
  doi="10.17487/RFC2825",
  }

@misc{rfc2826,
  author="Internet Architecture Board",
  title="{IAB Technical Comment on the Unique DNS Root}",
  howpublished="RFC 2826 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2826",
  pages="1--6",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2826.txt",
  key="RFC 2826",
  abstract={This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System).  This name space is a hierarchical name space derived from a single, globally unique root.  It is a technical constraint inherent in the design of the DNS.  One root must be supported by a set of coordinated root servers administered by a unique naming authority.  It is not technically feasible for there to be more than one root in the public DNS.  This memo provides information for the Internet community.},
  keywords="Internet Architecture Board, domain name, system",
  doi="10.17487/RFC2826",
  }

@misc{rfc2827,
  author="P. Ferguson and D. Senie",
  title="{Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing}",
  howpublished="RFC 2827 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2827",
  pages="1--10",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3704",
url="https://www.rfc-editor.org/rfc/rfc2827.txt",
  key="RFC 2827",
  abstract={This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ISP, Internet, Service, Provider, Internet, Protocol, DOS",
  doi="10.17487/RFC2827",
  }

@misc{rfc2828,
  author="R. Shirey",
  title="{Internet Security Glossary}",
  howpublished="RFC 2828 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2828",
  pages="1--212",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4949",
url="https://www.rfc-editor.org/rfc/rfc2828.txt",
  key="RFC 2828",
  abstract={This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology.  This memo provides information for the Internet community.},
  keywords="information, system, ISD, internet, standard documents",
  doi="10.17487/RFC2828",
  }

@misc{rfc2829,
  author="M. Wahl and H. Alvestrand and J. Hodges and R. Morgan",
  title="{Authentication Methods for LDAP}",
  howpublished="RFC 2829 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2829",
  pages="1--16",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4513, 4510, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2829.txt",
  key="RFC 2829",
  abstract={This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, security",
  doi="10.17487/RFC2829",
  }

@misc{rfc2830,
  author="J. Hodges and R. Morgan and M. Wahl",
  title="{Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security}",
  howpublished="RFC 2830 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2830",
  pages="1--12",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4511, 4513, 4510, updated by RFC 3377",
url="https://www.rfc-editor.org/rfc/rfc2830.txt",
  key="RFC 2830",
  abstract={This document defines the ``Start Transport Layer Security (TLS) Operation'' for LDAP. [STANDARDS-TRACK]},
  keywords="LDAP, TLS",
  doi="10.17487/RFC2830",
  }

@misc{rfc2831,
  author="P. Leach and C. Newman",
  title="{Using Digest Authentication as a SASL Mechanism}",
  howpublished="RFC 2831 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2831",
  pages="1--27",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6331",
url="https://www.rfc-editor.org/rfc/rfc2831.txt",
  key="RFC 2831",
  abstract={This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]},
  keywords="http, hypertext, transfer, protocol, security, simple, layer",
  doi="10.17487/RFC2831",
  }

@misc{rfc2832,
  author="S. Hollenbeck and M. Srivastava",
  title="{NSI Registry Registrar Protocol (RRP) Version 1.1.0}",
  howpublished="RFC 2832 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2832",
  pages="1--39",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3632",
url="https://www.rfc-editor.org/rfc/rfc2832.txt",
  key="RFC 2832",
  abstract={This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs).  This memo provides information for the Internet community.},
  keywords="RRP, shared, registration, system, gLTD, ccTLD, top level domain",
  doi="10.17487/RFC2832",
  }

@misc{rfc2833,
  author="H. Schulzrinne and S. Petrack",
  title="{RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals}",
  howpublished="RFC 2833 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2833",
  pages="1--30",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4733, 4734",
url="https://www.rfc-editor.org/rfc/rfc2833.txt",
  key="RFC 2833",
  abstract={This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]},
  keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency",
  doi="10.17487/RFC2833",
  }

@misc{rfc2834,
  author="J.-M. Pittet",
  title="{ARP and IP Broadcast over HIPPI-800}",
  howpublished="RFC 2834 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2834",
  pages="1--34",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc2834.txt",
  key="RFC 2834",
  abstract={This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses).  This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN).  This document (when combined with RFC 2067 ``IP over HIPPI'') obsoletes RFC 1374. [STANDARDS-TRACK]},
  keywords="address resolution, protocol, internet, high-performance, internface, parallel",
  doi="10.17487/RFC2834",
  }

@misc{rfc2835,
  author="J.-M. Pittet",
  title="{IP and ARP over HIPPI-6400 (GSN)}",
  howpublished="RFC 2835 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2835",
  pages="1--33",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc2835.txt",
  key="RFC 2835",
  abstract={This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP.  Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]},
  keywords="GSN, address resolution, protocol, internet, high-performance, internface, parallel",
  doi="10.17487/RFC2835",
  }

@misc{rfc2836,
  author="S. Brim and B. Carpenter and F. Le Faucheur",
  title="{Per Hop Behavior Identification Codes}",
  howpublished="RFC 2836 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2836",
  pages="1--7",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3140",
url="https://www.rfc-editor.org/rfc/rfc2836.txt",
  key="RFC 2836",
  abstract={This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]},
  keywords="PHB, differentiated, services, codepoint, DSCP",
  doi="10.17487/RFC2836",
  }

@misc{rfc2837,
  author="K. Teow",
  title="{Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard}",
  howpublished="RFC 2837 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2837",
  pages="1--48",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4044",
url="https://www.rfc-editor.org/rfc/rfc2837.txt",
  key="RFC 2837",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base",
  doi="10.17487/RFC2837",
  }

@misc{rfc2838,
  author="D. Zigmond and M. Vickers",
  title="{Uniform Resource Identifiers for Television Broadcasts}",
  howpublished="RFC 2838 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2838",
  pages="1--6",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2838.txt",
  key="RFC 2838",
  abstract={This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable.  In this context there is a need to reference television broadcasts using the URI format described in RFC 2396.  This memo provides information for the Internet community.},
  keywords="URI, TV, WWW, world wide web",
  doi="10.17487/RFC2838",
  }

@misc{rfc2839,
  author="F. da Cruz and J. Altman",
  title="{Internet Kermit Service}",
  howpublished="RFC 2839 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2839",
  pages="1--20",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2839.txt",
  key="RFC 2839",
  abstract={This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management.  This memo provides information for the Internet community.},
  keywords="file, transfer, management, service",
  doi="10.17487/RFC2839",
  }

@misc{rfc2840,
  author="J. Altman and F. da Cruz",
  title="{TELNET KERMIT OPTION}",
  howpublished="RFC 2840 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2840",
  pages="1--12",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2840.txt",
  key="RFC 2840",
  abstract={This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection.  This memo provides information for the Internet community.},
  keywords="file transfer, management, service",
  doi="10.17487/RFC2840",
  }

@misc{rfc2841,
  author="P. Metzger and W. Simpson",
  title="{IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)}",
  howpublished="RFC 2841 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2841",
  pages="1--9",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2841.txt",
  key="RFC 2841",
  abstract={This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header.  This memo defines a Historic Document for the Internet community.},
  keywords="IP-MAC, encryption, secure, hash, algorithm",
  doi="10.17487/RFC2841",
  }

@misc{rfc2842,
  author="R. Chandra and J. Scudder",
  title="{Capabilities Advertisement with BGP-4}",
  howpublished="RFC 2842 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2842",
  pages="1--5",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3392",
url="https://www.rfc-editor.org/rfc/rfc2842.txt",
  key="RFC 2842",
  abstract={This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]},
  keywords="border, gateway, protocol",
  doi="10.17487/RFC2842",
  }

@misc{rfc2843,
  author="P. Droz and T. Przygienda",
  title="{Proxy-PAR}",
  howpublished="RFC 2843 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2843",
  pages="1--13",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2843.txt",
  key="RFC 2843",
  abstract={The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]},
  keywords="PNNI augmented Routing, ATM, asynchronous, transfer mode",
  doi="10.17487/RFC2843",
  }

@misc{rfc2844,
  author="T. Przygienda and P. Droz and R. Haas",
  title="{OSPF over ATM and Proxy-PAR}",
  howpublished="RFC 2844 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2844",
  pages="1--14",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2844.txt",
  key="RFC 2844",
  abstract={This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="PNNI augmented Routing, asynchronous transfer mode, open shortest-path first",
  doi="10.17487/RFC2844",
  }

@misc{rfc2845,
  author="P. Vixie and O. Gudmundsson and D. {Eastlake 3rd} and B. Wellington",
  title="{Secret Key Transaction Authentication for DNS (TSIG)}",
  howpublished="RFC 2845 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2845",
  pages="1--15",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3645, 4635, 6895",
url="https://www.rfc-editor.org/rfc/rfc2845.txt",
  key="RFC 2845",
  abstract={This protocol allows for transaction level authentication using shared secrets and one way hashing.  It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]},
  keywords="TSIG, domain, name, system, transaction, signature",
  doi="10.17487/RFC2845",
  }

@misc{rfc2846,
  author="C. Allocchio",
  title="{GSTN Address Element Extensions in E-mail Services}",
  howpublished="RFC 2846 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2846",
  pages="1--35",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3191, 3192",
url="https://www.rfc-editor.org/rfc/rfc2846.txt",
  key="RFC 2846",
  abstract={This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]},
  keywords="global, switched, telephone, network",
  doi="10.17487/RFC2846",
  }

@misc{rfc2847,
  author="M. Eisler",
  title="{LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM}",
  howpublished="RFC 2847 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2847",
  pages="1--22",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2847.txt",
  key="RFC 2847",
  abstract={This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]},
  keywords="LIPKEY, client, server, simple pubilc, key mechanism, authentication",
  doi="10.17487/RFC2847",
  }

@misc{rfc2848,
  author="S. Petrack and L. Conroy",
  title="{The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services}",
  howpublished="RFC 2848 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2848",
  pages="1--73",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2848.txt",
  key="RFC 2848",
  abstract={This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]},
  keywords="session, initiation, protocol, internet, description",
  doi="10.17487/RFC2848",
  }

@misc{rfc2849,
  author="G. Good",
  title="{The LDAP Data Interchange Format (LDIF) - Technical Specification}",
  howpublished="RFC 2849 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2849",
  pages="1--14",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2849.txt",
  key="RFC 2849",
  abstract={This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]},
  keywords="LDIF, lightweight, directory, access, protocol file",
  doi="10.17487/RFC2849",
  }

@misc{rfc2850,
  author="Internet Architecture Board and B. Carpenter",
  title="{Charter of the Internet Architecture Board (IAB)}",
  howpublished="RFC 2850 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2850",
  pages="1--8",
  year=2000,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2850.txt",
  key="RFC 2850",
  abstract={This memo documents the composition, selection, roles, and organization of the Internet Architecture Board.  It replaces RFC 1601.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ISOC, Internet Society, IETF, IRTF",
  doi="10.17487/RFC2850",
  }

@misc{rfc2851,
  author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder",
  title="{Textual Conventions for Internet Network Addresses}",
  howpublished="RFC 2851 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2851",
  pages="1--16",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3291",
url="https://www.rfc-editor.org/rfc/rfc2851.txt",
  key="RFC 2851",
  abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]},
  keywords="layer, management, information, base, inet, address mib",
  doi="10.17487/RFC2851",
  }

@misc{rfc2852,
  author="D. Newman",
  title="{Deliver By SMTP Service Extension}",
  howpublished="RFC 2852 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2852",
  pages="1--13",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2852.txt",
  key="RFC 2852",
  abstract={This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]},
  keywords="simple, mail transfer, protocol, client server",
  doi="10.17487/RFC2852",
  }

@misc{rfc2853,
  author="J. Kabat and M. Upadhyay",
  title="{Generic Security Service API Version 2 : Java Bindings}",
  howpublished="RFC 2853 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2853",
  pages="1--96",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5653",
url="https://www.rfc-editor.org/rfc/rfc2853.txt",
  key="RFC 2853",
  abstract={This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]},
  keywords="GSI, application program, interface",
  doi="10.17487/RFC2853",
  }

@misc{rfc2854,
  author="D. Connolly and L. Masinter",
  title="{The 'text/html' Media Type}",
  howpublished="RFC 2854 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2854",
  pages="1--8",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2854.txt",
  key="RFC 2854",
  abstract={This document summarizes the history of HTML development, and defines the ``text/html'' MIME type by pointing to the relevant W3C recommendations.  This memo provides information for the Internet community.},
  keywords="HTML-INT, HTML, WWW, World, Wide, Web",
  doi="10.17487/RFC2854",
  }

@misc{rfc2855,
  author="K. Fujisawa",
  title="{DHCP for IEEE 1394}",
  howpublished="RFC 2855 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2855",
  pages="1--5",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2855.txt",
  key="RFC 2855",
  abstract={This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages.  IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.  Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol, high performance, serial bus",
  doi="10.17487/RFC2855",
  }

@misc{rfc2856,
  author="A. Bierman and K. McCloghrie and R. Presuhn",
  title="{Textual Conventions for Additional High Capacity Data Types}",
  howpublished="RFC 2856 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2856",
  pages="1--10",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2856.txt",
  key="RFC 2856",
  abstract={This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]},
  keywords="SNMP, simple, network, management, protocol",
  doi="10.17487/RFC2856",
  }

@misc{rfc2857,
  author="A. Keromytis and N. Provos",
  title="{The Use of HMAC-RIPEMD-160-96 within ESP and AH}",
  howpublished="RFC 2857 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2857",
  pages="1--7",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2857.txt",
  key="RFC 2857",
  abstract={This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]},
  keywords="ipsec, encapsulating, security, payload, authentication",
  doi="10.17487/RFC2857",
  }

@misc{rfc2858,
  author="T. Bates and Y. Rekhter and R. Chandra and D. Katz",
  title="{Multiprotocol Extensions for BGP-4}",
  howpublished="RFC 2858 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2858",
  pages="1--11",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4760",
url="https://www.rfc-editor.org/rfc/rfc2858.txt",
  key="RFC 2858",
  abstract={This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]},
  keywords="MEXT-BGP4, Border, gateway, protocol, router, network, layer",
  doi="10.17487/RFC2858",
  }

@misc{rfc2859,
  author="W. Fang and N. Seddigh and B. Nandy",
  title="{A Time Sliding Window Three Colour Marker (TSWTCM)}",
  howpublished="RFC 2859 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2859",
  pages="1--9",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2859.txt",
  key="RFC 2859",
  abstract={This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="TSWTCM, packets, traffic, stream, routers",
  doi="10.17487/RFC2859",
  }

@misc{rfc2860,
  author="B. Carpenter and F. Baker and M. Roberts",
  title="{Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority}",
  howpublished="RFC 2860 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2860",
  pages="1--7",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2860.txt",
  key="RFC 2860",
  abstract={This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000.  This memo provides information for the Internet community.},
  keywords="mou, iana, ietf, icann, engineering, task force, corporation names",
  doi="10.17487/RFC2860",
  }

@misc{rfc2861,
  author="M. Handley and J. Padhye and S. Floyd",
  title="{TCP Congestion Window Validation}",
  howpublished="RFC 2861 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2861",
  pages="1--11",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7661",
url="https://www.rfc-editor.org/rfc/rfc2861.txt",
  key="RFC 2861",
  abstract={This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="transmission, control, protocol",
  doi="10.17487/RFC2861",
  }

@misc{rfc2862,
  author="M. Civanlar and G. Cash",
  title="{RTP Payload Format for Real-Time Pointers}",
  howpublished="RFC 2862 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2862",
  pages="1--7",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2862.txt",
  key="RFC 2862",
  abstract={This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]},
  keywords="view graphs, resolution, audio, video, signals",
  doi="10.17487/RFC2862",
  }

@misc{rfc2863,
  author="K. McCloghrie and F. Kastenholz",
  title="{The Interfaces Group MIB}",
  howpublished="RFC 2863 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2863",
  pages="1--69",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2863.txt",
  key="RFC 2863",
  abstract={This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer.  It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]},
  keywords="INTERGRMIB, Management, Information, Base, Network",
  doi="10.17487/RFC2863",
  }

@misc{rfc2864,
  author="K. McCloghrie and G. Hanson",
  title="{The Inverted Stack Table Extension to the Interfaces Group MIB}",
  howpublished="RFC 2864 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2864",
  pages="1--11",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2864.txt",
  key="RFC 2864",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2864",
  }

@misc{rfc2865,
  author="C. Rigney and S. Willens and A. Rubens and W. Simpson",
  title="{Remote Authentication Dial In User Service (RADIUS)}",
  howpublished="RFC 2865 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2865",
  pages="1--76",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2868, 3575, 5080, 6929, 8044",
url="https://www.rfc-editor.org/rfc/rfc2865.txt",
  key="RFC 2865",
  abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]},
  keywords="RADIUS, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2865",
  }

@misc{rfc2866,
  author="C. Rigney",
  title="{RADIUS Accounting}",
  howpublished="RFC 2866 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2866",
  pages="1--28",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 2867, 5080, 5997",
url="https://www.rfc-editor.org/rfc/rfc2866.txt",
  key="RFC 2866",
  abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server.  This memo provides information for the Internet community.},
  keywords="RADIUS-ACC, remote, authentication, dial, in, user, service, encryption",
  doi="10.17487/RFC2866",
  }

@misc{rfc2867,
  author="G. Zorn and B. Aboba and D. Mitton",
  title="{RADIUS Accounting Modifications for Tunnel Protocol Support}",
  howpublished="RFC 2867 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2867",
  pages="1--11",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2867.txt",
  key="RFC 2867",
  abstract={This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks.  This memo provides information for the Internet community.},
  keywords="RADIUS], encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2867",
  }

@misc{rfc2868,
  author="G. Zorn and D. Leifer and A. Rubens and J. Shriver and M. Holdrege and I. Goyret",
  title="{RADIUS Attributes for Tunnel Protocol Support}",
  howpublished="RFC 2868 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2868",
  pages="1--20",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3575",
url="https://www.rfc-editor.org/rfc/rfc2868.txt",
  key="RFC 2868",
  abstract={This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks.  This memo provides information for the Internet community.},
  keywords="RADIUS, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2868",
  }

@misc{rfc2869,
  author="C. Rigney and W. Willats and P. Calhoun",
  title="{RADIUS Extensions}",
  howpublished="RFC 2869 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2869",
  pages="1--47",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3579, 5080",
url="https://www.rfc-editor.org/rfc/rfc2869.txt",
  key="RFC 2869",
  abstract={This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866.  This memo provides information for the Internet community.},
  keywords="RADIUS, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC2869",
  }

@misc{rfc2870,
  author="R. Bush and D. Karrenberg and M. Kosters and R. Plzak",
  title="{Root Name Server Operational Requirements}",
  howpublished="RFC 2870 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2870",
  pages="1--10",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7720",
url="https://www.rfc-editor.org/rfc/rfc2870.txt",
  key="RFC 2870",
  abstract={The primary focus of this document is to provide guidelines for operation of the root name servers.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="infrastructure, domain names, security",
  doi="10.17487/RFC2870",
  }

@misc{rfc2871,
  author="J. Rosenberg and H. Schulzrinne",
  title="{A Framework for Telephony Routing over IP}",
  howpublished="RFC 2871 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2871",
  pages="1--25",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2871.txt",
  key="RFC 2871",
  abstract={This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers.  This memo provides information for the Internet community.},
  keywords="internet, protocol, TRIP, gateway",
  doi="10.17487/RFC2871",
  }

@misc{rfc2872,
  author="Y. Bernet and R. Pabbati",
  title="{Application and Sub Application Identity Policy Element for Use with RSVP}",
  howpublished="RFC 2872 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2872",
  pages="1--6",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2872.txt",
  key="RFC 2872",
  abstract={RSVP signaling messages typically include policy data objects, which in turn contain policy elements.  Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow.  This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol",
  doi="10.17487/RFC2872",
  }

@misc{rfc2873,
  author="X. Xiao and A. Hannan and V. Paxson and E. Crabbe",
  title="{TCP Processing of the IPv4 Precedence Field}",
  howpublished="RFC 2873 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2873",
  pages="1--8",
  year=2000,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2873.txt",
  key="RFC 2873",
  abstract={This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]},
  keywords="transmission, control, protocol, internet",
  doi="10.17487/RFC2873",
  }

@misc{rfc2874,
  author="M. Crawford and C. Huitema",
  title="{DNS Extensions to Support IPv6 Address Aggregation and Renumbering}",
  howpublished="RFC 2874 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2874",
  pages="1--20",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3152, 3226, 3363, 3364",
url="https://www.rfc-editor.org/rfc/rfc2874.txt",
  key="RFC 2874",
  abstract={This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]},
  keywords="internet, protocol, domain, name, system",
  doi="10.17487/RFC2874",
  }

@misc{rfc2875,
  author="H. Prafullchandra and J. Schaad",
  title="{Diffie-Hellman Proof-of-Possession Algorithms}",
  howpublished="RFC 2875 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2875",
  pages="1--23",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6955",
url="https://www.rfc-editor.org/rfc/rfc2875.txt",
  key="RFC 2875",
  abstract={This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]},
  keywords="certificate, security, encryption",
  doi="10.17487/RFC2875",
  }

@misc{rfc2876,
  author="J. Pawling",
  title="{Use of the KEA and SKIPJACK Algorithms in CMS}",
  howpublished="RFC 2876 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2876",
  pages="1--13",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2876.txt",
  key="RFC 2876",
  abstract={This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types.  This memo provides information for the Internet community.},
  keywords="encryption, cryptographic, message, syntax",
  doi="10.17487/RFC2876",
  }

@misc{rfc2877,
  author="T. {Murphy Jr.} and P. Rieth and J. Stevens",
  title="{5250 Telnet Enhancements}",
  howpublished="RFC 2877 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2877",
  pages="1--36",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4777",
url="https://www.rfc-editor.org/rfc/rfc2877.txt",
  key="RFC 2877",
  abstract={This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name.  This memo provides information for the Internet community.},
  keywords="client, server, printer",
  doi="10.17487/RFC2877",
  }

@misc{rfc2878,
  author="M. Higashiyama and F. Baker",
  title="{PPP Bridging Control Protocol (BCP)}",
  howpublished="RFC 2878 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2878",
  pages="1--38",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3518",
url="https://www.rfc-editor.org/rfc/rfc2878.txt",
  key="RFC 2878",
  abstract={This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]},
  keywords="PPP-BCP, point-to-point, datagrams, network",
  doi="10.17487/RFC2878",
  }

@misc{rfc2879,
  author="G. Klyne and L. McIntyre",
  title="{Content Feature Schema for Internet Fax (V2)}",
  howpublished="RFC 2879 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2879",
  pages="1--58",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2879.txt",
  key="RFC 2879",
  abstract={This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]},
  keywords="media, features, mechanism",
  doi="10.17487/RFC2879",
  }

@misc{rfc2880,
  author="L. McIntyre and G. Klyne",
  title="{Internet Fax T.30 Feature Mapping}",
  howpublished="RFC 2880 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2880",
  pages="1--37",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2880.txt",
  key="RFC 2880",
  abstract={This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in ``Content feature schema for Internet fax''.  This memo provides information for the Internet community.},
  keywords="schema, media, tags",
  doi="10.17487/RFC2880",
  }

@misc{rfc2881,
  author="D. Mitton and M. Beadles",
  title="{Network Access Server Requirements Next Generation (NASREQNG) NAS Model}",
  howpublished="RFC 2881 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2881",
  pages="1--20",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2881.txt",
  key="RFC 2881",
  abstract={This document describes the terminology and gives a model of typical Network Access Server (NAS).  This memo provides information for the Internet community.},
  keywords="RADIUS, remote, authentication, dial-up, user service",
  doi="10.17487/RFC2881",
  }

@misc{rfc2882,
  author="D. Mitton",
  title="{Network Access Servers Requirements: Extended RADIUS Practices}",
  howpublished="RFC 2882 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2882",
  pages="1--16",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2882.txt",
  key="RFC 2882",
  abstract={This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139.  This memo provides information for the Internet community.},
  keywords="NAS, remote, authentication, dial-in, user service",
  doi="10.17487/RFC2882",
  }

@misc{rfc2883,
  author="S. Floyd and J. Mahdavi and M. Mathis and M. Podolsky",
  title="{An Extension to the Selective Acknowledgement (SACK) Option for TCP}",
  howpublished="RFC 2883 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2883",
  pages="1--17",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2883.txt",
  key="RFC 2883",
  abstract={This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]},
  keywords="SACK, transmission, control, protocol, packets, sender, receiver",
  doi="10.17487/RFC2883",
  }

@misc{rfc2884,
  author="J. Hadi Salim and U. Ahmed",
  title="{Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks}",
  howpublished="RFC 2884 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2884",
  pages="1--18",
  year=2000,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2884.txt",
  key="RFC 2884",
  abstract={This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System.  This memo provides information for the Internet community.},
  keywords="internet, protocol, end-to-end, TCP, transmission, control",
  doi="10.17487/RFC2884",
  }

@misc{rfc2885,
  author="F. Cuervo and N. Greene and C. Huitema and A. Rayhan and B. Rosen and J. Segers",
  title="{Megaco Protocol version 0.8}",
  howpublished="RFC 2885 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2885",
  pages="1--170",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3015",
url="https://www.rfc-editor.org/rfc/rfc2885.txt",
  key="RFC 2885",
  abstract={This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000.  It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]},
  keywords="H.248, media, gateway, control",
  doi="10.17487/RFC2885",
  }

@misc{rfc2886,
  author="T. Taylor",
  title="{Megaco Errata}",
  howpublished="RFC 2886 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2886",
  pages="1--21",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3015",
url="https://www.rfc-editor.org/rfc/rfc2886.txt",
  key="RFC 2886",
  abstract={This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]},
  keywords="H.248, media, gateway, control",
  doi="10.17487/RFC2886",
  }

@misc{rfc2887,
  author="M. Handley and S. Floyd and B. Whetten and R. Kermode and L. Vicisano and M. Luby",
  title="{The Reliable Multicast Design Space for Bulk Data Transfer}",
  howpublished="RFC 2887 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2887",
  pages="1--22",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2887.txt",
  key="RFC 2887",
  abstract={This document provides an overview of the design space and the ways in which application constraints affect possible solutions.  This memo provides information for the Internet community.},
  keywords="application, RM, congestion, control, data",
  doi="10.17487/RFC2887",
  }

@misc{rfc2888,
  author="P. Srisuresh",
  title="{Secure Remote Access with L2TP}",
  howpublished="RFC 2888 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2888",
  pages="1--19",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2888.txt",
  key="RFC 2888",
  abstract={The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet.  This memo provides information for the Internet community.},
  keywords="layer two, tunneling, protocol",
  doi="10.17487/RFC2888",
  }

@misc{rfc2889,
  author="R. Mandeville and J. Perser",
  title="{Benchmarking Methodology for LAN Switching Devices}",
  howpublished="RFC 2889 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2889",
  pages="1--35",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2889.txt",
  key="RFC 2889",
  abstract={This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices.  This memo provides information for the Internet community.},
  keywords="local, area, network, MAC, medium, access, control",
  doi="10.17487/RFC2889",
  }

@misc{rfc2890,
  author="G. Dommety",
  title="{Key and Sequence Number Extensions to GRE}",
  howpublished="RFC 2890 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2890",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2890.txt",
  key="RFC 2890",
  abstract={This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]},
  keywords="generic, routing, encapsulation",
  doi="10.17487/RFC2890",
  }

@misc{rfc2891,
  author="T. Howes and M. Wahl and A. Anantha",
  title="{LDAP Control Extension for Server Side Sorting of Search Results}",
  howpublished="RFC 2891 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2891",
  pages="1--8",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2891.txt",
  key="RFC 2891",
  abstract={This document describes two LDAPv3 control extensions for server side sorting of search results.  These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC2891",
  }

@misc{rfc2892,
  author="D. Tsiang and G. Suwala",
  title="{The Cisco SRP MAC Layer Protocol}",
  howpublished="RFC 2892 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2892",
  pages="1--52",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2892.txt",
  key="RFC 2892",
  abstract={This document specifies the MAC layer protocol, ``Spatial Reuse Protocol'' (SRP) for use with ring based media.  This is a second version of the protocol (V2).  This memo provides information for the Internet community.},
  keywords="spatial, reuse",
  doi="10.17487/RFC2892",
  }

@misc{rfc2893,
  author="R. Gilligan and E. Nordmark",
  title="{Transition Mechanisms for IPv6 Hosts and Routers}",
  howpublished="RFC 2893 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2893",
  pages="1--29",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4213",
url="https://www.rfc-editor.org/rfc/rfc2893.txt",
  key="RFC 2893",
  abstract={This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]},
  keywords="TRANS-IPV6, IPv4",
  doi="10.17487/RFC2893",
  }

@misc{rfc2894,
  author="M. Crawford",
  title="{Router Renumbering for IPv6}",
  howpublished="RFC 2894 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2894",
  pages="1--32",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2894.txt",
  key="RFC 2894",
  abstract={This document defines a mechanism called Router Renumbering (``RR'') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]},
  keywords="internet, protocol, operations, scalability, applicability",
  doi="10.17487/RFC2894",
  }

@misc{rfc2895,
  author="A. Bierman and C. Bucci and R. Iddon",
  title="{Remote Network Monitoring MIB Protocol Identifier Reference}",
  howpublished="RFC 2895 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2895",
  pages="1--42",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3395",
url="https://www.rfc-editor.org/rfc/rfc2895.txt",
  key="RFC 2895",
  abstract={This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]},
  keywords="RMON-MIB, management, information, base",
  doi="10.17487/RFC2895",
  }

@misc{rfc2896,
  author="A. Bierman and C. Bucci and R. Iddon",
  title="{Remote Network Monitoring MIB Protocol Identifier Macros}",
  howpublished="RFC 2896 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2896",
  pages="1--84",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2896.txt",
  key="RFC 2896",
  abstract={This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference.  This memo provides information for the Internet community.},
  keywords="RMON, management, information, base",
  doi="10.17487/RFC2896",
  }

@misc{rfc2897,
  author="D. Cromwell",
  title="{Proposal for an MGCP Advanced Audio Package}",
  howpublished="RFC 2897 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2897",
  pages="1--34",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2897.txt",
  key="RFC 2897",
  abstract={This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server.  This memo provides information for the Internet community.},
  keywords="media, gateway, control, protocol, IVR, interactive, voice, response",
  doi="10.17487/RFC2897",
  }

@misc{rfc2898,
  author="B. Kaliski",
  title="{PKCS \#5: Password-Based Cryptography Specification Version 2.0}",
  howpublished="RFC 2898 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2898",
  pages="1--34",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8018",
url="https://www.rfc-editor.org/rfc/rfc2898.txt",
  key="RFC 2898",
  abstract={This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.  This memo provides information for the Internet community.},
  keywords="public-key, authentication, encryption",
  doi="10.17487/RFC2898",
  }

@misc{rfc2899,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 2800-2899}",
  howpublished="RFC 2899 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2899",
  pages="1--22",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2899.txt",
  key="RFC 2899",
  doi="10.17487/RFC2899",
  }

@misc{rfc2900,
  author="J. Reynolds and R. Braden and S. Ginoza",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 2900 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2900",
  pages="1--42",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3000",
url="https://www.rfc-editor.org/rfc/rfc2900.txt",
  key="RFC 2900",
  abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001.  It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series.  This memo is an Internet Standard.},
  doi="10.17487/RFC2900",
  }

@misc{rfc2901,
  author="Z. Wenzel and J. Klensin and R. Bush and S. Huter",
  title="{Guide to Administrative Procedures of the Internet Infrastructure}",
  howpublished="RFC 2901 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2901",
  pages="1--31",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2901.txt",
  key="RFC 2901",
  abstract={This document describes the administrative procedures for networks seeking to connect to the global Internet.  This memo provides information for the Internet community.},
  keywords="address space, routing, database, domain name, registration",
  doi="10.17487/RFC2901",
  }

@misc{rfc2902,
  author="S. Deering and S. Hares and C. Perkins and R. Perlman",
  title="{Overview of the 1998 IAB Routing Workshop}",
  howpublished="RFC 2902 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2902",
  pages="1--16",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2902.txt",
  key="RFC 2902",
  abstract={This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998.  This memo provides information for the Internet community.},
  keywords="internet, architecture, board",
  doi="10.17487/RFC2902",
  }

@misc{rfc2903,
  author="C. de Laat and G. Gross and L. Gommans and J. Vollbrecht and D. Spence",
  title="{Generic AAA Architecture}",
  howpublished="RFC 2903 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2903",
  pages="1--26",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2903.txt",
  key="RFC 2903",
  abstract={This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC2903",
  }

@misc{rfc2904,
  author="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence",
  title="{AAA Authorization Framework}",
  howpublished="RFC 2904 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2904",
  pages="1--35",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2904.txt",
  key="RFC 2904",
  abstract={This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS).  It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.  This memo provides information for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC2904",
  }

@misc{rfc2905,
  author="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence",
  title="{AAA Authorization Application Examples}",
  howpublished="RFC 2905 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2905",
  pages="1--53",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2905.txt",
  key="RFC 2905",
  abstract={This memo describes several examples of applications requiring authorization.  This memo provides information for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC2905",
  }

@misc{rfc2906,
  author="S. Farrell and J. Vollbrecht and P. Calhoun and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence",
  title="{AAA Authorization Requirements}",
  howpublished="RFC 2906 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2906",
  pages="1--23",
  year=2000,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2906.txt",
  key="RFC 2906",
  abstract={This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet.  This memo provides information for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC2906",
  }

@misc{rfc2907,
  author="R. Kermode",
  title="{MADCAP Multicast Scope Nesting State Option}",
  howpublished="RFC 2907 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2907",
  pages="1--13",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2907.txt",
  key="RFC 2907",
  abstract={This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]},
  keywords="address, dynamic, allocation, client, protocol",
  doi="10.17487/RFC2907",
  }

@misc{rfc2908,
  author="D. Thaler and M. Handley and D. Estrin",
  title="{The Internet Multicast Address Allocation Architecture}",
  howpublished="RFC 2908 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2908",
  pages="1--13",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6308",
url="https://www.rfc-editor.org/rfc/rfc2908.txt",
  key="RFC 2908",
  abstract={This document proposes a multicast address allocation architecture (MALLOC) for the Internet.  This memo provides information for the Internet community.},
  keywords="MALLOC, host server, intra-domain, inter-domain",
  doi="10.17487/RFC2908",
  }

@misc{rfc2909,
  author="P. Radoslavov and D. Estrin and R. Govindan and M. Handley and S. Kumar and D. Thaler",
  title="{The Multicast Address-Set Claim (MASC) Protocol}",
  howpublished="RFC 2909 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2909",
  pages="1--56",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2909.txt",
  key="RFC 2909",
  abstract={This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MASC, inter-domain, router",
  doi="10.17487/RFC2909",
  }

@misc{rfc2910,
  author="R. Herriot and S. Butler and P. Moore and R. Turner and J. Wenn",
  title="{Internet Printing Protocol/1.1: Encoding and Transport}",
  howpublished="RFC 2910 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2910",
  pages="1--46",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8010, updated by RFCs 3380, 3381, 3382, 3510, 3995, 7472",
url="https://www.rfc-editor.org/rfc/rfc2910.txt",
  key="RFC 2910",
  abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]},
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC2910",
  }

@misc{rfc2911,
  author="T. Hastings and R. Herriot and R. deBry and S. Isaacson and P. Powell",
  title="{Internet Printing Protocol/1.1: Model and Semantics}",
  howpublished="RFC 2911 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2911",
  pages="1--224",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8011, updated by RFCs 3380, 3382, 3996, 3995, 7472",
url="https://www.rfc-editor.org/rfc/rfc2911.txt",
  key="RFC 2911",
  abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]},
  keywords="IPP-M-S, IPP, application, media-type, job",
  doi="10.17487/RFC2911",
  }

@misc{rfc2912,
  author="G. Klyne",
  title="{Indicating Media Features for MIME Content}",
  howpublished="RFC 2912 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2912",
  pages="1--11",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2912.txt",
  key="RFC 2912",
  abstract={This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]},
  keywords="multipurpose, mail extensions, tag, format",
  doi="10.17487/RFC2912",
  }

@misc{rfc2913,
  author="G. Klyne",
  title="{MIME Content Types in Media Feature Expressions}",
  howpublished="RFC 2913 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2913",
  pages="1--9",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2913.txt",
  key="RFC 2913",
  abstract={This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]},
  keywords="multipurpose, mail extensions, tag, format",
  doi="10.17487/RFC2913",
  }

@misc{rfc2914,
  author="S. Floyd",
  title="{Congestion Control Principles}",
  howpublished="RFC 2914 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2914",
  pages="1--17",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7141",
url="https://www.rfc-editor.org/rfc/rfc2914.txt",
  key="RFC 2914",
  abstract={The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="end-to-end",
  doi="10.17487/RFC2914",
  }

@misc{rfc2915,
  author="M. Mealling and R. Daniel",
  title="{The Naming Authority Pointer (NAPTR) DNS Resource Record}",
  howpublished="RFC 2915 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2915",
  pages="1--18",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3401, 3402, 3403, 3404",
url="https://www.rfc-editor.org/rfc/rfc2915.txt",
  key="RFC 2915",
  abstract={This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]},
  keywords="NAPTR, domain name system, RR",
  doi="10.17487/RFC2915",
  }

@misc{rfc2916,
  author="P. Faltstrom",
  title="{E.164 number and DNS}",
  howpublished="RFC 2916 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2916",
  pages="1--10",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3761",
url="https://www.rfc-editor.org/rfc/rfc2916.txt",
  key="RFC 2916",
  abstract={This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]},
  keywords="domain name system",
  doi="10.17487/RFC2916",
  }

@misc{rfc2917,
  author="K. Muthukrishnan and A. Malis",
  title="{A Core MPLS IP VPN Architecture}",
  howpublished="RFC 2917 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2917",
  pages="1--16",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2917.txt",
  key="RFC 2917",
  abstract={This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone.  This memo provides information for the Internet community.},
  keywords="internet protocol, virtual private networks, multiprotocol label switching",
  doi="10.17487/RFC2917",
  }

@misc{rfc2918,
  author="E. Chen",
  title="{Route Refresh Capability for BGP-4}",
  howpublished="RFC 2918 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2918",
  pages="1--4",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7313",
url="https://www.rfc-editor.org/rfc/rfc2918.txt",
  key="RFC 2918",
  abstract={This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]},
  keywords="border, gateway, protocol",
  doi="10.17487/RFC2918",
  }

@misc{rfc2919,
  author="R. Chandhok and G. Wenger",
  title="{List-Id: A Structured Field and Namespace for the Identification of Mailing Lists}",
  howpublished="RFC 2919 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2919",
  pages="1--9",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2919.txt",
  key="RFC 2919",
  abstract={Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list.  With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]},
  keywords="server, clients, user agents",
  doi="10.17487/RFC2919",
  }

@misc{rfc2920,
  author="N. Freed",
  title="{SMTP Service Extension for Command Pipelining}",
  howpublished="RFC 2920 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2920",
  pages="1--9",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2920.txt",
  key="RFC 2920",
  abstract={This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]},
  keywords="SMTP-Pipe, simple, mail, transfer, protocol, TCP, transmission, control, protocol",
  doi="10.17487/RFC2920",
  }

@misc{rfc2921,
  author="B. Fink",
  title="{6BONE pTLA and pNLA Formats (pTLA)}",
  howpublished="RFC 2921 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2921",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2921.txt",
  key="RFC 2921",
  abstract={This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, ``IPv6 Testing Address Allocation'', to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).  This memo provides information for the Internet community.},
  keywords="IPv6, internet, protocol, pseudo, top-level, next-level, aggregation, identifiers",
  doi="10.17487/RFC2921",
  }

@misc{rfc2922,
  author="A. Bierman and K. Jones",
  title="{Physical Topology MIB}",
  howpublished="RFC 2922 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2922",
  pages="1--32",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2922.txt",
  key="RFC 2922",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing physical topology identification and discovery.  This memo provides information for the Internet community.},
  keywords="management, information, base",
  doi="10.17487/RFC2922",
  }

@misc{rfc2923,
  author="K. Lahey",
  title="{TCP Problems with Path MTU Discovery}",
  howpublished="RFC 2923 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2923",
  pages="1--15",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2923.txt",
  key="RFC 2923",
  abstract={This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU.  This memo provides information for the Internet community.},
  keywords="transmission, control, protocol, maximum, unit",
  doi="10.17487/RFC2923",
  }

@misc{rfc2924,
  author="N. Brownlee and A. Blount",
  title="{Accounting Attributes and Record Formats}",
  howpublished="RFC 2924 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2924",
  pages="1--36",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2924.txt",
  key="RFC 2924",
  abstract={This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting.  This memo provides information for the Internet community.},
  keywords="data, transport, integrated",
  doi="10.17487/RFC2924",
  }

@misc{rfc2925,
  author="K. White",
  title="{Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations}",
  howpublished="RFC 2925 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2925",
  pages="1--77",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4560",
url="https://www.rfc-editor.org/rfc/rfc2925.txt",
  key="RFC 2925",
  abstract={This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]},
  keywords="mib, management, information, base",
  doi="10.17487/RFC2925",
  }

@misc{rfc2926,
  author="J. Kempf and R. Moats and P. St. Pierre",
  title="{Conversion of LDAP Schemas to and from SLP Templates}",
  howpublished="RFC 2926 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2926",
  pages="1--27",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2926.txt",
  key="RFC 2926",
  abstract={This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services.  This memo provides information for the Internet community.},
  keywords="service location, protocol, lightweight, directory, access",
  doi="10.17487/RFC2926",
  }

@misc{rfc2927,
  author="M. Wahl",
  title="{MIME Directory Profile for LDAP Schema}",
  howpublished="RFC 2927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2927",
  pages="1--10",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2927.txt",
  key="RFC 2927",
  abstract={This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2927",
  }

@misc{rfc2928,
  author="R. Hinden and S. Deering and R. Fink and T. Hain",
  title="{Initial IPv6 Sub-TLA ID Assignments}",
  howpublished="RFC 2928 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2928",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2928.txt",
  key="RFC 2928",
  abstract={This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries.  This memo provides information for the Internet community.},
  keywords="internet protocol, sub-top-level, aggregation, identifiers, address, registries",
  doi="10.17487/RFC2928",
  }

@misc{rfc2929,
  author="D. {Eastlake 3rd} and E. Brunner-Williams and B. Manning",
  title="{Domain Name System (DNS) IANA Considerations}",
  howpublished="RFC 2929 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2929",
  pages="1--12",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5395",
url="https://www.rfc-editor.org/rfc/rfc2929.txt",
  key="RFC 2929",
  abstract={This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet assigned numbers authority, resource records, RRs",
  doi="10.17487/RFC2929",
  }

@misc{rfc2930,
  author="D. {Eastlake 3rd}",
  title="{Secret Key Establishment for DNS (TKEY RR)}",
  howpublished="RFC 2930 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2930",
  pages="1--16",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6895",
url="https://www.rfc-editor.org/rfc/rfc2930.txt",
  key="RFC 2930",
  abstract={This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]},
  keywords="TKEY-RR, domain name system, resource record, transaction key",
  doi="10.17487/RFC2930",
  }

@misc{rfc2931,
  author="D. {Eastlake 3rd}",
  title="{DNS Request and Transaction Signatures ( SIG(0)s )}",
  howpublished="RFC 2931 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2931",
  pages="1--10",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2931.txt",
  key="RFC 2931",
  abstract={This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]},
  keywords="domain name system, data, security",
  doi="10.17487/RFC2931",
  }

@misc{rfc2932,
  author="K. McCloghrie and D. Farinacci and D. Thaler",
  title="{IPv4 Multicast Routing MIB}",
  howpublished="RFC 2932 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2932",
  pages="1--27",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5132",
url="https://www.rfc-editor.org/rfc/rfc2932.txt",
  key="RFC 2932",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]},
  keywords="internet, protocol, management, information, base",
  doi="10.17487/RFC2932",
  }

@misc{rfc2933,
  author="K. McCloghrie and D. Farinacci and D. Thaler",
  title="{Internet Group Management Protocol MIB}",
  howpublished="RFC 2933 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2933",
  pages="1--19",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5519",
url="https://www.rfc-editor.org/rfc/rfc2933.txt",
  key="RFC 2933",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]},
  keywords="igmp, management, information, base",
  doi="10.17487/RFC2933",
  }

@misc{rfc2934,
  author="K. McCloghrie and D. Farinacci and D. Thaler and B. Fenner",
  title="{Protocol Independent Multicast MIB for IPv4}",
  howpublished="RFC 2934 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2934",
  pages="1--27",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2934.txt",
  key="RFC 2934",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="internet, protocol, management, information, base",
  doi="10.17487/RFC2934",
  }

@misc{rfc2935,
  author="D. {Eastlake 3rd} and C. Smith",
  title="{Internet Open Trading Protocol (IOTP) HTTP Supplement}",
  howpublished="RFC 2935 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2935",
  pages="1--8",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2935.txt",
  key="RFC 2935",
  abstract={The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.  This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]},
  keywords="IOTP-HTTP, hypertext, XML, extensible, markup, language, transfer",
  doi="10.17487/RFC2935",
  }

@misc{rfc2936,
  author="D. {Eastlake 3rd} and C. Smith and D. Soroka",
  title="{HTTP MIME Type Handler Detection}",
  howpublished="RFC 2936 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2936",
  pages="1--13",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2936.txt",
  key="RFC 2936",
  abstract={Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser.  This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000.  This memo provides information for the Internet community.},
  keywords="multipurpose, internet, mail, extensions, hypertext, transfer, protocol",
  doi="10.17487/RFC2936",
  }

@misc{rfc2937,
  author="C. Smith",
  title="{The Name Service Search Option for DHCP}",
  howpublished="RFC 2937 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2937",
  pages="1--5",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2937.txt",
  key="RFC 2937",
  abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol",
  doi="10.17487/RFC2937",
  }

@misc{rfc2938,
  author="G. Klyne and L. Masinter",
  title="{Identifying Composite Media Features}",
  howpublished="RFC 2938 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2938",
  pages="1--18",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2938.txt",
  key="RFC 2938",
  abstract={This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]},
  keywords="tags, expression, hash",
  doi="10.17487/RFC2938",
  }

@misc{rfc2939,
  author="R. Droms",
  title="{Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types}",
  howpublished="RFC 2939 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2939",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2939.txt",
  key="RFC 2939",
  abstract={This document describes the procedure for defining new DHCP options and message types.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="dynamic, host, configuration, protocol, internet, assigned, numbers, authority",
  doi="10.17487/RFC2939",
  }

@misc{rfc2940,
  author="A. Smith and D. Partain and J. Seligson",
  title="{Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients}",
  howpublished="RFC 2940 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2940",
  pages="1--27",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2940.txt",
  key="RFC 2940",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]},
  keywords="cops, mib, management, information, base",
  doi="10.17487/RFC2940",
  }

@misc{rfc2941,
  author="T. Ts'o and J. Altman",
  title="{Telnet Authentication Option}",
  howpublished="RFC 2941 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2941",
  pages="1--15",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2941.txt",
  key="RFC 2941",
  abstract={This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]},
  keywords="TOPT-AUTH, encryption, Security",
  doi="10.17487/RFC2941",
  }

@misc{rfc2942,
  author="T. Ts'o",
  title="{Telnet Authentication: Kerberos Version 5}",
  howpublished="RFC 2942 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2942",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2942.txt",
  key="RFC 2942",
  abstract={This document describes how Kerberos Version 5 is used with the telnet protocol.  It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]},
  keywords="encryption",
  doi="10.17487/RFC2942",
  }

@misc{rfc2943,
  author="R. Housley and T. Horting and P. Yee",
  title="{TELNET Authentication Using DSA}",
  howpublished="RFC 2943 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2943",
  pages="1--12",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2943.txt",
  key="RFC 2943",
  abstract={This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA).  It relies on the Telnet Authentication Option. [STANDARDS-TRACK]},
  keywords="digital, signature, algorithm",
  doi="10.17487/RFC2943",
  }

@misc{rfc2944,
  author="T. Wu",
  title="{Telnet Authentication: SRP}",
  howpublished="RFC 2944 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2944",
  pages="1--7",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2944.txt",
  key="RFC 2944",
  abstract={This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]},
  keywords="secure, remote, password, protocol",
  doi="10.17487/RFC2944",
  }

@misc{rfc2945,
  author="T. Wu",
  title="{The SRP Authentication and Key Exchange System}",
  howpublished="RFC 2945 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2945",
  pages="1--8",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2945.txt",
  key="RFC 2945",
  abstract={This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]},
  keywords="secure, remote, password, protocol",
  doi="10.17487/RFC2945",
  }

@misc{rfc2946,
  author="T. Ts'o",
  title="{Telnet Data Encryption Option}",
  howpublished="RFC 2946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2946",
  pages="1--8",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2946.txt",
  key="RFC 2946",
  abstract={This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]},
  keywords="stream, authentication",
  doi="10.17487/RFC2946",
  }

@misc{rfc2947,
  author="J. Altman",
  title="{Telnet Encryption: DES3 64 bit Cipher Feedback}",
  howpublished="RFC 2947 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2947",
  pages="1--6",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2947.txt",
  key="RFC 2947",
  abstract={This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]},
  keywords="data, encryption, standard",
  doi="10.17487/RFC2947",
  }

@misc{rfc2948,
  author="J. Altman",
  title="{Telnet Encryption: DES3 64 bit Output Feedback}",
  howpublished="RFC 2948 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2948",
  pages="1--6",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2948.txt",
  key="RFC 2948",
  abstract={This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]},
  keywords="data, encryption, standard",
  doi="10.17487/RFC2948",
  }

@misc{rfc2949,
  author="J. Altman",
  title="{Telnet Encryption: CAST-128 64 bit Output Feedback}",
  howpublished="RFC 2949 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2949",
  pages="1--5",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2949.txt",
  key="RFC 2949",
  abstract={This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option.  Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]},
  keywords="algorithm, option",
  doi="10.17487/RFC2949",
  }

@misc{rfc2950,
  author="J. Altman",
  title="{Telnet Encryption: CAST-128 64 bit Cipher Feedback}",
  howpublished="RFC 2950 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2950",
  pages="1--5",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2950.txt",
  key="RFC 2950",
  abstract={This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option.  Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]},
  keywords="algorithm, option",
  doi="10.17487/RFC2950",
  }

@misc{rfc2951,
  author="R. Housley and T. Horting and P. Yee",
  title="{TELNET Authentication Using KEA and SKIPJACK}",
  howpublished="RFC 2951 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2951",
  pages="1--11",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2951.txt",
  key="RFC 2951",
  abstract={This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK.  This memo provides information for the Internet community.},
  keywords="key exchange, algorithm, encryption",
  doi="10.17487/RFC2951",
  }

@misc{rfc2952,
  author="T. Ts'o",
  title="{Telnet Encryption: DES 64 bit Cipher Feedback}",
  howpublished="RFC 2952 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2952",
  pages="1--5",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2952.txt",
  key="RFC 2952",
  abstract={This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option.  This memo provides information for the Internet community.},
  keywords="data, encryption, standard",
  doi="10.17487/RFC2952",
  }

@misc{rfc2953,
  author="T. Ts'o",
  title="{Telnet Encryption: DES 64 bit Output Feedback}",
  howpublished="RFC 2953 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2953",
  pages="1--5",
  year=2000,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2953.txt",
  key="RFC 2953",
  abstract={This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option.  This memo provides information for the Internet community.},
  keywords="data, encryption, standard",
  doi="10.17487/RFC2953",
  }

@misc{rfc2954,
  author="K. Rehbehn and D. Fowler",
  title="{Definitions of Managed Objects for Frame Relay Service}",
  howpublished="RFC 2954 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2954",
  pages="1--76",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2954.txt",
  key="RFC 2954",
  abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets.  In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]},
  keywords="FR-MIB, mib, management, information, base",
  doi="10.17487/RFC2954",
  }

@misc{rfc2955,
  author="K. Rehbehn and O. Nicklass and G. Mouradian",
  title="{Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function}",
  howpublished="RFC 2955 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2955",
  pages="1--39",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2955.txt",
  key="RFC 2955",
  abstract={This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]},
  keywords="asynchronous, transfer, mode, permanent, virtual, connections, MIB, management, information, base",
  doi="10.17487/RFC2955",
  }

@misc{rfc2956,
  author="M. Kaat",
  title="{Overview of 1999 IAB Network Layer Workshop}",
  howpublished="RFC 2956 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2956",
  pages="1--16",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2956.txt",
  key="RFC 2956",
  abstract={This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999.  The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet.  This memo provides information for the Internet community.},
  keywords="intenret, architecture, board",
  doi="10.17487/RFC2956",
  }

@misc{rfc2957,
  author="L. Daigle and P. Faltstrom",
  title="{The application/whoispp-query Content-Type}",
  howpublished="RFC 2957 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2957",
  pages="1--6",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2957.txt",
  key="RFC 2957",
  abstract={The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.  This memo provides information for the Internet community.},
  keywords="mime, multipurpose, internet, mail, extensions, media-types",
  doi="10.17487/RFC2957",
  }

@misc{rfc2958,
  author="L. Daigle and P. Faltstrom",
  title="{The application/whoispp-response Content-type}",
  howpublished="RFC 2958 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2958",
  pages="1--6",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2958.txt",
  key="RFC 2958",
  abstract={The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.  This memo provides information for the Internet community.},
  keywords="mime, multipurpose, internet, mail, extensions, media-types",
  doi="10.17487/RFC2958",
  }

@misc{rfc2959,
  author="M. Baugher and B. Strahm and I. Suconick",
  title="{Real-Time Transport Protocol Management Information Base}",
  howpublished="RFC 2959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2959",
  pages="1--31",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2959.txt",
  key="RFC 2959",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]},
  keywords="RTP, MIB",
  doi="10.17487/RFC2959",
  }

@misc{rfc2960,
  author="R. Stewart and Q. Xie and K. Morneault and C. Sharp and H. Schwarzbauer and T. Taylor and I. Rytina and M. Kalla and L. Zhang and V. Paxson",
  title="{Stream Control Transmission Protocol}",
  howpublished="RFC 2960 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2960",
  pages="1--134",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4960, updated by RFC 3309",
url="https://www.rfc-editor.org/rfc/rfc2960.txt",
  key="RFC 2960",
  abstract={This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]},
  keywords="SCTP, IP, internet, transport, packet, network",
  doi="10.17487/RFC2960",
  }

@misc{rfc2961,
  author="L. Berger and D. Gan and G. Swallow and P. Pan and F. Tommasi and S. Molendini",
  title="{RSVP Refresh Overhead Reduction Extensions}",
  howpublished="RFC 2961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2961",
  pages="1--34",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5063",
url="https://www.rfc-editor.org/rfc/rfc2961.txt",
  key="RFC 2961",
  abstract={This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, messages",
  doi="10.17487/RFC2961",
  }

@misc{rfc2962,
  author="D. Raz and J. Schoenwaelder and B. Sugla",
  title="{An SNMP Application Level Gateway for Payload Address Translation}",
  howpublished="RFC 2962 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2962",
  pages="1--20",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2962.txt",
  key="RFC 2962",
  abstract={This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another.  This memo provides information for the Internet community.},
  keywords="simple, network, management, protocol",
  doi="10.17487/RFC2962",
  }

@misc{rfc2963,
  author="O. Bonaventure and S. De Cnodder",
  title="{A Rate Adaptive Shaper for Differentiated Services}",
  howpublished="RFC 2963 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2963",
  pages="1--19",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2963.txt",
  key="RFC 2963",
  abstract={This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively.  This memo provides information for the Internet community.},
  keywords="RAS, TCP, transmission, control, protocol, diffserv",
  doi="10.17487/RFC2963",
  }

@misc{rfc2964,
  author="K. Moore and N. Freed",
  title="{Use of HTTP State Management}",
  howpublished="RFC 2964 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2964",
  pages="1--8",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2964.txt",
  key="RFC 2964",
  abstract={This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged.  This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="hypertext, transfer, protocol",
  doi="10.17487/RFC2964",
  }

@misc{rfc2965,
  author="D. Kristol and L. Montulli",
  title="{HTTP State Management Mechanism}",
  howpublished="RFC 2965 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="2965",
  pages="1--26",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6265",
url="https://www.rfc-editor.org/rfc/rfc2965.txt",
  key="RFC 2965",
  abstract={This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]},
  keywords="hypertext, transfer, protocol",
  doi="10.17487/RFC2965",
  }

@misc{rfc2966,
  author="T. Li and T. Przygienda and H. Smit",
  title="{Domain-wide Prefix Distribution with Two-Level IS-IS}",
  howpublished="RFC 2966 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2966",
  pages="1--14",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5302",
url="https://www.rfc-editor.org/rfc/rfc2966.txt",
  key="RFC 2966",
  abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain.  This memo provides information for the Internet community.},
  keywords="intermediate, system, routers, loops, IP, internet, protocol",
  doi="10.17487/RFC2966",
  }

@misc{rfc2967,
  author="L. Daigle and R. Hedberg",
  title="{TISDAG - Technical Infrastructure for Swedish Directory Access Gateways}",
  howpublished="RFC 2967 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2967",
  pages="1--105",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2967.txt",
  key="RFC 2967",
  abstract={The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users.  This memo provides information for the Internet community.},
  keywords="single, point, service",
  doi="10.17487/RFC2967",
  }

@misc{rfc2968,
  author="L. Daigle and T. Eklof",
  title="{Mesh of Multiple DAG servers - Results from TISDAG}",
  howpublished="RFC 2968 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2968",
  pages="1--9",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2968.txt",
  key="RFC 2968",
  abstract={This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!).  The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes.  The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers.  So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services.  This memo provides information for the Internet community.},
  keywords="technical, infrastructure, swedish, directory, access, gateways, mesh, index",
  doi="10.17487/RFC2968",
  }

@misc{rfc2969,
  author="T. Eklof and L. Daigle",
  title="{Wide Area Directory Deployment - Experiences from TISDAG}",
  howpublished="RFC 2969 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2969",
  pages="1--19",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2969.txt",
  key="RFC 2969",
  abstract={This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products.  This memo provides information for the Internet community.},
  keywords="technical, infrastructure, swedish, access, gateways",
  doi="10.17487/RFC2969",
  }

@misc{rfc2970,
  author="L. Daigle and T. Eklof",
  title="{Architecture for Integrated Directory Services - Result from TISDAG}",
  howpublished="RFC 2970 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2970",
  pages="1--18",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2970.txt",
  key="RFC 2970",
  abstract={Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.  This memo provides information for the Internet community.},
  keywords="ids, whitepages, technical, infrastructure, swedish, access, gateways",
  doi="10.17487/RFC2970",
  }

@misc{rfc2971,
  author="T. Showalter",
  title="{IMAP4 ID extension}",
  howpublished="RFC 2971 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2971",
  pages="1--8",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2971.txt",
  key="RFC 2971",
  abstract={This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service.  The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]},
  keywords="internet, message, access, protocol, client, server",
  doi="10.17487/RFC2971",
  }

@misc{rfc2972,
  author="N. Popp and M. Mealling and L. Masinter and K. Sollins",
  title="{Context and Goals for Common Name Resolution}",
  howpublished="RFC 2972 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2972",
  pages="1--11",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2972.txt",
  key="RFC 2972",
  abstract={This document establishes the context and goals for a Common Name Resolution Protocol.  This memo provides information for the Internet community.},
  keywords="CNRP",
  doi="10.17487/RFC2972",
  }

@misc{rfc2973,
  author="R. Balay and D. Katz and J. Parker",
  title="{IS-IS Mesh Groups}",
  howpublished="RFC 2973 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2973",
  pages="1--8",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2973.txt",
  key="RFC 2973",
  abstract={This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589.  This memo provides information for the Internet community.},
  keywords="intermediate, system, PDU, protocol data, unit",
  doi="10.17487/RFC2973",
  }

@misc{rfc2974,
  author="M. Handley and C. Perkins and E. Whelan",
  title="{Session Announcement Protocol}",
  howpublished="RFC 2974 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="2974",
  pages="1--18",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2974.txt",
  key="RFC 2974",
  abstract={This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SAP",
  doi="10.17487/RFC2974",
  }

@misc{rfc2975,
  author="B. Aboba and J. Arkko and D. Harrington",
  title="{Introduction to Accounting Management}",
  howpublished="RFC 2975 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2975",
  pages="1--54",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2975.txt",
  key="RFC 2975",
  abstract={This document describes and discusses the issues involved in the design of the modern accounting systems.  The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing.  This memo provides information for the Internet community.},
  keywords="resource, consumption data, cost allocation",
  doi="10.17487/RFC2975",
  }

@misc{rfc2976,
  author="S. Donovan",
  title="{The SIP INFO Method}",
  howpublished="RFC 2976 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2976",
  pages="1--9",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6086",
url="https://www.rfc-editor.org/rfc/rfc2976.txt",
  key="RFC 2976",
  abstract={This document proposes an extension to the Session Initiation Protocol (SIP).  This extension adds the INFO method to the SIP protocol.  The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]},
  keywords="session, initiation, protocol, information, extension",
  doi="10.17487/RFC2976",
  }

@misc{rfc2977,
  author="S. Glass and T. Hiller and S. Jacobs and C. Perkins",
  title="{Mobile IP Authentication, Authorization, and Accounting Requirements}",
  howpublished="RFC 2977 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2977",
  pages="1--27",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2977.txt",
  key="RFC 2977",
  abstract={This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.  This memo provides information for the Internet community.},
  keywords="AAA, internet, protocol",
  doi="10.17487/RFC2977",
  }

@misc{rfc2978,
  author="N. Freed and J. Postel",
  title="{IANA Charset Registration Procedures}",
  howpublished="RFC 2978 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="2978",
  pages="1--11",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2978.txt",
  key="RFC 2978",
  abstract={Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets.  This in turn means that the ability to label different charsets is essential.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="character, set, mime, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC2978",
  }

@misc{rfc2979,
  author="N. Freed",
  title="{Behavior of and Requirements for Internet Firewalls}",
  howpublished="RFC 2979 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2979",
  pages="1--7",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2979.txt",
  key="RFC 2979",
  abstract={This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls.  This memo provides information for the Internet community.},
  keywords="security, intranet, network",
  doi="10.17487/RFC2979",
  }

@misc{rfc2980,
  author="S. Barber",
  title="{Common NNTP Extensions}",
  howpublished="RFC 2980 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2980",
  pages="1--27",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3977, 4643, 4644, 6048",
url="https://www.rfc-editor.org/rfc/rfc2980.txt",
  key="RFC 2980",
  abstract={In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed.  While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol.  This memo provides information for the Internet community.},
  keywords="network, news, transfer, protocol",
  doi="10.17487/RFC2980",
  }

@misc{rfc2981,
  author="R. Kavasseri",
  title="{Event MIB}",
  howpublished="RFC 2981 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2981",
  pages="1--50",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2981.txt",
  key="RFC 2981",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC2981",
  }

@misc{rfc2982,
  author="R. Kavasseri",
  title="{Distributed Management Expression MIB}",
  howpublished="RFC 2982 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2982",
  pages="1--41",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2982.txt",
  key="RFC 2982",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]},
  keywords="information, base",
  doi="10.17487/RFC2982",
  }

@misc{rfc2983,
  author="D. Black",
  title="{Differentiated Services and Tunnels}",
  howpublished="RFC 2983 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2983",
  pages="1--14",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2983.txt",
  key="RFC 2983",
  abstract={This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms.  This memo provides information for the Internet community.},
  keywords="internet, protocol, encapsulation",
  doi="10.17487/RFC2983",
  }

@misc{rfc2984,
  author="C. Adams",
  title="{Use of the CAST-128 Encryption Algorithm in CMS}",
  howpublished="RFC 2984 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2984",
  pages="1--6",
  year=2000,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2984.txt",
  key="RFC 2984",
  abstract={This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]},
  keywords="cryptographic, message, syntax, security, cipher",
  doi="10.17487/RFC2984",
  }

@misc{rfc2985,
  author="M. Nystrom and B. Kaliski",
  title="{PKCS \#9: Selected Object Classes and Attribute Types Version 2.0}",
  howpublished="RFC 2985 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2985",
  pages="1--42",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2985.txt",
  key="RFC 2985",
  abstract={This memo represents a republication of PKCS \#9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from that specification.  This memo provides information for the Internet community.},
  keywords="public-key, cryptography, standards, LDAP, lightweight, directory, access, protocol",
  doi="10.17487/RFC2985",
  }

@misc{rfc2986,
  author="M. Nystrom and B. Kaliski",
  title="{PKCS \#10: Certification Request Syntax Specification Version 1.7}",
  howpublished="RFC 2986 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2986",
  pages="1--14",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5967",
url="https://www.rfc-editor.org/rfc/rfc2986.txt",
  key="RFC 2986",
  abstract={This memo represents a republication of PKCS \#10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from the PKCS \#9 v2.0 or the PKCS \#10 v1.7 document.  This memo provides information for the Internet community.},
  keywords="public-key, cryptography, standards, PKCS-10, public, key, distinguished, name, encryption, data",
  doi="10.17487/RFC2986",
  }

@misc{rfc2987,
  author="P. Hoffman",
  title="{Registration of Charset and Languages Media Features Tags}",
  howpublished="RFC 2987 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2987",
  pages="1--6",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2987.txt",
  key="RFC 2987",
  abstract={This document contains the registration for two media feature tags: ``charset'' and ``language''. [STANDARDS-TRACK]},
  keywords="character, sets, human, languages, devices",
  doi="10.17487/RFC2987",
  }

@misc{rfc2988,
  author="V. Paxson and M. Allman",
  title="{Computing TCP's Retransmission Timer}",
  howpublished="RFC 2988 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2988",
  pages="1--8",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6298",
url="https://www.rfc-editor.org/rfc/rfc2988.txt",
  key="RFC 2988",
  abstract={This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]},
  keywords="transmission, control, protocol, algorithm",
  doi="10.17487/RFC2988",
  }

@misc{rfc2989,
  author="B. Aboba and P. Calhoun and S. Glass and T. Hiller and P. McCann and H. Shiino and P. Walsh and G. Zorn and G. Dommety and C. Perkins and B. Patil and D. Mitton and S. Manning and M. Beadles and X. Chen and S. Sivalingham and A. Hameed and M. Munson and S. Jacobs and B. Lim and B. Hirschman and R. Hsu and H. Koo and M. Lipford and E. Campbell and Y. Xu and S. Baba and E. Jaques",
  title="{Criteria for Evaluating AAA Protocols for Network Access}",
  howpublished="RFC 2989 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2989",
  pages="1--28",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2989.txt",
  key="RFC 2989",
  abstract={This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access.  This memo provides information for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC2989",
  }

@misc{rfc2990,
  author="G. Huston",
  title="{Next Steps for the IP QoS Architecture}",
  howpublished="RFC 2990 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2990",
  pages="1--24",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2990.txt",
  key="RFC 2990",
  abstract={This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.  This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.  This memo provides information for the Internet community.},
  keywords="internet, protocol, quality of service, end-to-end",
  doi="10.17487/RFC2990",
  }

@misc{rfc2991,
  author="D. Thaler and C. Hopps",
  title="{Multipath Issues in Unicast and Multicast Next-Hop Selection}",
  howpublished="RFC 2991 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2991",
  pages="1--9",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2991.txt",
  key="RFC 2991",
  abstract={The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet.  This memo summarizes current practices, problems, and solutions.  This memo provides information for the Internet community.},
  keywords="routing, forwarding, packets, ECMP",
  doi="10.17487/RFC2991",
  }

@misc{rfc2992,
  author="C. Hopps",
  title="{Analysis of an Equal-Cost Multi-Path Algorithm}",
  howpublished="RFC 2992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2992",
  pages="1--8",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2992.txt",
  key="RFC 2992",
  abstract={Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost.  The forwarding engine identifies paths by next-hop.  When forwarding a packet the router must decide which next-hop (path) to use.  This document gives an analysis of one method for making that decision.  The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops.  This memo provides information for the Internet community.},
  keywords="ECMP, routing, packets, forwarding",
  doi="10.17487/RFC2992",
  }

@misc{rfc2993,
  author="T. Hain",
  title="{Architectural Implications of NAT}",
  howpublished="RFC 2993 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2993",
  pages="1--29",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2993.txt",
  key="RFC 2993",
  abstract={This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT).  This memo provides information for the Internet community.},
  keywords="network, address, translation",
  doi="10.17487/RFC2993",
  }

@misc{rfc2994,
  author="H. Ohta and M. Matsui",
  title="{A Description of the MISTY1 Encryption Algorithm}",
  howpublished="RFC 2994 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2994",
  pages="1--10",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2994.txt",
  key="RFC 2994",
  abstract={This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds.  It documents the algorithm description including key scheduling part and data randomizing part.  This memo provides information for the Internet community.},
  keywords="cryptosystem, security, data, stream",
  doi="10.17487/RFC2994",
  }

@misc{rfc2995,
  author="H. Lu and I. Faynberg and J. Voelker and M. Weissman and W. Zhang and S. Rhim and J. Hwang and S. Ago and S. Moeenuddin and S. Hadvani and S. Nyckelgard and J. Yoakum and L. Robart",
  title="{Pre-Spirits Implementations of PSTN-initiated Services}",
  howpublished="RFC 2995 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2995",
  pages="1--44",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2995.txt",
  key="RFC 2995",
  abstract={This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks.  SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.  This memo provides information for the Internet community.},
  keywords="public, switched, telephone, network",
  doi="10.17487/RFC2995",
  }

@misc{rfc2996,
  author="Y. Bernet",
  title="{Format of the RSVP DCLASS Object}",
  howpublished="RFC 2996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2996",
  pages="1--9",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2996.txt",
  key="RFC 2996",
  abstract={This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, QoS, Quality of Service",
  doi="10.17487/RFC2996",
  }

@misc{rfc2997,
  author="Y. Bernet and A. Smith and B. Davie",
  title="{Specification of the Null Service Type}",
  howpublished="RFC 2997 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="2997",
  pages="1--12",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2997.txt",
  key="RFC 2997",
  abstract={The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling.  However, it does not require them to specify resource requirements.  QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator).  This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling.  In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, QoS, Quality of Service",
  doi="10.17487/RFC2997",
  }

@misc{rfc2998,
  author="Y. Bernet and P. Ford and R. Yavatkar and F. Baker and L. Zhang and M. Speer and R. Braden and B. Davie and J. Wroclawski and E. Felstaine",
  title="{A Framework for Integrated Services Operation over Diffserv Networks}",
  howpublished="RFC 2998 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2998",
  pages="1--31",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2998.txt",
  key="RFC 2998",
  abstract={This document describes a framework by which Integrated Services may be supported over Diffserv networks.  This memo provides information for the Internet community.},
  keywords="intserv, QoS, Quality of Service, end-to-end",
  doi="10.17487/RFC2998",
  }

@misc{rfc2999,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 2900-2999}",
  howpublished="RFC 2999 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2999",
  pages="1--23",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2999.txt",
  key="RFC 2999",
  doi="10.17487/RFC2999",
  }

@misc{rfc3000,
  author="J. Reynolds and R. Braden and S. Ginoza and L. Shiota",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 3000 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3000",
  pages="1--43",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3300",
url="https://www.rfc-editor.org/rfc/rfc3000.txt",
  key="RFC 3000",
  abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001.  It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series.  The latest version of this memo is designated STD 1. [STANDARDS-TRACK]},
  doi="10.17487/RFC3000",
  }

@misc{rfc3001,
  author="M. Mealling",
  title="{A URN Namespace of Object Identifiers}",
  howpublished="RFC 3001 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3001",
  pages="1--5",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3061",
url="https://www.rfc-editor.org/rfc/rfc3001.txt",
  key="RFC 3001",
  abstract={This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs).  This memo provides information for the Internet community.},
  keywords="uniform, resource, names, OIDs",
  doi="10.17487/RFC3001",
  }

@misc{rfc3002,
  author="D. Mitzel",
  title="{Overview of 2000 IAB Wireless Internetworking Workshop}",
  howpublished="RFC 3002 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3002",
  pages="1--42",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3002.txt",
  key="RFC 3002",
  abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking.  This memo provides information for the Internet community.},
  keywords="internet, architecture, board",
  doi="10.17487/RFC3002",
  }

@misc{rfc3003,
  author="M. Nilsson",
  title="{The audio/mpeg Media Type}",
  howpublished="RFC 3003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3003",
  pages="1--5",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3003.txt",
  key="RFC 3003",
  abstract={The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files.  The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]},
  keywords="MIME, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC3003",
  }

@misc{rfc3004,
  author="G. Stump and R. Droms and Y. Gu and R. Vyaghrapuri and A. Demirtjis and B. Beser and J. Privat",
  title="{The User Class Option for DHCP}",
  howpublished="RFC 3004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3004",
  pages="1--6",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3004.txt",
  key="RFC 3004",
  abstract={This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents.  The information contained in this option is an opaque field that represents the user class of which the client is a member.  Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters.  This option should be configurable by a user. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol",
  doi="10.17487/RFC3004",
  }

@misc{rfc3005,
  author="S. Harris",
  title="{IETF Discussion List Charter}",
  howpublished="RFC 3005 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3005",
  pages="1--3",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3005.txt",
  key="RFC 3005",
  abstract={The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures.  As this is the most general IETF mailing list, considerable latitude is allowed.  Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, engineering, task, force",
  doi="10.17487/RFC3005",
  }

@misc{rfc3006,
  author="B. Davie and C. Iturralde and D. Oran and S. Casner and J. Wroclawski",
  title="{Integrated Services in the Presence of Compressible Flows}",
  howpublished="RFC 3006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3006",
  pages="1--13",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3006.txt",
  key="RFC 3006",
  abstract={This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]},
  keywords="routing, resource, allocation, int-serv",
  doi="10.17487/RFC3006",
  }

@misc{rfc3007,
  author="B. Wellington",
  title="{Secure Domain Name System (DNS) Dynamic Update}",
  howpublished="RFC 3007 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3007",
  pages="1--9",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3007.txt",
  key="RFC 3007",
  abstract={This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]},
  keywords="security, authentication, validation, DNSSEC",
  doi="10.17487/RFC3007",
  }

@misc{rfc3008,
  author="B. Wellington",
  title="{Domain Name System Security (DNSSEC) Signing Authority}",
  howpublished="RFC 3008 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3008",
  pages="1--7",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4035, 4033, 4034, updated by RFC 3658",
url="https://www.rfc-editor.org/rfc/rfc3008.txt",
  key="RFC 3008",
  abstract={This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority.  The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process.  Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]},
  keywords="DNSSEC, authentication, validation, SIG, signature",
  doi="10.17487/RFC3008",
  }

@misc{rfc3009,
  author="J. Rosenberg and H. Schulzrinne",
  title="{Registration of parityfec MIME types}",
  howpublished="RFC 3009 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3009",
  pages="1--10",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5109",
url="https://www.rfc-editor.org/rfc/rfc3009.txt",
  key="RFC 3009",
  abstract={The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.  This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec.  This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]},
  keywords="media-type, multimedia, internet, mail, extensions",
  doi="10.17487/RFC3009",
  }

@misc{rfc3010,
  author="S. Shepler and B. Callaghan and D. Robinson and R. Thurlow and C. Beame and M. Eisler and D. Noveck",
  title="{NFS version 4 Protocol}",
  howpublished="RFC 3010 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3010",
  pages="1--212",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3530",
url="https://www.rfc-editor.org/rfc/rfc3010.txt",
  key="RFC 3010",
  abstract={NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]},
  keywords="NFSv4, network, file, system",
  doi="10.17487/RFC3010",
  }

@misc{rfc3011,
  author="G. Waters",
  title="{The IPv4 Subnet Selection Option for DHCP}",
  howpublished="RFC 3011 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3011",
  pages="1--7",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3011.txt",
  key="RFC 3011",
  abstract={This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]},
  keywords="internet, protocol, dynamic, host, configuration",
  doi="10.17487/RFC3011",
  }

@misc{rfc3012,
  author="C. Perkins and P. Calhoun",
  title="{Mobile IPv4 Challenge/Response Extensions}",
  howpublished="RFC 3012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3012",
  pages="1--17",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4721",
url="https://www.rfc-editor.org/rfc/rfc3012.txt",
  key="RFC 3012",
  abstract={In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]},
  keywords="internet, protocol, authentication, foreign, agent",
  doi="10.17487/RFC3012",
  }

@misc{rfc3013,
  author="T. Killalea",
  title="{Recommended Internet Service Provider Security Services and Procedures}",
  howpublished="RFC 3013 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3013",
  pages="1--13",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3013.txt",
  key="RFC 3013",
  abstract={The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ISPs",
  doi="10.17487/RFC3013",
  }

@misc{rfc3014,
  author="R. Kavasseri",
  title="{Notification Log MIB}",
  howpublished="RFC 3014 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3014",
  pages="1--26",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3014.txt",
  key="RFC 3014",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC3014",
  }

@misc{rfc3015,
  author="F. Cuervo and N. Greene and A. Rayhan and C. Huitema and B. Rosen and J. Segers",
  title="{Megaco Protocol Version 1.0}",
  howpublished="RFC 3015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3015",
  pages="1--179",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3525",
url="https://www.rfc-editor.org/rfc/rfc3015.txt",
  key="RFC 3015",
  abstract={This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e.  a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]},
  keywords="MEGACO, H.248, media, gateway, control",
  doi="10.17487/RFC3015",
  }

@misc{rfc3016,
  author="Y. Kikuchi and T. Nomura and S. Fukunaga and Y. Matsui and H. Kimata",
  title="{RTP Payload Format for MPEG-4 Audio/Visual Streams}",
  howpublished="RFC 3016 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3016",
  pages="1--21",
  year=2000,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6416",
url="https://www.rfc-editor.org/rfc/rfc3016.txt",
  key="RFC 3016",
  abstract={This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]},
  keywords="real-time transport, protocol, media-type",
  doi="10.17487/RFC3016",
  }

@misc{rfc3017,
  author="M. Riegel and G. Zorn",
  title="{XML DTD for Roaming Access Phone Book}",
  howpublished="RFC 3017 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3017",
  pages="1--33",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3017.txt",
  key="RFC 3017",
  abstract={This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]},
  keywords="extensible, markup, language, document, type, declaration",
  doi="10.17487/RFC3017",
  }

@misc{rfc3018,
  author="A. Bogdanov",
  title="{Unified Memory Space Protocol Specification}",
  howpublished="RFC 3018 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3018",
  pages="1--81",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3018.txt",
  key="RFC 3018",
  abstract={This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="UMSP, network, connection-oriented",
  doi="10.17487/RFC3018",
  }

@misc{rfc3019,
  author="B. Haberman and R. Worzella",
  title="{IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol}",
  howpublished="RFC 3019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3019",
  pages="1--15",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5519",
url="https://www.rfc-editor.org/rfc/rfc3019.txt",
  key="RFC 3019",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets.  Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]},
  keywords="IPv6, MIB, MLD",
  doi="10.17487/RFC3019",
  }

@misc{rfc3020,
  author="P. Pate and B. Lynch and K. Rehbehn",
  title="{Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function}",
  howpublished="RFC 3020 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3020",
  pages="1--36",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3020.txt",
  key="RFC 3020",
  abstract={This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]},
  keywords="MIB, management, information, base",
  doi="10.17487/RFC3020",
  }

@misc{rfc3021,
  author="A. Retana and R. White and V. Fuller and D. McPherson",
  title="{Using 31-Bit Prefixes on IPv4 Point-to-Point Links}",
  howpublished="RFC 3021 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3021",
  pages="1--10",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3021.txt",
  key="RFC 3021",
  abstract={With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency.  One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]},
  keywords="internet, protocol, addresses, subnet masks",
  doi="10.17487/RFC3021",
  }

@misc{rfc3022,
  author="P. Srisuresh and K. Egevang",
  title="{Traditional IP Network Address Translator (Traditional NAT)}",
  howpublished="RFC 3022 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3022",
  pages="1--16",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3022.txt",
  key="RFC 3022",
  abstract={The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation.  In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail.  This memo provides information for the Internet community.},
  keywords="internet, protocol, ports, private",
  doi="10.17487/RFC3022",
  }

@misc{rfc3023,
  author="M. Murata and S. St. Laurent and D. Kohn",
  title="{XML Media Types}",
  howpublished="RFC 3023 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3023",
  pages="1--39",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7303, updated by RFC 6839",
url="https://www.rfc-editor.org/rfc/rfc3023.txt",
  key="RFC 3023",
  abstract={This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML).  This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]},
  keywords="extensible, markup, language, web, authority, hypertext, transfer, protocol",
  doi="10.17487/RFC3023",
  }

@misc{rfc3024,
  author="G. Montenegro",
  title="{Reverse Tunneling for Mobile IP, revised}",
  howpublished="RFC 3024 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3024",
  pages="1--30",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3024.txt",
  key="RFC 3024",
  abstract={This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels.  This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]},
  keywords="internet, protocol, node, care-of-address",
  doi="10.17487/RFC3024",
  }

@misc{rfc3025,
  author="G. Dommety and K. Leung",
  title="{Mobile IP Vendor/Organization-Specific Extensions}",
  howpublished="RFC 3025 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3025",
  pages="1--8",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3115",
url="https://www.rfc-editor.org/rfc/rfc3025.txt",
  key="RFC 3025",
  abstract={This document defines two new extensions to Mobile IP.  These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]},
  keywords="internet, protocol",
  doi="10.17487/RFC3025",
  }

@misc{rfc3026,
  author="R. Blane",
  title="{Liaison to IETF/ISOC on ENUM}",
  howpublished="RFC 3026 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3026",
  pages="1--6",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3026.txt",
  key="RFC 3026",
  abstract={Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000.  This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions.  This memo provides information for the Internet community.},
  keywords="dns, domain, name, system, internet, security, engineering, task force, E.164, number",
  doi="10.17487/RFC3026",
  }

@misc{rfc3027,
  author="M. Holdrege and P. Srisuresh",
  title="{Protocol Complications with the IP Network Address Translator}",
  howpublished="RFC 3027 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3027",
  pages="1--20",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3027.txt",
  key="RFC 3027",
  abstract={The purpose of this document is to identify the protocols and applications that break with NAT enroute.  The document also attempts to identify any known workarounds.  This document attempts to capture as much information as possible, but is by no means a comprehensive coverage.  This memo provides information for the Internet community.},
  keywords="IP, internet, protocol, network, address, translator",
  doi="10.17487/RFC3027",
  }

@misc{rfc3028,
  author="T. Showalter",
  title="{Sieve: A Mail Filtering Language}",
  howpublished="RFC 3028 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3028",
  pages="1--36",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5228, 5429",
url="https://www.rfc-editor.org/rfc/rfc3028.txt",
  key="RFC 3028",
  abstract={This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]},
  keywords="client, server",
  doi="10.17487/RFC3028",
  }

@misc{rfc3029,
  author="C. Adams and P. Sylvester and M. Zolotarev and R. Zuccherato",
  title="{Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols}",
  howpublished="RFC 3029 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3029",
  pages="1--51",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3029.txt",
  key="RFC 3029",
  abstract={This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DVCS, TTP, trusted third party",
  doi="10.17487/RFC3029",
  }

@misc{rfc3030,
  author="G. Vaudreuil",
  title="{SMTP Service Extensions for Transmission of Large and Binary MIME Messages}",
  howpublished="RFC 3030 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3030",
  pages="1--12",
  year=2000,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3030.txt",
  key="RFC 3030",
  abstract={This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]},
  keywords="simple, mail, transfer, protocol, multipurpose, interent",
  doi="10.17487/RFC3030",
  }

@misc{rfc3031,
  author="E. Rosen and A. Viswanathan and R. Callon",
  title="{Multiprotocol Label Switching Architecture}",
  howpublished="RFC 3031 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3031",
  pages="1--61",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6178, 6790",
url="https://www.rfc-editor.org/rfc/rfc3031.txt",
  key="RFC 3031",
  abstract={This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]},
  keywords="MPLS",
  doi="10.17487/RFC3031",
  }

@misc{rfc3032,
  author="E. Rosen and D. Tappan and G. Fedorkow and Y. Rekhter and D. Farinacci and T. Li and A. Conta",
  title="{MPLS Label Stack Encoding}",
  howpublished="RFC 3032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3032",
  pages="1--23",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3443, 4182, 5332, 3270, 5129, 5462, 5586, 7274",
url="https://www.rfc-editor.org/rfc/rfc3032.txt",
  key="RFC 3032",
  abstract={This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well.  This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]},
  keywords="multi-protocol, label, switching",
  doi="10.17487/RFC3032",
  }

@misc{rfc3033,
  author="M. Suzuki",
  title="{The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol}",
  howpublished="RFC 3033 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3033",
  pages="1--25",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3033.txt",
  key="RFC 3033",
  abstract={The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]},
  keywords="IP",
  doi="10.17487/RFC3033",
  }

@misc{rfc3034,
  author="A. Conta and P. Doolan and A. Malis",
  title="{Use of Label Switching on Frame Relay Networks Specification}",
  howpublished="RFC 3034 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3034",
  pages="1--24",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3034.txt",
  key="RFC 3034",
  abstract={This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]},
  keywords="MPLS, multi-protocol",
  doi="10.17487/RFC3034",
  }

@misc{rfc3035,
  author="B. Davie and J. Lawrence and K. McCloghrie and E. Rosen and G. Swallow and Y. Rekhter and P. Doolan",
  title="{MPLS using LDP and ATM VC Switching}",
  howpublished="RFC 3035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3035",
  pages="1--20",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3035.txt",
  key="RFC 3035",
  abstract={This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]},
  keywords="multi-protocol, label, switching, asynchronous, transfer, mode, distribution, protocol",
  doi="10.17487/RFC3035",
  }

@misc{rfc3036,
  author="L. Andersson and P. Doolan and N. Feldman and A. Fredette and B. Thomas",
  title="{LDP Specification}",
  howpublished="RFC 3036 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3036",
  pages="1--132",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5036",
url="https://www.rfc-editor.org/rfc/rfc3036.txt",
  key="RFC 3036",
  abstract={A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]},
  keywords="label, distribution, protocol",
  doi="10.17487/RFC3036",
  }

@misc{rfc3037,
  author="B. Thomas and E. Gray",
  title="{LDP Applicability}",
  howpublished="RFC 3037 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3037",
  pages="1--7",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3037.txt",
  key="RFC 3037",
  abstract={A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.  This memo provides information for the Internet community.},
  keywords="label, distribution, protocol",
  doi="10.17487/RFC3037",
  }

@misc{rfc3038,
  author="K. Nagami and Y. Katsube and N. Demizu and H. Esaki and P. Doolan",
  title="{VCID Notification over ATM link for LDP}",
  howpublished="RFC 3038 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3038",
  pages="1--19",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc3038.txt",
  key="RFC 3038",
  abstract={This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]},
  keywords="asynchronous, transfer, mode, label, distribution, protocol",
  doi="10.17487/RFC3038",
  }

@misc{rfc3039,
  author="S. Santesson and W. Polk and P. Barzin and M. Nystrom",
  title="{Internet X.509 Public Key Infrastructure Qualified Certificates Profile}",
  howpublished="RFC 3039 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3039",
  pages="1--35",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3739",
url="https://www.rfc-editor.org/rfc/rfc3039.txt",
  key="RFC 3039",
  abstract={This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet.  The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]},
  keywords="syntax",
  doi="10.17487/RFC3039",
  }

@misc{rfc3040,
  author="I. Cooper and I. Melve and G. Tomlinson",
  title="{Internet Web Replication and Caching Taxonomy}",
  howpublished="RFC 3040 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3040",
  pages="1--32",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3040.txt",
  key="RFC 3040",
  abstract={This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today.  It introduces standard concepts, and protocols used today within this application domain.  This memo provides information for the Internet community.},
  keywords="infrastructure, www, world, wide",
  doi="10.17487/RFC3040",
  }

@misc{rfc3041,
  author="T. Narten and R. Draves",
  title="{Privacy Extensions for Stateless Address Autoconfiguration in IPv6}",
  howpublished="RFC 3041 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3041",
  pages="1--17",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4941",
url="https://www.rfc-editor.org/rfc/rfc3041.txt",
  key="RFC 3041",
  abstract={This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]},
  keywords="internet, protocol, interface, identifier",
  doi="10.17487/RFC3041",
  }

@misc{rfc3042,
  author="M. Allman and H. Balakrishnan and S. Floyd",
  title="{Enhancing TCP's Loss Recovery Using Limited Transmit}",
  howpublished="RFC 3042 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3042",
  pages="1--9",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3042.txt",
  key="RFC 3042",
  abstract={This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]},
  keywords="transmission, control, protocol",
  doi="10.17487/RFC3042",
  }

@misc{rfc3043,
  author="M. Mealling",
  title="{The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations}",
  howpublished="RFC 3043 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3043",
  pages="1--5",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3043.txt",
  key="RFC 3043",
  abstract={This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc.  for naming people and organizations.  This memo provides information for the Internet community.},
  keywords="uniform, resource, name",
  doi="10.17487/RFC3043",
  }

@misc{rfc3044,
  author="S. Rozenfeld",
  title="{Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace}",
  howpublished="RFC 3044 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3044",
  pages="1--15",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3044.txt",
  key="RFC 3044",
  abstract={This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier.  This memo provides information for the Internet community.},
  keywords="serials, identifier",
  doi="10.17487/RFC3044",
  }

@misc{rfc3045,
  author="M. Meredith",
  title="{Storing Vendor Information in the LDAP root DSE}",
  howpublished="RFC 3045 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3045",
  pages="1--6",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3045.txt",
  key="RFC 3045",
  abstract={This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol, DSA-specific, entry",
  doi="10.17487/RFC3045",
  }

@misc{rfc3046,
  author="M. Patrick",
  title="{DHCP Relay Agent Information Option}",
  howpublished="RFC 3046 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3046",
  pages="1--14",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6607",
url="https://www.rfc-editor.org/rfc/rfc3046.txt",
  key="RFC 3046",
  abstract={Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts.  It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.  However, a number of security and scaling problems arise with such ``public'' DHCP use.  This document describes a new DHCP option to address these issues.  This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol",
  doi="10.17487/RFC3046",
  }

@misc{rfc3047,
  author="P. Luthi",
  title="{RTP Payload Format for ITU-T Recommendation G.722.1}",
  howpublished="RFC 3047 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3047",
  pages="1--8",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5577",
url="https://www.rfc-editor.org/rfc/rfc3047.txt",
  key="RFC 3047",
  abstract={This document describes the payload format for including G.722.1 generated bit streams within an RTP packet.  Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]},
  keywords="international, telecommunication, union, real-time, transport, protocol",
  doi="10.17487/RFC3047",
  }

@misc{rfc3048,
  author="B. Whetten and L. Vicisano and R. Kermode and M. Handley and S. Floyd and M. Luby",
  title="{Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer}",
  howpublished="RFC 3048 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3048",
  pages="1--20",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3048.txt",
  key="RFC 3048",
  abstract={This document describes a framework for the standardization of bulk-data reliable multicast transport.  This memo provides information for the Internet community.},
  keywords="RMT, protocol, core",
  doi="10.17487/RFC3048",
  }

@misc{rfc3049,
  author="J. Naugle and K. Kasthurirangan and G. Ledford",
  title="{TN3270E Service Location and Session Balancing}",
  howpublished="RFC 3049 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3049",
  pages="1--21",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3049.txt",
  key="RFC 3049",
  abstract={This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]},
  keywords="SLP",
  doi="10.17487/RFC3049",
  }

@misc{rfc3050,
  author="J. Lennox and H. Schulzrinne and J. Rosenberg",
  title="{Common Gateway Interface for SIP}",
  howpublished="RFC 3050 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3050",
  pages="1--35",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3050.txt",
  key="RFC 3050",
  abstract={This document defines a SIP CGI interface for providing SIP services on a SIP server.  This memo provides information for the Internet community.},
  keywords="session, initiation, protocol",
  doi="10.17487/RFC3050",
  }

@misc{rfc3051,
  author="J. Heath and J. Border",
  title="{IP Payload Compression Using ITU-T V.44 Packet Method}",
  howpublished="RFC 3051 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3051",
  pages="1--8",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3051.txt",
  key="RFC 3051",
  abstract={This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44.  This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393).  This memo provides information for the Internet community.},
  keywords="internet, protocol, international, telecommunication, union",
  doi="10.17487/RFC3051",
  }

@misc{rfc3052,
  author="M. Eder and S. Nag",
  title="{Service Management Architectures Issues and Review}",
  howpublished="RFC 3052 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3052",
  pages="1--12",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3052.txt",
  key="RFC 3052",
  abstract={The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved.  This memo provides information for the Internet community.},
  keywords="framework, packets, network",
  doi="10.17487/RFC3052",
  }

@misc{rfc3053,
  author="A. Durand and P. Fasano and I. Guardini and D. Lento",
  title="{IPv6 Tunnel Broker}",
  howpublished="RFC 3053 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3053",
  pages="1--13",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3053.txt",
  key="RFC 3053",
  abstract={The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names.  The concept of the tunnel broker was first presented at Orlando's IETF in December 1998.  Two implementations were demonstrated during the Grenoble IPng \& NGtrans interim meeting in February 1999.  This memo provides information for the Internet community.},
  keywords="internet, protocol, infrastructure",
  doi="10.17487/RFC3053",
  }

@misc{rfc3054,
  author="P. Blatherwick and R. Bell and P. Holland",
  title="{Megaco IP Phone Media Gateway Application Profile}",
  howpublished="RFC 3054 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3054",
  pages="1--14",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3054.txt",
  key="RFC 3054",
  abstract={This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway.  This memo provides information for the Internet community.},
  keywords="internet, protocol, H.248, telephone, MG",
  doi="10.17487/RFC3054",
  }

@misc{rfc3055,
  author="M. Krishnaswamy and D. Romascanu",
  title="{Management Information Base for the PINT Services Architecture}",
  howpublished="RFC 3055 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3055",
  pages="1--21",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3055.txt",
  key="RFC 3055",
  abstract={This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]},
  keywords="MIB, PSTN/Internet, interworking",
  doi="10.17487/RFC3055",
  }

@misc{rfc3056,
  author="B. Carpenter and K. Moore",
  title="{Connection of IPv6 Domains via IPv4 Clouds}",
  howpublished="RFC 3056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3056",
  pages="1--23",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3056.txt",
  key="RFC 3056",
  abstract={This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]},
  keywords="internet, protocol, wide area, network, unicast, point-to-point",
  doi="10.17487/RFC3056",
  }

@misc{rfc3057,
  author="K. Morneault and S. Rengasami and M. Kalla and G. Sidebottom",
  title="{ISDN Q.921-User Adaptation Layer}",
  howpublished="RFC 3057 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3057",
  pages="1--66",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4233, updated by RFC 3807",
url="https://www.rfc-editor.org/rfc/rfc3057.txt",
  key="RFC 3057",
  abstract={This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP).  This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]},
  keywords="SCTP, signaling, media, gateway, interface",
  doi="10.17487/RFC3057",
  }

@misc{rfc3058,
  author="S. Teiwes and P. Hartmann and D. Kuenzi",
  title="{Use of the IDEA Encryption Algorithm in CMS}",
  howpublished="RFC 3058 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3058",
  pages="1--8",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3058.txt",
  key="RFC 3058",
  abstract={This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption.  This memo provides information for the Internet community.},
  keywords="international, data encryption, algorithm, cryptic message, syntax, s/mime, multipurpose internet, mail extensions",
  doi="10.17487/RFC3058",
  }

@misc{rfc3059,
  author="E. Guttman",
  title="{Attribute List Extension for the Service Location Protocol}",
  howpublished="RFC 3059 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3059",
  pages="1--6",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3059.txt",
  key="RFC 3059",
  abstract={This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages.  This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]},
  keywords="SLPv2, messages, user agent",
  doi="10.17487/RFC3059",
  }

@misc{rfc3060,
  author="B. Moore and E. Ellesson and J. Strassner and A. Westerinen",
  title="{Policy Core Information Model -- Version 1 Specification}",
  howpublished="RFC 3060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3060",
  pages="1--100",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3460",
url="https://www.rfc-editor.org/rfc/rfc3060.txt",
  key="RFC 3060",
  abstract={This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]},
  keywords="CIM, common, schema, object-oriented",
  doi="10.17487/RFC3060",
  }

@misc{rfc3061,
  author="M. Mealling",
  title="{A URN Namespace of Object Identifiers}",
  howpublished="RFC 3061 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3061",
  pages="1--6",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3061.txt",
  key="RFC 3061",
  abstract={This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs).  This memo provides information for the Internet community.},
  keywords="uniform, resource, names, OIDs",
  doi="10.17487/RFC3061",
  }

@misc{rfc3062,
  author="K. Zeilenga",
  title="{LDAP Password Modify Extended Operation}",
  howpublished="RFC 3062 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3062",
  pages="1--6",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3062.txt",
  key="RFC 3062",
  abstract={This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC3062",
  }

@misc{rfc3063,
  author="Y. Ohba and Y. Katsube and E. Rosen and P. Doolan",
  title="{MPLS Loop Prevention Mechanism}",
  howpublished="RFC 3063 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3063",
  pages="1--44",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3063.txt",
  key="RFC 3063",
  abstract={This paper presents a simple mechanism, based on ``threads'', which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="multiprotocol, label, switching, path, LSPs",
  doi="10.17487/RFC3063",
  }

@misc{rfc3064,
  author="B. Foster",
  title="{MGCP CAS Packages}",
  howpublished="RFC 3064 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3064",
  pages="1--56",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3064.txt",
  key="RFC 3064",
  abstract={This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support.  This memo provides information for the Internet community.},
  keywords="media, gateway, controllers",
  doi="10.17487/RFC3064",
  }

@misc{rfc3065,
  author="P. Traina and D. McPherson and J. Scudder",
  title="{Autonomous System Confederations for BGP}",
  howpublished="RFC 3065 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3065",
  pages="1--11",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5065",
url="https://www.rfc-editor.org/rfc/rfc3065.txt",
  key="RFC 3065",
  abstract={This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the ``full mesh'' requirement.  The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]},
  keywords="BGP-ASC, AS, border, gateway, protocol",
  doi="10.17487/RFC3065",
  }

@misc{rfc3066,
  author="H. Alvestrand",
  title="{Tags for the Identification of Languages}",
  howpublished="RFC 3066 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3066",
  pages="1--13",
  year=2001,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4646, 4647",
url="https://www.rfc-editor.org/rfc/rfc3066.txt",
  key="RFC 3066",
  abstract={This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Lang-Tag",
  doi="10.17487/RFC3066",
  }

@misc{rfc3067,
  author="J. Arvidsson and A. Cormack and Y. Demchenko and J. Meijer",
  title="{TERENA'S Incident Object Description and Exchange Format Requirements}",
  howpublished="RFC 3067 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3067",
  pages="1--17",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3067.txt",
  key="RFC 3067",
  abstract={The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.).  This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements.  This memo provides information for the Internet community.},
  keywords="IEDEF, data, archiving",
  doi="10.17487/RFC3067",
  }

@misc{rfc3068,
  author="C. Huitema",
  title="{An Anycast Prefix for 6to4 Relay Routers}",
  howpublished="RFC 3068 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3068",
  pages="1--9",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7526",
url="https://www.rfc-editor.org/rfc/rfc3068.txt",
  key="RFC 3068",
  abstract={This memo introduces a ``6to4 anycast address'' in order to simplify the configuration of 6to4 routers.  It also defines how this address will be used by 6to4 relay routers, how the corresponding ``6to4 anycast prefix'' will be advertised in the IGP and in the EGP.  The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the ``6to4 relay anycast prefix.'' [STANDARDS-TRACK]},
  keywords="exterior, gateway, protocol, interior, IGP, EGP",
  doi="10.17487/RFC3068",
  }

@misc{rfc3069,
  author="D. McPherson and B. Dykes",
  title="{VLAN Aggregation for Efficient IP Address Allocation}",
  howpublished="RFC 3069 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3069",
  pages="1--7",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3069.txt",
  key="RFC 3069",
  abstract={This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation.  This memo provides information for the Internet community.},
  keywords="virtual, local, area, network, internet, protocol",
  doi="10.17487/RFC3069",
  }

@misc{rfc3070,
  author="V. Rawat and R. Tio and S. Nanji and R. Verma",
  title="{Layer Two Tunneling Protocol (L2TP) over Frame Relay}",
  howpublished="RFC 3070 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3070",
  pages="1--7",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3070.txt",
  key="RFC 3070",
  abstract={This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]},
  keywords="L2TP-FR, point-to-point, virtual, switched, circuits, PVCs, SVCs",
  doi="10.17487/RFC3070",
  }

@misc{rfc3071,
  author="J. Klensin",
  title="{Reflections on the DNS, RFC 1591, and Categories of Domains}",
  howpublished="RFC 3071 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3071",
  pages="1--10",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3071.txt",
  key="RFC 3071",
  abstract={This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability.  This memo provides information for the Internet community.},
  keywords="DNS, Policy, Top-Level, TLD",
  doi="10.17487/RFC3071",
  }

@misc{rfc3072,
  author="M. Wildgrube",
  title="{Structured Data Exchange Format (SDXF)}",
  howpublished="RFC 3072 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3072",
  pages="1--26",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3072.txt",
  key="RFC 3072",
  abstract={This specification describes an all-purpose interchange format for use as a file format or for net-working.  This memo provides information for the Internet community.},
  keywords="chunks, file, datatype",
  doi="10.17487/RFC3072",
  }

@misc{rfc3073,
  author="J. Collins",
  title="{Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration}",
  howpublished="RFC 3073 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3073",
  pages="1--6",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3073.txt",
  key="RFC 3073",
  abstract={This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr.  The encoding is defined by the PFR Specification.  This memo provides information for the Internet community.},
  keywords="multipurpose, internet, mail, extensions",
  doi="10.17487/RFC3073",
  }

@misc{rfc3074,
  author="B. Volz and S. Gonczi and T. Lemon and R. Stevens",
  title="{DHC Load Balancing Algorithm}",
  howpublished="RFC 3074 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3074",
  pages="1--10",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3074.txt",
  key="RFC 3074",
  abstract={This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol",
  doi="10.17487/RFC3074",
  }

@misc{rfc3075,
  author="D. {Eastlake 3rd} and J. Reagle and D. Solo",
  title="{XML-Signature Syntax and Processing}",
  howpublished="RFC 3075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3075",
  pages="1--64",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3275",
url="https://www.rfc-editor.org/rfc/rfc3075.txt",
  key="RFC 3075",
  abstract={This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]},
  keywords="extensible, markup, language",
  doi="10.17487/RFC3075",
  }

@misc{rfc3076,
  author="J. Boyer",
  title="{Canonical XML Version 1.0}",
  howpublished="RFC 3076 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3076",
  pages="1--28",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3076.txt",
  key="RFC 3076",
  abstract={This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes.  This memo provides information for the Internet community.},
  keywords="extensible, markup, language",
  doi="10.17487/RFC3076",
  }

@misc{rfc3077,
  author="E. Duros and W. Dabbous and H. Izumiyama and N. Fujii and Y. Zhang",
  title="{A Link-Layer Tunneling Mechanism for Unidirectional Links}",
  howpublished="RFC 3077 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3077",
  pages="1--25",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3077.txt",
  key="RFC 3077",
  abstract={This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]},
  keywords="ll, udl, bidirectional, connectivity, ip, internet, protocol",
  doi="10.17487/RFC3077",
  }

@misc{rfc3078,
  author="G. Pall and G. Zorn",
  title="{Microsoft Point-To-Point Encryption (MPPE) Protocol}",
  howpublished="RFC 3078 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3078",
  pages="1--12",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3078.txt",
  key="RFC 3078",
  abstract={This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets.  This memo provides information for the Internet community.},
  keywords="security, ppp",
  doi="10.17487/RFC3078",
  }

@misc{rfc3079,
  author="G. Zorn",
  title="{Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)}",
  howpublished="RFC 3079 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3079",
  pages="1--21",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3079.txt",
  key="RFC 3079",
  abstract={This document describes the method used to derive initial MPPE session keys from a variety of credential types.  It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.  This memo provides information for the Internet community.},
  keywords="security, ppp",
  doi="10.17487/RFC3079",
  }

@misc{rfc3080,
  author="M. Rose",
  title="{The Blocks Extensible Exchange Protocol Core}",
  howpublished="RFC 3080 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3080",
  pages="1--58",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3080.txt",
  key="RFC 3080",
  abstract={This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]},
  keywords="BEEP, text, binary, messages, kernal",
  doi="10.17487/RFC3080",
  }

@misc{rfc3081,
  author="M. Rose",
  title="{Mapping the BEEP Core onto TCP}",
  howpublished="RFC 3081 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3081",
  pages="1--8",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3081.txt",
  key="RFC 3081",
  abstract={This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]},
  keywords="transmission, control, protocol, blocks, extensible, exchange",
  doi="10.17487/RFC3081",
  }

@misc{rfc3082,
  author="J. Kempf and J. Goldschmidt",
  title="{Notification and Subscription for SLP}",
  howpublished="RFC 3082 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3082",
  pages="1--14",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3082.txt",
  key="RFC 3082",
  abstract={The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services.  The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it.  There exists another class of user agent applications, however, that requires notification when a new service appears or disappears.  In the RFC 2608 design, these applications are forced to poll the network to catch changes.  In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="service, location, protocol",
  doi="10.17487/RFC3082",
  }

@misc{rfc3083,
  author="R. Woundy",
  title="{Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems}",
  howpublished="RFC 3083 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3083",
  pages="1--45",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3083.txt",
  key="RFC 3083",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems.  This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.  This memo provides information for the Internet community.},
  keywords="MIB, BPI, data-over-cable, service interface, specifications",
  doi="10.17487/RFC3083",
  }

@misc{rfc3084,
  author="K. Chan and J. Seligson and D. Durham and S. Gai and K. McCloghrie and S. Herzog and F. Reichmeyer and R. Yavatkar and A. Smith",
  title="{COPS Usage for Policy Provisioning (COPS-PR)}",
  howpublished="RFC 3084 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3084",
  pages="1--34",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3084.txt",
  key="RFC 3084",
  abstract={This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]},
  keywords="COPS-PR, common, open, service, security, quality",
  doi="10.17487/RFC3084",
  }

@misc{rfc3085,
  author="A. Coates and D. Allen and D. Rivers-Moore",
  title="{URN Namespace for NewsML Resources}",
  howpublished="RFC 3085 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3085",
  pages="1--6",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3085.txt",
  key="RFC 3085",
  abstract={This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems.  This memo provides information for the Internet community.},
  keywords="uniform, resource, name, newsitems, iptc",
  doi="10.17487/RFC3085",
  }

@misc{rfc3086,
  author="K. Nichols and B. Carpenter",
  title="{Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification}",
  howpublished="RFC 3086 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3086",
  pages="1--24",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3086.txt",
  key="RFC 3086",
  abstract={This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products.  This format is specified to expedite working group review of PDB submissions.  This memo provides information for the Internet community.},
  keywords="diffserv, QoS, quality of service",
  doi="10.17487/RFC3086",
  }

@misc{rfc3087,
  author="B. Campbell and R. Sparks",
  title="{Control of Service Context using SIP Request-URI}",
  howpublished="RFC 3087 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3087",
  pages="1--39",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3087.txt",
  key="RFC 3087",
  abstract={This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention.  It does not define any new protocol with respect to RFC 2543.  This memo provides information for the Internet community.},
  keywords="session, initiation, protocol, uniform, resource, identifier",
  doi="10.17487/RFC3087",
  }

@misc{rfc3088,
  author="K. Zeilenga",
  title="{OpenLDAP Root Service An experimental LDAP referral service}",
  howpublished="RFC 3088 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3088",
  pages="1--11",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3088.txt",
  key="RFC 3088",
  abstract={The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the ``OpenLDAP Root Service''.  The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records).  This document describes this service.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="lightweight, directory, access, protocol, dns, domain, name, system",
  doi="10.17487/RFC3088",
  }

@misc{rfc3089,
  author="H. Kitamura",
  title="{A SOCKS-based IPv6/IPv4 Gateway Mechanism}",
  howpublished="RFC 3089 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3089",
  pages="1--12",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3089.txt",
  key="RFC 3089",
  abstract={This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes.  This memo provides information for the Internet community.},
  keywords="internet, protocol, application, layer",
  doi="10.17487/RFC3089",
  }

@misc{rfc3090,
  author="E. Lewis",
  title="{DNS Security Extension Clarification on Zone Status}",
  howpublished="RFC 3090 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3090",
  pages="1--11",
  year=2001,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFC 3658",
url="https://www.rfc-editor.org/rfc/rfc3090.txt",
  key="RFC 3090",
  abstract={The definition of a secured zone is presented, clarifying and updating sections of RFC 2535.  RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys.  This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used).  To further simplify the determination of a zone's status, ``experimentally secure'' status is deprecated. [STANDARDS-TRACK]},
  keywords="domain, name, system, rsa, dsa",
  doi="10.17487/RFC3090",
  }

@misc{rfc3091,
  author="H. Kennedy",
  title="{Pi Digit Generation Protocol}",
  howpublished="RFC 3091 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3091",
  pages="1--6",
  year=2001,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3091.txt",
  key="RFC 3091",
  abstract={This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3091",
  }

@misc{rfc3092,
  author="D. {Eastlake 3rd} and C. Manros and E. Raymond",
  title="{Etymology of ``Foo''}",
  howpublished="RFC 3092 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3092",
  pages="1--14",
  year=2001,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3092.txt",
  key="RFC 3092",
  abstract={Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition.  This document rectifies that deficiency.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3092",
  }

@misc{rfc3093,
  author="M. Gaynor and S. Bradner",
  title="{Firewall Enhancement Protocol (FEP)}",
  howpublished="RFC 3093 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3093",
  pages="1--11",
  year=2001,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3093.txt",
  key="RFC 3093",
  abstract={Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].  However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation.  We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3093",
  }

@misc{rfc3094,
  author="D. Sprague and R. Benedyk and D. Brendes and J. Keller",
  title="{Tekelec's Transport Adapter Layer Interface}",
  howpublished="RFC 3094 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3094",
  pages="1--106",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3094.txt",
  key="RFC 3094",
  abstract={This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network.  This memo provides information for the Internet community.},
  keywords="signaling, gatewa, circuit, network, internet, protocol",
  doi="10.17487/RFC3094",
  }

@misc{rfc3095,
  author="C. Bormann and C. Burmeister and M. Degermark and H. Fukushima and H. Hannu and L-E. Jonsson and R. Hakenberg and T. Koren and K. Le and Z. Liu and A. Martensson and A. Miyazaki and K. Svanbro and T. Wiebke and T. Yoshimura and H. Zheng",
  title="{RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed}",
  howpublished="RFC 3095 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3095",
  pages="1--168",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3759, 4815",
url="https://www.rfc-editor.org/rfc/rfc3095.txt",
  key="RFC 3095",
  abstract={This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]},
  keywords="encapsulating, security, payload, real-time, transport, protocol, user, datagram",
  doi="10.17487/RFC3095",
  }

@misc{rfc3096,
  author="M. Degermark",
  title="{Requirements for robust IP/UDP/RTP header compression}",
  howpublished="RFC 3096 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3096",
  pages="1--8",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3096.txt",
  key="RFC 3096",
  abstract={This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG.  It is based on the ROHC charter, discussions in the WG, the 3GPP document ``3GPP TR 23.922'', version 1.0.0 of October 1999, as well as contributions from 3G.IP.  This memo provides information for the Internet community.},
  keywords="real-time, transport, internet, protocol, user, datagram",
  doi="10.17487/RFC3096",
  }

@misc{rfc3097,
  author="R. Braden and L. Zhang",
  title="{RSVP Cryptographic Authentication -- Updated Message Type Value}",
  howpublished="RFC 3097 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3097",
  pages="1--4",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3097.txt",
  key="RFC 3097",
  abstract={This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]},
  keywords="RSVP, resource, reservation, protocol, security",
  doi="10.17487/RFC3097",
  }

@misc{rfc3098,
  author="T. Gavin and D. {Eastlake 3rd} and S. Hambridge",
  title="{How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to \$\$\$\$\$  MAKE ENEMIES FAST!  \$\$\$\$\$}",
  howpublished="RFC 3098 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3098",
  pages="1--28",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3098.txt",
  key="RFC 3098",
  abstract={This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion.  This memo provides information for the Internet community.},
  keywords="internet, marketing, users, service, providers, isps",
  doi="10.17487/RFC3098",
  }

@misc{rfc3099,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 3000-3099}",
  howpublished="RFC 3099 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3099",
  pages="1--25",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3099.txt",
  key="RFC 3099",
  doi="10.17487/RFC3099",
  }

@misc{rfc3101,
  author="P. Murphy",
  title="{The OSPF Not-So-Stubby Area (NSSA) Option}",
  howpublished="RFC 3101 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3101",
  pages="1--33",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3101.txt",
  key="RFC 3101",
  abstract={This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a ``not-so-stubby'' area (or NSSA).  NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.  The OSPF NSSA Option was originally defined in RFC 1587.  The functional differences between this memo and RFC 1587 are explained in Appendix F.  All differences, while expanding capability, are backward-compatible in nature.  Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]},
  keywords="OSPF-NSSA, stub, external routes, backward compatible",
  doi="10.17487/RFC3101",
  }

@misc{rfc3102,
  author="M. Borella and J. Lo and D. Grabelsky and G. Montenegro",
  title="{Realm Specific IP: Framework}",
  howpublished="RFC 3102 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3102",
  pages="1--30",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3102.txt",
  key="RFC 3102",
  abstract={This document examines the general framework of Realm Specific IP (RSIP).  RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained.  We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="RSIP, end-to-end, NAT, addressing, requirements",
  doi="10.17487/RFC3102",
  }

@misc{rfc3103,
  author="M. Borella and D. Grabelsky and J. Lo and K. Taniguchi",
  title="{Realm Specific IP: Protocol Specification}",
  howpublished="RFC 3103 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3103",
  pages="1--54",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3103.txt",
  key="RFC 3103",
  abstract={This document presents a protocol with which to implement Realm Specific IP (RSIP).  The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence.  This protocol is designed to operate on the application layer and to use its own TCP or UDP port.  In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="RSIP, host, gateway, NAT, requirements",
  doi="10.17487/RFC3103",
  }

@misc{rfc3104,
  author="G. Montenegro and M. Borella",
  title="{RSIP Support for End-to-end IPsec}",
  howpublished="RFC 3104 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3104",
  pages="1--19",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3104.txt",
  key="RFC 3104",
  abstract={This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="realm, specific, internet, protocol, NAT, addressing, requirements",
  doi="10.17487/RFC3104",
  }

@misc{rfc3105,
  author="J. Kempf and G. Montenegro",
  title="{Finding an RSIP Server with SLP}",
  howpublished="RFC 3105 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3105",
  pages="1--11",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3105.txt",
  key="RFC 3105",
  abstract={This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="realm, specific, internet, protocol, service, location, NAT, addressing, requirements",
  doi="10.17487/RFC3105",
  }

@misc{rfc3106,
  author="D. {Eastlake 3rd} and T. Goldstein",
  title="{ECML v1.1: Field Specifications for E-Commerce}",
  howpublished="RFC 3106 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3106",
  pages="1--20",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4112",
url="https://www.rfc-editor.org/rfc/rfc3106.txt",
  key="RFC 3106",
  abstract={Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there.  A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields.  Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields.  In addition, some fields are defined for merchant to consumer communication.  This memo provides information for the Internet community.},
  keywords="electronic, modeling, language",
  doi="10.17487/RFC3106",
  }

@misc{rfc3107,
  author="Y. Rekhter and E. Rosen",
  title="{Carrying Label Information in BGP-4}",
  howpublished="RFC 3107 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3107",
  pages="1--8",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6790",
url="https://www.rfc-editor.org/rfc/rfc3107.txt",
  key="RFC 3107",
  abstract={This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]},
  keywords="SDP, asynchronous, transfer, mode, AAL, syntax, adaption, layer",
  doi="10.17487/RFC3107",
  }

@misc{rfc3108,
  author="R. Kumar and M. Mostafa",
  title="{Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections}",
  howpublished="RFC 3108 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3108",
  pages="1--110",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3108.txt",
  key="RFC 3108",
  abstract={This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL).  The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]},
  keywords="asynchronous, transfer, mode, AAL, syntax, adaption, layer",
  doi="10.17487/RFC3108",
  }

@misc{rfc3109,
  author="R. Braden and R. Bush and J. Klensin",
  title="{Request to Move STD 39 to Historic Status}",
  howpublished="RFC 3109 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3109",
  pages="1--4",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3109.txt",
  key="RFC 3109",
  abstract={This memo changes the status of STD 39, BBN Report 1822, ``Specification of the Interconnection of a Host and an IMP'', from Standard to Historic.  This memo provides information for the Internet community.},
  keywords="BBN 1822, host, imp, arpanet",
  doi="10.17487/RFC3109",
  }

@misc{rfc3110,
  author="D. {Eastlake 3rd}",
  title="{RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)}",
  howpublished="RFC 3110 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3110",
  pages="1--7",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc3110.txt",
  key="RFC 3110",
  abstract={This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]},
  keywords="RRs, resource, records, security",
  doi="10.17487/RFC3110",
  }

@misc{rfc3111,
  author="E. Guttman",
  title="{Service Location Protocol Modifications for IPv6}",
  howpublished="RFC 3111 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3111",
  pages="1--13",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3111.txt",
  key="RFC 3111",
  abstract={This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks.  Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]},
  keywords="SLP, internet, protocol",
  doi="10.17487/RFC3111",
  }

@misc{rfc3112,
  author="K. Zeilenga",
  title="{LDAP Authentication Password Schema}",
  howpublished="RFC 3112 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3112",
  pages="1--9",
  year=2001,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3112.txt",
  key="RFC 3112",
  abstract={This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type.  This memo provides information for the Internet community.},
  keywords="lightweight, directory, access, protocol",
  doi="10.17487/RFC3112",
  }

@misc{rfc3113,
  author="K. Rosenbrock and R. Sanmugam and S. Bradner and J. Klensin",
  title="{3GPP-IETF Standardization Collaboration}",
  howpublished="RFC 3113 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3113",
  pages="1--7",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3113.txt",
  key="RFC 3113",
  abstract={This document describes the standardization collaboration between 3GPP and IETF.  This memo provides information for the Internet community.},
  keywords="internet, engineering, task, force, third generation, partnership project",
  doi="10.17487/RFC3113",
  }

@misc{rfc3114,
  author="W. Nicolls",
  title="{Implementing Company Classification Policy with the S/MIME Security Label}",
  howpublished="RFC 3114 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3114",
  pages="1--14",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3114.txt",
  key="RFC 3114",
  abstract={This document discusses how company security policy for data classification can be mapped to the S/MIME security label.  Actual policies from three companies provide worked examples.  This memo provides information for the Internet community.},
  keywords="data, multipurpose, internet mail extensions, access control, information classification, security category",
  doi="10.17487/RFC3114",
  }

@misc{rfc3115,
  author="G. Dommety and K. Leung",
  title="{Mobile IP Vendor/Organization-Specific Extensions}",
  howpublished="RFC 3115 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3115",
  pages="1--9",
  year=2001,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3115.txt",
  key="RFC 3115",
  abstract={This document defines two new extensions to Mobile IP.  These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]},
  keywords="internet, protocol",
  doi="10.17487/RFC3115",
  }

@misc{rfc3116,
  author="J. Dunn and C. Martin",
  title="{Methodology for ATM Benchmarking}",
  howpublished="RFC 3116 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3116",
  pages="1--127",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3116.txt",
  key="RFC 3116",
  abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices.  In addition to defining the tests this document also describes specific formats for reporting the results of the tests.  This memo provides information for the Internet community.},
  keywords="asynchronous, transfer mode, formats, switching",
  doi="10.17487/RFC3116",
  }

@misc{rfc3117,
  author="M. Rose",
  title="{On the Design of Application Protocols}",
  howpublished="RFC 3117 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3117",
  pages="1--27",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3117.txt",
  key="RFC 3117",
  abstract={This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP).  This memo provides information for the Internet community.},
  keywords="beep, bxxp, blocks, extensible, exchange, text, binary",
  doi="10.17487/RFC3117",
  }

@misc{rfc3118,
  author="R. Droms and W. Arbaugh",
  title="{Authentication for DHCP Messages}",
  howpublished="RFC 3118 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3118",
  pages="1--17",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3118.txt",
  key="RFC 3118",
  abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol, verification",
  doi="10.17487/RFC3118",
  }

@misc{rfc3119,
  author="R. Finlayson",
  title="{A More Loss-Tolerant RTP Payload Format for MP3 Audio}",
  howpublished="RFC 3119 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3119",
  pages="1--19",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5219",
url="https://www.rfc-editor.org/rfc/rfc3119.txt",
  key="RFC 3119",
  abstract={This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as ``MP3'').  This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]},
  keywords="real-time, protocol, moving, picture, experts, group",
  doi="10.17487/RFC3119",
  }

@misc{rfc3120,
  author="K. Best and N. Walsh",
  title="{A URN Namespace for XML.org}",
  howpublished="RFC 3120 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3120",
  pages="1--5",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3120.txt",
  key="RFC 3120",
  abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents).  This memo provides information for the Internet community.},
  keywords="uniform, resource, name, extensible, markup, language",
  doi="10.17487/RFC3120",
  }

@misc{rfc3121,
  author="K. Best and N. Walsh",
  title="{A URN Namespace for OASIS}",
  howpublished="RFC 3121 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3121",
  pages="1--7",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3121.txt",
  key="RFC 3121",
  abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents).  This memo provides information for the Internet community.},
  keywords="uniform, resource, name, organization for the advancement of structured information standards",
  doi="10.17487/RFC3121",
  }

@misc{rfc3122,
  author="A. Conta",
  title="{Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification}",
  howpublished="RFC 3122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3122",
  pages="1--20",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3122.txt",
  key="RFC 3122",
  abstract={This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]},
  keywords="internet, protocol, IND, link-layer",
  doi="10.17487/RFC3122",
  }

@misc{rfc3123,
  author="P. Koch",
  title="{A DNS RR Type for Lists of Address Prefixes (APL RR)}",
  howpublished="RFC 3123 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3123",
  pages="1--8",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3123.txt",
  key="RFC 3123",
  abstract={The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records).  Several approaches exist to describe networks or address ranges.  This document specifies a new DNS RR type ``APL'' for address prefix lists.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain, name, system, resource, record",
  doi="10.17487/RFC3123",
  }

@misc{rfc3124,
  author="H. Balakrishnan and S. Seshan",
  title="{The Congestion Manager}",
  howpublished="RFC 3124 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3124",
  pages="1--22",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3124.txt",
  key="RFC 3124",
  abstract={This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]},
  keywords="network, stream, end-system module",
  doi="10.17487/RFC3124",
  }

@misc{rfc3125,
  author="J. Ross and D. Pinkas and N. Pope",
  title="{Electronic Signature Policies}",
  howpublished="RFC 3125 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3125",
  pages="1--44",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3125.txt",
  key="RFC 3125",
  abstract={This document defines signature policies for electronic signatures.  A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined.  A given legal/contractual context may recognize a particular signature policy as meeting its requirements.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="signer, purchase, contract, invoice, transactions, applications",
  doi="10.17487/RFC3125",
  }

@misc{rfc3126,
  author="D. Pinkas and J. Ross and N. Pope",
  title="{Electronic Signature Formats for long term electronic signatures}",
  howpublished="RFC 3126 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3126",
  pages="1--84",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5126",
url="https://www.rfc-editor.org/rfc/rfc3126.txt",
  key="RFC 3126",
  abstract={This document defines the format of an electronic signature that can remain valid over long periods.  This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature).  This memo provides information for the Internet community.},
  keywords="purchase, contract, invoice, application, smart cards, data",
  doi="10.17487/RFC3126",
  }

@misc{rfc3127,
  author="D. Mitton and M. St.Johns and S. Barkley and D. Nelson and B. Patil and M. Stevens and B. Wolff",
  title="{Authentication, Authorization, and Accounting: Protocol Evaluation}",
  howpublished="RFC 3127 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3127",
  pages="1--84",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3127.txt",
  key="RFC 3127",
  abstract={This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989.  This memo provides information for the Internet community.},
  keywords="AAA, network, access, requirements",
  doi="10.17487/RFC3127",
  }

@misc{rfc3128,
  author="I. Miller",
  title="{Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)}",
  howpublished="RFC 3128 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3128",
  pages="1--5",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3128.txt",
  key="RFC 3128",
  abstract={This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the ``Tiny Fragment Attack'' described in section 3.1 of the RFC.  This document describes the attack and recommends corrective action.  This memo provides information for the Internet community.},
  keywords="firewalls, internet",
  doi="10.17487/RFC3128",
  }

@misc{rfc3129,
  author="M. Thomas",
  title="{Requirements for Kerberized Internet Negotiation of Keys}",
  howpublished="RFC 3129 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3129",
  pages="1--6",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3129.txt",
  key="RFC 3129",
  abstract={The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.  This memo provides information for the Internet community.},
  keywords="KINK, cryptographic, security, authentication",
  doi="10.17487/RFC3129",
  }

@misc{rfc3130,
  author="E. Lewis",
  title="{Notes from the State-Of-The-Technology: DNSSEC}",
  howpublished="RFC 3130 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3130",
  pages="1--10",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3130.txt",
  key="RFC 3130",
  abstract={This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.  This memo provides information for the Internet community.},
  keywords="domain, name, system, security, extensions, report",
  doi="10.17487/RFC3130",
  }

@misc{rfc3131,
  author="S. Bradner and P. Calhoun and H. Cuschieri and S. Dennett and G. Flynn and M. Lipford and M. McPheters",
  title="{3GPP2-IETF Standardization Collaboration}",
  howpublished="RFC 3131 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3131",
  pages="1--8",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3131.txt",
  key="RFC 3131",
  abstract={This document describes the standardization collaboration between 3GPP2 and IETF.  This memo provides information for the Internet community.},
  keywords="internet, engineering, task, force, third generation, partnership project",
  doi="10.17487/RFC3131",
  }

@misc{rfc3132,
  author="J. Kempf",
  title="{Dormant Mode Host Alerting (``IP Paging'') Problem Statement}",
  howpublished="RFC 3132 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3132",
  pages="1--14",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3132.txt",
  key="RFC 3132",
  abstract={This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging.  This memo provides information for the Internet community.},
  keywords="molulity, radio, link, internet, protocl",
  doi="10.17487/RFC3132",
  }

@misc{rfc3133,
  author="J. Dunn and C. Martin",
  title="{Terminology for Frame Relay Benchmarking}",
  howpublished="RFC 3133 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3133",
  pages="1--24",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3133.txt",
  key="RFC 3133",
  abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices.  This memo provides information for the Internet community.},
  keywords="switching, devices, signaling",
  doi="10.17487/RFC3133",
  }

@misc{rfc3134,
  author="J. Dunn and C. Martin",
  title="{Terminology for ATM ABR Benchmarking}",
  howpublished="RFC 3134 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3134",
  pages="1--16",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3134.txt",
  key="RFC 3134",
  abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate).  This memo provides information for the Internet community.},
  keywords="asynchronous, transfer, mode, available, bit rate",
  doi="10.17487/RFC3134",
  }

@misc{rfc3135,
  author="J. Border and M. Kojo and J. Griner and G. Montenegro and Z. Shelby",
  title="{Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations}",
  howpublished="RFC 3135 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3135",
  pages="1--45",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3135.txt",
  key="RFC 3135",
  abstract={This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments.  This memo provides information for the Internet community.},
  keywords="PEP, PILC, TCP, transmission, control, protocol",
  doi="10.17487/RFC3135",
  }

@misc{rfc3136,
  author="L. Slutsman and I. Faynberg and H. Lu and M. Weissman",
  title="{The SPIRITS Architecture}",
  howpublished="RFC 3136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3136",
  pages="1--10",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3136.txt",
  key="RFC 3136",
  abstract={This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet.  This memo provides information for the Internet community.},
  keywords="PSTN, public, switched, telephone, network",
  doi="10.17487/RFC3136",
  }

@misc{rfc3137,
  author="A. Retana and L. Nguyen and R. White and A. Zinin and D. McPherson",
  title="{OSPF Stub Router Advertisement}",
  howpublished="RFC 3137 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3137",
  pages="1--5",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6987",
url="https://www.rfc-editor.org/rfc/rfc3137.txt",
  key="RFC 3137",
  abstract={This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router.  This memo provides information for the Internet community.},
  keywords="open, shortest, path, first",
  doi="10.17487/RFC3137",
  }

@misc{rfc3138,
  author="D. Meyer",
  title="{Extended Assignments in 233/8}",
  howpublished="RFC 3138 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3138",
  pages="1--4",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5771",
url="https://www.rfc-editor.org/rfc/rfc3138.txt",
  key="RFC 3138",
  abstract={This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space.  This memo provides information for the Internet community.},
  keywords="internet, address, AS, autonomous, system, number",
  doi="10.17487/RFC3138",
  }

@misc{rfc3139,
  author="L. Sanchez and K. McCloghrie and J. Saperia",
  title="{Requirements for Configuration Management of IP-based Networks}",
  howpublished="RFC 3139 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3139",
  pages="1--11",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3139.txt",
  key="RFC 3139",
  abstract={This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks.  This memo provides information for the Internet community.},
  keywords="internet, protocol",
  doi="10.17487/RFC3139",
  }

@misc{rfc3140,
  author="D. Black and S. Brim and B. Carpenter and F. Le Faucheur",
  title="{Per Hop Behavior Identification Codes}",
  howpublished="RFC 3140 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3140",
  pages="1--8",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3140.txt",
  key="RFC 3140",
  abstract={This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages.  It replaces RFC 2836. [STANDARDS-TRACK]},
  keywords="PHB, differentiated, services, codepoint, DSCP",
  doi="10.17487/RFC3140",
  }

@misc{rfc3141,
  author="T. Hiller and P. Walsh and X. Chen and M. Munson and G. Dommety and S. Sivalingham and B. Lim and P. McCann and H. Shiino and B. Hirschman and S. Manning and R. Hsu and H. Koo and M. Lipford and P. Calhoun and C. Lo and E. Jaques and E. Campbell and Y.Xu and S.Baba and T.Ayaki and T.Seki and A.Hameed",
  title="{CDMA2000 Wireless Data Requirements for AAA}",
  howpublished="RFC 3141 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3141",
  pages="1--16",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3141.txt",
  key="RFC 3141",
  abstract={This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.  This memo provides information for the Internet community.},
  keywords="authentication, authorization, accounting",
  doi="10.17487/RFC3141",
  }

@misc{rfc3142,
  author="J. Hagino and K. Yamamoto",
  title="{An IPv6-to-IPv4 Transport Relay Translator}",
  howpublished="RFC 3142 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3142",
  pages="1--11",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3142.txt",
  key="RFC 3142",
  abstract={The document describes an IPv6-to-IPv4 transport relay translator (TRT).  This memo provides information for the Internet community.},
  keywords="TRT, internet, protocol",
  doi="10.17487/RFC3142",
  }

@misc{rfc3143,
  author="I. Cooper and J. Dilley",
  title="{Known HTTP Proxy/Caching Problems}",
  howpublished="RFC 3143 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3143",
  pages="1--32",
  year=2001,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3143.txt",
  key="RFC 3143",
  abstract={This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers.  The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems.  This memo provides information for the Internet community.},
  keywords="www, world wide web, hypertext transfer, protocol",
  doi="10.17487/RFC3143",
  }

@misc{rfc3144,
  author="D. Romascanu",
  title="{Remote Monitoring MIB Extensions for Interface Parameters Monitoring}",
  howpublished="RFC 3144 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3144",
  pages="1--30",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3144.txt",
  key="RFC 3144",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]},
  keywords="management, information, base",
  doi="10.17487/RFC3144",
  }

@misc{rfc3145,
  author="R. Verma and M. Verma and J. Carlson",
  title="{L2TP Disconnect Cause Information}",
  howpublished="RFC 3145 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3145",
  pages="1--10",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3145.txt",
  key="RFC 3145",
  abstract={This document provides an extension to the Layer 2 Tunneling Protocol (``L2TP''), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]},
  keywords="layer2, tunneling, PPP, point-to-point, accounting, debugging",
  doi="10.17487/RFC3145",
  }

@misc{rfc3146,
  author="K. Fujisawa and A. Onoe",
  title="{Transmission of IPv6 Packets over IEEE 1394 Networks}",
  howpublished="RFC 3146 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3146",
  pages="1--8",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc3146.txt",
  key="RFC 3146",
  abstract={This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]},
  keywords="link-local, addresses, statelessly, autoconfigured",
  doi="10.17487/RFC3146",
  }

@misc{rfc3147,
  author="P. Christian",
  title="{Generic Routing Encapsulation over CLNS Networks}",
  howpublished="RFC 3147 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3147",
  pages="1--8",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3147.txt",
  key="RFC 3147",
  abstract={This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation).  This may then be used as a method to tunnel IPv4 or IPv6 over CLNS.  This memo provides information for the Internet community.},
  keywords="connectionless, network, service, GRE, layer, protocol",
  doi="10.17487/RFC3147",
  }

@misc{rfc3148,
  author="M. Mathis and M. Allman",
  title="{A Framework for Defining Empirical Bulk Transfer Capacity Metrics}",
  howpublished="RFC 3148 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3148",
  pages="1--16",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3148.txt",
  key="RFC 3148",
  abstract={This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity.  This memo provides information for the Internet community.},
  keywords="BTC, transport, data",
  doi="10.17487/RFC3148",
  }

@misc{rfc3149,
  author="A. Srinath and G. Levendel and K. Fritz and R. Kalyanaram",
  title="{MGCP Business Phone Packages}",
  howpublished="RFC 3149 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3149",
  pages="1--41",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3149.txt",
  key="RFC 3149",
  abstract={This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones.  This memo provides information for the Internet community.},
  keywords="media, gateway, control, packages",
  doi="10.17487/RFC3149",
  }

@misc{rfc3150,
  author="S. Dawkins and G. Montenegro and M. Kojo and V. Magret",
  title="{End-to-end Performance Implications of Slow Links}",
  howpublished="RFC 3150 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3150",
  pages="1--17",
  year=2001,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3150.txt",
  key="RFC 3150",
  abstract={This document makes performance-related recommendations for users of network paths that traverse ``very low bit-rate'' links.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="PILC, data, applications, header, compression",
  doi="10.17487/RFC3150",
  }

@misc{rfc3151,
  author="N. Walsh and J. Cowan and P. Grosso",
  title="{A URN Namespace for Public Identifiers}",
  howpublished="RFC 3151 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3151",
  pages="1--9",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3151.txt",
  key="RFC 3151",
  abstract={This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax.  This memo provides information for the Internet community.},
  keywords="uniform, resource, name, publicid",
  doi="10.17487/RFC3151",
  }

@misc{rfc3152,
  author="R. Bush",
  title="{Delegation of IP6.ARPA}",
  howpublished="RFC 3152 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3152",
  pages="1--4",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3596",
url="https://www.rfc-editor.org/rfc/rfc3152.txt",
  key="RFC 3152",
  abstract={This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, protocol, domain, name, system, DNS, zone",
  doi="10.17487/RFC3152",
  }

@misc{rfc3153,
  author="R. Pazhyannur and I. Ali and C. Fox",
  title="{PPP Multiplexing}",
  howpublished="RFC 3153 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3153",
  pages="1--9",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3153.txt",
  key="RFC 3153",
  abstract={This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]},
  keywords="point-to-point, protocol",
  doi="10.17487/RFC3153",
  }

@misc{rfc3154,
  author="J. Kempf and C. Castelluccia and P. Mutaf and N. Nakajima and Y. Ohba and R. Ramjee and Y. Saifullah and B. Sarikaya and X. Xu",
  title="{Requirements and Functional Architecture for an IP Host Alerting Protocol}",
  howpublished="RFC 3154 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3154",
  pages="1--16",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3154.txt",
  key="RFC 3154",
  abstract={This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode.  The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging.  This memo provides information for the Internet community.},
  keywords="internet, protocol, paging, mobile, hosts",
  doi="10.17487/RFC3154",
  }

@misc{rfc3155,
  author="S. Dawkins and G. Montenegro and M. Kojo and V. Magret and N. Vaidya",
  title="{End-to-end Performance Implications of Links with Errors}",
  howpublished="RFC 3155 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3155",
  pages="1--16",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3155.txt",
  key="RFC 3155",
  abstract={This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="TCP, transmission, control, protocol",
  doi="10.17487/RFC3155",
  }

@misc{rfc3156,
  author="M. Elkins and D. Del Torto and R. Levien and T. Roessler",
  title="{MIME Security with OpenPGP}",
  howpublished="RFC 3156 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3156",
  pages="1--15",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3156.txt",
  key="RFC 3156",
  abstract={This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]},
  keywords="MIME-PGP, Authentication, Encryption",
  doi="10.17487/RFC3156",
  }

@misc{rfc3157,
  author="A. Arsenault and S. Farrell",
  title="{Securely Available Credentials - Requirements}",
  howpublished="RFC 3157 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3157",
  pages="1--20",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3157.txt",
  key="RFC 3157",
  abstract={This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.  This memo provides information for the Internet community.},
  keywords="SACRED, trusted roots, private keys, PSE, personal security environment",
  doi="10.17487/RFC3157",
  }

@misc{rfc3158,
  author="C. Perkins and J. Rosenberg and H. Schulzrinne",
  title="{RTP Testing Strategies}",
  howpublished="RFC 3158 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3158",
  pages="1--22",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3158.txt",
  key="RFC 3158",
  abstract={This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.  This memo provides information for the Internet community.},
  keywords="real-time, transport protocol",
  doi="10.17487/RFC3158",
  }

@misc{rfc3159,
  author="K. McCloghrie and M. Fine and J. Seligson and K. Chan and S. Hahn and R. Sahita and A. Smith and F. Reichmeyer",
  title="{Structure of Policy Provisioning Information (SPPI)}",
  howpublished="RFC 3159 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3159",
  pages="1--40",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3159.txt",
  key="RFC 3159",
  abstract={This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]},
  keywords="PIB, base, SNMP, simple, network, management, information, SMI",
  doi="10.17487/RFC3159",
  }

@misc{rfc3160,
  author="S. Harris",
  title="{The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force}",
  howpublished="RFC 3160 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3160",
  pages="1--38",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4677",
url="https://www.rfc-editor.org/rfc/rfc3160.txt",
  key="RFC 3160",
  abstract={This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process.  This memo provides information for the Internet community.},
  keywords="Internet, Engineering, Task, Force, Meeting",
  doi="10.17487/RFC3160",
  }

@misc{rfc3161,
  author="C. Adams and P. Cain and D. Pinkas and R. Zuccherato",
  title="{Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)}",
  howpublished="RFC 3161 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3161",
  pages="1--26",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5816",
url="https://www.rfc-editor.org/rfc/rfc3161.txt",
  key="RFC 3161",
  abstract={This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned.  It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]},
  keywords="TSA, authority, security, request, response",
  doi="10.17487/RFC3161",
  }

@misc{rfc3162,
  author="B. Aboba and G. Zorn and D. Mitton",
  title="{RADIUS and IPv6}",
  howpublished="RFC 3162 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3162",
  pages="1--12",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8044",
url="https://www.rfc-editor.org/rfc/rfc3162.txt",
  key="RFC 3162",
  abstract={This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]},
  keywords="remote, authentication, dial in user, service, attributes",
  doi="10.17487/RFC3162",
  }

@misc{rfc3163,
  author="R. Zuccherato and M. Nystrom",
  title="{ISO/IEC 9798-3 Authentication SASL Mechanism}",
  howpublished="RFC 3163 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3163",
  pages="1--17",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3163.txt",
  key="RFC 3163",
  abstract={This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="simple, authentication, security, layer",
  doi="10.17487/RFC3163",
  }

@misc{rfc3164,
  author="C. Lonvick",
  title="{The BSD Syslog Protocol}",
  howpublished="RFC 3164 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3164",
  pages="1--29",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5424",
url="https://www.rfc-editor.org/rfc/rfc3164.txt",
  key="RFC 3164",
  abstract={This document describes the observed behavior of the syslog protocol.  This memo provides information for the Internet community.},
  keywords="berkeley, software, distribution, transmission, messages",
  doi="10.17487/RFC3164",
  }

@misc{rfc3165,
  author="D. Levi and J. Schoenwaelder",
  title="{Definitions of Managed Objects for the Delegation of Management Scripts}",
  howpublished="RFC 3165 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3165",
  pages="1--64",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3165.txt",
  key="RFC 3165",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]},
  keywords="mib, information, base",
  doi="10.17487/RFC3165",
  }

@misc{rfc3166,
  author="D. Meyer and J. Scudder",
  title="{Request to Move RFC 1403 to Historic Status}",
  howpublished="RFC 3166 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3166",
  pages="1--3",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3166.txt",
  key="RFC 3166",
  abstract={RFC 1403, ``BGP OSPF Interaction'', describes technology which is no longer used.  This document requests that RFC 1403 be moved to Historic status.  This memo provides information for the Internet community.},
  keywords="BGP-OSPF, Border gateway protocol, Open shortest path first routing",
  doi="10.17487/RFC3166",
  }

@misc{rfc3167,
  author="D. Meyer and J. Scudder",
  title="{Request to Move RFC 1745 to Historic Status}",
  howpublished="RFC 3167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3167",
  pages="1--3",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3167.txt",
  key="RFC 3167",
  abstract={RFC 1745, ``BGP4/IDRP for IP---OSPF Interaction'', describes technology which was never deployed in the public internet.  This document requests that RFC 1745 be moved to Historic status.  This memo provides information for the Internet community.},
  keywords="BGP4/IDRP, Internet, Inter-Domain, Routing, Protocol, Border, Gateway, Open, Shortest, Path, First",
  doi="10.17487/RFC3167",
  }

@misc{rfc3168,
  author="K. Ramakrishnan and S. Floyd and D. Black",
  title="{The Addition of Explicit Congestion Notification (ECN) to IP}",
  howpublished="RFC 3168 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3168",
  pages="1--63",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4301, 6040",
url="https://www.rfc-editor.org/rfc/rfc3168.txt",
  key="RFC 3168",
  abstract={This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]},
  keywords="internet, protocol, header",
  doi="10.17487/RFC3168",
  }

@misc{rfc3169,
  author="M. Beadles and D. Mitton",
  title="{Criteria for Evaluating Network Access Server Protocols}",
  howpublished="RFC 3169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3169",
  pages="1--17",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3169.txt",
  key="RFC 3169",
  abstract={This document defines requirements for protocols used by Network Access Servers (NAS).  This memo provides information for the Internet community.},
  keywords="NAS, network, device, AAA, authentication, authorization, accounting",
  doi="10.17487/RFC3169",
  }

@misc{rfc3170,
  author="B. Quinn and K. Almeroth",
  title="{IP Multicast Applications: Challenges and Solutions}",
  howpublished="RFC 3170 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3170",
  pages="1--28",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3170.txt",
  key="RFC 3170",
  abstract={This document describes the challenges involved with designing and implementing multicast applications.  It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications.  This memo provides information for the Internet community.},
  keywords="internet, protocol, unicast",
  doi="10.17487/RFC3170",
  }

@misc{rfc3171,
  author="Z. Albanna and K. Almeroth and D. Meyer and M. Schipper",
  title="{IANA Guidelines for IPv4 Multicast Address Assignments}",
  howpublished="RFC 3171 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3171",
  pages="1--8",
  year=2001,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5771",
url="https://www.rfc-editor.org/rfc/rfc3171.txt",
  key="RFC 3171",
  abstract={This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, assigned, numbers, authority, protocol, parameters",
  doi="10.17487/RFC3171",
  }

@misc{rfc3172,
  author="G. Huston",
  title="{Management Guidelines \& Operational Requirements for the Address and Routing Parameter Area Domain (``arpa'')}",
  howpublished="RFC 3172 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3172",
  pages="1--8",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3172.txt",
  key="RFC 3172",
  abstract={This memo describes the management and operational requirements for the address and routing parameter area (``arpa'') domain.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="database, DNS, domain, name, system",
  doi="10.17487/RFC3172",
  }

@misc{rfc3173,
  author="A. Shacham and B. Monsour and R. Pereira and M. Thomas",
  title="{IP Payload Compression Protocol (IPComp)}",
  howpublished="RFC 3173 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3173",
  pages="1--13",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3173.txt",
  key="RFC 3173",
  abstract={This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]},
  keywords="IPCOMP, internet, protocol, datagram, lossless",
  doi="10.17487/RFC3173",
  }

@misc{rfc3174,
  author="D. {Eastlake 3rd} and P. Jones",
  title="{US Secure Hash Algorithm 1 (SHA1)}",
  howpublished="RFC 3174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3174",
  pages="1--22",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4634, 6234",
url="https://www.rfc-editor.org/rfc/rfc3174.txt",
  key="RFC 3174",
  abstract={The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community.  This memo provides information for the Internet community.},
  keywords="FIPS, federal, information, processing, standard",
  doi="10.17487/RFC3174",
  }

@misc{rfc3175,
  author="F. Baker and C. Iturralde and F. Le Faucheur and B. Davie",
  title="{Aggregation of RSVP for IPv4 and IPv6 Reservations}",
  howpublished="RFC 3175 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3175",
  pages="1--36",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5350",
url="https://www.rfc-editor.org/rfc/rfc3175.txt",
  key="RFC 3175",
  abstract={This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network.  It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required.  It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, internet, ATM, asynchronous, transfer, mode",
  doi="10.17487/RFC3175",
  }

@misc{rfc3176,
  author="P. Phaal and S. Panchen and N. McKee",
  title="{InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks}",
  howpublished="RFC 3176 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3176",
  pages="1--31",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3176.txt",
  key="RFC 3176",
  abstract={This memo defines InMon Corporation's sFlow system.  sFlow is a technology for monitoring traffic in data networks containing switches and routers.  In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector.  This memo provides information for the Internet community.},
  keywords="agent, data, MIB, management, information, base",
  doi="10.17487/RFC3176",
  }

@misc{rfc3177,
  author="IAB and IESG",
  title="{IAB/IESG Recommendations on IPv6 Address Allocations to Sites}",
  howpublished="RFC 3177 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3177",
  pages="1--10",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6177",
url="https://www.rfc-editor.org/rfc/rfc3177.txt",
  key="RFC 3177",
  abstract={This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites.  In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.},
  keywords="internet, architecture, board, engineering, steering, group, protocol",
  doi="10.17487/RFC3177",
  }

@misc{rfc3178,
  author="J. Hagino and H. Snyder",
  title="{IPv6 Multihoming Support at Site Exit Routers}",
  howpublished="RFC 3178 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3178",
  pages="1--12",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3178.txt",
  key="RFC 3178",
  abstract={The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements.  This memo provides information for the Internet community.},
  keywords="internet, protocol, ISP, Service, Provider, Routing",
  doi="10.17487/RFC3178",
  }

@misc{rfc3179,
  author="J. Schoenwaelder and J. Quittek",
  title="{Script MIB Extensibility Protocol Version 1.1}",
  howpublished="RFC 3179 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3179",
  pages="1--25",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3179.txt",
  key="RFC 3179",
  abstract={The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations.  The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="SMX, language, management, information, base",
  doi="10.17487/RFC3179",
  }

@misc{rfc3180,
  author="D. Meyer and P. Lothberg",
  title="{GLOP Addressing in 233/8}",
  howpublished="RFC 3180 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3180",
  pages="1--5",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3180.txt",
  key="RFC 3180",
  abstract={This document defines the policy for the use of 233/8 for statically e assigned multicast addresses.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="static, multicast",
  doi="10.17487/RFC3180",
  }

@misc{rfc3181,
  author="S. Herzog",
  title="{Signaled Preemption Priority Policy Element}",
  howpublished="RFC 3181 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3181",
  pages="1--12",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3181.txt",
  key="RFC 3181",
  abstract={This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]},
  keywords="rsvp, resource, reservation, protocol, cops, common, open, service",
  doi="10.17487/RFC3181",
  }

@misc{rfc3182,
  author="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. Moore and S. Herzog and R. Hess",
  title="{Identity Representation for RSVP}",
  howpublished="RFC 3182 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3182",
  pages="1--18",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3182.txt",
  key="RFC 3182",
  abstract={This document describes the representation of identity information in POLICY\_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP).  The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.  We describe the encoding of identities as RSVP policy element.  We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol",
  doi="10.17487/RFC3182",
  }

@misc{rfc3183,
  author="T. Dean and W. Ottaway",
  title="{Domain Security Services using S/MIME}",
  howpublished="RFC 3183 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3183",
  pages="1--24",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3183.txt",
  key="RFC 3183",
  abstract={This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services.  These services are collectively referred to as 'Domain Security Services'.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="secure/multipurpose, internet, mail, extensions",
  doi="10.17487/RFC3183",
  }

@misc{rfc3184,
  author="S. Harris",
  title="{IETF Guidelines for Conduct}",
  howpublished="RFC 3184 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3184",
  pages="1--4",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7154",
url="https://www.rfc-editor.org/rfc/rfc3184.txt",
  key="RFC 3184",
  abstract={This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, engineering, task, force",
  doi="10.17487/RFC3184",
  }

@misc{rfc3185,
  author="S. Farrell and S. Turner",
  title="{Reuse of CMS Content Encryption Keys}",
  howpublished="RFC 3185 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3185",
  pages="1--10",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3185.txt",
  key="RFC 3185",
  abstract={This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]},
  keywords="cryptographic, message, syntax, data, packets",
  doi="10.17487/RFC3185",
  }

@misc{rfc3186,
  author="S. Shimizu and T. Kawano and K. Murakami and E. Beier",
  title="{MAPOS/PPP Tunneling mode}",
  howpublished="RFC 3186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3186",
  pages="1--14",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3186.txt",
  key="RFC 3186",
  abstract={This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks.  Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead.  This memo provides information for the Internet community.},
  keywords="multiple, access, protocol, over, SONET/SDH, point-to-point",
  doi="10.17487/RFC3186",
  }

@misc{rfc3187,
  author="J. Hakala and H. Walravens",
  title="{Using International Standard Book Numbers as Uniform Resource Names}",
  howpublished="RFC 3187 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3187",
  pages="1--11",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3187.txt",
  key="RFC 3187",
  abstract={This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141.  Much of the discussion below is based on the ideas expressed in RFC 2288.  This memo provides information for the Internet community.},
  keywords="isbn, urn, bibliographic, identifiers",
  doi="10.17487/RFC3187",
  }

@misc{rfc3188,
  author="J. Hakala",
  title="{Using National Bibliography Numbers as Uniform Resource Names}",
  howpublished="RFC 3188 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3188",
  pages="1--13",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3188.txt",
  key="RFC 3188",
  abstract={This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141.  Much of the discussion is based on the ideas expressed in RFC 2288.  This memo provides information for the Internet community.},
  keywords="urn, nbn, national, libraries",
  doi="10.17487/RFC3188",
  }

@misc{rfc3189,
  author="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann",
  title="{RTP Payload Format for DV (IEC 61834) Video}",
  howpublished="RFC 3189 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3189",
  pages="1--13",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6469",
url="https://www.rfc-editor.org/rfc/rfc3189.txt",
  key="RFC 3189",
  abstract={This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as ``DV'' into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]},
  keywords="real-time, transport, protocol",
  doi="10.17487/RFC3189",
  }

@misc{rfc3190,
  author="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann",
  title="{RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio}",
  howpublished="RFC 3190 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3190",
  pages="1--17",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3190.txt",
  key="RFC 3190",
  abstract={This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP).  This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling.  The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]},
  keywords="real-time, transport, protocol, digital, audio, tape",
  doi="10.17487/RFC3190",
  }

@misc{rfc3191,
  author="C. Allocchio",
  title="{Minimal GSTN address format in Internet Mail}",
  howpublished="RFC 3191 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3191",
  pages="1--13",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3191.txt",
  key="RFC 3191",
  abstract={This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called ``telephone numbers'') in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]},
  keywords="MIN-PSTN, global, switched, telephone, network, email",
  doi="10.17487/RFC3191",
  }

@misc{rfc3192,
  author="C. Allocchio",
  title="{Minimal FAX address format in Internet Mail}",
  howpublished="RFC 3192 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3192",
  pages="1--11",
  year=2001,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3192.txt",
  key="RFC 3192",
  abstract={This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]},
  keywords="MINFAX-IM, facsimile, GSTN, global, switched, telephone, network",
  doi="10.17487/RFC3192",
  }

@misc{rfc3193,
  author="B. Patel and B. Aboba and W. Dixon and G. Zorn and S. Booth",
  title="{Securing L2TP using IPsec}",
  howpublished="RFC 3193 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3193",
  pages="1--28",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3193.txt",
  key="RFC 3193",
  abstract={This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection.  Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]},
  keywords="layer, two, tunneling, protocol, authentication",
  doi="10.17487/RFC3193",
  }

@misc{rfc3194,
  author="A. Durand and C. Huitema",
  title="{The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio}",
  howpublished="RFC 3194 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3194",
  pages="1--7",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3194.txt",
  key="RFC 3194",
  abstract={This document provides an update on the ``H ratio'' defined in RFC 1715.  It defines a new ratio which the authors claim is easier to understand.  This memo provides information for the Internet community.},
  keywords="IPng, White, Paper",
  doi="10.17487/RFC3194",
  }

@misc{rfc3195,
  author="D. New and M. Rose",
  title="{Reliable Delivery for syslog}",
  howpublished="RFC 3195 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3195",
  pages="1--36",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3195.txt",
  key="RFC 3195",
  abstract={The BSD Syslog Protocol describes a number of service options related to propagating event messages.  This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]},
  keywords="mappings, encryption, authentication, beep, blocks, extensible, exchange",
  doi="10.17487/RFC3195",
  }

@misc{rfc3196,
  author="T. Hastings and C. Manros and P. Zehler and C. Kugler and H. Holst",
  title="{Internet Printing Protocol/1.1: Implementor's Guide}",
  howpublished="RFC 3196 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3196",
  pages="1--96",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3196.txt",
  key="RFC 3196",
  abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).  This memo provides information for the Internet community.},
  keywords="IPP, client, object",
  doi="10.17487/RFC3196",
  }

@misc{rfc3197,
  author="R. Austein",
  title="{Applicability Statement for DNS MIB Extensions}",
  howpublished="RFC 3197 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3197",
  pages="1--5",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3197.txt",
  key="RFC 3197",
  abstract={This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status.  This memo provides information for the Internet community.},
  keywords="DNS-R-MIB, Domain, Name, System, Management, Information, Base",
  doi="10.17487/RFC3197",
  }

@misc{rfc3198,
  author="A. Westerinen and J. Schnizlein and J. Strassner and M. Scherling and B. Quinn and S. Herzog and A. Huynh and M. Carlson and J. Perry and S. Waldbusser",
  title="{Terminology for Policy-Based Management}",
  howpublished="RFC 3198 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3198",
  pages="1--21",
  year=2001,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3198.txt",
  key="RFC 3198",
  abstract={This document is a glossary of policy-related terms.  It provides abbreviations, explanations, and recommendations for use of these terms.  The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).  This memo provides information for the Internet community.},
  keywords="glossary, network, ISDs, internet, standard, documents",
  doi="10.17487/RFC3198",
  }

@misc{rfc3199,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 3100-3199}",
  howpublished="RFC 3199 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3199",
  pages="1--24",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3199.txt",
  key="RFC 3199",
  doi="10.17487/RFC3199",
  }

@misc{rfc3201,
  author="R. Steinberger and O. Nicklass",
  title="{Definitions of Managed Objects for Circuit to Interface Translation}",
  howpublished="RFC 3201 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3201",
  pages="1--23",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3201.txt",
  key="RFC 3201",
  abstract={This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable.  This is important for circuits that must be used within other MIB modules which require an ifEntry.  It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]},
  keywords="mib",
  doi="10.17487/RFC3201",
  }

@misc{rfc3202,
  author="R. Steinberger and O. Nicklass",
  title="{Definitions of Managed Objects for Frame Relay Service Level Definitions}",
  howpublished="RFC 3202 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3202",
  pages="1--64",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3202.txt",
  key="RFC 3202",
  abstract={This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]},
  keywords="mib",
  doi="10.17487/RFC3202",
  }

@misc{rfc3203,
  author="Y. T'Joens and C. Hublet and P. De Schrijver",
  title="{DHCP reconfigure extension}",
  howpublished="RFC 3203 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3203",
  pages="1--6",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6704",
url="https://www.rfc-editor.org/rfc/rfc3203.txt",
  key="RFC 3203",
  abstract={This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]},
  keywords="dynamic, host, configuration, protocol, forcerenew",
  doi="10.17487/RFC3203",
  }

@misc{rfc3204,
  author="E. Zimmerer and J. Peterson and A. Vemuri and L. Ong and F. Audet and M. Watson and M. Zonoun",
  title="{MIME media types for ISUP and QSIG Objects}",
  howpublished="RFC 3204 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3204",
  pages="1--10",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3459, 5621",
url="https://www.rfc-editor.org/rfc/rfc3204.txt",
  key="RFC 3204",
  abstract={This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048.  These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]},
  keywords="multipart, internet, mail, extensions",
  doi="10.17487/RFC3204",
  }

@misc{rfc3205,
  author="K. Moore",
  title="{On the use of HTTP as a Substrate}",
  howpublished="RFC 3205 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3205",
  pages="1--14",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3205.txt",
  key="RFC 3205",
  abstract={Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols.  This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="hypertext, transfer, protocol, layering",
  doi="10.17487/RFC3205",
  }

@misc{rfc3206,
  author="R. Gellens",
  title="{The SYS and AUTH POP Response Codes}",
  howpublished="RFC 3206 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3206",
  pages="1--6",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3206.txt",
  key="RFC 3206",
  abstract={This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure.  In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]},
  keywords="security, authentication",
  doi="10.17487/RFC3206",
  }

@misc{rfc3207,
  author="P. Hoffman",
  title="{SMTP Service Extension for Secure SMTP over Transport Layer Security}",
  howpublished="RFC 3207 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3207",
  pages="1--9",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7817",
url="https://www.rfc-editor.org/rfc/rfc3207.txt",
  key="RFC 3207",
  abstract={This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet.  This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]},
  keywords="simple, mail, transfer, protocol, ssl, tls",
  doi="10.17487/RFC3207",
  }

@misc{rfc3208,
  author="T. Speakman and J. Crowcroft and J. Gemmell and D. Farinacci and S. Lin and D. Leshchiner and M. Luby and T. Montgomery and L. Rizzo and A. Tweedly and N. Bhaskar and R. Edmonstone and R. Sumanasekera and L. Vicisano",
  title="{PGM Reliable Transport Protocol Specification}",
  howpublished="RFC 3208 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3208",
  pages="1--111",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3208.txt",
  key="RFC 3208",
  abstract={Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers.  PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss.  PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements.  Its central design goal is simplicity of operation with due regard for scalability and network efficiency.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="pragmatic, general, multicast",
  doi="10.17487/RFC3208",
  }

@misc{rfc3209,
  author="D. Awduche and L. Berger and D. Gan and T. Li and V. Srinivasan and G. Swallow",
  title="{RSVP-TE: Extensions to RSVP for LSP Tunnels}",
  howpublished="RFC 3209 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3209",
  pages="1--61",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3936, 4420, 4874, 5151, 5420, 5711, 6780, 6790, 7274",
url="https://www.rfc-editor.org/rfc/rfc3209.txt",
  key="RFC 3209",
  abstract={This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]},
  keywords="resource, reservation, protocol, label, switched, paths",
  doi="10.17487/RFC3209",
  }

@misc{rfc3210,
  author="D. Awduche and A. Hannan and X. Xiao",
  title="{Applicability Statement for Extensions to RSVP for LSP-Tunnels}",
  howpublished="RFC 3210 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3210",
  pages="1--8",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3210.txt",
  key="RFC 3210",
  abstract={This memo discusses the applicability of ``Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels''.  It highlights the protocol's principles of operation and describes the network context for which it was designed.  Guidelines for deployment are offered and known protocol limitations are indicated.  This document is intended to accompany the submission of ``Extensions to RSVP for LSP Tunnels'' onto the Internet standards track.  This memo provides information for the Internet community.},
  keywords="resource, reservation, protocol, label, switched, paths",
  doi="10.17487/RFC3210",
  }

@misc{rfc3211,
  author="P. Gutmann",
  title="{Password-based Encryption for CMS}",
  howpublished="RFC 3211 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3211",
  pages="1--17",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 3369, 3370",
url="https://www.rfc-editor.org/rfc/rfc3211.txt",
  key="RFC 3211",
  abstract={This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key.  The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]},
  keywords="cryptographic, message, syntax, S/MIME, key wrap, derivation, passwordrecipientinfo, PWRI",
  doi="10.17487/RFC3211",
  }

@misc{rfc3212,
  author="B. Jamoussi and L. Andersson and R. Callon and R. Dantu and L. Wu and P. Doolan and T. Worster and N. Feldman and A. Fredette and M. Girish and E. Gray and J. Heinanen and T. Kilty and A. Malis",
  title="{Constraint-Based LSP Setup using LDP}",
  howpublished="RFC 3212 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3212",
  pages="1--42",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3468, 7358",
url="https://www.rfc-editor.org/rfc/rfc3212.txt",
  key="RFC 3212",
  abstract={This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]},
  keywords="label, switching, protocol, distribution, CR",
  doi="10.17487/RFC3212",
  }

@misc{rfc3213,
  author="J. Ash and M. Girish and E. Gray and B. Jamoussi and G. Wright",
  title="{Applicability Statement for CR-LDP}",
  howpublished="RFC 3213 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3213",
  pages="1--7",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3213.txt",
  key="RFC 3213",
  abstract={This document discusses the applicability of Constraint-Based LSP Setup using LDP.  It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol.  This document is a prerequisite to advancing CR-LDP on the standards track.  This memo provides information for the Internet community.},
  keywords="constraint-based, label, distribution, protocol",
  doi="10.17487/RFC3213",
  }

@misc{rfc3214,
  author="J. Ash and Y. Lee and P. Ashwood-Smith and B. Jamoussi and D. Fedyk and D. Skalecki and L. Li",
  title="{LSP Modification Using CR-LDP}",
  howpublished="RFC 3214 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3214",
  pages="1--11",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3214.txt",
  key="RFC 3214",
  abstract={This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]},
  keywords="label, switching, protocol, constraint-based, distribution",
  doi="10.17487/RFC3214",
  }

@misc{rfc3215,
  author="C. Boscher and P. Cheval and L. Wu and E. Gray",
  title="{LDP State Machine}",
  howpublished="RFC 3215 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3215",
  pages="1--78",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3215.txt",
  key="RFC 3215",
  abstract={This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs.  In the current LDP specification, there is no state machine specified for processing LDP messages.  We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations.  This memo provides information for the Internet community.},
  keywords="label, distribution, protocol",
  doi="10.17487/RFC3215",
  }

@misc{rfc3216,
  author="C. Elliott and D. Harrington and J. Jason and J. Schoenwaelder and F. Strauss and W. Weiss",
  title="{SMIng Objectives}",
  howpublished="RFC 3216 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3216",
  pages="1--33",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3216.txt",
  key="RFC 3216",
  abstract={This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.  This memo provides information for the Internet community.},
  keywords="SNMP, simple, network, management, protocol, COPS-PR, common, open, policy, service, provisioning",
  doi="10.17487/RFC3216",
  }

@misc{rfc3217,
  author="R. Housley",
  title="{Triple-DES and RC2 Key Wrapping}",
  howpublished="RFC 3217 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3217",
  pages="1--9",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3217.txt",
  key="RFC 3217",
  abstract={This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key.  This memo provides information for the Internet community.},
  keywords="algorithm, data encryption standard",
  doi="10.17487/RFC3217",
  }

@misc{rfc3218,
  author="E. Rescorla",
  title="{Preventing the Million Message Attack on Cryptographic Message Syntax}",
  howpublished="RFC 3218 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3218",
  pages="1--7",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3218.txt",
  key="RFC 3218",
  abstract={This memo describes a strategy for resisting the Million Message Attack.  This memo provides information for the Internet community.},
  keywords="cryptographic, syntax",
  doi="10.17487/RFC3218",
  }

@misc{rfc3219,
  author="J. Rosenberg and H. Salama and M. Squire",
  title="{Telephony Routing over IP (TRIP)}",
  howpublished="RFC 3219 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3219",
  pages="1--79",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3219.txt",
  key="RFC 3219",
  abstract={This document presents the Telephony Routing over IP (TRIP).  TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations.  TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]},
  keywords="inter-administrative, BGP, border, gateway, protocol",
  doi="10.17487/RFC3219",
  }

@misc{rfc3220,
  author="C. Perkins",
  title="{IP Mobility Support for IPv4}",
  howpublished="RFC 3220 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3220",
  pages="1--98",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3344",
url="https://www.rfc-editor.org/rfc/rfc3220.txt",
  key="RFC 3220",
  abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet.  The protocol provides for registering the care-of address with a home agent.  The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address.  After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]},
  keywords="MOBILEIPSUPIP, Internet, Protocol",
  doi="10.17487/RFC3220",
  }

@misc{rfc3221,
  author="G. Huston",
  title="{Commentary on Inter-Domain Routing in the Internet}",
  howpublished="RFC 3221 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3221",
  pages="1--25",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3221.txt",
  key="RFC 3221",
  abstract={This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends.  The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.  This memo provides information for the Internet community.},
  keywords="BGP, border, gateway, protocol",
  doi="10.17487/RFC3221",
  }

@misc{rfc3222,
  author="G. Trotter",
  title="{Terminology for Forwarding Information Base (FIB) based Router Performance}",
  howpublished="RFC 3222 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3222",
  pages="1--15",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3222.txt",
  key="RFC 3222",
  abstract={This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router.  The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router.  This memo provides information for the Internet community.},
  keywords="internet, protocol, routing table, benchmark",
  doi="10.17487/RFC3222",
  }

@misc{rfc3224,
  author="E. Guttman",
  title="{Vendor Extensions for Service Location Protocol, Version 2}",
  howpublished="RFC 3224 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3224",
  pages="1--10",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3224.txt",
  key="RFC 3224",
  abstract={This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions.  The specification introduces a new SLPv2 extension: The Vendor Opaque Extension.  While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken.  This document udpates RFC 2608, ``The Service Location Protocol.'' [STANDARDS-TRACK]},
  keywords="SLP, SVRLOC, opaque",
  doi="10.17487/RFC3224",
  }

@misc{rfc3225,
  author="D. Conrad",
  title="{Indicating Resolver Support of DNSSEC}",
  howpublished="RFC 3225 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3225",
  pages="1--6",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3225.txt",
  key="RFC 3225",
  abstract={In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs.  This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]},
  keywords="domain, name, system, security, extensions",
  doi="10.17487/RFC3225",
  }

@misc{rfc3226,
  author="O. Gudmundsson",
  title="{DNSSEC and IPv6 A6 aware server/resolver message size requirements}",
  howpublished="RFC 3226 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3226",
  pages="1--6",
  year=2001,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3226.txt",
  key="RFC 3226",
  abstract={This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records.  This requirement is necessary because these new features increase the size of DNS messages.  If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load.  This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]},
  keywords="domain, name, space, security, extensions, dns, endso",
  doi="10.17487/RFC3226",
  }

@misc{rfc3227,
  author="D. Brezinski and T. Killalea",
  title="{Guidelines for Evidence Collection and Archiving}",
  howpublished="RFC 3227 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3227",
  pages="1--10",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3227.txt",
  key="RFC 3227",
  abstract={A ``security incident'' as defined in the ``Internet Security Glossary'', RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached.  The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="security, incident",
  doi="10.17487/RFC3227",
  }

@misc{rfc3228,
  author="B. Fenner",
  title="{IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)}",
  howpublished="RFC 3228 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3228",
  pages="1--4",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3228.txt",
  key="RFC 3228",
  abstract={This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="assigned, numbers, authority",
  doi="10.17487/RFC3228",
  }

@misc{rfc3229,
  author="J. Mogul and B. Krishnamurthy and F. Douglis and A. Feldmann and Y. Goland and A. van Hoff and D. Hellerstein",
  title="{Delta encoding in HTTP}",
  howpublished="RFC 3229 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3229",
  pages="1--49",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3229.txt",
  key="RFC 3229",
  abstract={This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]},
  keywords="hyper, text, transfer, protocol",
  doi="10.17487/RFC3229",
  }

@misc{rfc3230,
  author="J. Mogul and A. Van Hoff",
  title="{Instance Digests in HTTP}",
  howpublished="RFC 3230 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3230",
  pages="1--13",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3230.txt",
  key="RFC 3230",
  abstract={HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body.  However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding).  Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances.  Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest.  This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]},
  keywords="hyper, text, transfer, protocol",
  doi="10.17487/RFC3230",
  }

@misc{rfc3231,
  author="D. Levi and J. Schoenwaelder",
  title="{Definitions of Managed Objects for Scheduling Management Operations}",
  howpublished="RFC 3231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3231",
  pages="1--29",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3231.txt",
  key="RFC 3231",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]},
  keywords="mib, information, base",
  doi="10.17487/RFC3231",
  }

@misc{rfc3232,
  author="J. Reynolds",
  title="{Assigned Numbers: RFC 1700 is Replaced by an On-line Database}",
  howpublished="RFC 3232 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3232",
  pages="1--3",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3232.txt",
  key="RFC 3232",
  abstract={This memo obsoletes RFC 1700 (STD 2) ``Assigned Numbers'', which contained an October 1994 snapshot of assigned Internet protocol parameters.  This memo provides information for the Internet community.},
  keywords="IANA, internet, assigned, numbers, authority, parameters",
  doi="10.17487/RFC3232",
  }

@misc{rfc3233,
  author="P. Hoffman and S. Bradner",
  title="{Defining the IETF}",
  howpublished="RFC 3233 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3233",
  pages="1--4",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3233.txt",
  key="RFC 3233",
  abstract={This document gives a more concrete definition of ``the IETF'' as it understood today.  Many RFCs refer to ``the IETF''.  Many important IETF documents speak of the IETF as if it were an already-defined entity.  However, no IETF document correctly defines what the IETF is.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet, engineering, task, force",
  doi="10.17487/RFC3233",
  }

@misc{rfc3234,
  author="B. Carpenter and S. Brim",
  title="{Middleboxes: Taxonomy and Issues}",
  howpublished="RFC 3234 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3234",
  pages="1--27",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3234.txt",
  key="RFC 3234",
  abstract={This document is intended as part of an IETF discussion about ``middleboxes'' - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host.  This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions.  It does not, however, claim to be definitive.  This memo provides information for the Internet community.},
  keywords="internet, protocol, router, data, path, host",
  doi="10.17487/RFC3234",
  }

@misc{rfc3235,
  author="D. Senie",
  title="{Network Address Translator (NAT)-Friendly Application Design Guidelines}",
  howpublished="RFC 3235 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3235",
  pages="1--13",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3235.txt",
  key="RFC 3235",
  abstract={This document discusses those things that application designers might wish to consider when designing new protocols.  While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices.  Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).  This memo provides information for the Internet community.},
  keywords="NAPT, ALG, firewall",
  doi="10.17487/RFC3235",
  }

@misc{rfc3236,
  author="M. Baker and P. Stark",
  title="{The 'application/xhtml+xml' Media Type}",
  howpublished="RFC 3236 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3236",
  pages="1--8",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3236.txt",
  key="RFC 3236",
  abstract={This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'.  This memo provides information for the Internet community.},
  keywords="mime, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC3236",
  }

@misc{rfc3237,
  author="M. Tuexen and Q. Xie and R. Stewart and M. Shore and L. Ong and J. Loughney and M. Stillman",
  title="{Requirements for Reliable Server Pooling}",
  howpublished="RFC 3237 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3237",
  pages="1--10",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3237.txt",
  key="RFC 3237",
  abstract={This document defines a basic set of requirements for reliable server pooling.  This memo provides information for the Internet community.},
  keywords="rserpool, application",
  doi="10.17487/RFC3237",
  }

@misc{rfc3238,
  author="S. Floyd and L. Daigle",
  title="{IAB Architectural and Policy Considerations for Open Pluggable Edge Services}",
  howpublished="RFC 3238 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3238",
  pages="1--17",
  year=2002,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3238.txt",
  key="RFC 3238",
  abstract={This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF.  OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client.  These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.  This memo provides information for the Internet community.},
  keywords="OPES, internet, architecture, board",
  doi="10.17487/RFC3238",
  }

@misc{rfc3239,
  author="C. Kugler and H. Lewis and T. Hastings",
  title="{Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations}",
  howpublished="RFC 3239 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3239",
  pages="1--15",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3239.txt",
  key="RFC 3239",
  abstract={This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1.  Some of these administrative operations operate on the IPP Job and Printer objects.  The remaining operations operate on a new Device object that more closely models a single output device.  This memo provides information for the Internet community.},
  keywords="object, device",
  doi="10.17487/RFC3239",
  }

@misc{rfc3240,
  author="D. Clunie and E. Cordonnier",
  title="{Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration}",
  howpublished="RFC 3240 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3240",
  pages="1--6",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3240.txt",
  key="RFC 3240",
  abstract={This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine).  The baseline encoding is defined by the DICOM Standards Committee in ``Digital Imaging and Communications in Medicine''.  This memo provides information for the Internet community.},
  keywords="multipurpose, internet, mail, extensions",
  doi="10.17487/RFC3240",
  }

@misc{rfc3241,
  author="C. Bormann",
  title="{Robust Header Compression (ROHC) over PPP}",
  howpublished="RFC 3241 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3241",
  pages="1--12",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4815",
url="https://www.rfc-editor.org/rfc/rfc3241.txt",
  key="RFC 3241",
  abstract={This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP).  It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]},
  keywords="point-to-point protocol, datagram, packets",
  doi="10.17487/RFC3241",
  }

@misc{rfc3242,
  author="L-E. Jonsson and G. Pelletier",
  title="{RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP}",
  howpublished="RFC 3242 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3242",
  pages="1--21",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4362",
url="https://www.rfc-editor.org/rfc/rfc3242.txt",
  key="RFC 3242",
  abstract={This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation.  The profile is built as an extension to the ROHC RTP profile.  It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]},
  keywords="internet, protocol, user, datagram, real-time application, transport",
  doi="10.17487/RFC3242",
  }

@misc{rfc3243,
  author="L-E. Jonsson",
  title="{RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression}",
  howpublished="RFC 3243 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3243",
  pages="1--6",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3243.txt",
  key="RFC 3243",
  abstract={This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group.  It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.},
  keywords="internet, protocol, user, datagram, real-time application, transport, applications, LLA, link-layer assisted",
  doi="10.17487/RFC3243",
  }

@misc{rfc3244,
  author="M. Swift and J. Trostle and J. Brezak",
  title="{Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols}",
  howpublished="RFC 3244 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3244",
  pages="1--7",
  year=2002,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3244.txt",
  key="RFC 3244",
  abstract={This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols.  The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol.  Change password is a request reply protocol that includes a KRB\_PRIV message that contains the new password for the user.  This memo provides information for the Internet community.},
  keywords="security, message, codes",
  doi="10.17487/RFC3244",
  }

@misc{rfc3245,
  author="J. Klensin and IAB",
  title="{The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)}",
  howpublished="RFC 3245 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3245",
  pages="1--10",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3245.txt",
  key="RFC 3245",
  abstract={RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB.  It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of ``country code''-level subdomains of the top-level ENUM domain.  Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions.  The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model.  The content of the three memos is provided in this document for the information of the IETF community.},
  keywords="IAB, ARPA",
  doi="10.17487/RFC3245",
  }

@misc{rfc3246,
  author="B. Davie and A. Charny and J.C.R. Bennet and K. Benson and J.Y. Le Boudec and W. Courtney and S. Davari and V. Firoiu and D. Stiliadis",
  title="{An Expedited Forwarding PHB (Per-Hop Behavior)}",
  howpublished="RFC 3246 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3246",
  pages="1--16",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3246.txt",
  key="RFC 3246",
  abstract={This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF).  The PHB is a basic building block in the Differentiated Services architecture.  EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate.  This document obsoletes RFC 2598. [STANDARDS-TRACK]},
  keywords="per-hop behavior, expedited forwarding, differentiated services, delay, jitter",
  doi="10.17487/RFC3246",
  }

@misc{rfc3247,
  author="A. Charny and J. Bennet and K. Benson and J. Boudec and A. Chiu and W. Courtney and S. Davari and V. Firoiu and C. Kalmanek and K. Ramakrishnan",
  title="{Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)}",
  howpublished="RFC 3247 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3247",
  pages="1--24",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3247.txt",
  key="RFC 3247",
  abstract={This document was written during the process of clarification of RFC2598 ``An Expedited Forwarding PHB'' that led to the publication of revised specification of EF ``An Expedited Forwarding PHB''.  Its primary motivation is providing additional explanation to the revised EF definition and its properties.  The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures.  This memo provides information for the Internet community.},
  keywords="differentiated services, fifo, fair queuing, delay, jitter",
  doi="10.17487/RFC3247",
  }

@misc{rfc3248,
  author="G. Armitage and B. Carpenter and A. Casati and J. Crowcroft and J. Halpern and B. Kumar and J. Schnizlein",
  title="{A Delay Bound alternative revision of RFC 2598}",
  howpublished="RFC 3248 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3248",
  pages="1--11",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3248.txt",
  key="RFC 3248",
  abstract={For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000.  The original definition of EF was based on comparison of forwarding on an unloaded network.  This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network.  At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB).  An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group.  At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB.  This memo provides information for the Internet community.},
  keywords="per hop behavior, phb, expedited forwarding, ef, db",
  doi="10.17487/RFC3248",
  }

@misc{rfc3249,
  author="V. Cancio and M. Moldovan and H. Tamura and D. Wing",
  title="{Implementers Guide for Facsimile Using Internet Mail}",
  howpublished="RFC 3249 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3249",
  pages="1--21",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3249.txt",
  key="RFC 3249",
  abstract={This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532.  This is an informational document and its guidelines do not supersede the referenced documents.  This memo provides information for the Internet community.},
  keywords="fax, tiff, tiff-fx, ifax, e-mail, email, esmtp, dsn, mdn",
  doi="10.17487/RFC3249",
  }

@misc{rfc3250,
  author="L. McIntyre and G. Parsons and J. Rafferty",
  title="{Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration}",
  howpublished="RFC 3250 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3250",
  pages="1--7",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3950",
url="https://www.rfc-editor.org/rfc/rfc3250.txt",
  key="RFC 3250",
  abstract={This document describes the registration of the MIME sub-type image/tiff-fx.  The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]},
  keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions",
  doi="10.17487/RFC3250",
  }

@misc{rfc3251,
  author="B. Rajagopalan",
  title="{Electricity over IP}",
  howpublished="RFC 3251 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3251",
  pages="1--9",
  year=2002,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3251.txt",
  key="RFC 3251",
  abstract={Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane).  According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity.  This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors).  Readers of the previous work have been observed scratching their heads and muttering, ``What next?''.  This document answers that question.  This memo provides information for the Internet community.},
  keywords="Internet Protocol",
  doi="10.17487/RFC3251",
  }

@misc{rfc3252,
  author="H. Kennedy",
  title="{Binary Lexical Octet Ad-hoc Transport}",
  howpublished="RFC 3252 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3252",
  pages="1--16",
  year=2002,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3252.txt",
  key="RFC 3252",
  abstract={This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.  This memo provides information for the Internet community.},
  keywords="bloat",
  doi="10.17487/RFC3252",
  }

@misc{rfc3253,
  author="G. Clemm and J. Amsden and T. Ellison and C. Kaler and J. Whitehead",
  title="{Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)}",
  howpublished="RFC 3253 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3253",
  pages="1--118",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3253.txt",
  key="RFC 3253",
  abstract={This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]},
  keywords="hypertext, transfer, protocol, clients, label, configuration, management",
  doi="10.17487/RFC3253",
  }

@misc{rfc3254,
  author="H. Alvestrand",
  title="{Definitions for talking about directories}",
  howpublished="RFC 3254 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3254",
  pages="1--11",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3254.txt",
  key="RFC 3254",
  abstract={When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use.  For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency.  On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability.  This document discusses one group of such systems which is known under the term, ``directories''.  This memo provides information for the Internet community.},
  keywords="domain, name, system, lightweight, access, protocol",
  doi="10.17487/RFC3254",
  }

@misc{rfc3255,
  author="N. Jones and C. Murton",
  title="{Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads}",
  howpublished="RFC 3255 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3255",
  pages="1--8",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3255.txt",
  key="RFC 3255",
  abstract={This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3255",
  }

@misc{rfc3256,
  author="D. Jones and R. Woundy",
  title="{The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option}",
  howpublished="RFC 3256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3256",
  pages="1--5",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3256.txt",
  key="RFC 3256",
  abstract={This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3256",
  }

@misc{rfc3257,
  author="L. Coene",
  title="{Stream Control Transmission Protocol Applicability Statement}",
  howpublished="RFC 3257 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3257",
  pages="1--13",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3257.txt",
  key="RFC 3257",
  abstract={This document describes the applicability of the Stream Control Transmission Protocol (SCTP).  It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) \& Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP.  This memo provides information for the Internet community.},
  keywords="sctp, udp, tcp, rtp, transport security, transport, nat, multihoming",
  doi="10.17487/RFC3257",
  }

@misc{rfc3258,
  author="T. Hardie",
  title="{Distributing Authoritative Name Servers via Shared Unicast Addresses}",
  howpublished="RFC 3258 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3258",
  pages="1--11",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3258.txt",
  key="RFC 3258",
  abstract={This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations.  The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas.  This memo provides information for the Internet community.},
  keywords="dns, network, topology, latency",
  doi="10.17487/RFC3258",
  }

@misc{rfc3259,
  author="J. Ott and C. Perkins and D. Kutscher",
  title="{A Message Bus for Local Coordination}",
  howpublished="RFC 3259 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3259",
  pages="1--39",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3259.txt",
  key="RFC 3259",
  abstract={The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components.  The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes.  The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6.  The IP multicast scope is limited to link-local multicast.  This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.  This memo provides information for the Internet community.},
  keywords="mbus, message, ip, multicast, addressing, transport, syntax",
  doi="10.17487/RFC3259",
  }

@misc{rfc3260,
  author="D. Grossman",
  title="{New Terminology and Clarifications for Diffserv}",
  howpublished="RFC 3260 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3260",
  pages="1--10",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3260.txt",
  key="RFC 3260",
  abstract={This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications.  It is intended to update RFC 2474, RFC 2475 and RFC 2597.  When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs.  This memo provides information for the Internet community.},
  keywords="DIFFSRV, scalability, IP, internet, protocol",
  doi="10.17487/RFC3260",
  }

@misc{rfc3261,
  author="J. Rosenberg and H. Schulzrinne and G. Camarillo and A. Johnston and J. Peterson and R. Sparks and M. Handley and E. Schooler",
  title="{SIP: Session Initiation Protocol}",
  howpublished="RFC 3261 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3261",
  pages="1--269",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, 6878, 7462, 7463",
url="https://www.rfc-editor.org/rfc/rfc3261.txt",
  key="RFC 3261",
  abstract={This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3261",
  }

@misc{rfc3262,
  author="J. Rosenberg and H. Schulzrinne",
  title="{Reliability of Provisional Responses in Session Initiation Protocol (SIP)}",
  howpublished="RFC 3262 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3262",
  pages="1--14",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3262.txt",
  key="RFC 3262",
  abstract={This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages.  This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3262",
  }

@misc{rfc3263,
  author="J. Rosenberg and H. Schulzrinne",
  title="{Session Initiation Protocol (SIP): Locating SIP Servers}",
  howpublished="RFC 3263 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3263",
  pages="1--17",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7984",
url="https://www.rfc-editor.org/rfc/rfc3263.txt",
  key="RFC 3263",
  abstract={The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact.  It also uses DNS to allow a server to send a response to a backup client if the primary client has failed.  This document describes those DNS procedures in detail. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3263",
  }

@misc{rfc3264,
  author="J. Rosenberg and H. Schulzrinne",
  title="{An Offer/Answer Model with Session Description Protocol (SDP)}",
  howpublished="RFC 3264 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3264",
  pages="1--25",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6157",
url="https://www.rfc-editor.org/rfc/rfc3264.txt",
  key="RFC 3264",
  abstract={This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3264",
  }

@misc{rfc3265,
  author="A. B. Roach",
  title="{Session Initiation Protocol (SIP)-Specific Event Notification}",
  howpublished="RFC 3265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3265",
  pages="1--38",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6665, updated by RFCs 5367, 5727, 6446",
url="https://www.rfc-editor.org/rfc/rfc3265.txt",
  key="RFC 3265",
  abstract={This document describes an extension to the Session Initiation Protocol (SIP).  The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3265",
  }

@misc{rfc3266,
  author="S. Olson and G. Camarillo and A. B. Roach",
  title="{Support for IPv6 in Session Description Protocol (SDP)}",
  howpublished="RFC 3266 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3266",
  pages="1--5",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4566",
url="https://www.rfc-editor.org/rfc/rfc3266.txt",
  key="RFC 3266",
  abstract={This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).  Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]},
  keywords="internet addresses syntax",
  doi="10.17487/RFC3266",
  }

@misc{rfc3267,
  author="J. Sjoberg and M. Westerlund and A. Lakaniemi and Q. Xie",
  title="{Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs}",
  howpublished="RFC 3267 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3267",
  pages="1--49",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4867",
url="https://www.rfc-editor.org/rfc/rfc3267.txt",
  key="RFC 3267",
  abstract={This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals.  The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks.  In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email.  Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]},
  keywords="interoperate, applications",
  doi="10.17487/RFC3267",
  }

@misc{rfc3268,
  author="P. Chown",
  title="{Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)}",
  howpublished="RFC 3268 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3268",
  pages="1--7",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5246",
url="https://www.rfc-editor.org/rfc/rfc3268.txt",
  key="RFC 3268",
  abstract={This document proposes several new ciphersuites.  At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES.  The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]},
  keywords="idea, international data algorithm, symmetric",
  doi="10.17487/RFC3268",
  }

@misc{rfc3269,
  author="R. Kermode and L. Vicisano",
  title="{Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents}",
  howpublished="RFC 3269 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3269",
  pages="1--12",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3269.txt",
  key="RFC 3269",
  abstract={This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions.  The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use.  In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.  This memo provides information for the Internet community.},
  keywords="definitions, operation",
  doi="10.17487/RFC3269",
  }

@misc{rfc3270,
  author="F. Le Faucheur and L. Wu and B. Davie and S. Davari and P. Vaananen and R. Krishnan and P. Cheval and J. Heinanen",
  title="{Multi-Protocol Label Switching (MPLS) Support of Differentiated Services}",
  howpublished="RFC 3270 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3270",
  pages="1--64",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3270.txt",
  key="RFC 3270",
  abstract={This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]},
  keywords="diff-serv, ba, behaviour aggregate, lsp, label switched paths",
  doi="10.17487/RFC3270",
  }

@misc{rfc3271,
  author="V. Cerf",
  title="{The Internet is for Everyone}",
  howpublished="RFC 3271 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3271",
  pages="1--6",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3271.txt",
  key="RFC 3271",
  abstract={This document expresses the Internet Society's ideology that the Internet really is for everyone.  However, it will only be such if we make it so.  This memo provides information for the Internet community.},
  keywords="isoc, internet society, policy issues, social impact, economic impact, international policy, use and abuse of the internet",
  doi="10.17487/RFC3271",
  }

@misc{rfc3272,
  author="D. Awduche and A. Chiu and A. Elwalid and I. Widjaja and X. Xiao",
  title="{Overview and Principles of Internet Traffic Engineering}",
  howpublished="RFC 3272 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3272",
  pages="1--71",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3272.txt",
  key="RFC 3272",
  abstract={This memo describes the principles of Traffic Engineering (TE) in the Internet.  The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet.  The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.  This memo provides information for the Internet community.},
  keywords="te, ip, networks",
  doi="10.17487/RFC3272",
  }

@misc{rfc3273,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base for High Capacity Networks}",
  howpublished="RFC 3273 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3273",
  pages="1--77",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4502",
url="https://www.rfc-editor.org/rfc/rfc3273.txt",
  key="RFC 3273",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks.  This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]},
  keywords="rmon, mib, high speed networks",
  doi="10.17487/RFC3273",
  }

@misc{rfc3274,
  author="P. Gutmann",
  title="{Compressed Data Content Type for Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3274 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3274",
  pages="1--6",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3274.txt",
  key="RFC 3274",
  abstract={This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type.  Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size.  Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]},
  keywords="content info type",
  doi="10.17487/RFC3274",
  }

@misc{rfc3275,
  author="D. {Eastlake 3rd} and J. Reagle and D. Solo",
  title="{(Extensible Markup Language) XML-Signature Syntax and Processing}",
  howpublished="RFC 3275 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3275",
  pages="1--73",
  year=2002,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3275.txt",
  key="RFC 3275",
  abstract={This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]},
  keywords="extensible, markup, language",
  doi="10.17487/RFC3275",
  }

@misc{rfc3276,
  author="B. Ray and R. Abbi",
  title="{Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing}",
  howpublished="RFC 3276 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3276",
  pages="1--66",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4319",
url="https://www.rfc-editor.org/rfc/rfc3276.txt",
  key="RFC 3276",
  abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]},
  keywords="mib, interfaces",
  doi="10.17487/RFC3276",
  }

@misc{rfc3277,
  author="D. McPherson",
  title="{Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance}",
  howpublished="RFC 3277 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3277",
  pages="1--6",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3277.txt",
  key="RFC 3277",
  abstract={This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions.  The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification.  This memo provides information for the Internet community.},
  keywords="router",
  doi="10.17487/RFC3277",
  }

@misc{rfc3278,
  author="S. Blake-Wilson and D. Brown and P. Lambert",
  title="{Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3278",
  pages="1--16",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5753",
url="https://www.rfc-editor.org/rfc/rfc3278.txt",
  key="RFC 3278",
  abstract={This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS).  The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content.  The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.  This memo provides information for the Internet community.},
  keywords="public key, digital signatures, authentication",
  doi="10.17487/RFC3278",
  }

@misc{rfc3279,
  author="L. Bassham and W. Polk and R. Housley",
  title="{Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 3279 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3279",
  pages="1--27",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4055, 4491, 5480, 5758",
url="https://www.rfc-editor.org/rfc/rfc3279.txt",
  key="RFC 3279",
  abstract={This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).  Digital signatures are used to sign certificates and certificate revocation list (CRLs).  Certificates include the public key of the named subject. [STANDARDS-TRACK]},
  keywords="ASN.1",
  doi="10.17487/RFC3279",
  }

@misc{rfc3280,
  author="R. Housley and W. Polk and W. Ford and D. Solo",
  title="{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 3280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3280",
  pages="1--129",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5280, updated by RFCs 4325, 4630",
url="https://www.rfc-editor.org/rfc/rfc3280.txt",
  key="RFC 3280",
  abstract={This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3280",
  }

@misc{rfc3281,
  author="S. Farrell and R. Housley",
  title="{An Internet Attribute Certificate Profile for Authorization}",
  howpublished="RFC 3281 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3281",
  pages="1--40",
  year=2002,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5755",
url="https://www.rfc-editor.org/rfc/rfc3281.txt",
  key="RFC 3281",
  abstract={This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols.  Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements.  The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements.  The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]},
  keywords="electronic mail, email, ipsec, www security",
  doi="10.17487/RFC3281",
  }

@misc{rfc3282,
  author="H. Alvestrand",
  title="{Content Language Headers}",
  howpublished="RFC 3282 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3282",
  pages="1--8",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3282.txt",
  key="RFC 3282",
  abstract={This document defines a ``Content-language:'' header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an ``Accept-Language:'' header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3282",
  }

@misc{rfc3283,
  author="B. Mahoney and G. Babics and A. Taler",
  title="{Guide to Internet Calendaring}",
  howpublished="RFC 3283 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3283",
  pages="1--16",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3283.txt",
  key="RFC 3283",
  abstract={This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them.  Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems.  The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP).  The work in progress addressed is ``Calendar Access Protocol'' (CAP).  This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work.  This memo provides information for the Internet community.},
  keywords="scheduling systems, cap, calendar access protocool, itip, imip",
  doi="10.17487/RFC3283",
  }

@misc{rfc3284,
  author="D. Korn and J. MacDonald and J. Mogul and K. Vo",
  title="{The VCDIFF Generic Differencing and Compression Data Format}",
  howpublished="RFC 3284 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3284",
  pages="1--29",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3284.txt",
  key="RFC 3284",
  abstract={This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]},
  keywords="transport, portable, at\&t, encoding",
  doi="10.17487/RFC3284",
  }

@misc{rfc3285,
  author="M. Gahrns and T. Hain",
  title="{Using Microsoft Word to create Internet Drafts and RFCs}",
  howpublished="RFC 3285 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3285",
  pages="1--19",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5385",
url="https://www.rfc-editor.org/rfc/rfc3285.txt",
  key="RFC 3285",
  abstract={This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3285",
  }

@misc{rfc3286,
  author="L. Ong and J. Yoakum",
  title="{An Introduction to the Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 3286 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3286",
  pages="1--10",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3286.txt",
  key="RFC 3286",
  abstract={This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP).  It is intended as a guide for potential users of SCTP as a general purpose transport protocol.  This memo provides information for the Internet community.},
  keywords="transport, layer, telephony, signaling",
  doi="10.17487/RFC3286",
  }

@misc{rfc3287,
  author="A. Bierman",
  title="{Remote Monitoring MIB Extensions for Differentiated Services}",
  howpublished="RFC 3287 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3287",
  pages="1--120",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3287.txt",
  key="RFC 3287",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]},
  keywords="rmon, management information base, diffserv",
  doi="10.17487/RFC3287",
  }

@misc{rfc3288,
  author="E. O'Tuathail and M. Rose",
  title="{Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 3288 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3288",
  pages="1--20",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4227",
url="https://www.rfc-editor.org/rfc/rfc3288.txt",
  key="RFC 3288",
  abstract={This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP).  A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]},
  keywords="binding, markup language, xml",
  doi="10.17487/RFC3288",
  }

@misc{rfc3289,
  author="F. Baker and K. Chan and A. Smith",
  title="{Management Information Base for the Differentiated Services Architecture}",
  howpublished="RFC 3289 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3289",
  pages="1--116",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3289.txt",
  key="RFC 3289",
  abstract={This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture.  It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]},
  keywords="mib, diffserv, router, architecture",
  doi="10.17487/RFC3289",
  }

@misc{rfc3290,
  author="Y. Bernet and S. Blake and D. Grossman and A. Smith",
  title="{An Informal Management Model for Diffserv Routers}",
  howpublished="RFC 3290 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3290",
  pages="1--56",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3290.txt",
  key="RFC 3290",
  abstract={This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration.  This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers.  It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.  This memo provides information for the Internet community.},
  keywords="differentiated services",
  doi="10.17487/RFC3290",
  }

@misc{rfc3291,
  author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder",
  title="{Textual Conventions for Internet Network Addresses}",
  howpublished="RFC 3291 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3291",
  pages="1--20",
  year=2002,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4001",
url="https://www.rfc-editor.org/rfc/rfc3291.txt",
  key="RFC 3291",
  abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information.  The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="tc, mib, layer, management, information, base",
  doi="10.17487/RFC3291",
  }

@misc{rfc3292,
  author="A. Doria and F. Hellstrand and K. Sundell and T. Worster",
  title="{General Switch Management Protocol (GSMP) V3}",
  howpublished="RFC 3292 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3292",
  pages="1--137",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3292.txt",
  key="RFC 3292",
  abstract={This document describes the General Switch Management Protocol Version 3 (GSMPv3).  The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch.  The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]},
  keywords="switch, label, unicast, multicast, qos, quality of service",
  doi="10.17487/RFC3292",
  }

@misc{rfc3293,
  author="T. Worster and A. Doria and J. Buerkle",
  title="{General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)}",
  howpublished="RFC 3293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3293",
  pages="1--9",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3293.txt",
  key="RFC 3293",
  abstract={This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3293",
  }

@misc{rfc3294,
  author="A. Doria and K. Sundell",
  title="{General Switch Management Protocol (GSMP) Applicability}",
  howpublished="RFC 3294 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3294",
  pages="1--9",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3294.txt",
  key="RFC 3294",
  abstract={This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment.  It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration.  This memo provides information for the Internet community.},
  keywords="internet",
  doi="10.17487/RFC3294",
  }

@misc{rfc3295,
  author="H. Sjostrand and J. Buerkle and B. Srinivasan",
  title="{Definitions of Managed Objects for the General Switch Management Protocol (GSMP)}",
  howpublished="RFC 3295 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3295",
  pages="1--47",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3295.txt",
  key="RFC 3295",
  abstract={This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community.  In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]},
  keywords="mib, management information base, controller, gsmp-mib",
  doi="10.17487/RFC3295",
  }

@misc{rfc3296,
  author="K. Zeilenga",
  title="{Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories}",
  howpublished="RFC 3296 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3296",
  pages="1--14",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3296.txt",
  key="RFC 3296",
  abstract={This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]},
  keywords="schema, elements, description, formats",
  doi="10.17487/RFC3296",
  }

@misc{rfc3297,
  author="G. Klyne and R. Iwazaki and D. Crocker",
  title="{Content Negotiation for Messaging Services based on Email}",
  howpublished="RFC 3297 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3297",
  pages="1--46",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3297.txt",
  key="RFC 3297",
  abstract={This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]},
  keywords="facsimile",
  doi="10.17487/RFC3297",
  }

@misc{rfc3298,
  author="I. Faynberg and J. Gato and H. Lu and L. Slutsman",
  title="{Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements}",
  howpublished="RFC 3298 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3298",
  pages="1--17",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3298.txt",
  key="RFC 3298",
  abstract={This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for ``Service in the PSTN/IN Requesting InTernet Service''.) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet.  Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.  To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks.  The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.  This memo provides information for the Internet community.},
  keywords="support",
  doi="10.17487/RFC3298",
  }

@misc{rfc3299,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 3200-3299}",
  howpublished="RFC 3299 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3299",
  pages="1--30",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3299.txt",
  key="RFC 3299",
  doi="10.17487/RFC3299",
  }

@misc{rfc3300,
  author="J. Reynolds and R. Braden and S. Ginoza and A. De La Cruz",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 3300 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3300",
  pages="1--49",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3600",
url="https://www.rfc-editor.org/rfc/rfc3300.txt",
  key="RFC 3300",
  doi="10.17487/RFC3300",
  }

@misc{rfc3301,
  author="Y. T'Joens and P. Crivellari and B. Sales",
  title="{Layer Two Tunnelling Protocol (L2TP): ATM access network extensions}",
  howpublished="RFC 3301 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3301",
  pages="1--19",
  year=2002,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3301.txt",
  key="RFC 3301",
  keywords="",
  doi="10.17487/RFC3301",
  }

@misc{rfc3302,
  author="G. Parsons and J. Rafferty",
  title="{Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration}",
  howpublished="RFC 3302 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3302",
  pages="1--8",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3302.txt",
  key="RFC 3302",
  keywords="TIFF, Multipurpose, Internet, Mail, extensions",
  doi="10.17487/RFC3302",
  }

@misc{rfc3303,
  author="P. Srisuresh and J. Kuthan and J. Rosenberg and A. Molitor and A. Rayhan",
  title="{Middlebox communication architecture and framework}",
  howpublished="RFC 3303 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3303",
  pages="1--34",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3303.txt",
  key="RFC 3303",
  keywords="midcom",
  doi="10.17487/RFC3303",
  }

@misc{rfc3304,
  author="R. P. Swale and P. A. Mart and P. Sijben and S. Brim and M. Shore",
  title="{Middlebox Communications (midcom) Protocol Requirements}",
  howpublished="RFC 3304 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3304",
  pages="1--9",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3304.txt",
  key="RFC 3304",
  keywords="nat, network address protocol, firewall middleboxes",
  doi="10.17487/RFC3304",
  }

@misc{rfc3305,
  author="M. Mealling and R. Denenberg",
  title="{Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations}",
  howpublished="RFC 3305 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3305",
  pages="1--11",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3305.txt",
  key="RFC 3305",
  keywords="internet engineering task force",
  doi="10.17487/RFC3305",
  }

@misc{rfc3306,
  author="B. Haberman and D. Thaler",
  title="{Unicast-Prefix-based IPv6 Multicast Addresses}",
  howpublished="RFC 3306 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3306",
  pages="1--7",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3956, 4489, 7371",
url="https://www.rfc-editor.org/rfc/rfc3306.txt",
  key="RFC 3306",
  keywords="internet protocol",
  doi="10.17487/RFC3306",
  }

@misc{rfc3307,
  author="B. Haberman",
  title="{Allocation Guidelines for IPv6 Multicast Addresses}",
  howpublished="RFC 3307 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3307",
  pages="1--8",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3307.txt",
  key="RFC 3307",
  keywords="internet protocol",
  doi="10.17487/RFC3307",
  }

@misc{rfc3308,
  author="P. Calhoun and W. Luo and D. McPherson and K. Peirce",
  title="{Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension}",
  howpublished="RFC 3308 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3308",
  pages="1--10",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3308.txt",
  key="RFC 3308",
  keywords="per hop behavior, phb, diffserv",
  doi="10.17487/RFC3308",
  }

@misc{rfc3309,
  author="J. Stone and R. Stewart and D. Otis",
  title="{Stream Control Transmission Protocol (SCTP) Checksum Change}",
  howpublished="RFC 3309 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3309",
  pages="1--17",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4960",
url="https://www.rfc-editor.org/rfc/rfc3309.txt",
  key="RFC 3309",
  keywords="adler-32, checksum, error detection",
  doi="10.17487/RFC3309",
  }

@misc{rfc3310,
  author="A. Niemi and J. Arkko and V. Torvinen",
  title="{Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)}",
  howpublished="RFC 3310 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3310",
  pages="1--18",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3310.txt",
  key="RFC 3310",
  keywords="one-time password generation mechanism, umts, universal mobile telecommunications system",
  doi="10.17487/RFC3310",
  }

@misc{rfc3311,
  author="J. Rosenberg",
  title="{The Session Initiation Protocol (SIP) UPDATE Method}",
  howpublished="RFC 3311 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3311",
  pages="1--13",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3311.txt",
  key="RFC 3311",
  keywords="parameters, media streams",
  doi="10.17487/RFC3311",
  }

@misc{rfc3312,
  author="G. Camarillo and W. Marshall and J. Rosenberg",
  title="{Integration of Resource Management and Session Initiation Protocol (SIP)}",
  howpublished="RFC 3312 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3312",
  pages="1--30",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4032, 5027",
url="https://www.rfc-editor.org/rfc/rfc3312.txt",
  key="RFC 3312",
  keywords="qos, quality of service, precondition",
  doi="10.17487/RFC3312",
  }

@misc{rfc3313,
  author="W. Marshall",
  title="{Private Session Initiation Protocol (SIP) Extensions for Media Authorization}",
  howpublished="RFC 3313 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3313",
  pages="1--16",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3313.txt",
  key="RFC 3313",
  keywords="qos, quality of service",
  doi="10.17487/RFC3313",
  }

@misc{rfc3314,
  author="M. Wasserman",
  title="{Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards}",
  howpublished="RFC 3314 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3314",
  pages="1--23",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3314.txt",
  key="RFC 3314",
  keywords="internet protocol",
  doi="10.17487/RFC3314",
  }

@misc{rfc3315,
  author="R. Droms and J. Bound and B. Volz and T. Lemon and C. Perkins and M. Carney",
  title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 3315 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3315",
  pages="1--101",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4361, 5494, 6221, 6422, 6644, 7083, 7227, 7283, 7550",
url="https://www.rfc-editor.org/rfc/rfc3315.txt",
  key="RFC 3315",
  keywords="internet protocol, parameters, addresses",
  doi="10.17487/RFC3315",
  }

@misc{rfc3316,
  author="J. Arkko and G. Kuijpers and H. Soliman and J. Loughney and J. Wiljakka",
  title="{Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts}",
  howpublished="RFC 3316 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3316",
  pages="1--22",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7066",
url="https://www.rfc-editor.org/rfc/rfc3316.txt",
  key="RFC 3316",
  keywords="links, bandwidth",
  doi="10.17487/RFC3316",
  }

@misc{rfc3317,
  author="K. Chan and R. Sahita and S. Hahn and K. McCloghrie",
  title="{Differentiated Services Quality of Service Policy Information Base}",
  howpublished="RFC 3317 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3317",
  pages="1--96",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3317.txt",
  key="RFC 3317",
  keywords="pib, differentiated services architecture",
  doi="10.17487/RFC3317",
  }

@misc{rfc3318,
  author="R. Sahita and S. Hahn and K. Chan and K. McCloghrie",
  title="{Framework Policy Information Base}",
  howpublished="RFC 3318 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3318",
  pages="1--70",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3318.txt",
  key="RFC 3318",
  abstract={This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning. Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each.},
  doi="10.17487/RFC3318",
  }

@misc{rfc3319,
  author="H. Schulzrinne and B. Volz",
  title="{Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers}",
  howpublished="RFC 3319 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3319",
  pages="1--7",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3319.txt",
  key="RFC 3319",
  keywords="outbound proxy servers",
  doi="10.17487/RFC3319",
  }

@misc{rfc3320,
  author="R. Price and C. Bormann and J. Christoffersson and H. Hannu and Z. Liu and J. Rosenberg",
  title="{Signaling Compression (SigComp)}",
  howpublished="RFC 3320 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3320",
  pages="1--62",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4896",
url="https://www.rfc-editor.org/rfc/rfc3320.txt",
  key="RFC 3320",
  keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine",
  doi="10.17487/RFC3320",
  }

@misc{rfc3321,
  author="H. Hannu and J. Christoffersson and S. Forsgren and K.-C. Leung and Z. Liu and R. Price",
  title="{Signaling Compression (SigComp) - Extended Operations}",
  howpublished="RFC 3321 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3321",
  pages="1--19",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4896",
url="https://www.rfc-editor.org/rfc/rfc3321.txt",
  key="RFC 3321",
  keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine",
  doi="10.17487/RFC3321",
  }

@misc{rfc3322,
  author="H. Hannu",
  title="{Signaling Compression (SigComp) Requirements \& Assumptions}",
  howpublished="RFC 3322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3322",
  pages="1--13",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3322.txt",
  key="RFC 3322",
  keywords="sip, session initiation protocol, wireless, cellular, sdp, session description protocol",
  doi="10.17487/RFC3322",
  }

@misc{rfc3323,
  author="J. Peterson",
  title="{A Privacy Mechanism for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3323",
  pages="1--22",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3323.txt",
  key="RFC 3323",
  keywords="privacy service",
  doi="10.17487/RFC3323",
  }

@misc{rfc3324,
  author="M. Watson",
  title="{Short Term Requirements for Network Asserted Identity}",
  howpublished="RFC 3324 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3324",
  pages="1--11",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3324.txt",
  key="RFC 3324",
  keywords="session initiation protocol, sip, ua, user agent",
  doi="10.17487/RFC3324",
  }

@misc{rfc3325,
  author="C. Jennings and J. Peterson and M. Watson",
  title="{Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks}",
  howpublished="RFC 3325 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3325",
  pages="1--18",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5876",
url="https://www.rfc-editor.org/rfc/rfc3325.txt",
  key="RFC 3325",
  keywords="trust domain",
  doi="10.17487/RFC3325",
  }

@misc{rfc3326,
  author="H. Schulzrinne and D. Oran and G. Camarillo",
  title="{The Reason Header Field for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3326 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3326",
  pages="1--8",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3326.txt",
  key="RFC 3326",
  abstract={The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, ``Path'' which provides such a mechanism. [STANDARDS-TRACK]},
  keywords="heterogeneous error response forking problem, herfp",
  doi="10.17487/RFC3326",
  }

@misc{rfc3327,
  author="D. Willis and B. Hoeneisen",
  title="{Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts}",
  howpublished="RFC 3327 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3327",
  pages="1--17",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5626",
url="https://www.rfc-editor.org/rfc/rfc3327.txt",
  key="RFC 3327",
  keywords="3gpp, register, contact, path, registrar, user agent, ua",
  doi="10.17487/RFC3327",
  }

@misc{rfc3329,
  author="J. Arkko and V. Torvinen and G. Camarillo and A. Niemi and T. Haukka",
  title="{Security Mechanism Agreement for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3329 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3329",
  pages="1--24",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3329.txt",
  key="RFC 3329",
  keywords="ua, user agent",
  doi="10.17487/RFC3329",
  }

@misc{rfc3330,
  author="IANA",
  title="{Special-Use IPv4 Addresses}",
  howpublished="RFC 3330 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3330",
  pages="1--7",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5735",
url="https://www.rfc-editor.org/rfc/rfc3330.txt",
  key="RFC 3330",
  keywords="internet protocol, space assignments",
  doi="10.17487/RFC3330",
  }

@misc{rfc3331,
  author="K. Morneault and R. Dantu and G. Sidebottom and B. Bidulock and J. Heitz",
  title="{Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer}",
  howpublished="RFC 3331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3331",
  pages="1--94",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3331.txt",
  key="RFC 3331",
  keywords="sctp, stream control transmission protocol, sg, signaling gateway, media gateway controller, mgc",
  doi="10.17487/RFC3331",
  }

@misc{rfc3332,
  author="G. Sidebottom and K. Morneault and J. Pastor-Balbas",
  title="{Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)}",
  howpublished="RFC 3332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3332",
  pages="1--120",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4666",
url="https://www.rfc-editor.org/rfc/rfc3332.txt",
  key="RFC 3332",
  keywords="isup, sccp, sctp, stream control tranmission protocol, mgc, media gateway protocol, st, signalling gateway",
  doi="10.17487/RFC3332",
  }

@misc{rfc3334,
  author="T. Zseby and S. Zander and C. Carle",
  title="{Policy-Based Accounting}",
  howpublished="RFC 3334 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3334",
  pages="1--44",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3334.txt",
  key="RFC 3334",
  keywords="measurement, metering, meter configuration, qos auditing, aaa, aaa architecture, inter-domain accounting",
  doi="10.17487/RFC3334",
  }

@misc{rfc3335,
  author="T. Harding and R. Drummond and C. Shih",
  title="{MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet}",
  howpublished="RFC 3335 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3335",
  pages="1--29",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3335.txt",
  key="RFC 3335",
  keywords="multipurpose, internet mail extensions, edi",
  doi="10.17487/RFC3335",
  }

@misc{rfc3336,
  author="B. Thompson and T. Koren and B. Buffam",
  title="{PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)}",
  howpublished="RFC 3336 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3336",
  pages="1--16",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3336.txt",
  key="RFC 3336",
  keywords="point-to-point, protocol, atm, aal2, datagram, packets",
  doi="10.17487/RFC3336",
  }

@misc{rfc3337,
  author="B. Thompson and T. Koren and B. Buffam",
  title="{Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2}",
  howpublished="RFC 3337 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3337",
  pages="1--7",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3337.txt",
  key="RFC 3337",
  keywords="point-to-point, protocol, atm, aal2, encapsulation",
  doi="10.17487/RFC3337",
  }

@misc{rfc3338,
  author="S. Lee and M-K. Shin and Y-J. Kim and E. Nordmark and A. Durand",
  title="{Dual Stack Hosts Using ``Bump-in-the-API'' (BIA)}",
  howpublished="RFC 3338 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3338",
  pages="1--17",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6535",
url="https://www.rfc-editor.org/rfc/rfc3338.txt",
  key="RFC 3338",
  keywords="",
  doi="10.17487/RFC3338",
  }

@misc{rfc3339,
  author="G. Klyne and C. Newman",
  title="{Date and Time on the Internet: Timestamps}",
  howpublished="RFC 3339 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3339",
  pages="1--18",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3339.txt",
  key="RFC 3339",
  keywords="gregorian calendar, iso",
  doi="10.17487/RFC3339",
  }

@misc{rfc3340,
  author="M. Rose and G. Klyne and D. Crocker",
  title="{The Application Exchange Core}",
  howpublished="RFC 3340 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3340",
  pages="1--40",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3340.txt",
  key="RFC 3340",
  keywords="APEX",
  doi="10.17487/RFC3340",
  }

@misc{rfc3341,
  author="M. Rose and G. Klyne and D. Crocker",
  title="{The Application Exchange (APEX) Access Service}",
  howpublished="RFC 3341 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3341",
  pages="1--26",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3341.txt",
  key="RFC 3341",
  keywords="APEX",
  doi="10.17487/RFC3341",
  }

@misc{rfc3342,
  author="E. Dixon and H. Franklin and J. Kint and G. Klyne and D. New and S. Pead and M. Rose and M. Schwartz",
  title="{The Application Exchange (APEX) Option Party Pack, Part Deux!}",
  howpublished="RFC 3342 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3342",
  pages="1--22",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3342.txt",
  key="RFC 3342",
  keywords="datagram, service, core, relaying, mesh",
  doi="10.17487/RFC3342",
  }

@misc{rfc3343,
  author="M. Rose and G. Klyne and D. Crocker",
  title="{The Application Exchange (APEX) Presence Service}",
  howpublished="RFC 3343 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3343",
  pages="1--23",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3343.txt",
  key="RFC 3343",
  keywords="endpoint",
  doi="10.17487/RFC3343",
  }

@misc{rfc3344,
  author="C. Perkins",
  title="{IP Mobility Support for IPv4}",
  howpublished="RFC 3344 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3344",
  pages="1--99",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5944, updated by RFCs 4636, 4721",
url="https://www.rfc-editor.org/rfc/rfc3344.txt",
  key="RFC 3344",
  keywords="MOBILEIPSUPIP, Internet, Protocol",
  doi="10.17487/RFC3344",
  }

@misc{rfc3345,
  author="D. McPherson and V. Gill and D. Walton and A. Retana",
  title="{Border Gateway Protocol (BGP) Persistent Route Oscillation Condition}",
  howpublished="RFC 3345 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3345",
  pages="1--19",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3345.txt",
  key="RFC 3345",
  keywords="idr, ibgp",
  doi="10.17487/RFC3345",
  }

@misc{rfc3346,
  author="J. Boyle and V. Gill and A. Hannan and D. Cooper and D. Awduche and B. Christian and W.S. Lai",
  title="{Applicability Statement for Traffic Engineering with MPLS}",
  howpublished="RFC 3346 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3346",
  pages="1--14",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3346.txt",
  key="RFC 3346",
  keywords="multiprotocol label switching, te",
  doi="10.17487/RFC3346",
  }

@misc{rfc3347,
  author="M. Krueger and R. Haagens",
  title="{Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations}",
  howpublished="RFC 3347 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3347",
  pages="1--26",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3347.txt",
  key="RFC 3347",
  keywords="scsi, tcp. storage, fibre channel",
  doi="10.17487/RFC3347",
  }

@misc{rfc3348,
  author="M. Gahrns and R. Cheng",
  title="{The Internet Message Action Protocol (IMAP4) Child Mailbox Extension}",
  howpublished="RFC 3348 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3348",
  pages="1--6",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3348.txt",
  key="RFC 3348",
  keywords="children",
  doi="10.17487/RFC3348",
  }

@misc{rfc3349,
  author="M. Rose",
  title="{A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force}",
  howpublished="RFC 3349 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3349",
  pages="1--6",
  year=2002,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3349.txt",
  key="RFC 3349",
  keywords="beep",
  doi="10.17487/RFC3349",
  }

@misc{rfc3351,
  author="N. Charlton and M. Gasson and G. Gybels and M. Spanner and A. van Wijk",
  title="{User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals}",
  howpublished="RFC 3351 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3351",
  pages="1--17",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3351.txt",
  key="RFC 3351",
  keywords="relay service, transcoding service, textphone",
  doi="10.17487/RFC3351",
  }

@misc{rfc3352,
  author="K. Zeilenga",
  title="{Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status}",
  howpublished="RFC 3352 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3352",
  pages="1--4",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3352.txt",
  key="RFC 3352",
  keywords="CLDAP, CLDAP, Presentation, Address, Application, Entity, Title",
  doi="10.17487/RFC3352",
  }

@misc{rfc3353,
  author="D. Ooms and B. Sales and W. Livens and A. Acharya and F. Griffoul and F. Ansari",
  title="{Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment}",
  howpublished="RFC 3353 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3353",
  pages="1--30",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3353.txt",
  key="RFC 3353",
  keywords="inrternet protocol, l2, multicast routing protocoln",
  doi="10.17487/RFC3353",
  }

@misc{rfc3354,
  author="D. {Eastlake 3rd}",
  title="{Internet Open Trading Protocol Version 2 Requirements}",
  howpublished="RFC 3354 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3354",
  pages="1--6",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3354.txt",
  key="RFC 3354",
  keywords="payment, ecommerce, merchant, customer, delivery, signature, messaging, commerce, sale",
  doi="10.17487/RFC3354",
  }

@misc{rfc3355,
  author="A. Singh and R. Turner and R. Tio and S. Nanji",
  title="{Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)}",
  howpublished="RFC 3355 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3355",
  pages="1--13",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3355.txt",
  key="RFC 3355",
  keywords="link, dial-up server, asynchronous transfer mode",
  doi="10.17487/RFC3355",
  }

@misc{rfc3356,
  author="G. Fishman and S. Bradner",
  title="{Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines}",
  howpublished="RFC 3356 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3356",
  pages="1--12",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6756",
url="https://www.rfc-editor.org/rfc/rfc3356.txt",
  key="RFC 3356",
  keywords="internet, society, engineering, task, force",
  doi="10.17487/RFC3356",
  }

@misc{rfc3357,
  author="R. Koodli and R. Ravikanth",
  title="{One-way Loss Pattern Sample Metrics}",
  howpublished="RFC 3357 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3357",
  pages="1--15",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3357.txt",
  key="RFC 3357",
  keywords="packets, voice, video, stream",
  doi="10.17487/RFC3357",
  }

@misc{rfc3358,
  author="T. Przygienda",
  title="{Optional Checksums in Intermediate System to Intermediate System (ISIS)}",
  howpublished="RFC 3358 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3358",
  pages="1--4",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3358.txt",
  key="RFC 3358",
  keywords="type, length, value, complete sequence number, partial data",
  doi="10.17487/RFC3358",
  }

@misc{rfc3359,
  author="T. Przygienda",
  title="{Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System}",
  howpublished="RFC 3359 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3359",
  pages="1--5",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3359.txt",
  key="RFC 3359",
  keywords="is-is, igp, osi, complete sequence number, partial data",
  doi="10.17487/RFC3359",
  }

@misc{rfc3360,
  author="S. Floyd",
  title="{Inappropriate TCP Resets Considered Harmful}",
  howpublished="RFC 3360 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3360",
  pages="1--19",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3360.txt",
  key="RFC 3360",
  keywords="transmission control protocol, rst, bit, connection",
  doi="10.17487/RFC3360",
  }

@misc{rfc3361,
  author="H. Schulzrinne",
  title="{Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers}",
  howpublished="RFC 3361 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3361",
  pages="1--7",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3361.txt",
  key="RFC 3361",
  keywords="proxy servers",
  doi="10.17487/RFC3361",
  }

@misc{rfc3362,
  author="G. Parsons",
  title="{Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration}",
  howpublished="RFC 3362 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3362",
  pages="1--5",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3362.txt",
  key="RFC 3362",
  keywords="",
  doi="10.17487/RFC3362",
  }

@misc{rfc3363,
  author="R. Bush and A. Durand and B. Fink and O. Gudmundsson and T. Hain",
  title="{Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)}",
  howpublished="RFC 3363 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3363",
  pages="1--6",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6672",
url="https://www.rfc-editor.org/rfc/rfc3363.txt",
  key="RFC 3363",
  keywords="reverse mapping, label binary",
  doi="10.17487/RFC3363",
  }

@misc{rfc3364,
  author="R. Austein",
  title="{Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)}",
  howpublished="RFC 3364 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3364",
  pages="1--11",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3364.txt",
  key="RFC 3364",
  keywords="reverse mapping, rrs, resource records",
  doi="10.17487/RFC3364",
  }

@misc{rfc3365,
  author="J. Schiller",
  title="{Strong Security Requirements for Internet Engineering Task Force Standard Protocols}",
  howpublished="RFC 3365 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3365",
  pages="1--8",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3365.txt",
  key="RFC 3365",
  keywords="ietf",
  doi="10.17487/RFC3365",
  }

@misc{rfc3366,
  author="G. Fairhurst and L. Wood",
  title="{Advice to link designers on link Automatic Repeat reQuest (ARQ)}",
  howpublished="RFC 3366 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3366",
  pages="1--27",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3366.txt",
  key="RFC 3366",
  keywords="tcp/ip, subnetworks",
  doi="10.17487/RFC3366",
  }

@misc{rfc3367,
  author="N. Popp and M. Mealling and M. Moseley",
  title="{Common Name Resolution Protocol (CNRP)}",
  howpublished="RFC 3367 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3367",
  pages="1--42",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3367.txt",
  key="RFC 3367",
  keywords="unique resource locators, client applications",
  doi="10.17487/RFC3367",
  }

@misc{rfc3368,
  author="M. Mealling",
  title="{The 'go' URI Scheme for the Common Name Resolution Protocol}",
  howpublished="RFC 3368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3368",
  pages="1--8",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3368.txt",
  key="RFC 3368",
  keywords="uniform resource identifier",
  doi="10.17487/RFC3368",
  }

@misc{rfc3369,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3369 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3369",
  pages="1--52",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3852",
url="https://www.rfc-editor.org/rfc/rfc3369.txt",
  key="RFC 3369",
  keywords="digitally sign, authenticate, encrypt, arbitrary message content",
  doi="10.17487/RFC3369",
  }

@misc{rfc3370,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS) Algorithms}",
  howpublished="RFC 3370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3370",
  pages="1--24",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5754",
url="https://www.rfc-editor.org/rfc/rfc3370.txt",
  key="RFC 3370",
  keywords="digitally sign, authenticate, encrypt, arbitrary message content",
  doi="10.17487/RFC3370",
  }

@misc{rfc3371,
  author="E. Caves and P. Calhoun and R. Wheeler",
  title="{Layer Two Tunneling Protocol ``L2TP'' Management Information Base}",
  howpublished="RFC 3371 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3371",
  pages="1--70",
  year=2002,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3371.txt",
  key="RFC 3371",
  keywords="mib",
  doi="10.17487/RFC3371",
  }

@misc{rfc3372,
  author="A. Vemuri and J. Peterson",
  title="{Session Initiation Protocol for Telephones (SIP-T): Context and Architectures}",
  howpublished="RFC 3372 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3372",
  pages="1--23",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3372.txt",
  key="RFC 3372",
  keywords="pstn, public switch telephone network",
  doi="10.17487/RFC3372",
  }

@misc{rfc3373,
  author="D. Katz and R. Saluja",
  title="{Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies}",
  howpublished="RFC 3373 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3373",
  pages="1--9",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5303",
url="https://www.rfc-editor.org/rfc/rfc3373.txt",
  key="RFC 3373",
  keywords="links, handshake",
  doi="10.17487/RFC3373",
  }

@misc{rfc3374,
  author="J. Kempf",
  title="{Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network}",
  howpublished="RFC 3374 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3374",
  pages="1--14",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3374.txt",
  key="RFC 3374",
  keywords="aaa, qos, authentication authorization accounting, quality of service, header compression",
  doi="10.17487/RFC3374",
  }

@misc{rfc3375,
  author="S. Hollenbeck",
  title="{Generic Registry-Registrar Protocol Requirements}",
  howpublished="RFC 3375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3375",
  pages="1--21",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3375.txt",
  key="RFC 3375",
  keywords="rrp, client server, domain names",
  doi="10.17487/RFC3375",
  }

@misc{rfc3376,
  author="B. Cain and S. Deering and I. Kouvelas and B. Fenner and A. Thyagarajan",
  title="{Internet Group Management Protocol, Version 3}",
  howpublished="RFC 3376 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3376",
  pages="1--53",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4604",
url="https://www.rfc-editor.org/rfc/rfc3376.txt",
  key="RFC 3376",
  keywords="IGMP, IGMP, multicast, routing, IP, Internet Protocol",
  doi="10.17487/RFC3376",
  }

@misc{rfc3377,
  author="J. Hodges and R. Morgan",
  title="{Lightweight Directory Access Protocol (v3): Technical Specification}",
  howpublished="RFC 3377 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3377",
  pages="1--6",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4510",
url="https://www.rfc-editor.org/rfc/rfc3377.txt",
  key="RFC 3377",
  keywords="ldap, ldapv3",
  doi="10.17487/RFC3377",
  }

@misc{rfc3378,
  author="R. Housley and S. Hollenbeck",
  title="{EtherIP: Tunneling Ethernet Frames in IP Datagrams}",
  howpublished="RFC 3378 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3378",
  pages="1--9",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3378.txt",
  key="RFC 3378",
  keywords="internet protocol, ip 97",
  doi="10.17487/RFC3378",
  }

@misc{rfc3379,
  author="D. Pinkas and R. Housley",
  title="{Delegated Path Validation and Delegated Path Discovery Protocol Requirements}",
  howpublished="RFC 3379 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3379",
  pages="1--15",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3379.txt",
  key="RFC 3379",
  keywords="dpv, dpd, public, key, certificates",
  doi="10.17487/RFC3379",
  }

@misc{rfc3380,
  author="T. Hastings and R. Herriot and C. Kugler and H. Lewis",
  title="{Internet Printing Protocol (IPP): Job and Printer Set Operations}",
  howpublished="RFC 3380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3380",
  pages="1--59",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3380.txt",
  key="RFC 3380",
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC3380",
  }

@misc{rfc3381,
  author="T. Hastings and H. Lewis and R. Bergman",
  title="{Internet Printing Protocol (IPP): Job Progress Attributes}",
  howpublished="RFC 3381 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3381",
  pages="1--17",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8011",
url="https://www.rfc-editor.org/rfc/rfc3381.txt",
  key="RFC 3381",
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC3381",
  }

@misc{rfc3382,
  author="R. deBry and T. Hastings and R. Herriot and K. Ocke and P. Zehler",
  title="{Internet Printing Protocol (IPP): The 'collection' attribute syntax}",
  howpublished="RFC 3382 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3382",
  pages="1--38",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 8010, 8011",
url="https://www.rfc-editor.org/rfc/rfc3382.txt",
  key="RFC 3382",
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC3382",
  }

@misc{rfc3383,
  author="K. Zeilenga",
  title="{Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3383 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3383",
  pages="1--23",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4520",
url="https://www.rfc-editor.org/rfc/rfc3383.txt",
  key="RFC 3383",
  keywords="guidelines, extensible values",
  doi="10.17487/RFC3383",
  }

@misc{rfc3384,
  author="E. Stokes and R. Weiser and R. Moats and R. Huber",
  title="{Lightweight Directory Access Protocol (version 3) Replication Requirements}",
  howpublished="RFC 3384 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3384",
  pages="1--31",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3384.txt",
  key="RFC 3384",
  keywords="ldapv3, data interoperability, synchronization, multi-master",
  doi="10.17487/RFC3384",
  }

@misc{rfc3385,
  author="D. Sheinwald and J. Satran and P. Thaler and V. Cavanna",
  title="{Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations}",
  howpublished="RFC 3385 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3385",
  pages="1--23",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3385.txt",
  key="RFC 3385",
  keywords="error detection code",
  doi="10.17487/RFC3385",
  }

@misc{rfc3386,
  author="W. Lai and D. McDysan",
  title="{Network Hierarchy and Multilayer Survivability}",
  howpublished="RFC 3386 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3386",
  pages="1--27",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3386.txt",
  key="RFC 3386",
  keywords="service, provider, packet networks, protection, restoration, recovery",
  doi="10.17487/RFC3386",
  }

@misc{rfc3387,
  author="M. Eder and H. Chaskar and S. Nag",
  title="{Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network}",
  howpublished="RFC 3387 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3387",
  pages="1--19",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3387.txt",
  key="RFC 3387",
  keywords="internet protocol, packts, fuel-service",
  doi="10.17487/RFC3387",
  }

@misc{rfc3388,
  author="G. Camarillo and G. Eriksson and J. Holler and H. Schulzrinne",
  title="{Grouping of Media Lines in the Session Description Protocol (SDP)}",
  howpublished="RFC 3388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3388",
  pages="1--11",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5888",
url="https://www.rfc-editor.org/rfc/rfc3388.txt",
  key="RFC 3388",
  keywords="formats, attribute, port, host, interfaces, fid, flow identification, lip synchronization, ls",
  doi="10.17487/RFC3388",
  }

@misc{rfc3389,
  author="R. Zopf",
  title="{Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)}",
  howpublished="RFC 3389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3389",
  pages="1--8",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3389.txt",
  key="RFC 3389",
  keywords="codecs, audio, multimedia",
  doi="10.17487/RFC3389",
  }

@misc{rfc3390,
  author="M. Allman and S. Floyd and C. Partridge",
  title="{Increasing TCP's Initial Window}",
  howpublished="RFC 3390 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3390",
  pages="1--15",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3390.txt",
  key="RFC 3390",
  keywords="transmission control protocol",
  doi="10.17487/RFC3390",
  }

@misc{rfc3391,
  author="R. Herriot",
  title="{The MIME Application/Vnd.pwg-multiplexed Content-Type}",
  howpublished="RFC 3391 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3391",
  pages="1--25",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3391.txt",
  key="RFC 3391",
  keywords="multipurpose internet mail extensions, media type",
  doi="10.17487/RFC3391",
  }

@misc{rfc3392,
  author="R. Chandra and J. Scudder",
  title="{Capabilities Advertisement with BGP-4}",
  howpublished="RFC 3392 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3392",
  pages="1--6",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5492",
url="https://www.rfc-editor.org/rfc/rfc3392.txt",
  key="RFC 3392",
  keywords=" border, gateway, protocol",
  doi="10.17487/RFC3392",
  }

@misc{rfc3393,
  author="C. Demichelis and P. Chimento",
  title="{IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)}",
  howpublished="RFC 3393 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3393",
  pages="1--21",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3393.txt",
  key="RFC 3393",
  keywords=" internet protocol, ipdv",
  doi="10.17487/RFC3393",
  }

@misc{rfc3394,
  author="J. Schaad and R. Housley",
  title="{Advanced Encryption Standard (AES) Key Wrap Algorithm}",
  howpublished="RFC 3394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3394",
  pages="1--41",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3394.txt",
  key="RFC 3394",
  keywords="security",
  doi="10.17487/RFC3394",
  }

@misc{rfc3395,
  author="A. Bierman and C. Bucci and R. Dietz and A. Warth",
  title="{Remote Network Monitoring MIB Protocol Identifier Reference Extensions}",
  howpublished="RFC 3395 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3395",
  pages="1--21",
  year=2002,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3395.txt",
  key="RFC 3395",
  keywords="RMON-MIB, management, information, base",
  doi="10.17487/RFC3395",
  }

@misc{rfc3396,
  author="T. Lemon and S. Cheshire",
  title="{Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)}",
  howpublished="RFC 3396 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3396",
  pages="1--9",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3396.txt",
  key="RFC 3396",
  keywords="octet, packet, code",
  doi="10.17487/RFC3396",
  }

@misc{rfc3397,
  author="B. Aboba and S. Cheshire",
  title="{Dynamic Host Configuration Protocol (DHCP) Domain Search Option}",
  howpublished="RFC 3397 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3397",
  pages="1--8",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3397.txt",
  key="RFC 3397",
  keywords="dns, client, client server",
  doi="10.17487/RFC3397",
  }

@misc{rfc3398,
  author="G. Camarillo and A. B. Roach and J. Peterson and L. Ong",
  title="{Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping}",
  howpublished="RFC 3398 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3398",
  pages="1--68",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3398.txt",
  key="RFC 3398",
  keywords="signaling system no. 7, ss7, pstn, public switched telephone network",
  doi="10.17487/RFC3398",
  }

@misc{rfc3401,
  author="M. Mealling",
  title="{Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS}",
  howpublished="RFC 3401 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3401",
  pages="1--6",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3401.txt",
  key="RFC 3401",
  abstract={This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS).  DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.  This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276.  This memo provides information for the Internet community.},
  keywords="NAPTR, domain name system, RR",
  doi="10.17487/RFC3401",
  }

@misc{rfc3402,
  author="M. Mealling",
  title="{Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm}",
  howpublished="RFC 3402 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3402",
  pages="1--17",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3402.txt",
  key="RFC 3402",
  abstract={This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string.  Well-formed transformation rules will reflect the delegation of management of information associated with the string.  This document is also part of a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401).  It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]},
  keywords="NAPTR, domain name system, RR",
  doi="10.17487/RFC3402",
  }

@misc{rfc3403,
  author="M. Mealling",
  title="{Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database}",
  howpublished="RFC 3403 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3403",
  pages="1--14",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3403.txt",
  key="RFC 3403",
  abstract={This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules.  The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).  Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record.  It is also part of a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401).  It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]},
  keywords="NAPTR, domain name system, RR",
  doi="10.17487/RFC3403",
  }

@misc{rfc3404,
  author="M. Mealling",
  title="{Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)}",
  howpublished="RFC 3404 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3404",
  pages="1--18",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3404.txt",
  key="RFC 3404",
  abstract={This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI.  The method used to locate that authoritative server is the Dynamic Delegation Discovery System.  This document is part of a series that is specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401).  It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]},
  keywords="NAPTR, domain name system, RR",
  doi="10.17487/RFC3404",
  }

@misc{rfc3405,
  author="M. Mealling",
  title="{Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures}",
  howpublished="RFC 3405 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3405",
  pages="1--10",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3405.txt",
  key="RFC 3405",
  abstract={This document is fifth in a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401).  It is very important to note that it is impossible to read and understand any document in this series without reading the others.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="uniform resource identifiers",
  doi="10.17487/RFC3405",
  }

@misc{rfc3406,
  author="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom",
  title="{Uniform Resource Names (URN) Namespace Definition Mechanisms}",
  howpublished="RFC 3406 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3406",
  pages="1--22",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8141",
url="https://www.rfc-editor.org/rfc/rfc3406.txt",
  key="RFC 3406",
  abstract={This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) ``namespaces''.  The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405.  The whole rests on the concept of individual ``namespaces'' within the URN structure.  Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="namespaces, applications, structure",
  doi="10.17487/RFC3406",
  }

@misc{rfc3407,
  author="F. Andreasen",
  title="{Session Description Protocol (SDP) Simple Capability Declaration}",
  howpublished="RFC 3407 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3407",
  pages="1--10",
  year=2002,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3407.txt",
  key="RFC 3407",
  abstract={This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism.  Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document.  This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]},
  keywords="SDPng",
  doi="10.17487/RFC3407",
  }

@misc{rfc3408,
  author="Z. Liu and K. Le",
  title="{Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile}",
  howpublished="RFC 3408 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3408",
  pages="1--7",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3408.txt",
  key="RFC 3408",
  abstract={This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242.  Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio.  It is usable in certain widely deployed older air interfaces.  This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]},
  keywords="single-octet, packet size",
  doi="10.17487/RFC3408",
  }

@misc{rfc3409,
  author="K. Svanbro",
  title="{Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression}",
  howpublished="RFC 3409 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3409",
  pages="1--11",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3409.txt",
  key="RFC 3409",
  abstract={This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers.  The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc.  This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095].  Both general guidelines and guidelines specific for cellular systems are discussed in this document.  This memo provides information for the Internet community.},
  keywords="rohc, algorithms",
  doi="10.17487/RFC3409",
  }

@misc{rfc3410,
  author="J. Case and R. Mundy and D. Partain and B. Stewart",
  title="{Introduction and Applicability Statements for Internet-Standard Management Framework}",
  howpublished="RFC 3410 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3410",
  pages="1--27",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3410.txt",
  key="RFC 3410",
  abstract={The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3).  This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).  The architecture is designed to be modular to allow the evolution of the Framework over time.  The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended.  The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status.  This document obsoletes RFC 2570.  This memo provides information for the Internet community.},
  keywords="snmp, simple, protocol, snmpv3",
  doi="10.17487/RFC3410",
  }

@misc{rfc3411,
  author="D. Harrington and R. Presuhn and B. Wijnen",
  title="{An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks}",
  howpublished="RFC 3411 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3411",
  pages="1--64",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5343, 5590",
url="https://www.rfc-editor.org/rfc/rfc3411.txt",
  key="RFC 3411",
  abstract={This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks.  The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time.  The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.  This document obsoletes RFC 2571. [STANDARDS-TRACK]},
  keywords="ARCH-SNMP, simple, protocol, network, management",
  doi="10.17487/RFC3411",
  }

@misc{rfc3412,
  author="J. Case and D. Harrington and R. Presuhn and B. Wijnen",
  title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3412 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3412",
  pages="1--43",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5590",
url="https://www.rfc-editor.org/rfc/rfc3412.txt",
  key="RFC 3412",
  abstract={This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture.  It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications.  This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.  This document obsoletes RFC 2572. [STANDARDS-TRACK]},
  keywords="MPD-SNMP, processing, models, multiple",
  doi="10.17487/RFC3412",
  }

@misc{rfc3413,
  author="D. Levi and P. Meyer and B. Stewart",
  title="{Simple Network Management Protocol (SNMP) Applications}",
  howpublished="RFC 3413 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3413",
  pages="1--74",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3413.txt",
  key="RFC 3413",
  abstract={This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411.  The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.  This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.  This document obsoletes RFC 2573. [STANDARDS-TRACK]},
  keywords="SNMP-APP, simple, network, management, protocol, proxy, operations, command",
  doi="10.17487/RFC3413",
  }

@misc{rfc3414,
  author="U. Blumenthal and B. Wijnen",
  title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}",
  howpublished="RFC 3414 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3414",
  pages="1--88",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5590",
url="https://www.rfc-editor.org/rfc/rfc3414.txt",
  key="RFC 3414",
  abstract={This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture.  It defines the Elements of Procedure for providing SNMP message level security.  This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model.  This document obsoletes RFC 2574. [STANDARDS-TRACK]},
  keywords="USM-SNMPV3, message, level, mib, information, base",
  doi="10.17487/RFC3414",
  }

@misc{rfc3415,
  author="B. Wijnen and R. Presuhn and K. McCloghrie",
  title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3415 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3415",
  pages="1--39",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3415.txt",
  key="RFC 3415",
  abstract={This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture.  It defines the Elements of Procedure for controlling access to management information.  This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model.  This document obsoletes RFC 2575. [STANDARDS-TRACK]},
  keywords="VACM-SNMP, mib, information, base",
  doi="10.17487/RFC3415",
  }

@misc{rfc3416,
  author="R. Presuhn",
  title="{Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3416 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3416",
  pages="1--31",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3416.txt",
  key="RFC 3416",
  abstract={This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP).  It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs.  This document obsoletes RFC 1905. [STANDARDS-TRACK]},
  keywords="OPS-MIB, Simple, Network, Management, Protocol, Version 2",
  doi="10.17487/RFC3416",
  }

@misc{rfc3417,
  author="R. Presuhn",
  title="{Transport Mappings for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3417 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3417",
  pages="1--19",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4789, 5590",
url="https://www.rfc-editor.org/rfc/rfc3417.txt",
  key="RFC 3417",
  abstract={This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols.  This document obsoletes RFC 1906. [STANDARDS-TRACK]},
  keywords="TRANS-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC3417",
  }

@misc{rfc3418,
  author="R. Presuhn",
  title="{Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3418 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3418",
  pages="1--26",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3418.txt",
  key="RFC 3418",
  abstract={This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity.  This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]},
  keywords="SNMPv2-MIB, Simple, Network, Management, Protocol, Version, 2",
  doi="10.17487/RFC3418",
  }

@misc{rfc3419,
  author="M. Daniele and J. Schoenwaelder",
  title="{Textual Conventions for Transport Addresses}",
  howpublished="RFC 3419 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3419",
  pages="1--18",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3419.txt",
  key="RFC 3419",
  abstract={This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information.  The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]},
  keywords="mib, management information base",
  doi="10.17487/RFC3419",
  }

@misc{rfc3420,
  author="R. Sparks",
  title="{Internet Media Type message/sipfrag}",
  howpublished="RFC 3420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3420",
  pages="1--8",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3420.txt",
  key="RFC 3420",
  abstract={This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type.  This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message.  In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]},
  keywords="mime, multipurpose internet mail extesions",
  doi="10.17487/RFC3420",
  }

@misc{rfc3421,
  author="W. Zhao and H. Schulzrinne and E. Guttman and C. Bisdikian and W. Jerome",
  title="{Select and Sort Extensions for the Service Location Protocol (SLP)}",
  howpublished="RFC 3421 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3421",
  pages="1--8",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3421.txt",
  key="RFC 3421",
  abstract={This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP).  These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list.  Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="user agent, url, service reply, ua, svrrply",
  doi="10.17487/RFC3421",
  }

@misc{rfc3422,
  author="O. Okamoto and M. Maruyama and T. Sajima",
  title="{Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)}",
  howpublished="RFC 3422 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3422",
  pages="1--19",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3422.txt",
  key="RFC 3422",
  abstract={This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment.  This memo provides information for the Internet community.},
  keywords="tunneling, ethernet frames",
  doi="10.17487/RFC3422",
  }

@misc{rfc3423,
  author="K. Zhang and E. Elkin",
  title="{XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0}",
  howpublished="RFC 3423 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3423",
  pages="1--45",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3423.txt",
  key="RFC 3423",
  abstract={This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS).  The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.  This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.  This memo provides information for the Internet community.},
  keywords="data, delivery, message, format, template-based, client/server",
  doi="10.17487/RFC3423",
  }

@misc{rfc3424,
  author="L. Daigle and IAB",
  title="{IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation}",
  howpublished="RFC 3424 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3424",
  pages="1--9",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3424.txt",
  key="RFC 3424",
  abstract={As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers.  Various proposals have been made for ``UNilateral Self-Address Fixing (UNSAF)'' processes.  These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.  This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.  This memo provides information for the Internet community.},
  keywords="nat, middleboxes",
  doi="10.17487/RFC3424",
  }

@misc{rfc3425,
  author="D. Lawrence",
  title="{Obsoleting IQUERY}",
  howpublished="RFC 3425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3425",
  pages="1--5",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3425.txt",
  key="RFC 3425",
  abstract={The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented.  Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable.  Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete.  This document updates RFC 1035. [STANDARDS-TRACK]},
  keywords="dns lookups, domain",
  doi="10.17487/RFC3425",
  }

@misc{rfc3426,
  author="S. Floyd",
  title="{General Architectural and Policy Considerations}",
  howpublished="RFC 3426 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3426",
  pages="1--23",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3426.txt",
  key="RFC 3426",
  abstract={This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols.  We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed.  This memo provides information for the Internet community.},
  keywords="internet architecture",
  doi="10.17487/RFC3426",
  }

@misc{rfc3427,
  author="A. Mankin and S. Bradner and R. Mahy and D. Willis and J. Ott and B. Rosen",
  title="{Change Process for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3427 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3427",
  pages="1--12",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5727, updated by RFCs 3968, 3969",
url="https://www.rfc-editor.org/rfc/rfc3427.txt",
  key="RFC 3427",
  abstract={This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP).  There have been concerns with regards to new SIP proposals.  Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol.  The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="sipping",
  doi="10.17487/RFC3427",
  }

@misc{rfc3428,
  author="B. Campbell and J. Rosenberg and H. Schulzrinne and C. Huitema and D. Gurle",
  title="{Session Initiation Protocol (SIP) Extension for Instant Messaging}",
  howpublished="RFC 3428 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3428",
  pages="1--18",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3428.txt",
  key="RFC 3428",
  abstract={Instant Messaging (IM) refers to the transfer of messages between users in near real-time.  These messages are usually, but not required to be, short.  IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.  This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages.  Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol.  MESSAGE requests carry the content in the form of MIME body parts.  MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages.  MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]},
  keywords="im, message method",
  doi="10.17487/RFC3428",
  }

@misc{rfc3429,
  author="H. Ohta",
  title="{Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions}",
  howpublished="RFC 3429 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3429",
  pages="1--6",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3429.txt",
  key="RFC 3429",
  abstract={This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets.  This memo provides information for the Internet community.},
  keywords="reserved lavel values",
  doi="10.17487/RFC3429",
  }

@misc{rfc3430,
  author="J. Schoenwaelder",
  title="{Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping}",
  howpublished="RFC 3430 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3430",
  pages="1--10",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3430.txt",
  key="RFC 3430",
  abstract={This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP.  The transport mapping can be used with any version of SNMP.  This document extends the transport mappings defined in STD 62, RFC 3417.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="snmp, tcp",
  doi="10.17487/RFC3430",
  }

@misc{rfc3431,
  author="W. Segmuller",
  title="{Sieve Extension: Relational Tests}",
  howpublished="RFC 3431 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3431",
  pages="1--8",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5231",
url="https://www.rfc-editor.org/rfc/rfc3431.txt",
  key="RFC 3431",
  abstract={This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028.  This extension extends existing conditional tests in Sieve to allow relational operators.  In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]},
  keywords="sieve mail, filtering language",
  doi="10.17487/RFC3431",
  }

@misc{rfc3432,
  author="V. Raisanen and G. Grotefeld and A. Morton",
  title="{Network performance measurement with periodic streams}",
  howpublished="RFC 3432 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3432",
  pages="1--23",
  year=2002,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3432.txt",
  key="RFC 3432",
  abstract={This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks.  First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330.  The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified.  The sampling method avoids predictability by mandating random start times and finite length tests.  Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed.  Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]},
  keywords="cbr, constant bit rate, periodic sampling, poisson sampling",
  doi="10.17487/RFC3432",
  }

@misc{rfc3433,
  author="A. Bierman and D. Romascanu and K.C. Norseth",
  title="{Entity Sensor Management Information Base}",
  howpublished="RFC 3433 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3433",
  pages="1--17",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3433.txt",
  key="RFC 3433",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]},
  keywords="mib, physical sensors, snmp",
  doi="10.17487/RFC3433",
  }

@misc{rfc3434,
  author="A. Bierman and K. McCloghrie",
  title="{Remote Monitoring MIB Extensions for High Capacity Alarms}",
  howpublished="RFC 3434 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3434",
  pages="1--24",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3434.txt",
  key="RFC 3434",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]},
  keywords="rmon, counter64, smiv2, snmp",
  doi="10.17487/RFC3434",
  }

@misc{rfc3435,
  author="F. Andreasen and B. Foster",
  title="{Media Gateway Control Protocol (MGCP) Version 1.0}",
  howpublished="RFC 3435 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3435",
  pages="1--210",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3661",
url="https://www.rfc-editor.org/rfc/rfc3435.txt",
  key="RFC 3435",
  abstract={This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway.  The decomposed multimedia gateway consists of a Call Agent, which contains the call control ``intelligence'', and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.  Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints.  Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.  The endpoints automatically communicate changes in service state to the Call Agent.  Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.  The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways.  Such packages are defined in separate documents.  This memo provides information for the Internet community.},
  keywords="voice, IP, internet, VoIP",
  doi="10.17487/RFC3435",
  }

@misc{rfc3436,
  author="A. Jungmaier and E. Rescorla and M. Tuexen",
  title="{Transport Layer Security over Stream Control Transmission Protocol}",
  howpublished="RFC 3436 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3436",
  pages="1--9",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3436.txt",
  key="RFC 3436",
  abstract={This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.  The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.  Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]},
  keywords="sctp, tls",
  doi="10.17487/RFC3436",
  }

@misc{rfc3437,
  author="W. Palter and W. Townsley",
  title="{Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation}",
  howpublished="RFC 3437 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3437",
  pages="1--10",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3437.txt",
  key="RFC 3437",
  abstract={This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options.  PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use.  When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media.  Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP.  Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation.  This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]},
  keywords="l2tp, lcp",
  doi="10.17487/RFC3437",
  }

@misc{rfc3438,
  author="W. Townsley",
  title="{Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update}",
  howpublished="RFC 3438 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3438",
  pages="1--5",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3438.txt",
  key="RFC 3438",
  abstract={This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="L2TP, ppp, point-to-point, protocol, packets",
  doi="10.17487/RFC3438",
  }

@misc{rfc3439,
  author="R. Bush and D. Meyer",
  title="{Some Internet Architectural Guidelines and Philosophy}",
  howpublished="RFC 3439 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3439",
  pages="1--28",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3439.txt",
  key="RFC 3439",
  abstract={This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere.  We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones.  This memo provides information for the Internet community.},
  keywords="IAB",
  doi="10.17487/RFC3439",
  }

@misc{rfc3440,
  author="F. Ly and G. Bathrick",
  title="{Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines}",
  howpublished="RFC 3440 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3440",
  pages="1--36",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3440.txt",
  key="RFC 3440",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]},
  keywords="simple network management protocol, mib, adsl, asymmetric digital subscriber line",
  doi="10.17487/RFC3440",
  }

@misc{rfc3441,
  author="R. Kumar",
  title="{Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)}",
  howpublished="RFC 3441 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3441",
  pages="1--50",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3441.txt",
  key="RFC 3441",
  abstract={This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP).  This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters.  Also included is a description of codec and profile negotiation.  It extends the MGCP that is currently being deployed in a number of products.  Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol.  This memo provides information for the Internet community.},
  keywords="connection, codec profile",
  doi="10.17487/RFC3441",
  }

@misc{rfc3442,
  author="T. Lemon and S. Cheshire and B. Volz",
  title="{The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4}",
  howpublished="RFC 3442 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3442",
  pages="1--9",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3442.txt",
  key="RFC 3442",
  abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client.  The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]},
  keywords="Dynamic, Host, Configuration, Protocol, Bootstrap",
  doi="10.17487/RFC3442",
  }

@misc{rfc3443,
  author="P. Agarwal and B. Akyol",
  title="{Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks}",
  howpublished="RFC 3443 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3443",
  pages="1--10",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3443.txt",
  key="RFC 3443",
  abstract={This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path.  It updates RFC 3032, ``MPLS Label Stack Encoding''.  TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both ``push'' and ``pop'' cases.  The document also complements RFC 3270, ``MPLS Support of Differentiated Services'' and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]},
  keywords="label stack encoding, uniform model, pipe model",
  doi="10.17487/RFC3443",
  }

@misc{rfc3444,
  author="A. Pras and J. Schoenwaelder",
  title="{On the Difference between Information Models and Data Models}",
  howpublished="RFC 3444 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3444",
  pages="1--8",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3444.txt",
  key="RFC 3444",
  abstract={There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models.  This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.},
  keywords="network management",
  doi="10.17487/RFC3444",
  }

@misc{rfc3445,
  author="D. Massey and S. Rose",
  title="{Limiting the Scope of the KEY Resource Record (RR)}",
  howpublished="RFC 3445 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3445",
  pages="1--10",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3445.txt",
  key="RFC 3445",
  abstract={This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys.  Storing both DNSSEC and application keys with the same record type is a mistake.  This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data.  As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined.  Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed.  This document updates RFC 2535. [STANDARDS-TRACK]},
  keywords="DNS-SECEXT, dns, authentication",
  doi="10.17487/RFC3445",
  }

@misc{rfc3446,
  author="D. Kim and D. Meyer and H. Kilmer and D. Farinacci",
  title="{Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)}",
  howpublished="RFC 3446 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3446",
  pages="1--7",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3446.txt",
  key="RFC 3446",
  abstract={This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain.  This memo provides information for the Internet community.},
  keywords="sparse mode, single shared-tree",
  doi="10.17487/RFC3446",
  }

@misc{rfc3447,
  author="J. Jonsson and B. Kaliski",
  title="{Public-Key Cryptography Standards (PKCS) \#1: RSA Cryptography Specifications Version 2.1}",
  howpublished="RFC 3447 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3447",
  pages="1--72",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8017",
url="https://www.rfc-editor.org/rfc/rfc3447.txt",
  key="RFC 3447",
  abstract={This memo represents a republication of PKCS \#1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document is taken directly from the PKCS \#1 v2.1 document, with certain corrections made during the publication process.  This memo provides information for the Internet community.},
  keywords="data, public, key, cryptosystem",
  doi="10.17487/RFC3447",
  }

@misc{rfc3448,
  author="M. Handley and S. Floyd and J. Padhye and J. Widmer",
  title="{TCP Friendly Rate Control (TFRC): Protocol Specification}",
  howpublished="RFC 3448 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3448",
  pages="1--24",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5348",
url="https://www.rfc-editor.org/rfc/rfc3448.txt",
  key="RFC 3448",
  abstract={This document specifies TCP-Friendly Rate Control (TFRC).  TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment.  It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]},
  keywords="congestion, unicast, streaming media",
  doi="10.17487/RFC3448",
  }

@misc{rfc3449,
  author="H. Balakrishnan and V. Padmanabhan and G. Fairhurst and M. Sooriyabandara",
  title="{TCP Performance Implications of Network Path Asymmetry}",
  howpublished="RFC 3449 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3449",
  pages="1--41",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3449.txt",
  key="RFC 3449",
  abstract={This document describes TCP performance problems that arise because of asymmetric effects.  These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons.  However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.  The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks.  These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic.  Each technique is described, together with known issues, and recommendations for use.  A summary of the recommendations is provided at the end of the document.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="links, sender, receiver, ack",
  doi="10.17487/RFC3449",
  }

@misc{rfc3450,
  author="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and J. Crowcroft",
  title="{Asynchronous Layered Coding (ALC) Protocol Instantiation}",
  howpublished="RFC 3450 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3450",
  pages="1--34",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5775",
url="https://www.rfc-editor.org/rfc/rfc3450.txt",
  key="RFC 3450",
  abstract={This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.  Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="content, delivery, congestion, control, receivers",
  doi="10.17487/RFC3450",
  }

@misc{rfc3451,
  author="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and M. Handley and J. Crowcroft",
  title="{Layered Coding Transport (LCT) Building Block}",
  howpublished="RFC 3451 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3451",
  pages="1--29",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5651",
url="https://www.rfc-editor.org/rfc/rfc3451.txt",
  key="RFC 3451",
  abstract={Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols.  LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast.  LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="content, stream, delivery, multicast, internet protocol",
  doi="10.17487/RFC3451",
  }

@misc{rfc3452,
  author="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and J. Crowcroft",
  title="{Forward Error Correction (FEC) Building Block}",
  howpublished="RFC 3452 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3452",
  pages="1--16",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5052, 5445",
url="https://www.rfc-editor.org/rfc/rfc3452.txt",
  key="RFC 3452",
  abstract={This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport.  The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast.  This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.  The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.  This document should be read in conjunction with and uses the terminology of the companion document titled, ``The Use of Forward Error Correction (FEC) in Reliable Multicast''.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="content, stream, delivery, multicast, internet protocol",
  doi="10.17487/RFC3452",
  }

@misc{rfc3453,
  author="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and J. Crowcroft",
  title="{The Use of Forward Error Correction (FEC) in Reliable Multicast}",
  howpublished="RFC 3453 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3453",
  pages="1--18",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3453.txt",
  key="RFC 3453",
  abstract={This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast.  One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers.  Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced.  Examples are provided of possible abstract formats for packets carrying FEC.  This memo provides information for the Internet community.},
  keywords="ip, internet protocol, data transport",
  doi="10.17487/RFC3453",
  }

@misc{rfc3454,
  author="P. Hoffman and M. Blanchet",
  title="{Preparation of Internationalized Strings (``stringprep'')}",
  howpublished="RFC 3454 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3454",
  pages="1--91",
  year=2002,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7564",
url="https://www.rfc-editor.org/rfc/rfc3454.txt",
  key="RFC 3454",
  abstract={This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world.  The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.  This document does not specify how protocols should prepare text strings.  Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]},
  keywords="unicode text, internationalization",
  doi="10.17487/RFC3454",
  }

@misc{rfc3455,
  author="M. Garcia-Martin and E. Henrikson and D. Mills",
  title="{Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)}",
  howpublished="RFC 3455 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3455",
  pages="1--34",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7315",
url="https://www.rfc-editor.org/rfc/rfc3455.txt",
  key="RFC 3455",
  abstract={This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments.  The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3455",
  }

@misc{rfc3456,
  author="B. Patel and B. Aboba and S. Kelly and V. Gupta",
  title="{Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode}",
  howpublished="RFC 3456 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3456",
  pages="1--18",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3456.txt",
  key="RFC 3456",
  abstract={This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration.  In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful.  This may be accomplished by assigning the host a ``virtual'' address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway.  In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]},
  keywords="security, internet protocol",
  doi="10.17487/RFC3456",
  }

@misc{rfc3457,
  author="S. Kelly and S. Ramamoorthi",
  title="{Requirements for IPsec Remote Access Scenarios}",
  howpublished="RFC 3457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3457",
  pages="1--31",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3457.txt",
  key="RFC 3457",
  abstract={IPsec offers much promise as a secure remote access mechanism.  However, there are a number of differing remote access scenarios, each having some shared and some unique requirements.  A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario.  This document enumerates the requirements for a number of common remote access scenarios.  This memo provides information for the Internet community.},
  keywords="ipsra, common remote access scenarios",
  doi="10.17487/RFC3457",
  }

@misc{rfc3458,
  author="E. Burger and E. Candell and C. Eliot and G. Klyne",
  title="{Message Context for Internet Mail}",
  howpublished="RFC 3458 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3458",
  pages="1--17",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3938",
url="https://www.rfc-editor.org/rfc/rfc3458.txt",
  key="RFC 3458",
  abstract={This memo describes a new RFC 2822 message header, ``Message-Context''.  This header provides information about the context and presentation characteristics of a message.  A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]},
  keywords="user agent, ua",
  doi="10.17487/RFC3458",
  }

@misc{rfc3459,
  author="E. Burger",
  title="{Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter}",
  howpublished="RFC 3459 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3459",
  pages="1--24",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5621",
url="https://www.rfc-editor.org/rfc/rfc3459.txt",
  key="RFC 3459",
  abstract={This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message.  The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.  By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability.  Critical content can help a content gateway to decide what parts to forward.  It can indicate how hard a gateway should try to deliver a body part.  It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message.  In addition, critical content can help the gateway chose the notification strategy for the receiving system.  Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS-TRACK]},
  keywords="body parts, content-disposition",
  doi="10.17487/RFC3459",
  }

@misc{rfc3460,
  author="B. Moore",
  title="{Policy Core Information Model (PCIM) Extensions}",
  howpublished="RFC 3460 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3460",
  pages="1--93",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3460.txt",
  key="RFC 3460",
  abstract={This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060).  Two types of changes are included.  First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover.  Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules).  Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved.  This document updates RFC 3060. [STANDARDS-TRACK]},
  keywords="CIM, common, schema, object-oriented",
  doi="10.17487/RFC3460",
  }

@misc{rfc3461,
  author="K. Moore",
  title="{Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)}",
  howpublished="RFC 3461 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3461",
  pages="1--38",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3798, 3885, 5337, 6533, 8098",
url="https://www.rfc-editor.org/rfc/rfc3461.txt",
  key="RFC 3461",
  abstract={This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]},
  keywords="SMTP-DSN, simple, mail, transfer, protocol",
  doi="10.17487/RFC3461",
  }

@misc{rfc3462,
  author="G. Vaudreuil",
  title="{The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages}",
  howpublished="RFC 3462 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3462",
  pages="1--7",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6522, updated by RFC 5337",
url="https://www.rfc-editor.org/rfc/rfc3462.txt",
  key="RFC 3462",
  abstract={The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general ``family'' or ``container'' type for electronic mail reports of any kind.  Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.  This document is part of a four document set describing the delivery status report service.  This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]},
  keywords="MIME-RPT, Multipurpose, Internet, Mail, Extensions",
  doi="10.17487/RFC3462",
  }

@misc{rfc3463,
  author="G. Vaudreuil",
  title="{Enhanced Mail System Status Codes}",
  howpublished="RFC 3463 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3463",
  pages="1--16",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3886, 4468, 4865, 4954, 5248",
url="https://www.rfc-editor.org/rfc/rfc3463.txt",
  key="RFC 3463",
  abstract={This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics.  In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]},
  keywords="EMS-CODE, simple, mail, transfer, protocol, SMTP",
  doi="10.17487/RFC3463",
  }

@misc{rfc3464,
  author="K. Moore and G. Vaudreuil",
  title="{An Extensible Message Format for Delivery Status Notifications}",
  howpublished="RFC 3464 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3464",
  pages="1--40",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4865, 5337, 6533",
url="https://www.rfc-editor.org/rfc/rfc3464.txt",
  key="RFC 3464",
  abstract={This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients.  This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.  Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called ``Local Area Network (LAN)-based'' systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment.  To this end, the protocol described in this memo provides for the carriage of ``foreign'' addresses and error codes, in addition to those normally used in Internet mail.  Additional attributes may also be defined to support ``tunneling'' of foreign notifications through Internet mail. [STANDARDS-TRACK]},
  keywords="DSN, Multipurpose, Internet, Mail, Extensions, Content, Type",
  doi="10.17487/RFC3464",
  }

@misc{rfc3465,
  author="M. Allman",
  title="{TCP Congestion Control with Appropriate Byte Counting (ABC)}",
  howpublished="RFC 3465 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3465",
  pages="1--10",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3465.txt",
  key="RFC 3465",
  abstract={This document proposes a small modification to the way TCP increases its congestion window.  Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers.  This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="transmission control protocol, security performance",
  doi="10.17487/RFC3465",
  }

@misc{rfc3466,
  author="M. Day and B. Cain and G. Tomlinson and P. Rzewski",
  title="{A Model for Content Internetworking (CDI)}",
  howpublished="RFC 3466 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3466",
  pages="1--17",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7336",
url="https://www.rfc-editor.org/rfc/rfc3466.txt",
  key="RFC 3466",
  abstract={Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called ``content peering'' or ``CDN peering''.  A common vocabulary helps the process of discussing such interconnection and interoperation.  This document introduces content networks and content internetworking, and defines elements for such a common vocabulary.  This memo provides information for the Internet community.},
  keywords="distribution peering",
  doi="10.17487/RFC3466",
  }

@misc{rfc3467,
  author="J. Klensin",
  title="{Role of the Domain Name System (DNS)}",
  howpublished="RFC 3467 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3467",
  pages="1--31",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3467.txt",
  key="RFC 3467",
  abstract={This document reviews the original function and purpose of the domain name system (DNS).  It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it.  A framework for an alternative to placing these additional stresses on the DNS is then outlined.  This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.  This memo provides information for the Internet community.},
  keywords="history, internationalization, unicode, ascii, multilingual names",
  doi="10.17487/RFC3467",
  }

@misc{rfc3468,
  author="L. Andersson and G. Swallow",
  title="{The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols}",
  howpublished="RFC 3468 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3468",
  pages="1--11",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3468.txt",
  key="RFC 3468",
  abstract={This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on ``Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels'' (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to ``Constraint-Based LSP Setup using Label Distribution Protocol (LDP)'' (RFC 3212).  The recommendations of section 6 have been accepted by the IESG.  This memo provides information for the Internet community.},
  keywords="rsvp-te, ldp, resource reservation protocol label distribution",
  doi="10.17487/RFC3468",
  }

@misc{rfc3469,
  author="V. Sharma and F. Hellstrand",
  title="{Framework for Multi-Protocol Label Switching (MPLS)-based Recovery}",
  howpublished="RFC 3469 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3469",
  pages="1--40",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3469.txt",
  key="RFC 3469",
  abstract={Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing.  To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths.  This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery.  With these objectives in mind, this document specifies a framework for MPLS based recovery.  Restart issues are not included in this framework.  This memo provides information for the Internet community.},
  keywords="routing traffic",
  doi="10.17487/RFC3469",
  }

@misc{rfc3470,
  author="S. Hollenbeck and M. Rose and L. Masinter",
  title="{Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols}",
  howpublished="RFC 3470 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3470",
  pages="1--28",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3470.txt",
  key="RFC 3470",
  abstract={The Extensible Markup Language (XML) is a framework for structuring data.  While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.  There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application.  There has been much interest in the use of XML as a representation method.  This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="data, documents, structure",
  doi="10.17487/RFC3470",
  }

@misc{rfc3471,
  author="L. Berger",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description}",
  howpublished="RFC 3471 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3471",
  pages="1--34",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4201, 4328, 4872, 6002, 6003, 6205, 7074, 7699",
url="https://www.rfc-editor.org/rfc/rfc3471.txt",
  key="RFC 3471",
  abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS.  Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  This document presents a functional description of the extensions.  Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]},
  keywords="mpls, sonet/sdh",
  doi="10.17487/RFC3471",
  }

@misc{rfc3472,
  author="P. Ashwood-Smith and L. Berger",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions}",
  howpublished="RFC 3472 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3472",
  pages="1--23",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3468, 4201",
url="https://www.rfc-editor.org/rfc/rfc3472.txt",
  key="RFC 3472",
  abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS.  Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  This document presents a CR-LDP specific description of the extensions.  A generic functional description can be found in separate documents. [STANDARDS-TRACK]},
  keywords="mpls, sonet/sdh",
  doi="10.17487/RFC3472",
  }

@misc{rfc3473,
  author="L. Berger",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions}",
  howpublished="RFC 3473 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3473",
  pages="1--42",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4003, 4201, 4420, 4783, 4874, 4873, 4974, 5063, 5151, 5420, 6002, 6003, 6780",
url="https://www.rfc-editor.org/rfc/rfc3473.txt",
  key="RFC 3473",
  abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS.  Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  This document presents a RSVP-TE specific description of the extensions.  A generic functional description can be found in separate documents. [STANDARDS-TRACK]},
  keywords="mpls, sonet/sdh",
  doi="10.17487/RFC3473",
  }

@misc{rfc3474,
  author="Z. Lin and D. Pendarakis",
  title="{Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)}",
  howpublished="RFC 3474 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3474",
  pages="1--25",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3474.txt",
  key="RFC 3474",
  abstract={The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications.  These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs).  This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE).  It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.  This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort.  This memo provides information for the Internet community.},
  keywords="sonet, sdh",
  doi="10.17487/RFC3474",
  }

@misc{rfc3475,
  author="O. Aboul-Magd",
  title="{Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)}",
  howpublished="RFC 3475 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3475",
  pages="1--13",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3468",
url="https://www.rfc-editor.org/rfc/rfc3475.txt",
  key="RFC 3475",
  abstract={Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks.  The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities.  Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work.  This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points.  The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions.  The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents.  This memo provides information for the Internet community.},
  keywords="label switching protocol, itu-t",
  doi="10.17487/RFC3475",
  }

@misc{rfc3476,
  author="B. Rajagopalan",
  title="{Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling}",
  howpublished="RFC 3476 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3476",
  pages="1--11",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 3468",
url="https://www.rfc-editor.org/rfc/rfc3476.txt",
  key="RFC 3476",
  abstract={The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling.  These extensions consist of a set of new data objects and error codes.  This document describes these extensions.  This memo provides information for the Internet community.},
  keywords="oif, optical interworking forum, uni, user network interface",
  doi="10.17487/RFC3476",
  }

@misc{rfc3477,
  author="K. Kompella and Y. Rekhter",
  title="{Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)}",
  howpublished="RFC 3477 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3477",
  pages="1--9",
  year=2003,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6107",
url="https://www.rfc-editor.org/rfc/rfc3477.txt",
  key="RFC 3477",
  abstract={Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links.  This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]},
  keywords="mpls-te, traffic engineering",
  doi="10.17487/RFC3477",
  }

@misc{rfc3478,
  author="M. Leelanivas and Y. Rekhter and R. Aggarwal",
  title="{Graceful Restart Mechanism for Label Distribution Protocol}",
  howpublished="RFC 3478 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3478",
  pages="1--12",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3478.txt",
  key="RFC 3478",
  abstract={This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.  The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document).  Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.  The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.  The procedures described in this document apply to downstream unsolicited label distribution.  Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]},
  keywords="ldp, mpls",
  doi="10.17487/RFC3478",
  }

@misc{rfc3479,
  author="A. Farrel",
  title="{Fault Tolerance for the Label Distribution Protocol (LDP)}",
  howpublished="RFC 3479 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3479",
  pages="1--52",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3479.txt",
  key="RFC 3479",
  abstract={Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum.  Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.  The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific.  This document identifies issues in the LDP specification in RFC 3036, ``LDP Specification'', that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.  The issues and extensions described here are equally applicable to RFC 3212, ``Constraint-Based LSP Setup Using LDP'' (CR-LDP). [STANDARDS-TRACK]},
  keywords="mpls, multiprotocol label switching, cr-ldp, high availability restart",
  doi="10.17487/RFC3479",
  }

@misc{rfc3480,
  author="K. Kompella and Y. Rekhter and A. Kullberg",
  title="{Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)}",
  howpublished="RFC 3480 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3480",
  pages="1--8",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3480.txt",
  key="RFC 3480",
  abstract={Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links.  This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]},
  keywords="mpls, multiprotocol label switching, traffic engineering, mpls-te",
  doi="10.17487/RFC3480",
  }

@misc{rfc3481,
  author="H. Inamura and G. Montenegro and R. Ludwig and A. Gurtov and F. Khafizov",
  title="{TCP over Second (2.5G) and Third (3G) Generation Wireless Networks}",
  howpublished="RFC 3481 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3481",
  pages="1--26",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3481.txt",
  key="RFC 3481",
  abstract={This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks.  It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks.  It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues.  The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="paths, algorithm stacks",
  doi="10.17487/RFC3481",
  }

@misc{rfc3482,
  author="M. Foster and T. McGarry and J. Yu",
  title="{Number Portability in the Global Switched Telephone Network (GSTN): An Overview}",
  howpublished="RFC 3482 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3482",
  pages="1--30",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3482.txt",
  key="RFC 3482",
  abstract={This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).  NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers.  NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former.  In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific.  Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF.  This memo provides information for the Internet community.},
  keywords="e.164, telephony routing",
  doi="10.17487/RFC3482",
  }

@misc{rfc3483,
  author="D. Rawlins and A. Kulkarni and M. Bokaemper and K. Chan",
  title="{Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)}",
  howpublished="RFC 3483 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3483",
  pages="1--10",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3483.txt",
  key="RFC 3483",
  abstract={Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP).  The types of report information are success, failure and accounting of an installed state.  This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state.  This memo provides information for the Internet community.},
  keywords="accounting, policy decision, point, bdp",
  doi="10.17487/RFC3483",
  }

@misc{rfc3484,
  author="R. Draves",
  title="{Default Address Selection for Internet Protocol version 6 (IPv6)}",
  howpublished="RFC 3484 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3484",
  pages="1--24",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6724",
url="https://www.rfc-editor.org/rfc/rfc3484.txt",
  key="RFC 3484",
  abstract={This document describes two algorithms, for source address selection and for destination address selection.  The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations.  They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection.  The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior.  In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.  All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]},
  keywords="source, address destination",
  doi="10.17487/RFC3484",
  }

@misc{rfc3485,
  author="M. Garcia-Martin and C. Bormann and J. Ott and R. Price and A. B. Roach",
  title="{The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)}",
  howpublished="RFC 3485 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3485",
  pages="1--30",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4896",
url="https://www.rfc-editor.org/rfc/rfc3485.txt",
  key="RFC 3485",
  abstract={The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions.  The protocol can be compressed by using Signaling Compression (SigComp).  Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency.  The dictionary is compression algorithm independent. [STANDARDS-TRACK]},
  keywords="algorithm",
  doi="10.17487/RFC3485",
  }

@misc{rfc3486,
  author="G. Camarillo",
  title="{Compressing the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3486 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3486",
  pages="1--12",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5049",
url="https://www.rfc-editor.org/rfc/rfc3486.txt",
  key="RFC 3486",
  abstract={This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages.  It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3486",
  }

@misc{rfc3487,
  author="H. Schulzrinne",
  title="{Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3487 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3487",
  pages="1--17",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3487.txt",
  key="RFC 3487",
  abstract={This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP).  This memo provides information for the Internet community.},
  keywords="circuit switched network resources, end system resources, proxy resources, emergency preparedness communications",
  doi="10.17487/RFC3487",
  }

@misc{rfc3488,
  author="I. Wu and T. Eckert",
  title="{Cisco Systems Router-port Group Management Protocol (RGMP)}",
  howpublished="RFC 3488 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3488",
  pages="1--17",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3488.txt",
  key="RFC 3488",
  abstract={This document describes the Router-port Group Management Protocol (RGMP).  This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.  RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.  This memo provides information for the Internet community.},
  keywords="multicast, switches packet",
  doi="10.17487/RFC3488",
  }

@misc{rfc3489,
  author="J. Rosenberg and J. Weinberger and C. Huitema and R. Mahy",
  title="{STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)}",
  howpublished="RFC 3489 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3489",
  pages="1--47",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5389",
url="https://www.rfc-editor.org/rfc/rfc3489.txt",
  key="RFC 3489",
  abstract={Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet.  It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT.  STUN works with many existing NATs, and does not require any special behavior from them.  As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]},
  keywords="lightweight, applications, firewalls",
  doi="10.17487/RFC3489",
  }

@misc{rfc3490,
  author="P. Faltstrom and P. Hoffman and A. Costello",
  title="{Internationalizing Domain Names in Applications (IDNA)}",
  howpublished="RFC 3490 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3490",
  pages="1--22",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5890, 5891",
url="https://www.rfc-editor.org/rfc/rfc3490.txt",
  key="RFC 3490",
  abstract={Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire.  This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion.  IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today.  This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure.  IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]},
  keywords="idn, ascii, characters",
  doi="10.17487/RFC3490",
  }

@misc{rfc3491,
  author="P. Hoffman and M. Blanchet",
  title="{Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)}",
  howpublished="RFC 3491 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3491",
  pages="1--7",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5891",
url="https://www.rfc-editor.org/rfc/rfc3491.txt",
  key="RFC 3491",
  abstract={This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world.  This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]},
  keywords="idna, applications",
  doi="10.17487/RFC3491",
  }

@misc{rfc3492,
  author="A. Costello",
  title="{Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)}",
  howpublished="RFC 3492 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3492",
  pages="1--35",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5891",
url="https://www.rfc-editor.org/rfc/rfc3492.txt",
  key="RFC 3492",
  abstract={Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).  It uniquely and reversibly transforms a Unicode string into an ASCII string.  ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens).  This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.  Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]},
  keywords="syntax, string host label",
  doi="10.17487/RFC3492",
  }

@misc{rfc3493,
  author="R. Gilligan and S. Thomson and J. Bound and J. McCann and W. Stevens",
  title="{Basic Socket Interface Extensions for IPv6}",
  howpublished="RFC 3493 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3493",
  pages="1--39",
  year=2003,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3493.txt",
  key="RFC 3493",
  abstract={The de facto standard Application Program Interface (API) for TCP/IP applications is the ``sockets'' interface.  Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems.  TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications.  But changes are required to the sockets API to support IPv6 and this memo describes these changes.  These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options.  These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications.  Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document.  This memo provides information for the Internet community.},
  keywords="internet, protocol, api, application, program, interface, tcp, transmission control",
  doi="10.17487/RFC3493",
  }

@misc{rfc3494,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status}",
  howpublished="RFC 3494 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3494",
  pages="1--5",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3494.txt",
  key="RFC 3494",
  abstract={This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so.  This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status.  This memo provides information for the Internet community.},
  keywords="DAP, interactive, access, X.500, LDAP, lightweight directory protocol, STR-REP, directory names, representing names",
  doi="10.17487/RFC3494",
  }

@misc{rfc3495,
  author="B. Beser and P. Duffy",
  title="{Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration}",
  howpublished="RFC 3495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3495",
  pages="1--13",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3495.txt",
  key="RFC 3495",
  abstract={This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures.  Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA).  The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]},
  keywords="packetcable media terminal adapter, mta",
  doi="10.17487/RFC3495",
  }

@misc{rfc3496,
  author="A. G. Malis and T. Hsiao",
  title="{Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering}",
  howpublished="RFC 3496 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3496",
  pages="1--6",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3496.txt",
  key="RFC 3496",
  abstract={This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering.  This memo provides information for the Internet community.},
  keywords="diff-serv, diffserv, rsvp-te, resource reservation protocol",
  doi="10.17487/RFC3496",
  }

@misc{rfc3497,
  author="L. Gharai and C. Perkins and G. Goncher and A. Mankin",
  title="{RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video}",
  howpublished="RFC 3497 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3497",
  pages="1--12",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3497.txt",
  key="RFC 3497",
  abstract={This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M.  SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, hdtv, high definition television",
  doi="10.17487/RFC3497",
  }

@misc{rfc3498,
  author="J. Kuhfeld and J. Johnson and M. Thatcher",
  title="{Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures}",
  howpublished="RFC 3498 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3498",
  pages="1--43",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3498.txt",
  key="RFC 3498",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]},
  keywords="mib, management information base, tcp/ip transmission control protocol, internet protocol",
  doi="10.17487/RFC3498",
  }

@misc{rfc3499,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 3400-3499}",
  howpublished="RFC 3499 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3499",
  pages="1--38",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3499.txt",
  key="RFC 3499",
  doi="10.17487/RFC3499",
  }

@misc{rfc3501,
  author="M. Crispin",
  title="{INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1}",
  howpublished="RFC 3501 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3501",
  pages="1--108",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186, 6858, 7817",
url="https://www.rfc-editor.org/rfc/rfc3501.txt",
  key="RFC 3501",
  abstract={The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server.  IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.  IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.  IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.  These numbers are either message sequence numbers or unique identifiers.  IMAP4rev1 supports a single server.  A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.  IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]},
  keywords="IMAPv4, imap, imapv4rev1",
  doi="10.17487/RFC3501",
  }

@misc{rfc3502,
  author="M. Crispin",
  title="{Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension}",
  howpublished="RFC 3502 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3502",
  pages="1--7",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4466, 4469",
url="https://www.rfc-editor.org/rfc/rfc3502.txt",
  key="RFC 3502",
  abstract={This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501).  This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.  A server which supports this extension indicates this with a capability name of ``MULTIAPPEND''. [STANDARDS-TRACK]},
  keywords="IMAPv4, imap, imapv4rev1",
  doi="10.17487/RFC3502",
  }

@misc{rfc3503,
  author="A. Melnikov",
  title="{Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)}",
  howpublished="RFC 3503 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3503",
  pages="1--9",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3503.txt",
  key="RFC 3503",
  abstract={The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements.  However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.  This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]},
  keywords="mua, mail user agent, imap4",
  doi="10.17487/RFC3503",
  }

@misc{rfc3504,
  author="D. Eastlake",
  title="{Internet Open Trading Protocol (IOTP) Version 1, Errata}",
  howpublished="RFC 3504 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3504",
  pages="1--6",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3504.txt",
  key="RFC 3504",
  abstract={Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted.  This informational document lists these errors and provides corrections for them.  This memo provides information for the Internet community.},
  keywords="commerce, payment, system, merchant, system, xml, extensible, markup, language, security",
  doi="10.17487/RFC3504",
  }

@misc{rfc3505,
  author="D. Eastlake",
  title="{Electronic Commerce Modeling Language (ECML): Version 2 Requirements}",
  howpublished="RFC 3505 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3505",
  pages="1--8",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3505.txt",
  key="RFC 3505",
  abstract={This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification.  It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing.  This memo provides information for the Internet community.},
  keywords="xml, extensible markup language",
  doi="10.17487/RFC3505",
  }

@misc{rfc3506,
  author="K. Fujimura and D. Eastlake",
  title="{Requirements and Design for Voucher Trading System (VTS)}",
  howpublished="RFC 3506 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3506",
  pages="1--15",
  year=2003,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3506.txt",
  key="RFC 3506",
  abstract={Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions.  These activities can be generalized using the concept of a ``voucher'', which is a digital representation of the right to claim goods or services.  This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described.  This memo provides information for the Internet community.},
  keywords="generic voucher language, gvl",
  doi="10.17487/RFC3506",
  }

@misc{rfc3507,
  author="J. Elson and A. Cerpa",
  title="{Internet Content Adaptation Protocol (ICAP)}",
  howpublished="RFC 3507 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3507",
  pages="1--49",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3507.txt",
  key="RFC 3507",
  abstract={ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services.  ICAP is, in essence, a lightweight protocol for executing a ``remote procedure call'' on HTTP messages.  It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing (``adaptation'').  The server executes its transformation service on messages and sends back responses to the client, usually with modified messages.  Typically, the adapted messages are either HTTP requests or HTTP responses.  This memo provides information for the Internet community.},
  keywords="http, hyper-text markup protocol, request, response, client server",
  doi="10.17487/RFC3507",
  }

@misc{rfc3508,
  author="O. Levin",
  title="{H.323 Uniform Resource Locator (URL) Scheme Registration}",
  howpublished="RFC 3508 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3508",
  pages="1--6",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3508.txt",
  key="RFC 3508",
  abstract={ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL).  This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA).  This memo provides information for the Internet community.},
  keywords="itu-t, packet networks",
  doi="10.17487/RFC3508",
  }

@misc{rfc3509,
  author="A. Zinin and A. Lindem and D. Yeung",
  title="{Alternative Implementations of OSPF Area Border Routers}",
  howpublished="RFC 3509 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3509",
  pages="1--12",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3509.txt",
  key="RFC 3509",
  abstract={Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks.  Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations.  If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped.  This document describes alternative ABR behaviors implemented in Cisco and IBM routers.  This memo provides information for the Internet community.},
  keywords="traffic, backbone",
  doi="10.17487/RFC3509",
  }

@misc{rfc3510,
  author="R. Herriot and I. McDonald",
  title="{Internet Printing Protocol/1.1: IPP URL Scheme}",
  howpublished="RFC 3510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3510",
  pages="1--16",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3510.txt",
  key="RFC 3510",
  abstract={This memo defines the ``ipp'' URL (Uniform Resource Locator) scheme.  This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, ``IPP URL Scheme'', of RFC 2910.  An ``ipp'' URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]},
  keywords="IPP-E-T, IPP, application, media-type, media, type",
  doi="10.17487/RFC3510",
  }

@misc{rfc3511,
  author="B. Hickman and D. Newman and S. Tadjudin and T. Martin",
  title="{Benchmarking Methodology for Firewall Performance}",
  howpublished="RFC 3511 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3511",
  pages="1--34",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3511.txt",
  key="RFC 3511",
  abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls.  In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.  This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.},
  keywords="client server, traffic, authentication, web caching",
  doi="10.17487/RFC3511",
  }

@misc{rfc3512,
  author="M. MacFaden and D. Partain and J. Saperia and W. Tackabury",
  title="{Configuring Networks and Devices with Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3512 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3512",
  pages="1--83",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3512.txt",
  key="RFC 3512",
  abstract={This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP).  In particular, it offers guidance in the effective use of SNMP for configuration management.  This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks.  This memo provides information for the Internet community.},
  keywords="internet standard framework",
  doi="10.17487/RFC3512",
  }

@misc{rfc3513,
  author="R. Hinden and S. Deering",
  title="{Internet Protocol Version 6 (IPv6) Addressing Architecture}",
  howpublished="RFC 3513 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3513",
  pages="1--26",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4291",
url="https://www.rfc-editor.org/rfc/rfc3513.txt",
  key="RFC 3513",
  abstract={This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol.  The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]},
  keywords="internet, protocol, unicast, anycast, multicast, node",
  doi="10.17487/RFC3513",
  }

@misc{rfc3514,
  author="S. Bellovin",
  title="{The Security Flag in the IPv4 Header}",
  howpublished="RFC 3514 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3514",
  pages="1--6",
  year=2003,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3514.txt",
  key="RFC 3514",
  abstract={Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual.  We define a security flag in the IPv4 header as a means of distinguishing the two cases.  This memo provides information for the Internet community.},
  keywords="evil, evil bit",
  doi="10.17487/RFC3514",
  }

@misc{rfc3515,
  author="R. Sparks",
  title="{The Session Initiation Protocol (SIP) Refer Method}",
  howpublished="RFC 3515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3515",
  pages="1--23",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7647",
url="https://www.rfc-editor.org/rfc/rfc3515.txt",
  key="RFC 3515",
  abstract={This document defines the REFER method.  This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request.  It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request.  This can be used to enable many applications, including call transfer.  In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]},
  keywords="resource request, call transfer",
  doi="10.17487/RFC3515",
  }

@misc{rfc3516,
  author="L. Nerenberg",
  title="{IMAP4 Binary Content Extension}",
  howpublished="RFC 3516 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3516",
  pages="1--8",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4466",
url="https://www.rfc-editor.org/rfc/rfc3516.txt",
  key="RFC 3516",
  abstract={This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4).  It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]},
  keywords="internet message acess procotol",
  doi="10.17487/RFC3516",
  }

@misc{rfc3517,
  author="E. Blanton and M. Allman and K. Fall and L. Wang",
  title="{A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP}",
  howpublished="RFC 3517 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3517",
  pages="1--13",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6675",
url="https://www.rfc-editor.org/rfc/rfc3517.txt",
  key="RFC 3517",
  abstract={This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option.  The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]},
  keywords="transmission control protocol, retransmission, congestion control",
  doi="10.17487/RFC3517",
  }

@misc{rfc3518,
  author="M. Higashiyama and F. Baker and T. Liao",
  title="{Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)}",
  howpublished="RFC 3518 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3518",
  pages="1--40",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3518.txt",
  key="RFC 3518",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.  This document defines the NCP for establishing and configuring Remote Bridging for PPP links.  This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge.  This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]},
  keywords="PPP-BCP, point-to-point, datagrams, network",
  doi="10.17487/RFC3518",
  }

@misc{rfc3519,
  author="H. Levkowetz and S. Vaarala",
  title="{Mobile IP Traversal of Network Address Translation (NAT) Devices}",
  howpublished="RFC 3519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3519",
  pages="1--34",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3519.txt",
  key="RFC 3519",
  abstract={Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT).  This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices.  The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]},
  keywords="Internet Protocol, datagram, traffic, Mobile IP, NAT, NAPT, traversal, tunnelling, tunneling, UDP, private address space, keepalives, port 434, MIP, MIPv4, network address translation",
  doi="10.17487/RFC3519",
  }

@misc{rfc3520,
  author="L-N. Hamer and B. Gage and B. Kosinski and H. Shieh",
  title="{Session Authorization Policy Element}",
  howpublished="RFC 3520 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3520",
  pages="1--30",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3520.txt",
  key="RFC 3520",
  abstract={This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control.  The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes.  This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network.  We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS-TRACK]},
  keywords="admission control, resource reservation",
  doi="10.17487/RFC3520",
  }

@misc{rfc3521,
  author="L-N. Hamer and B. Gage and H. Shieh",
  title="{Framework for Session Set-up with Media Authorization}",
  howpublished="RFC 3521 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3521",
  pages="1--25",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3521.txt",
  key="RFC 3521",
  abstract={Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used.  During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host.  Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.  To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session.  This memo provides information for the Internet community.},
  keywords="qos, quality of service, streams, linkage, policy control, admission, theft service, resource reservation, token",
  doi="10.17487/RFC3521",
  }

@misc{rfc3522,
  author="R. Ludwig and M. Meyer",
  title="{The Eifel Detection Algorithm for TCP}",
  howpublished="RFC 3522 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3522",
  pages="1--14",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3522.txt",
  key="RFC 3522",
  abstract={The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily.  It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection.  The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP.  Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily.  The Eifel detection algorithm provides a basis for future TCP enhancements.  This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="transmission control protocol, loss recovery, timestamps",
  doi="10.17487/RFC3522",
  }

@misc{rfc3523,
  author="J. Polk",
  title="{Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology}",
  howpublished="RFC 3523 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3523",
  pages="1--6",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3523.txt",
  key="RFC 3523",
  abstract={This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls.  These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents.  This memo provides information for the Internet community.},
  keywords="naming convetions, phone",
  doi="10.17487/RFC3523",
  }

@misc{rfc3524,
  author="G. Camarillo and A. Monrad",
  title="{Mapping of Media Streams to Resource Reservation Flows}",
  howpublished="RFC 3524 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3524",
  pages="1--6",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3524.txt",
  key="RFC 3524",
  abstract={This document defines an extension to the Session Description Protocol (SDP) grouping framework.  It allows requesting a group of media streams to be mapped into a single resource reservation flow.  The SDP syntax needed is defined, as well as a new ``semantics'' attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]},
  keywords="sdp, session description protocol, srf, single",
  doi="10.17487/RFC3524",
  }

@misc{rfc3525,
  author="C. Groves and M. Pantaleo and T. Anderson and T. Taylor",
  title="{Gateway Control Protocol Version 1}",
  howpublished="RFC 3525 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3525",
  pages="1--213",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5125",
url="https://www.rfc-editor.org/rfc/rfc3525.txt",
  key="RFC 3525",
  abstract={This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller.  The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.  This document replaces RFC 3015.  It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16.  It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248.  The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1.  Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.  Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]},
  keywords="MEGACO, H.248, media, gateway, control",
  doi="10.17487/RFC3525",
  }

@misc{rfc3526,
  author="T. Kivinen and M. Kojo",
  title="{More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)}",
  howpublished="RFC 3526 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3526",
  pages="1--10",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3526.txt",
  key="RFC 3526",
  abstract={This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol.  It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14.  The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]},
  keywords="bit groups",
  doi="10.17487/RFC3526",
  }

@misc{rfc3527,
  author="K. Kinnear and M. Stapp and R. Johnson and J. Kumarasamy",
  title="{Link Selection sub-option for the Relay Agent Information Option for DHCPv4}",
  howpublished="RFC 3527 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3527",
  pages="1--9",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3527.txt",
  key="RFC 3527",
  abstract={This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4).  The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent.  The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server.  Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol",
  doi="10.17487/RFC3527",
  }

@misc{rfc3528,
  author="W. Zhao and H. Schulzrinne and E. Guttman",
  title="{Mesh-enhanced Service Location Protocol (mSLP)}",
  howpublished="RFC 3528 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3528",
  pages="1--15",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3528.txt",
  key="RFC 3528",
  abstract={This document describes the Mesh-enhanced Service Location Protocol (mSLP).  mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture.  Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding.  mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs.  mSLP is backward compatible with SLPv2 and can be deployed incrementally.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="da, directory agent, slpda, service agent, sa, slpv2",
  doi="10.17487/RFC3528",
  }

@misc{rfc3529,
  author="W. Harold",
  title="{Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 3529 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3529",
  pages="1--15",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3529.txt",
  key="RFC 3529",
  abstract={Markup Language-Remote Procedure Calling protocol that works over the Internet.  It defines an XML format for messages that are transfered between clients and servers using HTTP.  An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation.  Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.  This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="format, messages, clients, servers",
  doi="10.17487/RFC3529",
  }

@misc{rfc3530,
  author="S. Shepler and B. Callaghan and D. Robinson and R. Thurlow and C. Beame and M. Eisler and D. Noveck",
  title="{Network File System (NFS) version 4 Protocol}",
  howpublished="RFC 3530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3530",
  pages="1--275",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7530",
url="https://www.rfc-editor.org/rfc/rfc3530.txt",
  key="RFC 3530",
  abstract={The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813.  Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol.  In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added.  Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.  This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]},
  keywords="NFSv4, network, file, system",
  doi="10.17487/RFC3530",
  }

@misc{rfc3531,
  author="M. Blanchet",
  title="{A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block}",
  howpublished="RFC 3531 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3531",
  pages="1--7",
  year=2003,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3531.txt",
  key="RFC 3531",
  abstract={This document proposes a method to manage the assignment of bits of an IPv6 address block or range.  When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have.  It does it by keeping the bits around the borders of the partition to be free as long as possible.  This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6.  It is a generalization of RFC 1219 and can be used for IPv6 assignments.  This memo provides information for the Internet community.},
  keywords="address plan, addressing, range, space, internet protocol",
  doi="10.17487/RFC3531",
  }

@misc{rfc3532,
  author="T. Anderson and J. Buerkle",
  title="{Requirements for the Dynamic Partitioning of Switching Elements}",
  howpublished="RFC 3532 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3532",
  pages="1--11",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3532.txt",
  key="RFC 3532",
  abstract={This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions.  These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party.  This memo provides information for the Internet community.},
  keywords="atm, asynchronous transfer mode",
  doi="10.17487/RFC3532",
  }

@misc{rfc3533,
  author="S. Pfeiffer",
  title="{The Ogg Encapsulation Format Version 0}",
  howpublished="RFC 3533 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3533",
  pages="1--15",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3533.txt",
  key="RFC 3533",
  abstract={This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams.  It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream.  This memo provides information for the Internet community.  This memo provides information for the Internet community.},
  keywords="bitstream, media streams, video, audio, xiph.org, multimedia, media interleading format, video bitstream packaging, audio bitstream packaging, free encapsulation format, stream based storage of codec data, framed bitstream",
  doi="10.17487/RFC3533",
  }

@misc{rfc3534,
  author="L. Walleij",
  title="{The application/ogg Media Type}",
  howpublished="RFC 3534 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3534",
  pages="1--6",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5334",
url="https://www.rfc-editor.org/rfc/rfc3534.txt",
  key="RFC 3534",
  abstract={The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks.  The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet.  It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]},
  keywords="mime, multipurpose internet mail extenstions",
  doi="10.17487/RFC3534",
  }

@misc{rfc3535,
  author="J. Schoenwaelder",
  title="{Overview of the 2002 IAB Network Management Workshop}",
  howpublished="RFC 3535 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3535",
  pages="1--20",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3535.txt",
  key="RFC 3535",
  abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management.  The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002.  The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management.  This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.  This memo provides information for the Internet community.},
  keywords="Internet Architecture Board",
  doi="10.17487/RFC3535",
  }

@misc{rfc3536,
  author="P. Hoffman",
  title="{Terminology Used in Internationalization in the IETF}",
  howpublished="RFC 3536 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3536",
  pages="1--30",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6365",
url="https://www.rfc-editor.org/rfc/rfc3536.txt",
  key="RFC 3536",
  abstract={This document provides a glossary of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.  This memo provides information for the Internet community.},
  keywords="internet engineering task force",
  doi="10.17487/RFC3536",
  }

@misc{rfc3537,
  author="J. Schaad and R. Housley",
  title="{Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key}",
  howpublished="RFC 3537 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3537",
  pages="1--9",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3537.txt",
  key="RFC 3537",
  abstract={This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key.  The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key.  The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key.  One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]},
  keywords="",
  doi="10.17487/RFC3537",
  }

@misc{rfc3538,
  author="Y. Kawatsura",
  title="{Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)}",
  howpublished="RFC 3538 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3538",
  pages="1--56",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3538.txt",
  key="RFC 3538",
  abstract={This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API).  It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP.  This memo provides information for the Internet community.},
  keywords="payment, input, output, parameter",
  doi="10.17487/RFC3538",
  }

@misc{rfc3539,
  author="B. Aboba and J. Wood",
  title="{Authentication, Authorization and Accounting (AAA) Transport Profile}",
  howpublished="RFC 3539 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3539",
  pages="1--41",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3539.txt",
  key="RFC 3539",
  abstract={This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA).  It also provides recommendations on the use of transport by AAA protocols.  This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3539",
  }

@misc{rfc3540,
  author="N. Spring and D. Wetherall and D. Ely",
  title="{Robust Explicit Congestion Notification (ECN) Signaling with Nonces}",
  howpublished="RFC 3540 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3540",
  pages="1--13",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3540.txt",
  key="RFC 3540",
  abstract={This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender.  It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.  The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header.  It is computationally efficient for both routers and hosts.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="congestion control, tcp, traffic control protocol",
  doi="10.17487/RFC3540",
  }

@misc{rfc3541,
  author="A. Walsh",
  title="{A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)}",
  howpublished="RFC 3541 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3541",
  pages="1--6",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3541.txt",
  key="RFC 3541",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D.  This memo provides information for the Internet community.},
  keywords="virtual reality monitoring language, vrml, extensible markup language, x3d, xml, dtd, document type definition",
  doi="10.17487/RFC3541",
  }

@misc{rfc3542,
  author="W. Stevens and M. Thomas and E. Nordmark and T. Jinmei",
  title="{Advanced Sockets Application Program Interface (API) for IPv6}",
  howpublished="RFC 3542 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3542",
  pages="1--77",
  year=2003,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3542.txt",
  key="RFC 3542",
  abstract={This document provides sockets Application Program Interface (API) to support ``advanced'' IPv6 applications, as a supplement to a separate specification, RFC 3493.  The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields.  This document proposes some portable interfaces for applications that use raw sockets under IPv6.  There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information.  This document provides API access to these features too.  Additionally, some extended interfaces to libraries for the ``r'' commands are defined.  The extension will provide better backward compatibility to existing implementations that are not IPv6-capable.  This memo provides information for the Internet community.},
  keywords="application, program, interface",
  doi="10.17487/RFC3542",
  }

@misc{rfc3543,
  author="S. Glass and M. Chandra",
  title="{Registration Revocation in Mobile IPv4}",
  howpublished="RFC 3543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3543",
  pages="1--33",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3543.txt",
  key="RFC 3543",
  abstract={This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration.  The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well.  Moreover, the mechanism provides for this notification to be acknowledged.  A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC3543",
  }

@misc{rfc3544,
  author="T. Koren and S. Casner and C. Bormann",
  title="{IP Header Compression over PPP}",
  howpublished="RFC 3544 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3544",
  pages="1--14",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3544.txt",
  key="RFC 3544",
  abstract={This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661).  It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472).  Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]},
  keywords="IPCOM-PPP, internet, protocol, point-to-point, datagrams",
  doi="10.17487/RFC3544",
  }

@misc{rfc3545,
  author="T. Koren and S. Casner and J. Geevarghese and B. Thompson and P. Ruddy",
  title="{Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering}",
  howpublished="RFC 3545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3545",
  pages="1--22",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3545.txt",
  key="RFC 3545",
  abstract={This document describes a header compression scheme for point to point links with packet loss and long delays.  It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508.  CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired.  To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here.  The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters.  With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]},
  keywords="point to point, header",
  doi="10.17487/RFC3545",
  }

@misc{rfc3546,
  author="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and T. Wright",
  title="{Transport Layer Security (TLS) Extensions}",
  howpublished="RFC 3546 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3546",
  pages="1--29",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4366",
url="https://www.rfc-editor.org/rfc/rfc3546.txt",
  key="RFC 3546",
  abstract={This document describes extensions that may be used to add functionality to Transport Layer Security (TLS).  It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.  The extensions may be used by TLS clients and servers.  The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]},
  keywords="transport, protocol, layer, authentication, privacy",
  doi="10.17487/RFC3546",
  }

@misc{rfc3547,
  author="M. Baugher and B. Weis and T. Hardjono and H. Harney",
  title="{The Group Domain of Interpretation}",
  howpublished="RFC 3547 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3547",
  pages="1--48",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6407",
url="https://www.rfc-editor.org/rfc/rfc3547.txt",
  key="RFC 3547",
  abstract={This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications.  The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers.  These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]},
  keywords="isamkp, doi, key management, security, encryption",
  doi="10.17487/RFC3547",
  }

@misc{rfc3548,
  author="S. Josefsson",
  title="{The Base16, Base32, and Base64 Data Encodings}",
  howpublished="RFC 3548 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3548",
  pages="1--13",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4648",
url="https://www.rfc-editor.org/rfc/rfc3548.txt",
  key="RFC 3548",
  abstract={This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets.  This memo provides information for the Internet community.},
  keywords="schemes, data, line-feeds, alphabets, base encoding, hex",
  doi="10.17487/RFC3548",
  }

@misc{rfc3549,
  author="J. Salim and H. Khosravi and A. Kleen and A. Kuznetsov",
  title="{Linux Netlink as an IP Services Protocol}",
  howpublished="RFC 3549 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3549",
  pages="1--33",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3549.txt",
  key="RFC 3549",
  abstract={This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space.  The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service.  As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.).  This document is intended as informational in the context of prior art for the ForCES IETF working group.  This memo provides information for the Internet community.},
  keywords="internet protocol messaging system",
  doi="10.17487/RFC3549",
  }

@misc{rfc3550,
  author="H. Schulzrinne and S. Casner and R. Frederick and V. Jacobson",
  title="{RTP: A Transport Protocol for Real-Time Applications}",
  howpublished="RFC 3550 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3550",
  pages="1--104",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5506, 5761, 6051, 6222, 7022, 7160, 7164, 8083, 8108",
url="https://www.rfc-editor.org/rfc/rfc3550.txt",
  key="RFC 3550",
  abstract={This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers.  Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used.  The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]},
  keywords="RTP, end-to-end, network, audio, video, RTCP",
  doi="10.17487/RFC3550",
  }

@misc{rfc3551,
  author="H. Schulzrinne and S. Casner",
  title="{RTP Profile for Audio and Video Conferences with Minimal Control}",
  howpublished="RFC 3551 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3551",
  pages="1--44",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5761, 7007",
url="https://www.rfc-editor.org/rfc/rfc3551.txt",
  key="RFC 3551",
  abstract={This document describes a profile called ``RTP/AVP'' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control.  It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences.  In particular, this document defines a set of default mappings from payload type numbers to encodings.  This document also describes how audio and video data may be carried within RTP.  It defines a set of standard encodings and their names when used within RTP.  The descriptions provide pointers to reference implementations and the detailed standards.  This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.  This memorandum obsoletes RFC 1890.  It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found.  The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]},
  keywords="RTP-AV, end-to-end, network, conference",
  doi="10.17487/RFC3551",
  }

@misc{rfc3552,
  author="E. Rescorla and B. Korver",
  title="{Guidelines for Writing RFC Text on Security Considerations}",
  howpublished="RFC 3552 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3552",
  pages="1--44",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3552.txt",
  key="RFC 3552",
  abstract={All RFCs are required to have a Security Considerations section.  Historically, such sections have been relatively weak.  This document provides guidelines to RFC authors on how to write a good Security Considerations section.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Request for Comment",
  doi="10.17487/RFC3552",
  }

@misc{rfc3553,
  author="M. Mealling and L. Masinter and T. Hardie and G. Klyne",
  title="{An IETF URN Sub-namespace for Registered Protocol Parameters}",
  howpublished="RFC 3553 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3553",
  pages="1--8",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3553.txt",
  key="RFC 3553",
  abstract={This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items.  The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="syntax, uniform resource names",
  doi="10.17487/RFC3553",
  }

@misc{rfc3554,
  author="S. Bellovin and J. Ioannidis and A. Keromytis and R. Stewart",
  title="{On the Use of Stream Control Transmission Protocol (SCTP) with IPsec}",
  howpublished="RFC 3554 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3554",
  pages="1--9",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3554.txt",
  key="RFC 3554",
  abstract={This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]},
  keywords="ike, internet key exchange, security",
  doi="10.17487/RFC3554",
  }

@misc{rfc3555,
  author="S. Casner and P. Hoschka",
  title="{MIME Type Registration of RTP Payload Formats}",
  howpublished="RFC 3555 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3555",
  pages="1--45",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4855, 4856, updated by RFCs 3625, 4629",
url="https://www.rfc-editor.org/rfc/rfc3555.txt",
  key="RFC 3555",
  abstract={This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names.  This is useful in a text- based format or control protocol to identify the type of an RTP transmission.  This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes.  Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]},
  keywords="real time transport protocol, multipurpose internet mail extensions",
  doi="10.17487/RFC3555",
  }

@misc{rfc3556,
  author="S. Casner",
  title="{Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth}",
  howpublished="RFC 3556 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3556",
  pages="1--8",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3556.txt",
  key="RFC 3556",
  abstract={This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute.  These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]},
  keywords="real time transport protocol, real-time",
  doi="10.17487/RFC3556",
  }

@misc{rfc3557,
  author="Q. Xie",
  title="{RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding}",
  howpublished="RFC 3557 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3557",
  pages="1--15",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3557.txt",
  key="RFC 3557",
  abstract={This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]},
  keywords="real time transport protocol, real-time, dsr",
  doi="10.17487/RFC3557",
  }

@misc{rfc3558,
  author="A. Li",
  title="{RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)}",
  howpublished="RFC 3558 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3558",
  pages="1--23",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4788",
url="https://www.rfc-editor.org/rfc/rfc3558.txt",
  key="RFC 3558",
  abstract={This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech.  Two sub-formats are specified for different application scenarios.  A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame.  A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]},
  keywords="real time transport protocol, real-time, bundled, interleaved",
  doi="10.17487/RFC3558",
  }

@misc{rfc3559,
  author="D. Thaler",
  title="{Multicast Address Allocation MIB}",
  howpublished="RFC 3559 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3559",
  pages="1--37",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3559.txt",
  key="RFC 3559",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]},
  keywords="maas, management information base",
  doi="10.17487/RFC3559",
  }

@misc{rfc3560,
  author="R. Housley",
  title="{Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3560 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3560",
  pages="1--18",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3560.txt",
  key="RFC 3560",
  abstract={This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS).  The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients.  The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]},
  keywords="security encryption",
  doi="10.17487/RFC3560",
  }

@misc{rfc3561,
  author="C. Perkins and E. Belding-Royer and S. Das",
  title="{Ad hoc On-Demand Distance Vector (AODV) Routing}",
  howpublished="RFC 3561 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3561",
  pages="1--37",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3561.txt",
  key="RFC 3561",
  abstract={The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network.  It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network.  It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as ``counting to infinity'') associated with classical distance vector protocols.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="unicast, multiple nodes",
  doi="10.17487/RFC3561",
  }

@misc{rfc3562,
  author="M. Leech",
  title="{Key Management Considerations for the TCP MD5 Signature Option}",
  howpublished="RFC 3562 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3562",
  pages="1--7",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3562.txt",
  key="RFC 3562",
  abstract={The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure.  The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature.  This document addresses the security requirements of that keying material.  This memo provides information for the Internet community.},
  keywords="bgp, border gateway protocol, security, encryption",
  doi="10.17487/RFC3562",
  }

@misc{rfc3563,
  author="A. Zinin",
  title="{Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development}",
  howpublished="RFC 3563 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3563",
  pages="1--8",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6233",
url="https://www.rfc-editor.org/rfc/rfc3563.txt",
  key="RFC 3563",
  abstract={This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol.  The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3563",
  }

@misc{rfc3564,
  author="F. Le Faucheur and W. Lai",
  title="{Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering}",
  howpublished="RFC 3564 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3564",
  pages="1--22",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3564.txt",
  key="RFC 3564",
  abstract={This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE).  Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements.  Specification for this solution itself is outside the scope of this document.  A problem statement is first provided.  Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs.  The detailed requirements that need to be addressed by the technical solution are also reviewed.  Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.  This memo provides information for the Internet community.},
  keywords="multi-protocol label switching, bandwidth constraints model, overbooking",
  doi="10.17487/RFC3564",
  }

@misc{rfc3565,
  author="J. Schaad",
  title="{Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3565 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3565",
  pages="1--14",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3565.txt",
  key="RFC 3565",
  abstract={This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]},
  keywords="security, data encoding",
  doi="10.17487/RFC3565",
  }

@misc{rfc3566,
  author="S. Frankel and H. Herbert",
  title="{The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec}",
  howpublished="RFC 3566 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3566",
  pages="1--11",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3566.txt",
  key="RFC 3566",
  abstract={A Message Authentication Code (MAC) is a key-dependent one way hash function.  One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation.  The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams.  This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation.  This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]},
  keywords="authentication, hash security",
  doi="10.17487/RFC3566",
  }

@misc{rfc3567,
  author="T. Li and R. Atkinson",
  title="{Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication}",
  howpublished="RFC 3567 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3567",
  pages="1--6",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5304",
url="https://www.rfc-editor.org/rfc/rfc3567.txt",
  key="RFC 3567",
  abstract={This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.  The base specification includes an authentication mechanism that allows for multiple authentication algorithms.  The base specification only specifies the algorithm for cleartext passwords.  This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.  This memo provides information for the Internet community.},
  keywords="iso, international standards organization",
  doi="10.17487/RFC3567",
  }

@misc{rfc3568,
  author="A. Barbir and B. Cain and R. Nair and O. Spatscheck",
  title="{Known Content Network (CN) Request-Routing Mechanisms}",
  howpublished="RFC 3568 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3568",
  pages="1--19",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3568.txt",
  key="RFC 3568",
  abstract={This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics.  The document covers techniques that were commonly used in the industry on or before December 2000.  In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection.  In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing.  This memo provides information for the Internet community.},
  keywords="metrics, routing, redirection",
  doi="10.17487/RFC3568",
  }

@misc{rfc3569,
  author="S. Bhattacharyya",
  title="{An Overview of Source-Specific Multicast (SSM)}",
  howpublished="RFC 3569 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3569",
  pages="1--14",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3569.txt",
  key="RFC 3569",
  abstract={The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment.  It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.  This memo provides information for the Internet community.},
  keywords="routing applications, deployment interoperability",
  doi="10.17487/RFC3569",
  }

@misc{rfc3570,
  author="P. Rzewski and M. Day and D. Gilletti",
  title="{Content Internetworking (CDI) Scenarios}",
  howpublished="RFC 3570 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3570",
  pages="1--20",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6770",
url="https://www.rfc-editor.org/rfc/rfc3570.txt",
  key="RFC 3570",
  abstract={In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect.  The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals.  This memo provides information for the Internet community.},
  keywords="production networks",
  doi="10.17487/RFC3570",
  }

@misc{rfc3571,
  author="D. Rawlins and A. Kulkarni and K. Ho Chan and M. Bokaemper and D. Dutt",
  title="{Framework Policy Information Base for Usage Feedback}",
  howpublished="RFC 3571 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3571",
  pages="1--35",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3571.txt",
  key="RFC 3571",
  abstract={This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device.  The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported.  This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected.  This memo provides information for the Internet community.},
  keywords="pib",
  doi="10.17487/RFC3571",
  }

@misc{rfc3572,
  author="T. Ogura and M. Maruyama and T. Yoshida",
  title="{Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)}",
  howpublished="RFC 3572 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3572",
  pages="1--14",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc3572.txt",
  key="RFC 3572",
  abstract={Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).  This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame.  It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.  This memo provides information for the Internet community.},
  keywords="ipv6, synchronous optical network, synchronous digital hierarchy",
  doi="10.17487/RFC3572",
  }

@misc{rfc3573,
  author="I. Goyret",
  title="{Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)}",
  howpublished="RFC 3573 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3573",
  pages="1--13",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3573.txt",
  key="RFC 3573",
  abstract={The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions.  It is common for these PPP sessions to be established using modems connected over the public switched telephone network.  One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial.  While the modem call is on hold, the client phone line can be used to place or receive other calls.  The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled.  This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]},
  keywords="ppp, point to point, point-to-point, pstn, public switched telephone network",
  doi="10.17487/RFC3573",
  }

@misc{rfc3574,
  author="J. Soininen",
  title="{Transition Scenarios for 3GPP Networks}",
  howpublished="RFC 3574 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3574",
  pages="1--12",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3574.txt",
  key="RFC 3574",
  abstract={This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition.  The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet.  GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope.  The purpose of the document is to list the scenarios for further discussion and study.  This memo provides information for the Internet community.},
  keywords="third generation parnership project, packet, ipv6, ipv4, internet",
  doi="10.17487/RFC3574",
  }

@misc{rfc3575,
  author="B. Aboba",
  title="{IANA Considerations for RADIUS (Remote Authentication Dial In User Service)}",
  howpublished="RFC 3575 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3575",
  pages="1--8",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6929",
url="https://www.rfc-editor.org/rfc/rfc3575.txt",
  key="RFC 3575",
  abstract={This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]},
  keywords="internet assigned numbers authority, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC3575",
  }

@misc{rfc3576,
  author="M. Chiba and G. Dommety and M. Eklund and D. Mitton and B. Aboba",
  title="{Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)}",
  howpublished="RFC 3576 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3576",
  pages="1--30",
  year=2003,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5176",
url="https://www.rfc-editor.org/rfc/rfc3576.txt",
  key="RFC 3576",
  abstract={This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products.  This includes support for disconnecting users and changing authorizations applicable to a user session.  This memo provides information for the Internet community.},
  keywords="nas, network access server",
  doi="10.17487/RFC3576",
  }

@misc{rfc3577,
  author="S. Waldbusser and R. Cole and C. Kalbfleisch and D. Romascanu",
  title="{Introduction to the Remote Monitoring (RMON) Family of MIB Modules}",
  howpublished="RFC 3577 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3577",
  pages="1--31",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3577.txt",
  key="RFC 3577",
  abstract={The Remote Monitoring (RMON) Framework consists of a number of interrelated documents.  This memo describes these documents and how they relate to one another.  This memo provides information for the Internet community.},
  keywords="management information base",
  doi="10.17487/RFC3577",
  }

@misc{rfc3578,
  author="G. Camarillo and A. B. Roach and J. Peterson and L. Ong",
  title="{Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3578 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3578",
  pages="1--13",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3578.txt",
  key="RFC 3578",
  abstract={This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP).  This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]},
  keywords="pstn, public switched telephone network",
  doi="10.17487/RFC3578",
  }

@misc{rfc3579,
  author="B. Aboba and P. Calhoun",
  title="{RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)}",
  howpublished="RFC 3579 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3579",
  pages="1--46",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5080",
url="https://www.rfc-editor.org/rfc/rfc3579.txt",
  key="RFC 3579",
  abstract={This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms.  In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes.  This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server.  While EAP was originally developed for use with PPP, it is now also in use with IEEE 802.  This memo provides information for the Internet community.},
  keywords="RADIUS, encryption, NAS, Network, Access, Server",
  doi="10.17487/RFC3579",
  }

@misc{rfc3580,
  author="P. Congdon and B. Aboba and A. Smith and G. Zorn and J. Roese",
  title="{IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines}",
  howpublished="RFC 3580 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3580",
  pages="1--30",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7268",
url="https://www.rfc-editor.org/rfc/rfc3580.txt",
  key="RFC 3580",
  abstract={This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators.  The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.  This memo provides information for the Internet community.},
  keywords="AAA, authentication, authorization and accounting",
  doi="10.17487/RFC3580",
  }

@misc{rfc3581,
  author="J. Rosenberg and H. Schulzrinne",
  title="{An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing}",
  howpublished="RFC 3581 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3581",
  pages="1--13",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3581.txt",
  key="RFC 3581",
  abstract={The Session Initiation Protocol (SIP) operates over UDP and TCP, among others.  When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request.  This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT).  This extension defines a new parameter for the Via header field, called ``rport'', that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]},
  keywords="report client server",
  doi="10.17487/RFC3581",
  }

@misc{rfc3582,
  author="J. Abley and B. Black and V. Gill",
  title="{Goals for IPv6 Site-Multihoming Architectures}",
  howpublished="RFC 3582 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3582",
  pages="1--9",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3582.txt",
  key="RFC 3582",
  abstract={This document outlines a set of goals for proposed new IPv6 site- multihoming architectures.  It is recognised that this set of goals is ambitious and that some goals may conflict with others.  The solution or solutions adopted may only be able to satisfy some of the goals presented here.  This memo provides information for the Internet community.},
  keywords="internet protocol, multi6",
  doi="10.17487/RFC3582",
  }

@misc{rfc3583,
  author="H. Chaskar",
  title="{Requirements of a Quality of Service (QoS) Solution for Mobile IP}",
  howpublished="RFC 3583 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3583",
  pages="1--10",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3583.txt",
  key="RFC 3583",
  abstract={Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet.  However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP.  This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.  This memo provides information for the Internet community.},
  keywords="internet protocol, routing packets, node",
  doi="10.17487/RFC3583",
  }

@misc{rfc3584,
  author="R. Frye and D. Levi and S. Routhier and B. Wijnen",
  title="{Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework}",
  howpublished="RFC 3584 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3584",
  pages="1--51",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3584.txt",
  key="RFC 3584",
  abstract={The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1).  This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format.  This document obsoletes RFC 2576.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="SNMP, simple network management protocol, mib information base",
  doi="10.17487/RFC3584",
  }

@misc{rfc3585,
  author="J. Jason and L. Rafalow and E. Vyncke",
  title="{IPsec Configuration Policy Information Model}",
  howpublished="RFC 3585 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3585",
  pages="1--88",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3585.txt",
  key="RFC 3585",
  abstract={This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints.  The information model described in this document models the configuration parameters defined by IPSec.  The information model also covers the parameters found by the Internet Key Exchange protocol (IKE).  Other key exchange protocols could easily be added to the information model by a simple extension.  Further extensions can further be added easily due to the object-oriented nature of the model.  This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]},
  keywords="ike, internet key exchange protocol, core, pcim",
  doi="10.17487/RFC3585",
  }

@misc{rfc3586,
  author="M. Blaze and A. Keromytis and M. Richardson and L. Sanchez",
  title="{IP Security Policy (IPSP) Requirements}",
  howpublished="RFC 3586 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3586",
  pages="1--10",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3586.txt",
  key="RFC 3586",
  abstract={This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework.  The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties.  This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]},
  keywords="data integrity, authentication, host network",
  doi="10.17487/RFC3586",
  }

@misc{rfc3587,
  author="R. Hinden and S. Deering and E. Nordmark",
  title="{IPv6 Global Unicast Address Format}",
  howpublished="RFC 3587 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3587",
  pages="1--5",
  year=2003,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3587.txt",
  key="RFC 3587",
  abstract={This document obsoletes RFC 2374, ``An IPv6 Aggregatable Global Unicast Address Format''.  It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA).  This document makes RFC 2374 and the TLA/NLA structure historic.  This memo provides information for the Internet community.},
  keywords="internet, protocol, architecture, routing",
  doi="10.17487/RFC3587",
  }

@misc{rfc3588,
  author="P. Calhoun and J. Loughney and E. Guttman and G. Zorn and J. Arkko",
  title="{Diameter Base Protocol}",
  howpublished="RFC 3588 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3588",
  pages="1--147",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6733, updated by RFCs 5729, 5719, 6408",
url="https://www.rfc-editor.org/rfc/rfc3588.txt",
  key="RFC 3588",
  abstract={The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility.  Diameter is also intended to work in both local Authentication, Authorization \& Accounting and roaming situations.  This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications.  The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]},
  keywords="aaa, authentication authorization accounting, ip mobility",
  doi="10.17487/RFC3588",
  }

@misc{rfc3589,
  author="J. Loughney",
  title="{Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5}",
  howpublished="RFC 3589 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3589",
  pages="1--5",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3589.txt",
  key="RFC 3589",
  abstract={This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5.  This document does not pass judgment on the usage of these command codes.  Further more, these command codes are for use for Release 5.  For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification.  This memo provides information for the Internet community.},
  keywords="iana, allocation",
  doi="10.17487/RFC3589",
  }

@misc{rfc3590,
  author="B. Haberman",
  title="{Source Address Selection for the Multicast Listener Discovery (MLD) Protocol}",
  howpublished="RFC 3590 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3590",
  pages="1--6",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3590.txt",
  key="RFC 3590",
  abstract={It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration.  This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]},
  keywords="MLD-IPv6, internet protocol, routher, packets",
  doi="10.17487/RFC3590",
  }

@misc{rfc3591,
  author="H-K. Lam and M. Stewart and A. Huynh",
  title="{Definitions of Managed Objects for the Optical Interface Type}",
  howpublished="RFC 3591 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3591",
  pages="1--174",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3591.txt",
  key="RFC 3591",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets.  In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872.  The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]},
  keywords="management information base, mib, snmp, simple network management protocol, otn, optical transport network, itu-t, performance monitoring, configuration, dwdm, optical tranmission session, optical multiplex section, optical channel, otuk, odukt, oduk",
  doi="10.17487/RFC3591",
  }

@misc{rfc3592,
  author="K. Tesink",
  title="{Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type}",
  howpublished="RFC 3592 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3592",
  pages="1--73",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3592.txt",
  key="RFC 3592",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.  This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.  This memo replaces RFC 2558.  Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]},
  keywords="MIB, Management, SNMP",
  doi="10.17487/RFC3592",
  }

@misc{rfc3593,
  author="K. Tesink",
  title="{Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}",
  howpublished="RFC 3593 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3593",
  pages="1--10",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3593.txt",
  key="RFC 3593",
  abstract={This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals.  This memo replaces RFC 2493.  Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]},
  keywords="management, information, base, data",
  doi="10.17487/RFC3593",
  }

@misc{rfc3594,
  author="P. Duffy",
  title="{PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option}",
  howpublished="RFC 3594 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3594",
  pages="1--7",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3594.txt",
  key="RFC 3594",
  abstract={This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option.  This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol",
  doi="10.17487/RFC3594",
  }

@misc{rfc3595,
  author="B. Wijnen",
  title="{Textual Conventions for IPv6 Flow Label}",
  howpublished="RFC 3595 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3595",
  pages="1--6",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3595.txt",
  key="RFC 3595",
  abstract={This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label.  The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="mib, management information base",
  doi="10.17487/RFC3595",
  }

@misc{rfc3596,
  author="S. Thomson and C. Huitema and V. Ksinant and M. Souissi",
  title="{DNS Extensions to Support IP Version 6}",
  howpublished="RFC 3596 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3596",
  pages="1--8",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3596.txt",
  key="RFC 3596",
  abstract={This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6).  The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing.  The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]},
  keywords="internet protocol, domain name system, DNS, zone",
  doi="10.17487/RFC3596",
  }

@misc{rfc3597,
  author="A. Gustafsson",
  title="{Handling of Unknown DNS Resource Record (RR) Types}",
  howpublished="RFC 3597 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3597",
  pages="1--8",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4033, 4034, 4035, 5395, 6195, 6895",
url="https://www.rfc-editor.org/rfc/rfc3597.txt",
  key="RFC 3597",
  abstract={Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software.  This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]},
  keywords="domain name system, name server software, compression, transparency",
  doi="10.17487/RFC3597",
  }

@misc{rfc3598,
  author="K. Murchison",
  title="{Sieve Email Filtering -- Subaddress Extension}",
  howpublished="RFC 3598 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3598",
  pages="1--6",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5233",
url="https://www.rfc-editor.org/rfc/rfc3598.txt",
  key="RFC 3598",
  abstract={On email systems that allow for ``subaddressing'' or ``detailed addressing'' (e.g., ``ken+sieve@example.org''), it is sometimes desirable to make comparisons against these sub-parts of addresses.  This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS-TRACK]},
  keywords="users, detailed addressing language, address, part, test, detail, filter, mailbox",
  doi="10.17487/RFC3598",
  }

@misc{rfc3599,
  author="S. Ginoza",
  title="{Request for Comments Summary RFC Numbers 3500-3599}",
  howpublished="RFC 3599 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3599",
  pages="1--34",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3599.txt",
  key="RFC 3599",
  abstract={This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599.  This is a status report on these RFCs.},
  doi="10.17487/RFC3599",
  }

@misc{rfc3600,
  author="J. Reynolds and S. Ginoza",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 3600 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3600",
  pages="1--50",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3700",
url="https://www.rfc-editor.org/rfc/rfc3600.txt",
  key="RFC 3600",
  abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003.  It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series.  The latest version of this memo is designated STD 1.},
  doi="10.17487/RFC3600",
  }

@misc{rfc3601,
  author="C. Allocchio",
  title="{Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses}",
  howpublished="RFC 3601 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3601",
  pages="1--10",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3601.txt",
  key="RFC 3601",
  abstract={This memo describes the full set of notations needed to represent a text string in a Dial Sequence.  A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional ``actions'' (such as ``wait for dialtone'', ``pause for N secs'', etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.},
  keywords="notations, dtmf, dual tone multifrequency, telephony, e-mail addresses, urls, integrated messaging, 3gpp",
  doi="10.17487/RFC3601",
  }

@misc{rfc3602,
  author="S. Frankel and R. Glenn and S. Kelly",
  title="{The AES-CBC Cipher Algorithm and Its Use with IPsec}",
  howpublished="RFC 3602 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3602",
  pages="1--15",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3602.txt",
  key="RFC 3602",
  abstract={This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).},
  keywords="ipsec, encapsulating, security, payload",
  doi="10.17487/RFC3602",
  }

@misc{rfc3603,
  author="W. Marshall and F. Andreasen",
  title="{Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture}",
  howpublished="RFC 3603 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3603",
  pages="1--28",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5503",
url="https://www.rfc-editor.org/rfc/rfc3603.txt",
  key="RFC 3603",
  abstract={In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call.  This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture.  These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues.  The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.},
  keywords="network access coordination",
  doi="10.17487/RFC3603",
  }

@misc{rfc3604,
  author="H. Khosravi and G. Kullgren and S. Shew and J. Sadler and A. Watanabe",
  title="{Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)}",
  howpublished="RFC 3604 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3604",
  pages="1--16",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3604.txt",
  key="RFC 3604",
  abstract={This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP).  It also contains clarifications and suggested changes to the GSMPv3 specification.},
  keywords="controllers, routers, formats, codes",
  doi="10.17487/RFC3604",
  }

@misc{rfc3605,
  author="C. Huitema",
  title="{Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)}",
  howpublished="RFC 3605 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3605",
  pages="1--8",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3605.txt",
  key="RFC 3605",
  abstract={The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions.  When a session requires multiple ports, SDP assumes that these ports have consecutive numbers.  However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation.  To handle this, we propose an extension attribute to SDP.},
  keywords="nat, network access translation, port mapping",
  doi="10.17487/RFC3605",
  }

@misc{rfc3606,
  author="F. Ly and M. Noto and A. Smith and E. Spiegel and K. Tesink",
  title="{Definitions of Supplemental Managed Objects for ATM Interface}",
  howpublished="RFC 3606 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3606",
  pages="1--94",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3606.txt",
  key="RFC 3606",
  abstract={This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).},
  keywords="asynchronous transfer mode, mib, management information base",
  doi="10.17487/RFC3606",
  }

@misc{rfc3607,
  author="M. Leech",
  title="{Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool}",
  howpublished="RFC 3607 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3607",
  pages="1--8",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3607.txt",
  key="RFC 3607",
  abstract={This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack.  It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.},
  keywords="security encryption, des, data standard, distributed cryptanalysis, computer virus, network worm, codebreaking",
  doi="10.17487/RFC3607",
  }

@misc{rfc3608,
  author="D. Willis and B. Hoeneisen",
  title="{Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration}",
  howpublished="RFC 3608 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3608",
  pages="1--17",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5630",
url="https://www.rfc-editor.org/rfc/rfc3608.txt",
  key="RFC 3608",
  abstract={This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.},
  keywords="user agent, domain, register",
  doi="10.17487/RFC3608",
  }

@misc{rfc3609,
  author="R. Bonica and K. Kompella and D. Meyer",
  title="{Tracing Requirements for Generic Tunnels}",
  howpublished="RFC 3609 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3609",
  pages="1--9",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3609.txt",
  key="RFC 3609",
  abstract={This document specifies requirements for a generic route-tracing application.  It also specifies requirements for a protocol that will support that application.  Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane.  They will also use the application to discover details regarding tunnels that support IP forwarding.  The generic route-tracing application, specified herein, supports a superset of the functionality that ``traceroute'' currently offers.  Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network.  Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.},
  keywords="traceroute, application, IP, internet protocol",
  doi="10.17487/RFC3609",
  }

@misc{rfc3610,
  author="D. Whiting and R. Housley and N. Ferguson",
  title="{Counter with CBC-MAC (CCM)}",
  howpublished="RFC 3610 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3610",
  pages="1--26",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3610.txt",
  key="RFC 3610",
  abstract={Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode.  CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).},
  keywords="authentication, encryption, security, ciphers",
  doi="10.17487/RFC3610",
  }

@misc{rfc3611,
  author="T. Friedman and R. Caceres and A. Clark",
  title="{RTP Control Protocol Extended Reports (RTCP XR)}",
  howpublished="RFC 3611 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3611",
  pages="1--55",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3611.txt",
  key="RFC 3611",
  abstract={This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP).  XR packets are composed of report blocks, and seven block types are defined here.  The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets.  Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics.  In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.},
  keywords="real time transport protocol, packet, type, sdp, session description, blocks",
  doi="10.17487/RFC3611",
  }

@misc{rfc3612,
  author="A. Farrel",
  title="{Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)}",
  howpublished="RFC 3612 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3612",
  pages="1--16",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3612.txt",
  key="RFC 3612",
  abstract={This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable.  The issues and extensions described in this document are equally applicable to RFC 3212, ``Constraint-Based LSP Setup Using LDP''.},
  keywords="mpls, fault tolerence, high availability, multiprotocol label switching, cr-ldp, high availability restart",
  doi="10.17487/RFC3612",
  }

@misc{rfc3613,
  author="R. Morgan and K. Hazelton",
  title="{Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)}",
  howpublished="RFC 3613 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3613",
  pages="1--8",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3613.txt",
  key="RFC 3613",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE).  This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.},
  keywords="internet2, middleware",
  doi="10.17487/RFC3613",
  }

@misc{rfc3614,
  author="J. Smith",
  title="{A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)}",
  howpublished="RFC 3614 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3614",
  pages="1--6",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3614.txt",
  key="RFC 3614",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards.  Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.},
  keywords="iso, international organization standardization, multimedia, metadata, xml, classification, schemes, digital rights management",
  doi="10.17487/RFC3614",
  }

@misc{rfc3615,
  author="J. Gustin and A. Goyens",
  title="{A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging}",
  howpublished="RFC 3615 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3615",
  pages="1--5",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3615.txt",
  key="RFC 3615",
  abstract={This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.},
  keywords="messaging service, interface software",
  doi="10.17487/RFC3615",
  }

@misc{rfc3616,
  author="F. Bellifemine and I. Constantinescu and S. Willmott",
  title="{A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)}",
  howpublished="RFC 3616 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3616",
  pages="1--8",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3616.txt",
  key="RFC 3616",
  abstract={This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA).  This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.},
  keywords="URN NID, Uniform Resource Name Namespace Identification",
  doi="10.17487/RFC3616",
  }

@misc{rfc3617,
  author="E. Lear",
  title="{Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)}",
  howpublished="RFC 3617 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3617",
  pages="1--7",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3617.txt",
  key="RFC 3617",
  abstract={The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time.  While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.},
  doi="10.17487/RFC3617",
  }

@misc{rfc3618,
  author="B. Fenner and D. Meyer",
  title="{Multicast Source Discovery Protocol (MSDP)}",
  howpublished="RFC 3618 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3618",
  pages="1--19",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3618.txt",
  key="RFC 3618",
  abstract={The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together.  Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains.  This document reflects existing MSDP implementations.},
  keywords="ipv4, pim-sm, independent multicast, sparse-mode, rp, rendezvous point",
  doi="10.17487/RFC3618",
  }

@misc{rfc3619,
  author="S. Shah and M. Yip",
  title="{Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1}",
  howpublished="RFC 3619 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3619",
  pages="1--7",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3619.txt",
  key="RFC 3619",
  abstract={This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings.  An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).},
  keywords="ethernet rings, robust",
  doi="10.17487/RFC3619",
  }

@misc{rfc3620,
  author="D. New",
  title="{The TUNNEL Profile}",
  howpublished="RFC 3620 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3620",
  pages="1--18",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3620.txt",
  key="RFC 3620",
  abstract={This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy.  It allows authorized users to access services through a firewall.},
  keywords="beep, blocks extensible exchange protocol, firewall, application layer",
  doi="10.17487/RFC3620",
  }

@misc{rfc3621,
  author="A. Berger and D. Romascanu",
  title="{Power Ethernet MIB}",
  howpublished="RFC 3621 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3621",
  pages="1--20",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3621.txt",
  key="RFC 3621",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).},
  keywords="management information base, data terminal equipment power, dte, power sourcing equipment, pse",
  doi="10.17487/RFC3621",
  }

@misc{rfc3622,
  author="M. Mealling",
  title="{A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project}",
  howpublished="RFC 3622 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3622",
  pages="1--7",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3622.txt",
  key="RFC 3622",
  abstract={This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.},
  keywords="federated network identity",
  doi="10.17487/RFC3622",
  }

@misc{rfc3623,
  author="J. Moy and P. Pillay-Esnault and A. Lindem",
  title="{Graceful OSPF Restart}",
  howpublished="RFC 3623 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3623",
  pages="1--18",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3623.txt",
  key="RFC 3623",
  abstract={This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted.  This is called ``graceful restart'' or ``non-stop forwarding''.  A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes.  In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo.  Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.},
  keywords="open shortest path first, non-stop forwarding",
  doi="10.17487/RFC3623",
  }

@misc{rfc3624,
  author="B. Foster and D. Auerbach and F. Andreasen",
  title="{The Media Gateway Control Protocol (MGCP) Bulk Audit Package}",
  howpublished="RFC 3624 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3624",
  pages="1--19",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3624.txt",
  key="RFC 3624",
  abstract={The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time.  This document describes a new MGCP package for bulk auditing of a group of gateway endpoints.  It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.},
  keywords="call agent, endpoints, naming conventions",
  doi="10.17487/RFC3624",
  }

@misc{rfc3625,
  author="R. Gellens and H. Garudadri",
  title="{The QCP File Format and Media Types for Speech Data}",
  howpublished="RFC 3625 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3625",
  pages="1--15",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3625.txt",
  key="RFC 3625",
  abstract={RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format.  Many implementations have been using the ``QCP'' file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets).  This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.},
  keywords="13k, qcelp, audio, multimedia, voip, real time transport protocol, multipurpose internet mail extensions",
  doi="10.17487/RFC3625",
  }

@misc{rfc3626,
  author="T. Clausen and P. Jacquet",
  title="{Optimized Link State Routing Protocol (OLSR)}",
  howpublished="RFC 3626 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3626",
  pages="1--75",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3626.txt",
  key="RFC 3626",
  abstract={This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks.  The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN.  The key concept used in the protocol is that of multipoint relays (MPRs).  MPRs are selected nodes which forward broadcast messages during the flooding process.  This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message.  In OLSR, link state information is generated only by nodes elected as MPRs.  Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network.  As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors.  Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network.  This information is then used for route calculation.  OLSR provides optimal routes (in terms of number of hops).  The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.},
  keywords="mobile ad hoc, wireless multipoint relays, mpr, mprs",
  doi="10.17487/RFC3626",
  }

@misc{rfc3627,
  author="P. Savola",
  title="{Use of /127 Prefix Length Between Routers Considered Harmful}",
  howpublished="RFC 3627 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3627",
  pages="1--6",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6547",
url="https://www.rfc-editor.org/rfc/rfc3627.txt",
  key="RFC 3627",
  abstract={In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.  Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented.  This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.},
  keywords="address space, anycast",
  doi="10.17487/RFC3627",
  }

@misc{rfc3628,
  author="D. Pinkas and N. Pope and J. Ross",
  title="{Policy Requirements for Time-Stamping Authorities (TSAs)}",
  howpublished="RFC 3628 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3628",
  pages="1--43",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3628.txt",
  key="RFC 3628",
  abstract={This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better.  A TSA may define its own policy which enhances the policy defined in this document.  Such a policy shall incorporate or further constrain the requirements identified in this document.},
  keywords="tokens, public key certificates",
  doi="10.17487/RFC3628",
  }

@misc{rfc3629,
  author="F. Yergeau",
  title="{UTF-8, a transformation format of ISO 10646}",
  howpublished="RFC 3629 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3629",
  pages="1--14",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3629.txt",
  key="RFC 3629",
  abstract={ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.},
  keywords="UTF-8, UCS, Transformation, Format",
  doi="10.17487/RFC3629",
  }

@misc{rfc3630,
  author="D. Katz and K. Kompella and D. Yeung",
  title="{Traffic Engineering (TE) Extensions to OSPF Version 2}",
  howpublished="RFC 3630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3630",
  pages="1--14",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4203, 5786",
url="https://www.rfc-editor.org/rfc/rfc3630.txt",
  key="RFC 3630",
  abstract={This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.},
  keywords="open-shortest, path, first, ink, state, advertisement",
  doi="10.17487/RFC3630",
  }

@misc{rfc3631,
  author="S. Bellovin and J. Schiller and C. Kaufman",
  title="{Security Mechanisms for the Internet}",
  howpublished="RFC 3631 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3631",
  pages="1--20",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3631.txt",
  key="RFC 3631",
  abstract={Security must be built into Internet Protocols for those protocols to offer their services securely.  Many security problems can be traced to improper implementations.  However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable.  Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.  However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable.  The precise one that is appropriate in any given situation can vary.  We review a number of different choices, explaining the properties of each.},
  keywords="protocol, host compromise, dos, denial of service",
  doi="10.17487/RFC3631",
  }

@misc{rfc3632,
  author="S. Hollenbeck and S. Veeramachaneni and S. Yalamanchilli",
  title="{VeriSign Registry Registrar Protocol (RRP) Version 2.0.0}",
  howpublished="RFC 3632 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3632",
  pages="1--8",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3632.txt",
  key="RFC 3632",
  abstract={This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832.  The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.},
  keywords="RRP, shared, registration, system, gLTD, ccTLD, top level domain",
  doi="10.17487/RFC3632",
  }

@misc{rfc3633,
  author="O. Troan and R. Droms",
  title="{IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6}",
  howpublished="RFC 3633 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3633",
  pages="1--19",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6603, 7550",
url="https://www.rfc-editor.org/rfc/rfc3633.txt",
  key="RFC 3633",
  abstract={The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP).  This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.},
  keywords="automated delegation router",
  doi="10.17487/RFC3633",
  }

@misc{rfc3634,
  author="K. Luehrs and R. Woundy and J. Bevilacqua and N. Davoust",
  title="{Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option}",
  howpublished="RFC 3634 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3634",
  pages="1--7",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3634.txt",
  key="RFC 3634",
  abstract={This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.},
  keywords="",
  doi="10.17487/RFC3634",
  }

@misc{rfc3635,
  author="J. Flick",
  title="{Definitions of Managed Objects for the Ethernet-like Interface Types}",
  howpublished="RFC 3635 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3635",
  pages="1--64",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3635.txt",
  key="RFC 3635",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing Ethernet-like interfaces.  This memo obsoletes RFC 2665.  It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.},
  keywords="MIB, management, information, base",
  doi="10.17487/RFC3635",
  }

@misc{rfc3636,
  author="J. Flick",
  title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}",
  howpublished="RFC 3636 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3636",
  pages="1--62",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4836",
url="https://www.rfc-editor.org/rfc/rfc3636.txt",
  key="RFC 3636",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs).  This memo obsoletes RFC 2668.  This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs.  This memo also obsoletes RFC 1515.},
  keywords="MAU-MIB, management, information, base",
  doi="10.17487/RFC3636",
  }

@misc{rfc3637,
  author="C.M. Heard",
  title="{Definitions of Managed Objects for the Ethernet WAN Interface Sublayer}",
  howpublished="RFC 3637 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3637",
  pages="1--37",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3637.txt",
  key="RFC 3637",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.  In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).  The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.},
  keywords="mib, management information base",
  doi="10.17487/RFC3637",
  }

@misc{rfc3638,
  author="J. Flick and C. M. Heard",
  title="{Applicability Statement for Reclassification of RFC 1643 to Historic Status}",
  howpublished="RFC 3638 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3638",
  pages="1--5",
  year=2003,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3638.txt",
  key="RFC 3638",
  abstract={This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.},
  keywords="ETHER-MIB, MIB, Network, Management, SNMP, Ethernet",
  doi="10.17487/RFC3638",
  }

@misc{rfc3639,
  author="M. St. Johns and G. Huston and IAB",
  title="{Considerations on the use of a Service Identifier in Packet Headers}",
  howpublished="RFC 3639 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3639",
  pages="1--8",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3639.txt",
  key="RFC 3639",
  abstract={This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.},
  keywords="port fields, protocol number",
  doi="10.17487/RFC3639",
  }

@misc{rfc3640,
  author="J. van der Meer and D. Mackie and V. Swaminathan and D. Singer and P. Gentric",
  title="{RTP Payload Format for Transport of MPEG-4 Elementary Streams}",
  howpublished="RFC 3640 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3640",
  pages="1--43",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5691",
url="https://www.rfc-editor.org/rfc/rfc3640.txt",
  key="RFC 3640",
  abstract={The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard.  MPEG defines tools to compress content such as audio-visual information into elementary streams.  This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.},
  keywords="real time transport protocol, audio video streams",
  doi="10.17487/RFC3640",
  }

@misc{rfc3641,
  author="S. Legg",
  title="{Generic String Encoding Rules (GSER) for ASN.1 Types}",
  howpublished="RFC 3641 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3641",
  pages="1--16",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4792",
url="https://www.rfc-editor.org/rfc/rfc3641.txt",
  key="RFC 3641",
  abstract={This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.},
  keywords="asn.1, abstract syntax notation",
  doi="10.17487/RFC3641",
  }

@misc{rfc3642,
  author="S. Legg",
  title="{Common Elements of Generic String Encoding Rules (GSER) Encodings}",
  howpublished="RFC 3642 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3642",
  pages="1--13",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3642.txt",
  key="RFC 3642",
  abstract={The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type.  Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors.  This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.},
  keywords="asn.1, abstract syntax notation",
  doi="10.17487/RFC3642",
  }

@misc{rfc3643,
  author="R. Weber and M. Rajagopal and F. Travostino and M. O'Donnell and C. Monia and M. Merhar",
  title="{Fibre Channel (FC) Frame Encapsulation}",
  howpublished="RFC 3643 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3643",
  pages="1--20",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3643.txt",
  key="RFC 3643",
  abstract={This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network.  This specification is intended for use by any IETF protocol that encapsulates FC frames.},
  keywords="ips, ip storage, frame header",
  doi="10.17487/RFC3643",
  }

@misc{rfc3644,
  author="Y. Snir and Y. Ramberg and J. Strassner and R. Cohen and B. Moore",
  title="{Policy Quality of Service (QoS) Information Model}",
  howpublished="RFC 3644 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3644",
  pages="1--73",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3644.txt",
  key="RFC 3644",
  abstract={This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies.  This document is based on the IETF Policy Core Information Model and its extensions.  It defines an information model for QoS enforcement for differentiated and integrated services using policy.  It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.},
  keywords="integrated differentiated, object oriented",
  doi="10.17487/RFC3644",
  }

@misc{rfc3645,
  author="S. Kwan and P. Garg and J. Gilroy and L. Esibov and J. Westhead and R. Hall",
  title="{Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)}",
  howpublished="RFC 3645 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3645",
  pages="1--26",
  year=2003,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3645.txt",
  key="RFC 3645",
  abstract={The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS.  TSIG is extensible through the definition of new algorithms.  This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743).  This document updates RFC 2845.},
  keywords="TSIG, domain name system, transaction, signature",
  doi="10.17487/RFC3645",
  }

@misc{rfc3646,
  author="R. Droms",
  title="{DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 3646 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3646",
  pages="1--7",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3646.txt",
  key="RFC 3646",
  abstract={This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.},
  keywords="domain name system, service, server, client",
  doi="10.17487/RFC3646",
  }

@misc{rfc3647,
  author="S. Chokhani and W. Ford and R. Sabett and C. Merrill and S. Wu",
  title="{Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework}",
  howpublished="RFC 3647 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3647",
  pages="1--94",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3647.txt",
  key="RFC 3647",
  abstract={This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates.  In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement.  This document supersedes RFC 2527.},
  keywords="pkix, encryption, security, authentication",
  doi="10.17487/RFC3647",
  }

@misc{rfc3648,
  author="J. Whitehead and J. Reschke",
  title="{Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol}",
  howpublished="RFC 3648 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3648",
  pages="1--30",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3648.txt",
  key="RFC 3648",
  abstract={This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members.  Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server.  Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.},
  keywords="server client semantics, ordering, orderpatch method, position header, ordering-type header",
  doi="10.17487/RFC3648",
  }

@misc{rfc3649,
  author="S. Floyd",
  title="{HighSpeed TCP for Large Congestion Windows}",
  howpublished="RFC 3649 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3649",
  pages="1--34",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3649.txt",
  key="RFC 3649",
  abstract={The proposals in this document are experimental.  While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control.  In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.  This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows.  The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments.  For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours).  This is widely acknowledged as an unrealistic constraint.  To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.},
  keywords="transmission control protocol, round-trip, rate packet",
  doi="10.17487/RFC3649",
  }

@misc{rfc3650,
  author="S. Sun and L. Lannom and B. Boesch",
  title="{Handle System Overview}",
  howpublished="RFC 3650 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3650",
  pages="1--21",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3650.txt",
  key="RFC 3650",
  abstract={This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs.  The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet.  The Handle System manages handles, which are unique names for digital objects and other Internet resources.},
  keywords="name service",
  doi="10.17487/RFC3650",
  }

@misc{rfc3651,
  author="S. Sun and S. Reilly and L. Lannom",
  title="{Handle System Namespace and Service Definition}",
  howpublished="RFC 3651 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3651",
  pages="1--41",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3651.txt",
  key="RFC 3651",
  abstract={The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet.  This document provides a detailed description of the Handle System namespace, and its data, service, and operation models.  The namespace definition specifies the handle syntax and its semantic structure.  The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service.  The service model provides definitions of various Handle System components and explains how they work together over the network.  Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.},
  keywords="name service",
  doi="10.17487/RFC3651",
  }

@misc{rfc3652,
  author="S. Sun and S. Reilly and L. Lannom and J. Petrone",
  title="{Handle System Protocol (ver 2.1) Specification}",
  howpublished="RFC 3652 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3652",
  pages="1--53",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3652.txt",
  key="RFC 3652",
  abstract={The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet.  This document describes the protocol used for client software to access the Handle System for both handle resolution and administration.  The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle.  It also defines the messages exchanged between the client and server for any handle operation.},
  keywords="name service",
  doi="10.17487/RFC3652",
  }

@misc{rfc3653,
  author="J. Boyer and M. Hughes and J. Reagle",
  title="{XML-Signature XPath Filter 2.0}",
  howpublished="RFC 3653 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3653",
  pages="1--15",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3653.txt",
  key="RFC 3653",
  abstract={XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML.  Some applications require the ability to specify a subset of a given XML document as the information content to be signed.  The XML Signature specification meets this requirement with the XPath transform.  However, this transform can be difficult to implement efficiently with existing technologies.  This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles.  This document is the W3C XML Signature XPath-Filter 2.0 Recommendation.  This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation.  It is a stable document and may be used as reference material or cited as a normative reference from another document.  W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.  This enhances the functionality and interoperability of the Web.},
  keywords="extensible markup language, digital signature",
  doi="10.17487/RFC3653",
  }

@misc{rfc3654,
  author="H. Khosravi and T. Anderson",
  title="{Requirements for Separation of IP Control and Forwarding}",
  howpublished="RFC 3654 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3654",
  pages="1--18",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3654.txt",
  key="RFC 3654",
  abstract={This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology.  This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.},
  keywords="forces, forwarding control, element separation data",
  doi="10.17487/RFC3654",
  }

@misc{rfc3655,
  author="B. Wellington and O. Gudmundsson",
  title="{Redefinition of DNS Authenticated Data (AD) bit}",
  howpublished="RFC 3655 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3655",
  pages="1--8",
  year=2003,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3655.txt",
  key="RFC 3655",
  abstract={This document alters the specification defined in RFC 2535.  Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful.  This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.},
  keywords="DNS-SECEXT, dns, authentication",
  doi="10.17487/RFC3655",
  }

@misc{rfc3656,
  author="R. Siemborski",
  title="{The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol}",
  howpublished="RFC 3656 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3656",
  pages="1--19",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3656.txt",
  key="RFC 3656",
  abstract={As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users.  It is preferable to allow many machines to share the responsibility of mail delivery.  The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace.  This document is intended to serve as a reference guide to that protocol.},
  keywords="imap, pop3, post office protocol, internet message access",
  doi="10.17487/RFC3656",
  }

@misc{rfc3657,
  author="S. Moriai and A. Kato",
  title="{Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3657 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3657",
  pages="1--14",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3657.txt",
  key="RFC 3657",
  abstract={This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).},
  keywords="security, mail content, key",
  doi="10.17487/RFC3657",
  }

@misc{rfc3658,
  author="O. Gudmundsson",
  title="{Delegation Signer (DS) Resource Record (RR)}",
  howpublished="RFC 3658 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3658",
  pages="1--19",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFC 3755",
url="https://www.rfc-editor.org/rfc/rfc3658.txt",
  key="RFC 3658",
  abstract={The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone.  The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations.  The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.  This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers.  This change is not backwards compatible with RFC 2535.  This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.},
  keywords="zone cut, zone key, security, dns, domain name system",
  doi="10.17487/RFC3658",
  }

@misc{rfc3659,
  author="P. Hethmon",
  title="{Extensions to FTP}",
  howpublished="RFC 3659 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3659",
  pages="1--61",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3659.txt",
  key="RFC 3659",
  abstract={This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode.  It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]},
  keywords="FTP, file transfer protocol, stream mode, data transfer storage",
  doi="10.17487/RFC3659",
  }

@misc{rfc3660,
  author="B. Foster and F. Andreasen",
  title="{Basic Media Gateway Control Protocol (MGCP) Packages}",
  howpublished="RFC 3660 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3660",
  pages="1--64",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3660.txt",
  key="RFC 3660",
  abstract={This document provides a basic set of Media Gateway Control Protocol (MGCP) packages.  The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages.  In addition to these, five new packages are defined here.  These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.},
  keywords="generic, line, trunk, handset, dtmf, dual tone multifrequency",
  doi="10.17487/RFC3660",
  }

@misc{rfc3661,
  author="B. Foster and C. Sivachelvan",
  title="{Media Gateway Control Protocol (MGCP) Return Code Usage}",
  howpublished="RFC 3661 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3661",
  pages="1--24",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3661.txt",
  key="RFC 3661",
  abstract={This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0.  Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway.  That is not possible and not necessary.  What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation.  The purpose of this document is to provide implementation guidelines to ensure that consistency.},
  keywords="guidelines, call agent, implementation",
  doi="10.17487/RFC3661",
  }

@misc{rfc3662,
  author="R. Bless and K. Nichols and K. Wehrle",
  title="{A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services}",
  howpublished="RFC 3662 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3662",
  pages="1--17",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3662.txt",
  key="RFC 3662",
  abstract={This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be ``starved'' (although starvation is not strictly required) in a properly functioning network.  This is in contrast to the Internet's ``best-effort'' or ``normal Internet traffic'' model, where prolonged starvation indicates network problems.  In this sense, the proposed PDB's traffic is forwarded with a ``lower'' priority than the normal ``best-effort'' Internet traffic, thus the PDB is called ``Lower Effort'' (LE).  Use of this PDB permits a network operator to strictly limit the effect of its traffic on ``best-effort''/``normal'' or all other Internet traffic.  This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.},
  keywords="traffic network, ds, le",
  doi="10.17487/RFC3662",
  }

@misc{rfc3663,
  author="A. Newton",
  title="{Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3663 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3663",
  pages="1--21",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3663.txt",
  key="RFC 3663",
  abstract={Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes.  This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.},
  keywords="referral types, well-known",
  doi="10.17487/RFC3663",
  }

@misc{rfc3664,
  author="P. Hoffman",
  title="{The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)}",
  howpublished="RFC 3664 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3664",
  pages="1--4",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4434",
url="https://www.rfc-editor.org/rfc/rfc3664.txt",
  key="RFC 3664",
  abstract={Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES).  This document describes such an algorithm, called AES-XCBC-PRF-128.},
  keywords="security, ipsec, advanced encryption standard, mac, message authentication code",
  doi="10.17487/RFC3664",
  }

@misc{rfc3665,
  author="A. Johnston and S. Donovan and R. Sparks and C. Cunningham and K. Summers",
  title="{Session Initiation Protocol (SIP) Basic Call Flow Examples}",
  howpublished="RFC 3665 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3665",
  pages="1--94",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3665.txt",
  key="RFC 3665",
  abstract={This document gives examples of Session Initiation Protocol (SIP) call flows.  Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers.  Scenarios include SIP Registration and SIP session establishment.  Call flow diagrams and message details are shown.},
  keywords="user agent, client proxy, redirect",
  doi="10.17487/RFC3665",
  }

@misc{rfc3666,
  author="A. Johnston and S. Donovan and R. Sparks and C. Cunningham and K. Summers",
  title="{Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows}",
  howpublished="RFC 3666 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3666",
  pages="1--118",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3666.txt",
  key="RFC 3666",
  abstract={This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN).  Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways.  Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP.  PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling.  PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange).  Call flow diagrams and message details are shown.},
  keywords="user proxy, gateway, telephony",
  doi="10.17487/RFC3666",
  }

@misc{rfc3667,
  author="S. Bradner",
  title="{IETF Rights in Contributions}",
  howpublished="RFC 3667 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3667",
  pages="1--18",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3978",
url="https://www.rfc-editor.org/rfc/rfc3667.txt",
  key="RFC 3667",
  abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible.  This memo details the IETF policies on rights in Contributions to the IETF.  It also describes the objectives that the policies are designed to meet.  This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="intellectual property rights, copyright, ipr",
  doi="10.17487/RFC3667",
  }

@misc{rfc3668,
  author="S. Bradner",
  title="{Intellectual Property Rights in IETF Technology}",
  howpublished="RFC 3668 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3668",
  pages="1--17",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 3979",
url="https://www.rfc-editor.org/rfc/rfc3668.txt",
  key="RFC 3668",
  abstract={The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible.  The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders.  This memo details the IETF policies concerning IPR related to technology worked on within the IETF.  It also describes the objectives that the policies are designed to meet.  This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026.  This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipr, copyright",
  doi="10.17487/RFC3668",
  }

@misc{rfc3669,
  author="S. Brim",
  title="{Guidelines for Working Groups on Intellectual Property Issues}",
  howpublished="RFC 3669 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3669",
  pages="1--17",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3669.txt",
  key="RFC 3669",
  abstract={This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues.  It documents specific examples of how IPR issues have been dealt with in the IETF.  This memo provides information for the Internet community.},
  keywords="ipr, copyright",
  doi="10.17487/RFC3669",
  }

@misc{rfc3670,
  author="B. Moore and D. Durham and J. Strassner and A. Westerinen and W. Weiss",
  title="{Information Model for Describing Network Device QoS Datapath Mechanisms}",
  howpublished="RFC 3670 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3670",
  pages="1--97",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3670.txt",
  key="RFC 3670",
  abstract={The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts.  Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device.  This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services.  This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices.  Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.  This document, as well as QPIM, are information models.  That is, they represent information independent of a binding to a specific type of repository},
  keywords="quality of service, host, netowrk devices, traffic",
  doi="10.17487/RFC3670",
  }

@misc{rfc3671,
  author="K. Zeilenga",
  title="{Collective Attributes in the Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3671 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3671",
  pages="1--10",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3671.txt",
  key="RFC 3671",
  abstract={X.500 collective attributes allow common characteristics to be shared between collections of entries.  This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol).  This document provides schema definitions for collective attributes for use in LDAP.},
  keywords="x.500, information model schema",
  doi="10.17487/RFC3671",
  }

@misc{rfc3672,
  author="K. Zeilenga",
  title="{Subentries in the Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3672 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3672",
  pages="1--12",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3672.txt",
  key="RFC 3672",
  abstract={In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement.  This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).},
  keywords="special subtree",
  doi="10.17487/RFC3672",
  }

@misc{rfc3673,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes}",
  howpublished="RFC 3673 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3673",
  pages="1--5",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3673.txt",
  key="RFC 3673",
  abstract={The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes.  This document describes an LDAP extension which clients may use to request the return of all operational attributes.},
  keywords="user mechanisms, extension",
  doi="10.17487/RFC3673",
  }

@misc{rfc3674,
  author="K. Zeilenga",
  title="{Feature Discovery in Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3674 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3674",
  pages="1--5",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4512",
url="https://www.rfc-editor.org/rfc/rfc3674.txt",
  key="RFC 3674",
  abstract={The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features.  This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.},
  keywords="elective extensions, mechanisms",
  doi="10.17487/RFC3674",
  }

@misc{rfc3675,
  author="D. {Eastlake 3rd}",
  title="{.sex Considered Dangerous}",
  howpublished="RFC 3675 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3675",
  pages="1--22",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3675.txt",
  key="RFC 3675",
  abstract={Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag ``adult'' or ``unsafe'' material or the like.  This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.},
  keywords="top level domains, tld, ip addresses, internet protocol filters",
  doi="10.17487/RFC3675",
  }

@misc{rfc3676,
  author="R. Gellens",
  title="{The Text/Plain Format and DelSp Parameters}",
  howpublished="RFC 3676 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3676",
  pages="1--20",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3676.txt",
  key="RFC 3676",
  abstract={This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type.  In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines.  This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.  This document supersedes the one specified in RFC 2646, ``The Text/Plain Format Parameter'', and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]},
  keywords="media type, mime, multipurpose, internet, mail, extension",
  doi="10.17487/RFC3676",
  }

@misc{rfc3677,
  author="L. Daigle and Internet Architecture Board",
  title="{IETF ISOC Board of Trustee Appointment Procedures}",
  howpublished="RFC 3677 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3677",
  pages="1--7",
  year=2003,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3677.txt",
  key="RFC 3677",
  abstract={This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.},
  keywords="internet society, bot, engineering task force",
  doi="10.17487/RFC3677",
  }

@misc{rfc3678,
  author="D. Thaler and B. Fenner and B. Quinn",
  title="{Socket Interface Extensions for Multicast Source Filters}",
  howpublished="RFC 3678 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3678",
  pages="1--18",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3678.txt",
  key="RFC 3678",
  abstract={The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic.  This capability also simplifies support of one-to-many type multicast applications.  This document specifies new socket options and functions to manage source filters for IP Multicast group memberships.  It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs).  These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.},
  keywords="ip, internet protocol, application program interface, apis, input, output",
  doi="10.17487/RFC3678",
  }

@misc{rfc3679,
  author="R. Droms",
  title="{Unused Dynamic Host Configuration Protocol (DHCP) Option Codes}",
  howpublished="RFC 3679 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3679",
  pages="1--8",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3679.txt",
  key="RFC 3679",
  abstract={Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used.  This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future.  The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.},
  keywords="dynamic, host, configuration, protocol, internet, assigned, numbers, authority",
  doi="10.17487/RFC3679",
  }

@misc{rfc3680,
  author="J. Rosenberg",
  title="{A Session Initiation Protocol (SIP) Event Package for Registrations}",
  howpublished="RFC 3680 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3680",
  pages="1--26",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6140",
url="https://www.rfc-editor.org/rfc/rfc3680.txt",
  key="RFC 3680",
  abstract={This document defines a Session Initiation Protocol (SIP) event package for registrations.  Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations.  Registrations can also be altered by administrators in order to enforce policy.  As a result, these registrations represent a piece of state in the network that can change dynamically.  There are many cases where a user agent would like to be notified of changes in this state.  This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]},
  keywords="REGISTER, event package name, event package parameters",
  doi="10.17487/RFC3680",
  }

@misc{rfc3681,
  author="R. Bush and R. Fink",
  title="{Delegation of E.F.F.3.IP6.ARPA}",
  howpublished="RFC 3681 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3681",
  pages="1--4",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3681.txt",
  key="RFC 3681",
  abstract={This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.},
  keywords="dns, domain name system",
  doi="10.17487/RFC3681",
  }

@misc{rfc3682,
  author="V. Gill and J. Heasley and D. Meyer",
  title="{The Generalized TTL Security Mechanism (GTSM)}",
  howpublished="RFC 3682 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3682",
  pages="1--11",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5082",
url="https://www.rfc-editor.org/rfc/rfc3682.txt",
  key="RFC 3682",
  abstract={The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461).  This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036).  While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions.  GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="time to live, packet hop limit",
  doi="10.17487/RFC3682",
  }

@misc{rfc3683,
  author="M. Rose",
  title="{A Practice for Revoking Posting Rights to IETF Mailing Lists}",
  howpublished="RFC 3683 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3683",
  pages="1--13",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3683.txt",
  key="RFC 3683",
  abstract={All self-governing bodies have ways of managing the scope of participant interaction.  The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion.  An important part of this consensus-driven process is the pervasive use of mailing lists for discussion.  Notably, in a small number of cases, a participant has engaged in a ``denial-of-service'' attack to disrupt the consensus-driven process.  Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks.  This memo recommends such a practice for use by the IETF.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3683",
  }

@misc{rfc3684,
  author="R. Ogier and F. Templin and M. Lewis",
  title="{Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)}",
  howpublished="RFC 3684 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3684",
  pages="1--46",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3684.txt",
  key="RFC 3684",
  abstract={Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination.  Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm.  To minimize overhead, each node reports only *part* of its source tree to neighbors.  TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree.  Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks.  TBRPF performs neighbor discovery using ``differential'' HELLO messages which report only *changes* in the status of neighbors.  This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="proactive routing, ad-hoc networks, neighbor discovery, link-state routing, mobile ad-hoc network, mobile mesh network, packet radio network, wireless communications",
  doi="10.17487/RFC3684",
  }

@misc{rfc3685,
  author="C. Daboo",
  title="{SIEVE Email Filtering: Spamtest and VirusTest Extensions}",
  howpublished="RFC 3685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3685",
  pages="1--9",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5235",
url="https://www.rfc-editor.org/rfc/rfc3685.txt",
  key="RFC 3685",
  abstract={The SIEVE mail filtering language ``spamtest'' and ``virustest'' extensions permit users to use simple, portable commands for spam and virus tests on email messages.  Each extension provides a new test using matches against numeric 'scores'.  It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]},
  keywords="messages, portable commands",
  doi="10.17487/RFC3685",
  }

@misc{rfc3686,
  author="R. Housley",
  title="{Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)}",
  howpublished="RFC 3686 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3686",
  pages="1--19",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3686.txt",
  key="RFC 3686",
  abstract={This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.},
  keywords="authentication vector, cipher block",
  doi="10.17487/RFC3686",
  }

@misc{rfc3687,
  author="S. Legg",
  title="{Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules}",
  howpublished="RFC 3687 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3687",
  pages="1--42",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3687.txt",
  key="RFC 3687",
  abstract={The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes.  Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability.  This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]},
  keywords="syntax data schema",
  doi="10.17487/RFC3687",
  }

@misc{rfc3688,
  author="M. Mealling",
  title="{The IETF XML Registry}",
  howpublished="RFC 3688 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3688",
  pages="1--8",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3688.txt",
  key="RFC 3688",
  abstract={This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.},
  keywords="extensible markup language",
  doi="10.17487/RFC3688",
  }

@misc{rfc3689,
  author="K. Carlberg and R. Atkinson",
  title="{General Requirements for Emergency Telecommunication Service (ETS)}",
  howpublished="RFC 3689 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3689",
  pages="1--10",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3689.txt",
  key="RFC 3689",
  abstract={This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS).  Solutions to these requirements are not presented in this document.  Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s).  This memo provides information for the Internet community.},
  doi="10.17487/RFC3689",
  }

@misc{rfc3690,
  author="K. Carlberg and R. Atkinson",
  title="{IP Telephony Requirements for Emergency Telecommunication Service (ETS)}",
  howpublished="RFC 3690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3690",
  pages="1--7",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3690.txt",
  key="RFC 3690",
  abstract={This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony.  It is an extension to the general requirements presented in RFC 3689.  Solutions to these requirements are not presented in this document.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3690",
  }

@misc{rfc3691,
  author="A. Melnikov",
  title="{Internet Message Access Protocol (IMAP) UNSELECT command}",
  howpublished="RFC 3691 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3691",
  pages="1--5",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3691.txt",
  key="RFC 3691",
  abstract={This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it.  Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox.  While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]},
  keywords="mailbox session client",
  doi="10.17487/RFC3691",
  }

@misc{rfc3692,
  author="T. Narten",
  title="{Assigning Experimental and Testing Numbers Considered Useful}",
  howpublished="RFC 3692 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3692",
  pages="1--7",
  year=2004,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3692.txt",
  key="RFC 3692",
  abstract={When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment.  For example, to test a new DHCP option, one needs an option number to identify the new function.  This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features.  This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.},
  keywords="iana, internet assigned numbers authority, values, implementations",
  doi="10.17487/RFC3692",
  }

@misc{rfc3693,
  author="J. Cuellar and J. Morris and D. Mulligan and J. Peterson and J. Polk",
  title="{Geopriv Requirements}",
  howpublished="RFC 3693 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3693",
  pages="1--30",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6280, 7459",
url="https://www.rfc-editor.org/rfc/rfc3693.txt",
  key="RFC 3693",
  abstract={Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity).  There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.  This document focuses on the authorization, security and privacy requirements for such location-dependent services.  Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object.  This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.  This memo provides information for the Internet community.},
  keywords="security privacy, lo, location object",
  doi="10.17487/RFC3693",
  }

@misc{rfc3694,
  author="M. Danley and D. Mulligan and J. Morris and J. Peterson",
  title="{Threat Analysis of the Geopriv Protocol}",
  howpublished="RFC 3694 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3694",
  pages="1--18",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6280",
url="https://www.rfc-editor.org/rfc/rfc3694.txt",
  key="RFC 3694",
  abstract={This document provides some analysis of threats against the Geopriv protocol architecture.  It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv.  Some security properties that meet these threats are enumerated as a reference for Geopriv requirements.  This memo provides information for the Internet community.},
  keywords="privacy security, data information",
  doi="10.17487/RFC3694",
  }

@misc{rfc3695,
  author="M. Luby and L. Vicisano",
  title="{Compact Forward Error Correction (FEC) Schemes}",
  howpublished="RFC 3695 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3695",
  pages="1--13",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5445",
url="https://www.rfc-editor.org/rfc/rfc3695.txt",
  key="RFC 3695",
  abstract={This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452.  The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length.  Thus, they more flexibly support different delivery models with less packet header overhead.  This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0.  This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="content, stream, delivery, multicast, internet protocol",
  doi="10.17487/RFC3695",
  }

@misc{rfc3696,
  author="J. Klensin",
  title="{Application Techniques for Checking and Transformation of Names}",
  howpublished="RFC 3696 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3696",
  pages="1--16",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3696.txt",
  key="RFC 3696",
  abstract={Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information.  The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications.  These flaws make it more difficult, or impossible, for users of the applications to access the full Internet.  This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves.  This document draws summaries of the applicable rules together in one place and supplies references to the actual standards.  This memo provides information for the Internet community.},
  keywords="top-level domains, tlds",
  doi="10.17487/RFC3696",
  }

@misc{rfc3697,
  author="J. Rajahalme and A. Conta and B. Carpenter and S. Deering",
  title="{IPv6 Flow Label Specification}",
  howpublished="RFC 3697 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3697",
  pages="1--9",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6437",
url="https://www.rfc-editor.org/rfc/rfc3697.txt",
  key="RFC 3697",
  abstract={This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.  Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.  The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]},
  keywords="nodes, packets",
  doi="10.17487/RFC3697",
  }

@misc{rfc3698,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP): Additional Matching Rules}",
  howpublished="RFC 3698 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3698",
  pages="1--9",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4517",
url="https://www.rfc-editor.org/rfc/rfc3698.txt",
  key="RFC 3698",
  abstract={This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP).  As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, directory services",
  doi="10.17487/RFC3698",
  }

@misc{rfc3700,
  author="J. Reynolds and S. Ginoza",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 3700 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3700",
  pages="1--54",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5000",
url="https://www.rfc-editor.org/rfc/rfc3700.txt",
  key="RFC 3700",
  abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004.  It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series.  The latest version of this memo is designated STD 1. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3700",
  }

@misc{rfc3701,
  author="R. Fink and R. Hinden",
  title="{6bone (IPv6 Testing Address Allocation) Phaseout}",
  howpublished="RFC 3701 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3701",
  pages="1--6",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3701.txt",
  key="RFC 3701",
  abstract={The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet.  It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471.  As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone.  This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this.  This document obsoletes RFC 2471, ``IPv6 Testing Address Allocation'', December, 1998.  RFC 2471 will become historic.  This memo provides information for the Internet community.},
  keywords="internet, protocol, protocotype, software, architecture",
  doi="10.17487/RFC3701",
  }

@misc{rfc3702,
  author="J. Loughney and G. Camarillo",
  title="{Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3702 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3702",
  pages="1--15",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3702.txt",
  key="RFC 3702",
  abstract={As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions.  This document sets out the basic requirements for this work.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3702",
  }

@misc{rfc3703,
  author="J. Strassner and B. Moore and R. Moats and E. Ellesson",
  title="{Policy Core Lightweight Directory Access Protocol (LDAP) Schema}",
  howpublished="RFC 3703 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3703",
  pages="1--61",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4104",
url="https://www.rfc-editor.org/rfc/rfc3703.txt",
  key="RFC 3703",
  abstract={This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol.  This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other.  Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.  These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]},
  keywords="mapping classes",
  doi="10.17487/RFC3703",
  }

@misc{rfc3704,
  author="F. Baker and P. Savola",
  title="{Ingress Filtering for Multihomed Networks}",
  howpublished="RFC 3704 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3704",
  pages="1--16",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3704.txt",
  key="RFC 3704",
  abstract={BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network.  As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment.  There are cases when this may create problems, e.g., with multihoming.  This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular.  This memo updates RFC 2827.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ISP, Internet Service Provider, Internet Protocol, DOS",
  doi="10.17487/RFC3704",
  }

@misc{rfc3705,
  author="B. Ray and R. Abbi",
  title="{High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}",
  howpublished="RFC 3705 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3705",
  pages="1--11",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3705.txt",
  key="RFC 3705",
  abstract={This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals.  The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]},
  keywords="management information base",
  doi="10.17487/RFC3705",
  }

@misc{rfc3706,
  author="G. Huang and S. Beaulieu and D. Rochefort",
  title="{A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers}",
  howpublished="RFC 3706 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3706",
  pages="1--13",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3706.txt",
  key="RFC 3706",
  abstract={This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors.  The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness.  DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources.  This memo provides information for the Internet community.},
  keywords="security authentication, dead peer detection, dpd, keepalive",
  doi="10.17487/RFC3706",
  }

@misc{rfc3707,
  author="A. Newton",
  title="{Cross Registry Internet Service Protocol (CRISP) Requirements}",
  howpublished="RFC 3707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3707",
  pages="1--26",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3707.txt",
  key="RFC 3707",
  abstract={Internet registries expose administrative and operational data via varying directory services.  This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.  This memo provides information for the Internet community.},
  keywords="directory services domain",
  doi="10.17487/RFC3707",
  }

@misc{rfc3708,
  author="E. Blanton and M. Allman",
  title="{Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions}",
  howpublished="RFC 3708 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3708",
  pages="1--9",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3708.txt",
  key="RFC 3708",
  abstract={TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively.  This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3708",
  }

@misc{rfc3709,
  author="S. Santesson and R. Housley and T. Freeman",
  title="{Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates}",
  howpublished="RFC 3709 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3709",
  pages="1--21",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6170",
url="https://www.rfc-editor.org/rfc/rfc3709.txt",
  key="RFC 3709",
  abstract={This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]},
  keywords="authentication, security identification",
  doi="10.17487/RFC3709",
  }

@misc{rfc3710,
  author="H. Alvestrand",
  title="{An IESG charter}",
  howpublished="RFC 3710 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3710",
  pages="1--12",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 3932, 5742",
url="https://www.rfc-editor.org/rfc/rfc3710.txt",
  key="RFC 3710",
  abstract={This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF).  It is meant to document the charter of the IESG as it is presently understood.  This memo provides information for the Internet community.},
  keywords="internet engineering steering group",
  doi="10.17487/RFC3710",
  }

@misc{rfc3711,
  author="M. Baugher and D. McGrew and M. Naslund and E. Carrara and K. Norrman",
  title="{The Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 3711 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3711",
  pages="1--56",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5506, 6904",
url="https://www.rfc-editor.org/rfc/rfc3711.txt",
  key="RFC 3711",
  abstract={This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]},
  keywords="authentication, traffic, cryptographic",
  doi="10.17487/RFC3711",
  }

@misc{rfc3712,
  author="P. Fleming and I. McDonald",
  title="{Lightweight Directory Access Protocol (LDAP): Schema for Printer Services}",
  howpublished="RFC 3712 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3712",
  pages="1--33",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7612",
url="https://www.rfc-editor.org/rfc/rfc3712.txt",
  key="RFC 3712",
  abstract={This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS).  This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911).  A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759).  This memo provides information for the Internet community.},
  keywords="object classes, attributes",
  doi="10.17487/RFC3712",
  }

@misc{rfc3713,
  author="M. Matsui and J. Nakajima and S. Moriai",
  title="{A Description of the Camellia Encryption Algorithm}",
  howpublished="RFC 3713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3713",
  pages="1--15",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3713.txt",
  key="RFC 3713",
  abstract={This document describes the Camellia encryption algorithm.  Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys.  The algorithm description is presented together with key scheduling part and data randomizing part.  This memo provides information for the Internet community.},
  keywords="security, key, cryptographic",
  doi="10.17487/RFC3713",
  }

@misc{rfc3714,
  author="S. Floyd and J. Kempf",
  title="{IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet}",
  howpublished="RFC 3714 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3714",
  pages="1--32",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3714.txt",
  key="RFC 3714",
  abstract={This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet.  These concerns have to do with fairness, user quality, and with the dangers of congestion collapse.  The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term.  This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP.  We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic.  This memo provides information for the Internet community.},
  keywords="end-to-end, qos, qualify of service, voip, internet protocol",
  doi="10.17487/RFC3714",
  }

@misc{rfc3715,
  author="B. Aboba and W. Dixon",
  title="{IPsec-Network Address Translation (NAT) Compatibility Requirements}",
  howpublished="RFC 3715 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3715",
  pages="1--18",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3715.txt",
  key="RFC 3715",
  abstract={This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them.  Perhaps the most common use of IPsec is in providing virtual private networking capabilities.  One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet.  Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels.  The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses.  This memo provides information for the Internet community.},
  keywords="virtual private networks, vpns, intranet",
  doi="10.17487/RFC3715",
  }

@misc{rfc3716,
  author="IAB Advisory Committee",
  title="{The IETF in the Large:  Administration and Execution}",
  howpublished="RFC 3716 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3716",
  pages="1--40",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3716.txt",
  key="RFC 3716",
  abstract={In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.  The AdvComm mandate did not include the standards process itself.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3716",
  }

@misc{rfc3717,
  author="B. Rajagopalan and J. Luciani and D. Awduche",
  title="{IP over Optical Networks: A Framework}",
  howpublished="RFC 3717 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3717",
  pages="1--48",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3717.txt",
  key="RFC 3717",
  abstract={The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks.  The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing.  At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane.  This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as ``IP over optical networks'').  This memo provides information for the Internet community.},
  keywords="transport infrastructure, routers, high-speed",
  doi="10.17487/RFC3717",
  }

@misc{rfc3718,
  author="R. McGowan",
  title="{A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access}",
  howpublished="RFC 3718 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3718",
  pages="1--11",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3718.txt",
  key="RFC 3718",
  abstract={This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF.  It is intended solely for informational purposes.  Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding \& standardization processes.},
  doi="10.17487/RFC3718",
  }

@misc{rfc3719,
  author="J. Parker",
  title="{Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)}",
  howpublished="RFC 3719 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3719",
  pages="1--15",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3719.txt",
  key="RFC 3719",
  abstract={This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today.  These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol.  A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic.  This memo provides information for the Internet community.},
  keywords="routing, routeing, interior gateway protocol, igp, conformance, ip traffic",
  doi="10.17487/RFC3719",
  }

@misc{rfc3720,
  author="J. Satran and K. Meth and C. Sapuntzakis and M. Chadalapaka and E. Zeidner",
  title="{Internet Small Computer Systems Interface (iSCSI)}",
  howpublished="RFC 3720 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3720",
  pages="1--257",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7143, updated by RFCs 3980, 4850, 5048, 7146",
url="https://www.rfc-editor.org/rfc/rfc3720.txt",
  key="RFC 3720",
  abstract={This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP.  The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.  SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices.  SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).  As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols.  IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to ``carry'' SCSI. [STANDARDS-TRACK]},
  keywords="transport protocol, tcp, transmission control protocol",
  doi="10.17487/RFC3720",
  }

@misc{rfc3721,
  author="M. Bakke and J. Hafner and J. Hufferd and K. Voruganti and M. Krueger",
  title="{Internet Small Computer Systems Interface (iSCSI) Naming and Discovery}",
  howpublished="RFC 3721 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3721",
  pages="1--22",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7143",
url="https://www.rfc-editor.org/rfc/rfc3721.txt",
  key="RFC 3721",
  abstract={This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators.  This document complements the iSCSI protocol document.  Flexibility is the key guiding principle behind this document.  That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.  This memo provides information for the Internet community.},
  keywords="targets, environments, scalibilty, target, initiator, scsi, device name",
  doi="10.17487/RFC3721",
  }

@misc{rfc3722,
  author="M. Bakke",
  title="{String Profile for Internet Small Computer Systems Interface (iSCSI) Names}",
  howpublished="RFC 3722 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3722",
  pages="1--8",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3722.txt",
  key="RFC 3722",
  abstract={This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world.  The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network.  The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]},
  keywords="transport, unique, global",
  doi="10.17487/RFC3722",
  }

@misc{rfc3723,
  author="B. Aboba and J. Tseng and J. Walker and V. Rangan and F. Travostino",
  title="{Securing Block Storage Protocols over IP}",
  howpublished="RFC 3723 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3723",
  pages="1--70",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc3723.txt",
  key="RFC 3723",
  abstract={This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange).  Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols.  Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]},
  keywords="internet, threat models, performance, security",
  doi="10.17487/RFC3723",
  }

@misc{rfc3724,
  author="J. Kempf and R. Austein and IAB",
  title="{The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture}",
  howpublished="RFC 3724 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3724",
  pages="1--14",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3724.txt",
  key="RFC 3724",
  abstract={The end-to-end principle is the core architectural guideline of the Internet.  In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years.  We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.  This memo provides information for the Internet community.},
  keywords="architectural guideline",
  doi="10.17487/RFC3724",
  }

@misc{rfc3725,
  author="J. Rosenberg and J. Peterson and H. Schulzrinne and G. Camarillo",
  title="{Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3725 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3725",
  pages="1--31",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3725.txt",
  key="RFC 3725",
  abstract={Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties.  Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP).  However, there are several possible approaches, each with different benefits and drawbacks.  This document discusses best current practices for the usage of SIP for third party call control.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3725",
  }

@misc{rfc3726,
  author="M. Brunner",
  title="{Requirements for Signaling Protocols}",
  howpublished="RFC 3726 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3726",
  pages="1--42",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3726.txt",
  key="RFC 3726",
  abstract={This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains.  Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP).  However, in recent years, several other applications of signaling have been defined.  For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes.  To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions.  This document presents the assumptions before listing the requirements.  The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility.  This memo provides information for the Internet community.},
  keywords="rsvp, resource reservation protocol, middleboxes, nsis",
  doi="10.17487/RFC3726",
  }

@misc{rfc3727,
  author="S. Legg",
  title="{ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules}",
  howpublished="RFC 3727 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3727",
  pages="1--5",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3727.txt",
  key="RFC 3727",
  abstract={This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]},
  keywords="lightweight directory access protocol",
  doi="10.17487/RFC3727",
  }

@misc{rfc3728,
  author="B. Ray and R. Abbi",
  title="{Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)}",
  howpublished="RFC 3728 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3728",
  pages="1--76",
  year=2004,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3728.txt",
  key="RFC 3728",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]},
  keywords="management information base, mib",
  doi="10.17487/RFC3728",
  }

@misc{rfc3729,
  author="S. Waldbusser",
  title="{Application Performance Measurement MIB}",
  howpublished="RFC 3729 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3729",
  pages="1--61",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3729.txt",
  key="RFC 3729",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3729",
  }

@misc{rfc3730,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 3730 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3730",
  pages="1--69",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4930",
url="https://www.rfc-editor.org/rfc/rfc3730.txt",
  key="RFC 3730",
  abstract={This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]},
  keywords="shared framework mapping",
  doi="10.17487/RFC3730",
  }

@misc{rfc3731,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}",
  howpublished="RFC 3731 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3731",
  pages="1--45",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4931",
url="https://www.rfc-editor.org/rfc/rfc3731.txt",
  key="RFC 3731",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC3731",
  }

@misc{rfc3732,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Host Mapping}",
  howpublished="RFC 3732 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3732",
  pages="1--28",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4932",
url="https://www.rfc-editor.org/rfc/rfc3732.txt",
  key="RFC 3732",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC3732",
  }

@misc{rfc3733,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Contact Mapping}",
  howpublished="RFC 3733 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3733",
  pages="1--41",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4933",
url="https://www.rfc-editor.org/rfc/rfc3733.txt",
  key="RFC 3733",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository.  Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC3733",
  }

@misc{rfc3734,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Transport Over TCP}",
  howpublished="RFC 3734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3734",
  pages="1--9",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4934",
url="https://www.rfc-editor.org/rfc/rfc3734.txt",
  key="RFC 3734",
  abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]},
  keywords="mapping, client, server, tls, transport layer security",
  doi="10.17487/RFC3734",
  }

@misc{rfc3735,
  author="S. Hollenbeck",
  title="{Guidelines for Extending the Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 3735 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3735",
  pages="1--13",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3735.txt",
  key="RFC 3735",
  abstract={The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3735",
  }

@misc{rfc3736,
  author="R. Droms",
  title="{Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6}",
  howpublished="RFC 3736 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3736",
  pages="1--9",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3736.txt",
  key="RFC 3736",
  abstract={Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients.  A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration.  This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3736",
  }

@misc{rfc3737,
  author="B. Wijnen and A. Bierman",
  title="{IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules}",
  howpublished="RFC 3737 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3737",
  pages="1--7",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3737.txt",
  key="RFC 3737",
  abstract={This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root.  This memo also documents the currently assigned values. [STANDARDS-TRACK]},
  keywords="management information base, internet assigned numbers authority",
  doi="10.17487/RFC3737",
  }

@misc{rfc3738,
  author="M. Luby and V. Goyal",
  title="{Wave and Equation Based Rate Control (WEBRC) Building Block}",
  howpublished="RFC 3738 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3738",
  pages="1--32",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3738.txt",
  key="RFC 3738",
  abstract={This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery.  WEBRC is specifically designed to support protocols using IP multicast.  It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections.  WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol.  Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender.  Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="congestion control, data delivery, multicast, ip, internet protocol",
  doi="10.17487/RFC3738",
  }

@misc{rfc3739,
  author="S. Santesson and M. Nystrom and T. Polk",
  title="{Internet X.509 Public Key Infrastructure: Qualified Certificates Profile}",
  howpublished="RFC 3739 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3739",
  pages="1--34",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3739.txt",
  key="RFC 3739",
  abstract={This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons.  The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates.  However, the profile does not define any legal requirements for such Qualified Certificates.  The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements.  The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]},
  keywords="syntax",
  doi="10.17487/RFC3739",
  }

@misc{rfc3740,
  author="T. Hardjono and B. Weis",
  title="{The Multicast Group Security Architecture}",
  howpublished="RFC 3740 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3740",
  pages="1--26",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3740.txt",
  key="RFC 3740",
  abstract={This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups.  The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.  This memo provides information for the Internet community.},
  keywords="data packets",
  doi="10.17487/RFC3740",
  }

@misc{rfc3741,
  author="J. Boyer and D. {Eastlake 3rd} and J. Reagle",
  title="{Exclusive XML Canonicalization, Version 1.0}",
  howpublished="RFC 3741 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3741",
  pages="1--16",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3741.txt",
  key="RFC 3741",
  abstract={Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the ``xml:'' namespace.  However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument.  For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context.  This requirement is satisfied by Exclusive XML Canonicalization.  This memo provides information for the Internet community.},
  keywords="extensible markup language, namespace",
  doi="10.17487/RFC3741",
  }

@misc{rfc3742,
  author="S. Floyd",
  title="{Limited Slow-Start for TCP with Large Congestion Windows}",
  howpublished="RFC 3742 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3742",
  pages="1--7",
  year=2004,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3742.txt",
  key="RFC 3742",
  abstract={This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows.  For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time.  Such an increase can easily result in thousands of packets being dropped in one round-trip time.  This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link.  This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="transmission control protocol",
  doi="10.17487/RFC3742",
  }

@misc{rfc3743,
  author="K. Konishi and K. Huang and H. Qian and Y. Ko",
  title="{Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean}",
  howpublished="RFC 3743 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3743",
  pages="1--33",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3743.txt",
  key="RFC 3743",
  abstract={Achieving internationalized access to domain names raises many complex issues.  These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.  The IETF Standards for Internationalized Domain Names, known as ``IDNA'', focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII.  The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition.  The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols.  This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3743",
  }

@misc{rfc3744,
  author="G. Clemm and J. Reschke and E. Sedlar and J. Whitehead",
  title="{Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol}",
  howpublished="RFC 3744 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3744",
  pages="1--72",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3744.txt",
  key="RFC 3744",
  abstract={This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol.  This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal.  A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories.  Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3744",
  }

@misc{rfc3745,
  author="D. Singer and R. Clark and D. Lee",
  title="{MIME Type Registrations for JPEG 2000 (ISO/IEC 15444)}",
  howpublished="RFC 3745 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3745",
  pages="1--14",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3745.txt",
  key="RFC 3745",
  abstract={This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]},
  keywords="multipurpose internet mail extensions, joint photographic experts group",
  doi="10.17487/RFC3745",
  }

@misc{rfc3746,
  author="L. Yang and R. Dantu and T. Anderson and R. Gopal",
  title="{Forwarding and Control Element Separation (ForCES) Framework}",
  howpublished="RFC 3746 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3746",
  pages="1--40",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3746.txt",
  key="RFC 3746",
  abstract={This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions.  This is memo provides information for the Internet community.},
  keywords="network elements",
  doi="10.17487/RFC3746",
  }

@misc{rfc3747,
  author="H. Hazewinkel and D. Partain",
  title="{The Differentiated Services Configuration MIB}",
  howpublished="RFC 3747 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3747",
  pages="1--24",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3747.txt",
  key="RFC 3747",
  abstract={This memo describes a MIB module that provides a conceptual layer between high-level ``network-wide'' policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system.  This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]},
  keywords="management information base, diffserv",
  doi="10.17487/RFC3747",
  }

@misc{rfc3748,
  author="B. Aboba and L. Blunk and J. Vollbrecht and J. Carlson and H. Levkowetz",
  title="{Extensible Authentication Protocol (EAP)}",
  howpublished="RFC 3748 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3748",
  pages="1--67",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5247, 7057",
url="https://www.rfc-editor.org/rfc/rfc3748.txt",
  key="RFC 3748",
  abstract={This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods.  EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.  Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.  This document obsoletes RFC 2284.  A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]},
  keywords="PPP-EAP, data link layers, ppp, point-to-point, ieee 802",
  doi="10.17487/RFC3748",
  }

@misc{rfc3749,
  author="S. Hollenbeck",
  title="{Transport Layer Security Protocol Compression Methods}",
  howpublished="RFC 3749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3749",
  pages="1--8",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3749.txt",
  key="RFC 3749",
  abstract={The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol.  TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed.  This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]},
  keywords="tls, lossless data compression, handshake protocol",
  doi="10.17487/RFC3749",
  }

@misc{rfc3750,
  author="C. Huitema and R. Austein and S. Satapati and R. van der Pol",
  title="{Unmanaged Networks IPv6 Transition Scenarios}",
  howpublished="RFC 3750 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3750",
  pages="1--20",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3750.txt",
  key="RFC 3750",
  abstract={This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks.  In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used.  One specific scope is the ``unmanaged network'', which typically corresponds to a home or small office network.  The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP).  We first examine the generic requirements of four classes of applications: local, client, peer to peer and server.  Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6.  This memo provides information for the Internet community.},
  keywords="single subnet, gateway, isp, internet service provider",
  doi="10.17487/RFC3750",
  }

@misc{rfc3751,
  author="S. Bradner",
  title="{Omniscience Protocol Requirements}",
  howpublished="RFC 3751 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3751",
  pages="1--9",
  year=2004,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3751.txt",
  key="RFC 3751",
  abstract={There have been a number of legislative initiatives in the U.S.  and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users.  This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3751",
  }

@misc{rfc3752,
  author="A. Barbir and E. Burger and R. Chen and S. McHenry and H. Orman and R. Penno",
  title="{Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios}",
  howpublished="RFC 3752 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3752",
  pages="1--14",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3752.txt",
  key="RFC 3752",
  abstract={This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES).  The work examines services that could be performed to requests and/or responses.  This memo provides information for the Internet community.},
  keywords="application data services",
  doi="10.17487/RFC3752",
  }

@misc{rfc3753,
  author="J. Manner and M. Kojo",
  title="{Mobility Related Terminology}",
  howpublished="RFC 3753 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3753",
  pages="1--36",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3753.txt",
  key="RFC 3753",
  abstract={There is a need for common definitions of terminology in the work to be done around IP mobility.  This document defines terms for mobility related terminology.  The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks.  Other working groups dealing with mobility may want to take advantage of this terminology.  This memo provides information for the Internet community.},
  keywords="networks, ip, internet protocol",
  doi="10.17487/RFC3753",
  }

@misc{rfc3754,
  author="R. Bless and K. Wehrle",
  title="{IP Multicast in Differentiated Services (DS) Networks}",
  howpublished="RFC 3754 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3754",
  pages="1--34",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3754.txt",
  key="RFC 3754",
  abstract={This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 (``An Architecture of Differentiated Services'').  It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.  This memo provides information for the Internet community.},
  keywords="internet protocol",
  doi="10.17487/RFC3754",
  }

@misc{rfc3755,
  author="S. Weiler",
  title="{Legacy Resolver Compatibility for Delegation Signer (DS)}",
  howpublished="RFC 3755 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3755",
  pages="1--9",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFCs 3757, 3845",
url="https://www.rfc-editor.org/rfc/rfc3755.txt",
  key="RFC 3755",
  abstract={As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.  Many deployed nameservers understand variants of these semantics.  Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable.  This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]},
  keywords="dnssec, DNS Security, rr, resource record, DNS-SECEXT, dns, authentication, nsec, nextsecure",
  doi="10.17487/RFC3755",
  }

@misc{rfc3756,
  author="P. Nikander and J. Kempf and E. Nordmark",
  title="{IPv6 Neighbor Discovery (ND) Trust Models and Threats}",
  howpublished="RFC 3756 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3756",
  pages="1--23",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3756.txt",
  key="RFC 3756",
  abstract={The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH).  However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management.  This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery.  The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.  This memo provides information for the Internet community.},
  keywords="authentication, security key management",
  doi="10.17487/RFC3756",
  }

@misc{rfc3757,
  author="O. Kolkman and J. Schlyter and E. Lewis",
  title="{Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag}",
  howpublished="RFC 3757 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3757",
  pages="1--8",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3757.txt",
  key="RFC 3757",
  abstract={With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced.  During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set.  A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.  The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration.  The flag bit is not to be used in the DNS verification protocol.  This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]},
  keywords="dnssec",
  doi="10.17487/RFC3757",
  }

@misc{rfc3758,
  author="R. Stewart and M. Ramalho and Q. Xie and M. Tuexen and P. Conrad",
  title="{Stream Control Transmission Protocol (SCTP) Partial Reliability Extension}",
  howpublished="RFC 3758 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3758",
  pages="1--22",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3758.txt",
  key="RFC 3758",
  abstract={This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward.  When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol.  This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]},
  keywords="init, init ack, forward tsn",
  doi="10.17487/RFC3758",
  }

@misc{rfc3759,
  author="L-E. Jonsson",
  title="{RObust Header Compression (ROHC): Terminology and Channel Mapping Examples}",
  howpublished="RFC 3759 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3759",
  pages="1--20",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3759.txt",
  key="RFC 3759",
  abstract={This document aims to clarify terms and concepts presented in RFC 3095.  RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC).  The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used.  This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues.  This memo provides information for the Internet community.},
  keywords="encapsulating, security, payload, real-time, transport, protocol, user, datagram",
  doi="10.17487/RFC3759",
  }

@misc{rfc3760,
  author="D. Gustafson and M. Just and M. Nystrom",
  title="{Securely Available Credentials (SACRED) - Credential Server Framework}",
  howpublished="RFC 3760 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3760",
  pages="1--22",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3760.txt",
  key="RFC 3760",
  abstract={As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization.  This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3760",
  }

@misc{rfc3761,
  author="P. Faltstrom and M. Mealling",
  title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)}",
  howpublished="RFC 3761 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3761",
  pages="1--18",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 6116, 6117",
url="https://www.rfc-editor.org/rfc/rfc3761.txt",
  key="RFC 3761",
  abstract={This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers.  More specifically, how DNS can be used for identifying available services connected to one E.164 number.  It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401.  It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]},
  keywords="domain name system",
  doi="10.17487/RFC3761",
  }

@misc{rfc3762,
  author="O. Levin",
  title="{Telephone Number Mapping (ENUM) Service Registration for H.323}",
  howpublished="RFC 3762 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3762",
  pages="1--5",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc3762.txt",
  key="RFC 3762",
  abstract={The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet.  This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]},
  keywords="multimedia, packet based network",
  doi="10.17487/RFC3762",
  }

@misc{rfc3763,
  author="S. Shalunov and B. Teitelbaum",
  title="{One-way Active Measurement Protocol (OWAMP) Requirements}",
  howpublished="RFC 3763 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3763",
  pages="1--11",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3763.txt",
  key="RFC 3763",
  abstract={With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision.  To do so in an interoperable manner, a common protocol for such measurements is required.  This document specifies requirements for a one-way active measurement protocol (OWAMP) standard.  The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.  This memo provides information for the Internet community.},
  keywords="performance metrics, delay, unidirectional",
  doi="10.17487/RFC3763",
  }

@misc{rfc3764,
  author="J. Peterson",
  title="{enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record}",
  howpublished="RFC 3764 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3764",
  pages="1--8",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc3764.txt",
  key="RFC 3764",
  abstract={This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761.  Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]},
  keywords="aor, electronic number",
  doi="10.17487/RFC3764",
  }

@misc{rfc3765,
  author="G. Huston",
  title="{NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control}",
  howpublished="RFC 3765 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3765",
  pages="1--7",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3765.txt",
  key="RFC 3765",
  abstract={This document describes the use of a scope control Border Gateway Protocol (BGP) community.  This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated.  In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections.  This memo provides information for the Internet community.},
  keywords="peer connections, propagated",
  doi="10.17487/RFC3765",
  }

@misc{rfc3766,
  author="H. Orman and P. Hoffman",
  title="{Determining Strengths For Public Keys Used For Exchanging Symmetric Keys}",
  howpublished="RFC 3766 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3766",
  pages="1--23",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3766.txt",
  key="RFC 3766",
  abstract={Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack.  That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements.  The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage.  While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement.  This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement.  Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given.  The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="security, cryptography algorithms, integers",
  doi="10.17487/RFC3766",
  }

@misc{rfc3767,
  author="S. Farrell",
  title="{Securely Available Credentials Protocol}",
  howpublished="RFC 3767 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3767",
  pages="1--25",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3767.txt",
  key="RFC 3767",
  abstract={This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS \#15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.  The protocol's payloads are described in XML.  This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol.  Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]},
  keywords="beep, blocks extensible exchange protocol, xml, extensible mark up language",
  doi="10.17487/RFC3767",
  }

@misc{rfc3768,
  author="R. Hinden",
  title="{Virtual Router Redundancy Protocol (VRRP)}",
  howpublished="RFC 3768 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3768",
  pages="1--27",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5798",
url="https://www.rfc-editor.org/rfc/rfc3768.txt",
  key="RFC 3768",
  abstract={This memo defines the Virtual Router Redundancy Protocol (VRRP).  VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.  The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses.  The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable.  This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts.  The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]},
  keywords="VRRP, vrrp, lan, local, area, network, ip, internet, protocol",
  doi="10.17487/RFC3768",
  }

@misc{rfc3769,
  author="S. Miyakawa and R. Droms",
  title="{Requirements for IPv6 Prefix Delegation}",
  howpublished="RFC 3769 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3769",
  pages="1--6",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3769.txt",
  key="RFC 3769",
  abstract={This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or ``site'').  This memo provides information for the Internet community.},
  keywords="internet protocol version 6",
  doi="10.17487/RFC3769",
  }

@misc{rfc3770,
  author="R. Housley and T. Moore",
  title="{Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)}",
  howpublished="RFC 3770 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3770",
  pages="1--9",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4334",
url="https://www.rfc-editor.org/rfc/rfc3770.txt",
  key="RFC 3770",
  abstract={This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]},
  keywords="ssid, system service identifiers, eap",
  doi="10.17487/RFC3770",
  }

@misc{rfc3771,
  author="R. Harrison and K. Zeilenga",
  title="{The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message}",
  howpublished="RFC 3771 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3771",
  pages="1--8",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4511, 4510",
url="https://www.rfc-editor.org/rfc/rfc3771.txt",
  key="RFC 3771",
  abstract={This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP).  The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained.  This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]},
  keywords="LDAPv3, LDAv3, x.500",
  doi="10.17487/RFC3771",
  }

@misc{rfc3772,
  author="J. Carlson and R. Winslow",
  title="{Point-to-Point Protocol (PPP) Vendor Protocol}",
  howpublished="RFC 3772 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3772",
  pages="1--10",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3772.txt",
  key="RFC 3772",
  abstract={The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links.  The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers.  This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]},
  keywords="link control protocol, lcp",
  doi="10.17487/RFC3772",
  }

@misc{rfc3773,
  author="E. Candell",
  title="{High-Level Requirements for Internet Voice Mail}",
  howpublished="RFC 3773 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3773",
  pages="1--9",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3773.txt",
  key="RFC 3773",
  abstract={This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged.  IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients.  Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment.  This document does not include goals that were met fully by VPIM version 2.  This memo provides information for the Internet community.},
  keywords="ivm, internet voice messaging, voice profile for internet mail, vpim",
  doi="10.17487/RFC3773",
  }

@misc{rfc3774,
  author="E. Davies",
  title="{IETF Problem Statement}",
  howpublished="RFC 3774 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3774",
  pages="1--22",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3774.txt",
  key="RFC 3774",
  abstract={This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF).  We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community.  The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003.  The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections.  This memo provides information for the Internet community.},
  keywords="ietf, process, problem, analysis",
  doi="10.17487/RFC3774",
  }

@misc{rfc3775,
  author="D. Johnson and C. Perkins and J. Arkko",
  title="{Mobility Support in IPv6}",
  howpublished="RFC 3775 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3775",
  pages="1--165",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6275",
url="https://www.rfc-editor.org/rfc/rfc3775.txt",
  key="RFC 3775",
  abstract={This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location.  IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address.  The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address.  To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option.  All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]},
  keywords="internet protocol, nodes",
  doi="10.17487/RFC3775",
  }

@misc{rfc3776,
  author="J. Arkko and V. Devarapalli and F. Dupont",
  title="{Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents}",
  howpublished="RFC 3776 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3776",
  pages="1--40",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4877",
url="https://www.rfc-editor.org/rfc/rfc3776.txt",
  key="RFC 3776",
  abstract={Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node.  Mobile IPv6 base document defines the main requirements these nodes must follow.  This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]},
  keywords="security, internet protocol",
  doi="10.17487/RFC3776",
  }

@misc{rfc3777,
  author="J. Galvin",
  title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}",
  howpublished="RFC 3777 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3777",
  pages="1--34",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7437, updated by RFCs 5078, 5633, 5680, 6859",
url="https://www.rfc-editor.org/rfc/rfc3777.txt",
  key="RFC 3777",
  abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified.  This document is a self-consistent, organized compilation of the process as it was known at the time of publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet Architecture Board, Engineering Steering Group",
  doi="10.17487/RFC3777",
  }

@misc{rfc3778,
  author="E. Taft and J. Pravetz and S. Zilles and L. Masinter",
  title="{The application/pdf Media Type}",
  howpublished="RFC 3778 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3778",
  pages="1--14",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8118",
url="https://www.rfc-editor.org/rfc/rfc3778.txt",
  key="RFC 3778",
  abstract={PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993.  This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'.  This memo provides information for the Internet community.},
  keywords="portable document format, document exchange, digital signatures",
  doi="10.17487/RFC3778",
  }

@misc{rfc3779,
  author="C. Lynn and S. Kent and K. Seo",
  title="{X.509 Extensions for IP Addresses and AS Identifiers}",
  howpublished="RFC 3779 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3779",
  pages="1--27",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3779.txt",
  key="RFC 3779",
  abstract={This document defines two X.509 v3 certificate extensions.  The first binds a list of IP address blocks, or prefixes, to the subject of a certificate.  The second binds a list of autonomous system identifiers to the subject of a certificate.  These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]},
  keywords="allocation, atrribute certificate, authorization, autonomous system number authorization, certificate, delegation, internet registry, ip address authorization, public key infrastructure, right-to-use, secure allocation",
  doi="10.17487/RFC3779",
  }

@misc{rfc3780,
  author="F. Strauss and J. Schoenwaelder",
  title="{SMIng - Next Generation Structure of Management Information}",
  howpublished="RFC 3780 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3780",
  pages="1--64",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3780.txt",
  key="RFC 3780",
  abstract={This memo defines the base SMIng (Structure of Management Information, Next Generation) language.  SMIng is a data definition language that provides a protocol-independent representation for management information.  Separate RFCs define mappings of SMIng to specific management protocols, including SNMP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="data definition language",
  doi="10.17487/RFC3780",
  }

@misc{rfc3781,
  author="F. Strauss and J. Schoenwaelder",
  title="{Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 3781 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3781",
  pages="1--49",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3781.txt",
  key="RFC 3781",
  abstract={SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information.  This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="data definition language",
  doi="10.17487/RFC3781",
  }

@misc{rfc3782,
  author="S. Floyd and T. Henderson and A. Gurtov",
  title="{The NewReno Modification to TCP's Fast Recovery Algorithm}",
  howpublished="RFC 3782 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3782",
  pages="1--19",
  year=2004,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6582",
url="https://www.rfc-editor.org/rfc/rfc3782.txt",
  key="RFC 3782",
  abstract={The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.  The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms.  The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout.  However, RFC 2582 also defined ``Careful'' and ``Less Careful'' variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant.  This document specifies the previously-named ``Careful'' variant as the basic version of NewReno TCP. [STANDARDS-TRACK]},
  keywords="Transmission, Control, Protocol",
  doi="10.17487/RFC3782",
  }

@misc{rfc3783,
  author="M. Chadalapaka and R. Elliott",
  title="{Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI}",
  howpublished="RFC 3783 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3783",
  pages="1--14",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3783.txt",
  key="RFC 3783",
  abstract={Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP.  The iSCSI session abstraction is equivalent to the classic SCSI ``I\_T nexus'', which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols.  The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target.  This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI.  This memo provides information for the Internet community.},
  keywords="Internet Small Computer Systems Interface, iscsi",
  doi="10.17487/RFC3783",
  }

@misc{rfc3784,
  author="H. Smit and T. Li",
  title="{Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)}",
  howpublished="RFC 3784 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3784",
  pages="1--13",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5305, updated by RFC 4205",
url="https://www.rfc-editor.org/rfc/rfc3784.txt",
  key="RFC 3784",
  abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).  This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units.  This information describes additional details regarding the state of the network that are useful for traffic engineering computations.  This memo provides information for the Internet community.},
  keywords="link state protocol, lsp",
  doi="10.17487/RFC3784",
  }

@misc{rfc3785,
  author="F. Le Faucheur and R. Uppili and A. Vedrenne and P. Merckx and T. Telkamp",
  title="{Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric}",
  howpublished="RFC 3785 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3785",
  pages="1--8",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3785.txt",
  key="RFC 3785",
  abstract={This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels.  This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks).  No protocol extensions or modifications are required.  This text documents current router implementations and deployment practices.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="link, bandwidth router",
  doi="10.17487/RFC3785",
  }

@misc{rfc3786,
  author="A. Hermelin and S. Previdi and M. Shand",
  title="{Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit}",
  howpublished="RFC 3786 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3786",
  pages="1--14",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5311",
url="https://www.rfc-editor.org/rfc/rfc3786.txt",
  key="RFC 3786",
  abstract={This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589.  This mechanism can be used in IP-only, OSI-only, and dual routers.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3786",
  }

@misc{rfc3787,
  author="J. Parker",
  title="{Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)}",
  howpublished="RFC 3787 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3787",
  pages="1--11",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3787.txt",
  key="RFC 3787",
  abstract={This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today.  These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic.  A companion document describes the differences between the protocol described in ISO 10589 and current practice.  This memo provides information for the Internet community.},
  keywords="routing traffic",
  doi="10.17487/RFC3787",
  }

@misc{rfc3788,
  author="J. Loughney and M. Tuexen and J. Pastor-Balbas",
  title="{Security Considerations for Signaling Transport (SIGTRAN) Protocols}",
  howpublished="RFC 3788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3788",
  pages="1--13",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3788.txt",
  key="RFC 3788",
  abstract={This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols.  The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication.  The support of IPsec is mandatory for all nodes running SIGTRAN protocols.  TLS support is optional. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3788",
  }

@misc{rfc3789,
  author="P. Nesser and II and A. Bergstrom",
  title="{Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents}",
  howpublished="RFC 3789 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3789",
  pages="1--10",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3789.txt",
  key="RFC 3789",
  abstract={This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs.  It is broken into seven documents conforming to the current IETF areas.  It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3789",
  }

@misc{rfc3790,
  author="C. Mickles and P. Nesser and II",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents}",
  howpublished="RFC 3790 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3790",
  pages="1--49",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3790.txt",
  key="RFC 3790",
  abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3790",
  }

@misc{rfc3791,
  author="C. Olvera and P. Nesser and II",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents}",
  howpublished="RFC 3791 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3791",
  pages="1--15",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3791.txt",
  key="RFC 3791",
  abstract={This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3791",
  }

@misc{rfc3792,
  author="P. Nesser and II and A. Bergstrom",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents}",
  howpublished="RFC 3792 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3792",
  pages="1--25",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3792.txt",
  key="RFC 3792",
  abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3792",
  }

@misc{rfc3793,
  author="P. Nesser and II and A. Bergstrom",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents}",
  howpublished="RFC 3793 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3793",
  pages="1--6",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3793.txt",
  key="RFC 3793",
  abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3793",
  }

@misc{rfc3794,
  author="P. Nesser and II and A. Bergstrom",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents}",
  howpublished="RFC 3794 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3794",
  pages="1--31",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3794.txt",
  key="RFC 3794",
  abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3794",
  }

@misc{rfc3795,
  author="R. Sofia and P. Nesser and II",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents}",
  howpublished="RFC 3795 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3795",
  pages="1--50",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3795.txt",
  key="RFC 3795",
  abstract={This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6.  This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used.  Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.  To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs.  Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3795",
  }

@misc{rfc3796,
  author="P. Nesser and II and A. Bergstrom",
  title="{Survey of IPv4 Addresses in Currently Deployed IETF Operations \& Management Area Standards Track and Experimental Documents}",
  howpublished="RFC 3796 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3796",
  pages="1--43",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3796.txt",
  key="RFC 3796",
  abstract={This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations \& Management Area accepted standards.  In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken.  One of these steps is the evolution of current protocols that have IPv4 dependencies.  It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3796",
  }

@misc{rfc3797,
  author="D. {Eastlake 3rd}",
  title="{Publicly Verifiable Nominations Committee (NomCom) Random Selection}",
  howpublished="RFC 3797 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3797",
  pages="1--19",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3797.txt",
  key="RFC 3797",
  abstract={This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.  As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used.  Similar techniques would be applicable to other cases.  This memo provides information for the Internet community.},
  keywords="Internet Engineering Task Force, IETF",
  doi="10.17487/RFC3797",
  }

@misc{rfc3798,
  author="T. Hansen and G. Vaudreuil",
  title="{Message Disposition Notification}",
  howpublished="RFC 3798 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3798",
  pages="1--30",
  year=2004,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8098, updated by RFCs 5337, 6533",
url="https://www.rfc-editor.org/rfc/rfc3798.txt",
  key="RFC 3798",
  abstract={This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.  This content-type is intended to be machine-processable.  Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message.  The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary ``LAN-based'' systems, and often referred to as ``read receipts,'' ``acknowledgements'', or ``receipt notifications.'' The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.  Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary ``LAN-based'' systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment.  To this end, the protocol described in this memo provides for the carriage of ``foreign'' addresses, in addition to those normally used in Internet Mail.  Additional attributes may also be defined to support ``tunneling'' of foreign notifications through Internet Mail. [STANDARDS-TRACK]},
  keywords="EMF-MDN, MDN, media-type, MIME, multipurpose internet mail extensions",
  doi="10.17487/RFC3798",
  }

@misc{rfc3801,
  author="G. Vaudreuil and G. Parsons",
  title="{Voice Profile for Internet Mail - version 2 (VPIMv2)}",
  howpublished="RFC 3801 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3801",
  pages="1--55",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3801.txt",
  key="RFC 3801",
  abstract={This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms.  The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document.  These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer.  As a result, VPIM also specifies additional functionality, as it is needed.  This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.  This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision.  No protocol changes were made in this revision.  A list of changes from RFC 2421 are noted in Appendix F.  Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]},
  keywords="MIME-VP2, vpim, messaging",
  doi="10.17487/RFC3801",
  }

@misc{rfc3802,
  author="G. Vaudreuil and G. Parsons",
  title="{Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration}",
  howpublished="RFC 3802 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3802",
  pages="1--7",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3802.txt",
  key="RFC 3802",
  abstract={This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio.  This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]},
  keywords="MIME-ADPCM, multipurpose, internet, mail, extensions, audio",
  doi="10.17487/RFC3802",
  }

@misc{rfc3803,
  author="G. Vaudreuil and G. Parsons",
  title="{Content Duration MIME Header Definition}",
  howpublished="RFC 3803 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3803",
  pages="1--5",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3803.txt",
  key="RFC 3803",
  abstract={This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]},
  keywords="CONT-DUR, multipurpose internet mail extensions, time, media",
  doi="10.17487/RFC3803",
  }

@misc{rfc3804,
  author="G. Parsons",
  title="{Voice Profile for Internet Mail (VPIM) Addressing}",
  howpublished="RFC 3804 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3804",
  pages="1--15",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3804.txt",
  key="RFC 3804",
  abstract={This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage.  Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]},
  keywords="formats",
  doi="10.17487/RFC3804",
  }

@misc{rfc3805,
  author="R. Bergman and H. Lewis and I. McDonald",
  title="{Printer MIB v2}",
  howpublished="RFC 3805 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3805",
  pages="1--171",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3805.txt",
  key="RFC 3805",
  abstract={This document provides definitions of models and manageable objects for printing environments.  The objects included in this MIB apply to physical, as well as logical entities within a printing device.  This document obsoletes RFC 1759. [STANDARDS-TRACK]},
  keywords="Print-MIB, Management Information Base, snmp, management",
  doi="10.17487/RFC3805",
  }

@misc{rfc3806,
  author="R. Bergman and H. Lewis and I. McDonald",
  title="{Printer Finishing MIB}",
  howpublished="RFC 3806 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3806",
  pages="1--53",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3806.txt",
  key="RFC 3806",
  abstract={This document defines a MIB module for the management of printer finishing device subunits.  The finishing device subunits applicable to this MIB are an integral part of the Printer System.  This MIB applies only to a Finisher Device that is connected to a Printer System.  This memo provides information for the Internet community.},
  keywords="finisher, snmp",
  doi="10.17487/RFC3806",
  }

@misc{rfc3807,
  author="E. Weilandt and N. Khanchandani and S. Rao",
  title="{V5.2-User Adaptation Layer (V5UA)}",
  howpublished="RFC 3807 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3807",
  pages="1--24",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3807.txt",
  key="RFC 3807",
  abstract={This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP).  This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC).  It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface.  This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057).  It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]},
  keywords="v5, v5.1, v5.2, backhauling, imap, sctp, isdn, access network, c-path, c-channel, efa, envelope function address, lapv5, pstn, v5ptm, mgc, gateway controller, gateway",
  doi="10.17487/RFC3807",
  }

@misc{rfc3808,
  author="I. McDonald",
  title="{IANA Charset MIB}",
  howpublished="RFC 3808 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3808",
  pages="1--14",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3808.txt",
  key="RFC 3808",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  This IANA Charset MIB is now an IANA registry.  In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759).  A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978).  This memo provides information for the Internet community.},
  keywords="management information base, IANACharset",
  doi="10.17487/RFC3808",
  }

@misc{rfc3809,
  author="A. Nagarajan",
  title="{Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)}",
  howpublished="RFC 3809 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3809",
  pages="1--25",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3809.txt",
  key="RFC 3809",
  abstract={This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN).  The requirements are categorized into service requirements, provider requirements and engineering requirements.  These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies.  All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.  This memo provides information for the Internet community.},
  keywords="service engineering",
  doi="10.17487/RFC3809",
  }

@misc{rfc3810,
  author="R. Vida and L. Costa",
  title="{Multicast Listener Discovery Version 2 (MLDv2) for IPv6}",
  howpublished="RFC 3810 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3810",
  pages="1--62",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4604",
url="https://www.rfc-editor.org/rfc/rfc3810.txt",
  key="RFC 3810",
  abstract={This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2).  MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes.  MLDv2 is designed to be interoperable with MLDv1.  MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]},
  keywords="ssm, source filtering, igmp, group management, mld",
  doi="10.17487/RFC3810",
  }

@misc{rfc3811,
  author="T. Nadeau and J. Cucchiara",
  title="{Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management}",
  howpublished="RFC 3811 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3811",
  pages="1--20",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc3811.txt",
  key="RFC 3811",
  abstract={This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information.  The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="management information base",
  doi="10.17487/RFC3811",
  }

@misc{rfc3812,
  author="C. Srinivasan and A. Viswanathan and T. Nadeau",
  title="{Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)}",
  howpublished="RFC 3812 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3812",
  pages="1--68",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3812.txt",
  key="RFC 3812",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3812",
  }

@misc{rfc3813,
  author="C. Srinivasan and A. Viswanathan and T. Nadeau",
  title="{Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)}",
  howpublished="RFC 3813 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3813",
  pages="1--60",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3813.txt",
  key="RFC 3813",
  abstract={This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]},
  doi="10.17487/RFC3813",
  }

@misc{rfc3814,
  author="T. Nadeau and C. Srinivasan and A. Viswanathan",
  title="{Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)}",
  howpublished="RFC 3814 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3814",
  pages="1--42",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3814.txt",
  key="RFC 3814",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3814",
  }

@misc{rfc3815,
  author="J. Cucchiara and H. Sjostrand and J. Luciani",
  title="{Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)}",
  howpublished="RFC 3815 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3815",
  pages="1--106",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3815.txt",
  key="RFC 3815",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3815",
  }

@misc{rfc3816,
  author="J. Quittek and M. Stiemerling and H. Hartenstein",
  title="{Definitions of Managed Objects for RObust Header Compression (ROHC)}",
  howpublished="RFC 3816 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3816",
  pages="1--53",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3816.txt",
  key="RFC 3816",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC).  The managed objects defined in this memo are grouped into three MIB modules.  The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]},
  keywords="mib, management information base",
  doi="10.17487/RFC3816",
  }

@misc{rfc3817,
  author="W. Townsley and R. da Silva",
  title="{Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)}",
  howpublished="RFC 3817 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3817",
  pages="1--17",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3817.txt",
  key="RFC 3817",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network.  And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet.  L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP.  Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined.  This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP.  This memo provides information for the Internet community.},
  keywords="point-to-point",
  doi="10.17487/RFC3817",
  }

@misc{rfc3818,
  author="V. Schryver",
  title="{IANA Considerations for the Point-to-Point Protocol (PPP)}",
  howpublished="RFC 3818 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3818",
  pages="1--4",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3818.txt",
  key="RFC 3818",
  abstract={The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to ``actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value.'' In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be ``first come first served.'' This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3818",
  }

@misc{rfc3819,
  author="P. Karn and C. Bormann and G. Fairhurst and D. Grossman and R. Ludwig and J. Mahdavi and G. Montenegro and J. Touch and L. Wood",
  title="{Advice for Internet Subnetwork Designers}",
  howpublished="RFC 3819 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3819",
  pages="1--60",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3819.txt",
  key="RFC 3819",
  abstract={This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="digital communication equipment, link-layer protocols, packet-switched local networks",
  doi="10.17487/RFC3819",
  }

@misc{rfc3820,
  author="S. Tuecke and V. Welch and D. Engert and L. Pearlman and M. Thompson",
  title="{Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile}",
  howpublished="RFC 3820 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3820",
  pages="1--37",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3820.txt",
  key="RFC 3820",
  abstract={This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet.  The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]},
  keywords="authentication, security credentials, restricted delegation, single-signon, delegation of rights",
  doi="10.17487/RFC3820",
  }

@misc{rfc3821,
  author="M. Rajagopal and E. Rodriguez and R. Weber",
  title="{Fibre Channel Over TCP/IP (FCIP)}",
  howpublished="RFC 3821 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3821",
  pages="1--74",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc3821.txt",
  key="RFC 3821",
  abstract={Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric.  FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]},
  keywords="storage area networks, IP-based networks, unified storage area network",
  doi="10.17487/RFC3821",
  }

@misc{rfc3822,
  author="D. Peterson",
  title="{Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)}",
  howpublished="RFC 3822 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3822",
  pages="1--11",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc3822.txt",
  key="RFC 3822",
  abstract={This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]},
  keywords="dynamic discovery",
  doi="10.17487/RFC3822",
  }

@misc{rfc3823,
  author="B. Kovitz",
  title="{MIME Media Type for the Systems Biology Markup Language (SBML)}",
  howpublished="RFC 3823 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3823",
  pages="1--8",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3823.txt",
  key="RFC 3823",
  abstract={This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language.  SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community.  This memo provides information for the Internet community.},
  keywords="sub-type application/sbml+xml, systems biology community",
  doi="10.17487/RFC3823",
  }

@misc{rfc3824,
  author="J. Peterson and H. Liu and J. Yu and B. Campbell",
  title="{Using E.164 numbers with the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3824",
  pages="1--16",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3824.txt",
  key="RFC 3824",
  abstract={There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM.  Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations.  This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications.  It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number.  This memo provides information for the Internet community.},
  keywords="telephone records, applications",
  doi="10.17487/RFC3824",
  }

@misc{rfc3825,
  author="J. Polk and J. Schnizlein and M. Linsner",
  title="{Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information}",
  howpublished="RFC 3825 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3825",
  pages="1--15",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6225",
url="https://www.rfc-editor.org/rfc/rfc3825.txt",
  key="RFC 3825",
  abstract={This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client.  The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each.  The reference datum for these values is also included. [STANDARDS-TRACK]},
  keywords="dhcp, lci, geographic location",
  doi="10.17487/RFC3825",
  }

@misc{rfc3826,
  author="U. Blumenthal and F. Maino and K. McCloghrie",
  title="{The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model}",
  howpublished="RFC 3826 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3826",
  pages="1--16",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3826.txt",
  key="RFC 3826",
  abstract={This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture.  The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]},
  keywords="management information base, simple network management protocol",
  doi="10.17487/RFC3826",
  }

@misc{rfc3827,
  author="K. Sarcar",
  title="{Additional Snoop Datalink Types}",
  howpublished="RFC 3827 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3827",
  pages="1--4",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3827.txt",
  key="RFC 3827",
  abstract={The snoop file format provides a way to store and exchange datalink layer packet traces.  This document describes extensions to this file format to support new media.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3827",
  }

@misc{rfc3828,
  author="L-A. Larzon and M. Degermark and S. Pink and L-E. Jonsson and G. Fairhurst",
  title="{The Lightweight User Datagram Protocol (UDP-Lite)}",
  howpublished="RFC 3828 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3828",
  pages="1--12",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6335",
url="https://www.rfc-editor.org/rfc/rfc3828.txt",
  key="RFC 3828",
  abstract={This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded.  If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3828",
  }

@misc{rfc3829,
  author="R. Weltman and M. Smith and M. Wahl",
  title="{Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls}",
  howpublished="RFC 3829 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3829",
  pages="1--6",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3829.txt",
  key="RFC 3829",
  abstract={This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes.  Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation.  This memo provides information for the Internet community.},
  keywords="bind operation",
  doi="10.17487/RFC3829",
  }

@misc{rfc3830,
  author="J. Arkko and E. Carrara and F. Lindholm and M. Naslund and K. Norrman",
  title="{MIKEY: Multimedia Internet KEYing}",
  howpublished="RFC 3830 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3830",
  pages="1--66",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4738, 6309",
url="https://www.rfc-editor.org/rfc/rfc3830.txt",
  key="RFC 3830",
  abstract={This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication).  In particular, its use to support the Secure Real-time Transport Protocol is described in detail.  Security protocols for real-time multimedia applications have started to appear.  This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]},
  keywords="key management scheme, real-time applications",
  doi="10.17487/RFC3830",
  }

@misc{rfc3831,
  author="C. DeSanti",
  title="{Transmission of IPv6 Packets over Fibre Channel}",
  howpublished="RFC 3831 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3831",
  pages="1--24",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4338",
url="https://www.rfc-editor.org/rfc/rfc3831.txt",
  key="RFC 3831",
  abstract={This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]},
  keywords="addresses, link-local, internet protocol",
  doi="10.17487/RFC3831",
  }

@misc{rfc3832,
  author="W. Zhao and H. Schulzrinne and E. Guttman and C. Bisdikian and W. Jerome",
  title="{Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV}",
  howpublished="RFC 3832 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3832",
  pages="1--8",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3832.txt",
  key="RFC 3832",
  abstract={Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains.  This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV.  It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="DNS-SRV, domain, name, system, resource, record",
  doi="10.17487/RFC3832",
  }

@misc{rfc3833,
  author="D. Atkins and R. Austein",
  title="{Threat Analysis of the Domain Name System (DNS)}",
  howpublished="RFC 3833 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3833",
  pages="1--16",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3833.txt",
  key="RFC 3833",
  abstract={Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect.  Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified.  This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.  This memo provides information for the Internet community.},
  keywords="data disclosure, security, authentication",
  doi="10.17487/RFC3833",
  }

@misc{rfc3834,
  author="K. Moore",
  title="{Recommendations for Automatic Responses to Electronic Mail}",
  howpublished="RFC 3834 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3834",
  pages="1--22",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5436",
url="https://www.rfc-editor.org/rfc/rfc3834.txt",
  key="RFC 3834",
  abstract={This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including ``out of the office'' or ``vacation'' response generators, mail filtering software, email-based information services, and other automatic responders.  The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]},
  keywords="automatic mail responders",
  doi="10.17487/RFC3834",
  }

@misc{rfc3835,
  author="A. Barbir and R. Penno and R. Chen and M. Hofmann and H. Orman",
  title="{An Architecture for Open Pluggable Edge Services (OPES)}",
  howpublished="RFC 3835 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3835",
  pages="1--17",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3835.txt",
  key="RFC 3835",
  abstract={This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service.  This memo provides information for the Internet community.},
  keywords="application service, data stream service, data consumer, data dispatcher architecture",
  doi="10.17487/RFC3835",
  }

@misc{rfc3836,
  author="A. Beck and M. Hofmann and H. Orman and R. Penno and A. Terzis",
  title="{Requirements for Open Pluggable Edge Services (OPES) Callout Protocols}",
  howpublished="RFC 3836 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3836",
  pages="1--13",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3836.txt",
  key="RFC 3836",
  abstract={This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services.  The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols.  This memo provides information for the Internet community.},
  keywords="callout protocol, remote execution, OPES services",
  doi="10.17487/RFC3836",
  }

@misc{rfc3837,
  author="A. Barbir and O. Batuner and B. Srinivas and M. Hofmann and H. Orman",
  title="{Security Threats and Risks for Open Pluggable Edge Services (OPES)}",
  howpublished="RFC 3837 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3837",
  pages="1--14",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3837.txt",
  key="RFC 3837",
  abstract={The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture.  The main goal of this document is threat discovery and analysis.  The document does not specify or recommend any solutions.  This memo provides information for the Internet community.},
  keywords="threat discovery, threat analysis",
  doi="10.17487/RFC3837",
  }

@misc{rfc3838,
  author="A. Barbir and O. Batuner and A. Beck and T. Chan and H. Orman",
  title="{Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)}",
  howpublished="RFC 3838 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3838",
  pages="1--17",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3838.txt",
  key="RFC 3838",
  abstract={This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow.  This memo provides information for the Internet community.},
  keywords="opes flow",
  doi="10.17487/RFC3838",
  }

@misc{rfc3839,
  author="R. Castagno and D. Singer",
  title="{MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files}",
  howpublished="RFC 3839 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3839",
  pages="1--7",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6381",
url="https://www.rfc-editor.org/rfc/rfc3839.txt",
  key="RFC 3839",
  abstract={This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]},
  keywords="standard MIME types, 3GPP multimedia file format, ISO Media File Format",
  doi="10.17487/RFC3839",
  }

@misc{rfc3840,
  author="J. Rosenberg and H. Schulzrinne and P. Kyzivat",
  title="{Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3840 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3840",
  pages="1--36",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3840.txt",
  key="RFC 3840",
  abstract={This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain.  This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]},
  keywords="ua, contact header field",
  doi="10.17487/RFC3840",
  }

@misc{rfc3841,
  author="J. Rosenberg and H. Schulzrinne and P. Kyzivat",
  title="{Caller Preferences for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3841 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3841",
  pages="1--26",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3841.txt",
  key="RFC 3841",
  abstract={This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers.  These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers.  It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]},
  keywords="Uniform Resource Identifiers, URI, Accept-Contact, Reject-Contact, Request-Disposition",
  doi="10.17487/RFC3841",
  }

@misc{rfc3842,
  author="R. Mahy",
  title="{A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3842 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3842",
  pages="1--19",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3842.txt",
  key="RFC 3842",
  abstract={This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]},
  keywords="message waiting status, message summary",
  doi="10.17487/RFC3842",
  }

@misc{rfc3843,
  author="L-E. Jonsson and G. Pelletier",
  title="{RObust Header Compression (ROHC): A Compression Profile for IP}",
  howpublished="RFC 3843 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3843",
  pages="1--16",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4815",
url="https://www.rfc-editor.org/rfc/rfc3843.txt",
  key="RFC 3843",
  abstract={The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams.  However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095.  This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]},
  keywords="compression protocols",
  doi="10.17487/RFC3843",
  }

@misc{rfc3844,
  author="E. Davies and J. Hofmann",
  title="{IETF Problem Resolution Process}",
  howpublished="RFC 3844 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3844",
  pages="1--20",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3844.txt",
  key="RFC 3844",
  abstract={This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement.  It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF.  Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes.  The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions.  Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals.  This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG.  While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements.  This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group.  This memo provides information for the Internet community.},
  keywords="ietf, process, problem, analysis",
  doi="10.17487/RFC3844",
  }

@misc{rfc3845,
  author="J. Schlyter",
  title="{DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format}",
  howpublished="RFC 3845 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3845",
  pages="1--7",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 4033, 4034, 4035",
url="https://www.rfc-editor.org/rfc/rfc3845.txt",
  key="RFC 3845",
  abstract={This document redefines the wire format of the ``Type Bit Map'' field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]},
  keywords="dnssec, DNS Security, rr, resource record, DNS-SECEXT, dns, authentication, nsec, nextsecure",
  doi="10.17487/RFC3845",
  }

@misc{rfc3846,
  author="F. Johansson and T. Johansson",
  title="{Mobile IPv4 Extension for Carrying Network Access Identifiers}",
  howpublished="RFC 3846 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3846",
  pages="1--8",
  year=2004,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3846.txt",
  key="RFC 3846",
  abstract={When a mobile node moves between two foreign networks, it has to be re-authenticated.  If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used).  This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs).  The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment.  This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]},
  keywords="nai, internet protocol, home aaa server, ha server, home agents",
  doi="10.17487/RFC3846",
  }

@misc{rfc3847,
  author="M. Shand and L. Ginsberg",
  title="{Restart Signaling for Intermediate System to Intermediate System (IS-IS)}",
  howpublished="RFC 3847 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3847",
  pages="1--21",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5306",
url="https://www.rfc-editor.org/rfc/rfc3847.txt",
  key="RFC 3847",
  abstract={This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.  This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts.  This memo provides information for the Internet community.},
  keywords="LSP database synchronization, transient routing disruption, database synchronization",
  doi="10.17487/RFC3847",
  }

@misc{rfc3848,
  author="C. Newman",
  title="{ESMTP and LMTP Transmission Types Registration}",
  howpublished="RFC 3848 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3848",
  pages="1--4",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3848.txt",
  key="RFC 3848",
  abstract={This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the ``with'' clause of a Received header in an Internet message. [STANDARDS-TRACK]},
  keywords="smtp, simple mail transfer protocol",
  doi="10.17487/RFC3848",
  }

@misc{rfc3849,
  author="G. Huston and A. Lord and P. Smith",
  title="{IPv6 Address Prefix Reserved for Documentation}",
  howpublished="RFC 3849 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3849",
  pages="1--4",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3849.txt",
  key="RFC 3849",
  abstract={To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like.  Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations.  The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation.  This memo provides information for the Internet community.},
  keywords="unicast, site-local, link-local",
  doi="10.17487/RFC3849",
  }

@misc{rfc3850,
  author="B. Ramsdell",
  title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling}",
  howpublished="RFC 3850 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3850",
  pages="1--16",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5750",
url="https://www.rfc-editor.org/rfc/rfc3850.txt",
  key="RFC 3850",
  abstract={This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.  S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.  S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile.  S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]},
  keywords="x.509, encryption, certificate, multipurpose, internet, mail, extensions, secure",
  doi="10.17487/RFC3850",
  }

@misc{rfc3851,
  author="B. Ramsdell",
  title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification}",
  howpublished="RFC 3851 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3851",
  pages="1--36",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5751",
url="https://www.rfc-editor.org/rfc/rfc3851.txt",
  key="RFC 3851",
  abstract={This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.  Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 2633. [STANDARDS-TRACK]},
  keywords="secure, multipurpose, internet, mail, extensions, encryption",
  doi="10.17487/RFC3851",
  }

@misc{rfc3852,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 3852 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3852",
  pages="1--56",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5652, updated by RFCs 4853, 5083",
url="https://www.rfc-editor.org/rfc/rfc3852.txt",
  key="RFC 3852",
  abstract={This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]},
  keywords="digitally sign, authenticate, encrypt, arbitrary message content",
  doi="10.17487/RFC3852",
  }

@misc{rfc3853,
  author="J. Peterson",
  title="{S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3853 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3853",
  pages="1--6",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3853.txt",
  key="RFC 3853",
  abstract={RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP).  This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC3853",
  }

@misc{rfc3854,
  author="P. Hoffman and C. Bonatti and A. Eggen",
  title="{Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)}",
  howpublished="RFC 3854 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3854",
  pages="1--15",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3854.txt",
  key="RFC 3854",
  abstract={This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]},
  keywords="encryption, cryptographic signature",
  doi="10.17487/RFC3854",
  }

@misc{rfc3855,
  author="P. Hoffman and C. Bonatti",
  title="{Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400}",
  howpublished="RFC 3855 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3855",
  pages="1--12",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3855.txt",
  key="RFC 3855",
  abstract={This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]},
  keywords="cms, cryptographic message syntax message",
  doi="10.17487/RFC3855",
  }

@misc{rfc3856,
  author="J. Rosenberg",
  title="{A Presence Event Package for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3856 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3856",
  pages="1--27",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3856.txt",
  key="RFC 3856",
  abstract={This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence.  Presence is defined as the willingness and ability of a user to communicate with other users on the network.  Historically, presence has been limited to ``on-line'' and ``off-line'' indicators; the notion of presence here is broader.  Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework.  This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]},
  keywords="subscription notification",
  doi="10.17487/RFC3856",
  }

@misc{rfc3857,
  author="J. Rosenberg",
  title="{A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3857 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3857",
  pages="1--20",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3857.txt",
  key="RFC 3857",
  abstract={This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework.  Watcher information refers to the set of users subscribed to a particular resource within a particular event package.  Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected.  A user can subscribe to this information, and therefore learn about changes to it.  This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3857",
  }

@misc{rfc3858,
  author="J. Rosenberg",
  title="{An Extensible Markup Language (XML) Based Format for Watcher Information}",
  howpublished="RFC 3858 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3858",
  pages="1--13",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3858.txt",
  key="RFC 3858",
  abstract={Watchers are defined as entities that request (i.e., subscribe to) information about a resource.  There is fairly complex state associated with these subscriptions.  The union of the state for all subscriptions to a particular resource is called the watcher information for that resource.  This state is dynamic, changing as subscribers come and go.  As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource.  In order to enable this, a format is needed to describe the state of watchers on a resource.  This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]},
  keywords="xml",
  doi="10.17487/RFC3858",
  }

@misc{rfc3859,
  author="J. Peterson",
  title="{Common Profile for Presence (CPP)}",
  howpublished="RFC 3859 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3859",
  pages="1--15",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3859.txt",
  key="RFC 3859",
  abstract={At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved.  This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]},
  keywords="data formats, semantics, instant messaging",
  doi="10.17487/RFC3859",
  }

@misc{rfc3860,
  author="J. Peterson",
  title="{Common Profile for Instant Messaging (CPIM)}",
  howpublished="RFC 3860 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3860",
  pages="1--13",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3860.txt",
  key="RFC 3860",
  abstract={At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved.  This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]},
  keywords="data formats, semantics, instant messaging",
  doi="10.17487/RFC3860",
  }

@misc{rfc3861,
  author="J. Peterson",
  title="{Address Resolution for Instant Messaging and Presence}",
  howpublished="RFC 3861 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3861",
  pages="1--8",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3861.txt",
  key="RFC 3861",
  abstract={Presence and instant messaging are defined in RFC 2778.  The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES.  This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]},
  keywords="uri, schemes, universal resource identifier, impp, instant messaging and presence protocol, presentity, instant inbox",
  doi="10.17487/RFC3861",
  }

@misc{rfc3862,
  author="G. Klyne and D. Atkins",
  title="{Common Presence and Instant Messaging (CPIM): Message Format}",
  howpublished="RFC 3862 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3862",
  pages="1--30",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3862.txt",
  key="RFC 3862",
  abstract={This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]},
  keywords="instant messaging and presence protocol, message/cpim",
  doi="10.17487/RFC3862",
  }

@misc{rfc3863,
  author="H. Sugano and S. Fujimoto and G. Klyne and A. Bateman and W. Carr and J. Peterson",
  title="{Presence Information Data Format (PIDF)}",
  howpublished="RFC 3863 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3863",
  pages="1--28",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3863.txt",
  key="RFC 3863",
  abstract={This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type ``application/pidf+xml'' to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]},
  keywords="instant messaging and presence protocol, cpp, common profile for presence, presence data format, application/pidf+xml",
  doi="10.17487/RFC3863",
  }

@misc{rfc3864,
  author="G. Klyne and M. Nottingham and J. Mogul",
  title="{Registration Procedures for Message Header Fields}",
  howpublished="RFC 3864 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3864",
  pages="1--17",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3864.txt",
  key="RFC 3864",
  abstract={This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet mail, HTTP, Netnews",
  doi="10.17487/RFC3864",
  }

@misc{rfc3865,
  author="C. Malamud",
  title="{A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension}",
  howpublished="RFC 3865 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3865",
  pages="1--19",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3865.txt",
  key="RFC 3865",
  abstract={This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world ``No Soliciting'' sign.  In addition to the service extension, a new message header and extensions to the existing ``received'' message header are described. [STANDARDS-TRACK]},
  keywords="unsolicited bulk email, ube, no soliciting, solicitation class keywords, solicitation mail header, trace fields",
  doi="10.17487/RFC3865",
  }

@misc{rfc3866,
  author="K. Zeilenga",
  title="{Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 3866 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3866",
  pages="1--15",
  year=2004,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3866.txt",
  key="RFC 3866",
  abstract={It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs.  This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]},
  keywords="lightweight, directory, access, protocol, servers",
  doi="10.17487/RFC3866",
  }

@misc{rfc3867,
  author="Y. Kawatsura and M. Hiroya and H. Beykirch",
  title="{Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)}",
  howpublished="RFC 3867 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3867",
  pages="1--106",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3867.txt",
  key="RFC 3867",
  abstract={The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.},
  keywords="modules, data format exchange",
  doi="10.17487/RFC3867",
  }

@misc{rfc3868,
  author="J. Loughney and G. Sidebottom and L. Coene and G. Verwimp and J. Keller and B. Bidulock",
  title="{Signalling Connection Control Part User Adaptation Layer (SUA)}",
  howpublished="RFC 3868 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3868",
  pages="1--131",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3868.txt",
  key="RFC 3868",
  abstract={This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol.  The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]},
  keywords="sctp, stream control transmission protocol, modular, symmetric, signalling gateway, signalling endpoint architecture",
  doi="10.17487/RFC3868",
  }

@misc{rfc3869,
  author="R. Atkinson and S. Floyd and Internet Architecture Board",
  title="{IAB Concerns and Recommendations Regarding Internet Research and Evolution}",
  howpublished="RFC 3869 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3869",
  pages="1--30",
  year=2004,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3869.txt",
  key="RFC 3869",
  abstract={This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.  This memo provides information for the Internet community.},
  keywords="internet architecture board, internet infrastructure, non-commercial funding",
  doi="10.17487/RFC3869",
  }

@misc{rfc3870,
  author="A. Swartz",
  title="{application/rdf+xml Media Type Registration}",
  howpublished="RFC 3870 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3870",
  pages="1--8",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3870.txt",
  key="RFC 3870",
  abstract={This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF).  RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web.  RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization.  This memo provides information for the Internet community.},
  keywords="xml, extensible markup language, mime, multipurpose internet mail extensions, rdf, resource description framework",
  doi="10.17487/RFC3870",
  }

@misc{rfc3871,
  author="G. Jones",
  title="{Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure}",
  howpublished="RFC 3871 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3871",
  pages="1--81",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3871.txt",
  key="RFC 3871",
  abstract={This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches).  A framework is defined for specifying ``profiles'', which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...).  The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3871",
  }

@misc{rfc3872,
  author="D. Zinman and D. Walker and J. Jiang",
  title="{Management Information Base for Telephony Routing over IP (TRIP)}",
  howpublished="RFC 3872 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3872",
  pages="1--53",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3872.txt",
  key="RFC 3872",
  abstract={This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]},
  keywords="mib",
  doi="10.17487/RFC3872",
  }

@misc{rfc3873,
  author="J. Pastor and M. Belinchon",
  title="{Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)}",
  howpublished="RFC 3873 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3873",
  pages="1--46",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3873.txt",
  key="RFC 3873",
  abstract={The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3873",
  }

@misc{rfc3874,
  author="R. Housley",
  title="{A 224-bit One-way Hash Function: SHA-224}",
  howpublished="RFC 3874 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3874",
  pages="1--6",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3874.txt",
  key="RFC 3874",
  abstract={This document specifies a 224-bit one-way hash function, called SHA-224.  SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits.  This memo provides information for the Internet community.},
  keywords="secure standard",
  doi="10.17487/RFC3874",
  }

@misc{rfc3875,
  author="D. Robinson and K. Coar",
  title="{The Common Gateway Interface (CGI) Version 1.1}",
  howpublished="RFC 3875 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3875",
  pages="1--36",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3875.txt",
  key="RFC 3875",
  abstract={The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.},
  keywords="www, world wide web",
  doi="10.17487/RFC3875",
  }

@misc{rfc3876,
  author="D. Chadwick and S. Mullan",
  title="{Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)}",
  howpublished="RFC 3876 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3876",
  pages="1--12",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3876.txt",
  key="RFC 3876",
  abstract={This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry.  Specifically, only those values that match a ``values return'' filter.  Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]},
  keywords="attribute, filter",
  doi="10.17487/RFC3876",
  }

@misc{rfc3877,
  author="S. Chisholm and D. Romascanu",
  title="{Alarm Management Information Base (MIB)}",
  howpublished="RFC 3877 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3877",
  pages="1--75",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3877.txt",
  key="RFC 3877",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes management objects used for modelling and storing alarms. [STANDARDS-TRACK]},
  keywords="alarm mib, iana-itu-alarm-tc-mib, itu-alarm-tc-mib, itu-alarm-mib",
  doi="10.17487/RFC3877",
  }

@misc{rfc3878,
  author="H. Lam and A. Huynh and D. Perkins",
  title="{Alarm Reporting Control Management Information Base (MIB)}",
  howpublished="RFC 3878 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3878",
  pages="1--16",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3878.txt",
  key="RFC 3878",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS-TRACK]},
  keywords="alarm condition, probably cause",
  doi="10.17487/RFC3878",
  }

@misc{rfc3879,
  author="C. Huitema and B. Carpenter",
  title="{Deprecating Site Local Addresses}",
  howpublished="RFC 3879 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3879",
  pages="1--10",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3879.txt",
  key="RFC 3879",
  abstract={This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them.  This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]},
  keywords="ipv6, architecture",
  doi="10.17487/RFC3879",
  }

@misc{rfc3880,
  author="J. Lennox and X. Wu and H. Schulzrinne",
  title="{Call Processing Language (CPL): A Language for User Control of Internet Telephony Services}",
  howpublished="RFC 3880 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3880",
  pages="1--74",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3880.txt",
  key="RFC 3880",
  abstract={This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services.  It is designed to be implementable on either network servers or user agents.  It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol.  It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3880",
  }

@misc{rfc3881,
  author="G. Marshall",
  title="{Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications}",
  howpublished="RFC 3881 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3881",
  pages="1--47",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3881.txt",
  key="RFC 3881",
  abstract={This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems.  The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers.  It consolidates several previous documents on security auditing of healthcare data.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3881",
  }

@misc{rfc3882,
  author="D. Turk",
  title="{Configuring BGP to Block Denial-of-Service Attacks}",
  howpublished="RFC 3882 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3882",
  pages="1--8",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3882.txt",
  key="RFC 3882",
  abstract={This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks.  Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network.  The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis.  This memo provides information for the Internet community.},
  keywords="dos, border gateway protocol",
  doi="10.17487/RFC3882",
  }

@misc{rfc3883,
  author="S. Rao and A. Zinin and A. Roy",
  title="{Detecting Inactive Neighbors over OSPF Demand Circuits (DC)}",
  howpublished="RFC 3883 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3883",
  pages="1--6",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3883.txt",
  key="RFC 3883",
  abstract={OSPF is a link-state intra-domain routing protocol used in IP networks.  OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic.  A part of the OSPF demand circuit extensions is the Hello suppression mechanism.  This technique allows a demand circuit to go down when no interesting traffic is going through the link.  However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link.  This memo introduces a new mechanism called ``neighbor probing'' to address the above problem. [STANDARDS-TRACK]},
  keywords="OSPF-DC, Open Shortest Path First",
  doi="10.17487/RFC3883",
  }

@misc{rfc3884,
  author="J. Touch and L. Eggert and Y. Wang",
  title="{Use of IPsec Transport Mode for Dynamic Routing}",
  howpublished="RFC 3884 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3884",
  pages="1--25",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3884.txt",
  key="RFC 3884",
  abstract={IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN).  Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses.  The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts.  An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran.  IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet.  IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header.  IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture.  IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts.  IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).  This memo provides information for the Internet community.},
  doi="10.17487/RFC3884",
  }

@misc{rfc3885,
  author="E. Allman and T. Hansen",
  title="{SMTP Service Extension for Message Tracking}",
  howpublished="RFC 3885 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3885",
  pages="1--9",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3885.txt",
  key="RFC 3885",
  abstract={This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]},
  keywords="simple mail transfer protocol",
  doi="10.17487/RFC3885",
  }

@misc{rfc3886,
  author="E. Allman",
  title="{An Extensible Message Format for Message Tracking Responses}",
  howpublished="RFC 3886 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3886",
  pages="1--11",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3886.txt",
  key="RFC 3886",
  abstract={Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, ``An Extensible Message Format for Delivery Status Notifications''. It is to be issued upon a request as described in ``Message Tracking Query Protocol''. This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK]},
  keywords="Delivery Status Notifications, DSN, Message Disposition Notifications, MDN",
  doi="10.17487/RFC3886",
  }

@misc{rfc3887,
  author="T. Hansen",
  title="{Message Tracking Query Protocol}",
  howpublished="RFC 3887 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3887",
  pages="1--23",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3887.txt",
  key="RFC 3887",
  abstract={Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message.  This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]},
  keywords="mtqp, ESMTP",
  doi="10.17487/RFC3887",
  }

@misc{rfc3888,
  author="T. Hansen",
  title="{Message Tracking Model and Requirements}",
  howpublished="RFC 3888 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3888",
  pages="1--11",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3888.txt",
  key="RFC 3888",
  abstract={Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message.  This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions.  This memo provides information for the Internet community.},
  keywords="",
  doi="10.17487/RFC3888",
  }

@misc{rfc3890,
  author="M. Westerlund",
  title="{A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)}",
  howpublished="RFC 3890 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3890",
  pages="1--22",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3890.txt",
  key="RFC 3890",
  abstract={This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]},
  keywords="tias, application specific maximum",
  doi="10.17487/RFC3890",
  }

@misc{rfc3891,
  author="R. Mahy and B. Biggs and R. Dean",
  title="{The Session Initiation Protocol (SIP) ``Replaces'' Header}",
  howpublished="RFC 3891 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3891",
  pages="1--16",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3891.txt",
  key="RFC 3891",
  abstract={This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control.  The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog.  This primitive can be used to enable a variety of features, for example: ``Attended Transfer'' and ``Call Pickup''.  Note that the definition of these example features is non-normative. [STANDARDS-TRACK]},
  keywords="multi-party applications, call control",
  doi="10.17487/RFC3891",
  }

@misc{rfc3892,
  author="R. Sparks",
  title="{The Session Initiation Protocol (SIP) Referred-By Mechanism}",
  howpublished="RFC 3892 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3892",
  pages="1--25",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3892.txt",
  key="RFC 3892",
  abstract={The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference.  If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target).  This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary.  This information includes the identity of the referrer and the URI to which the referrer referred.  The mechanism utilizes S/MIME to help protect this information from a malicious intermediary.  This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]},
  keywords="REFER",
  doi="10.17487/RFC3892",
  }

@misc{rfc3893,
  author="J. Peterson",
  title="{Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format}",
  howpublished="RFC 3893 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3893",
  pages="1--13",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3893.txt",
  key="RFC 3893",
  abstract={RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers.  This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment.  A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document.  Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]},
  keywords="authenticated identity body, digitally-signed SIP message, message fragment, Authenticated Identity Bodies, AIB",
  doi="10.17487/RFC3893",
  }

@misc{rfc3894,
  author="J. Degener",
  title="{Sieve Extension: Copying Without Side Effects}",
  howpublished="RFC 3894 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3894",
  pages="1--5",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3894.txt",
  key="RFC 3894",
  abstract={The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's ``inbox''. Actions such as ``fileinto'' and ``redirect'' cancel this default behavior. This document defines a new keyword parameter, ``:copy'', to be used with the Sieve ``fileinto'' and ``redirect'' actions. Adding ``:copy'' to an action suppresses cancellation of the default ``inbox'' save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK]},
  keywords="client, server",
  doi="10.17487/RFC3894",
  }

@misc{rfc3895,
  author="O. Nicklass",
  title="{Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types}",
  howpublished="RFC 3895 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3895",
  pages="1--84",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4805",
url="https://www.rfc-editor.org/rfc/rfc3895.txt",
  key="RFC 3895",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces.  This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.  This document obsoletes RFC 2495. [STANDARDS-TRACK]},
  keywords="management information base",
  doi="10.17487/RFC3895",
  }

@misc{rfc3896,
  author="O. Nicklass",
  title="{Definitions of Managed Objects for the DS3/E3 Interface Type}",
  howpublished="RFC 3896 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3896",
  pages="1--63",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3896.txt",
  key="RFC 3896",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing DS3 and E3 interfaces.  This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.  This document obsoletes RFC 2496. [STANDARDS-TRACK]},
  keywords="DS3-E3-MIB, management information base",
  doi="10.17487/RFC3896",
  }

@misc{rfc3897,
  author="A. Barbir",
  title="{Open Pluggable Edge Services (OPES) Entities and End Points Communication}",
  howpublished="RFC 3897 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3897",
  pages="1--14",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3897.txt",
  key="RFC 3897",
  abstract={This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).  This memo provides information for the Internet community.},
  keywords="tracing, non-blocking, bypass",
  doi="10.17487/RFC3897",
  }

@misc{rfc3898,
  author="V. Kalusivalingam",
  title="{Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 3898 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3898",
  pages="1--7",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3898.txt",
  key="RFC 3898",
  abstract={This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]},
  keywords="NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name",
  doi="10.17487/RFC3898",
  }

@misc{rfc3901,
  author="A. Durand and J. Ihren",
  title="{DNS IPv6 Transport Operational Guidelines}",
  howpublished="RFC 3901 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3901",
  pages="1--5",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3901.txt",
  key="RFC 3901",
  abstract={This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="domain name system, internet protocol",
  doi="10.17487/RFC3901",
  }

@misc{rfc3902,
  author="M. Baker and M. Nottingham",
  title="{The ``application/soap+xml'' media type}",
  howpublished="RFC 3902 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3902",
  pages="1--5",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3902.txt",
  key="RFC 3902",
  abstract={This document defines the ``application/soap+xml'' media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3902",
  }

@misc{rfc3903,
  author="A. Niemi",
  title="{Session Initiation Protocol (SIP) Extension for Event State Publication}",
  howpublished="RFC 3903 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3903",
  pages="1--32",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3903.txt",
  key="RFC 3903",
  abstract={This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework.  The first application of this extension is for the publication of presence information.  The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package.  It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]},
  keywords="presence, information, package",
  doi="10.17487/RFC3903",
  }

@misc{rfc3904,
  author="C. Huitema and R. Austein and S. Satapati and R. van der Pol",
  title="{Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks}",
  howpublished="RFC 3904 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3904",
  pages="1--19",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3904.txt",
  key="RFC 3904",
  abstract={This document analyzes issues involved in the transition of ``unmanaged networks'' from IPv4 to IPv6.  Unmanaged networks typically correspond to home networks or small office networks.  A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6.  Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.  This memo provides information for the Internet community.},
  keywords="home office, internet protocol",
  doi="10.17487/RFC3904",
  }

@misc{rfc3905,
  author="V. See",
  title="{A Template for IETF Patent Disclosures and Licensing Declarations}",
  howpublished="RFC 3905 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3905",
  pages="1--9",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3905.txt",
  key="RFC 3905",
  abstract={This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations.  The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668.  This memo provides information for the Internet community.},
  keywords="ipr",
  doi="10.17487/RFC3905",
  }

@misc{rfc3906,
  author="N. Shen and H. Smit",
  title="{Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels}",
  howpublished="RFC 3906 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3906",
  pages="1--8",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3906.txt",
  key="RFC 3906",
  abstract={This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts.  In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering.  This memo provides information for the Internet community.},
  keywords="hop-by-hop link-state routing protocols, SPF, shortest path first",
  doi="10.17487/RFC3906",
  }

@misc{rfc3909,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Cancel Operation}",
  howpublished="RFC 3909 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3909",
  pages="1--7",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3909.txt",
  key="RFC 3909",
  abstract={This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation.  Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]},
  keywords="abandon operation, outstanding operation",
  doi="10.17487/RFC3909",
  }

@misc{rfc3910,
  author="V. Gurbani and A. Brusilovsky and I. Faynberg and J. Gato and H. Lu and M. Unmehopa",
  title="{The SPIRITS (Services in PSTN requesting Internet Services) Protocol}",
  howpublished="RFC 3910 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3910",
  pages="1--50",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3910.txt",
  key="RFC 3910",
  abstract={This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol.  The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet.  On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities.  Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network.  The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]},
  keywords="pstn, sip, services, event notification, eventpackages, internet call waiting, xml, wireless, intelligent network, in, detection point, dp",
  doi="10.17487/RFC3910",
  }

@misc{rfc3911,
  author="R. Mahy and D. Petrie",
  title="{The Session Initiation Protocol (SIP) ``Join'' Header}",
  howpublished="RFC 3911 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3911",
  pages="1--17",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3911.txt",
  key="RFC 3911",
  abstract={This document defines a new header for use with SIP multi-party applications and call control.  The Join header is used to logically join an existing SIP dialog with a new SIP dialog.  This primitive can be used to enable a variety of features, for example: ``Barge-In'', answering-machine-style ``Message Screening'' and ``Call Center Monitoring''.  Note that definition of these example features is non-normative. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3911",
  }

@misc{rfc3912,
  author="L. Daigle",
  title="{WHOIS Protocol Specification}",
  howpublished="RFC 3912 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3912",
  pages="1--4",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3912.txt",
  key="RFC 3912",
  abstract={This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954.  The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet.  This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]},
  keywords="NICNAME",
  doi="10.17487/RFC3912",
  }

@misc{rfc3913,
  author="D. Thaler",
  title="{Border Gateway Multicast Protocol (BGMP): Protocol Specification}",
  howpublished="RFC 3913 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="3913",
  pages="1--41",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3913.txt",
  key="RFC 3913",
  abstract={This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing.  BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed.  BGMP natively supports ``source-specific multicast'' (SSM).  To also support ``any-source multicast'' (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain).  It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains.  Each of these domains then becomes the root of the shared domain-trees for all groups in its range.  Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.  This memo provides information for the Internet community.},
  keywords="enter-domain, source-specific multicast, ssm",
  doi="10.17487/RFC3913",
  }

@misc{rfc3914,
  author="A. Barbir and A. Rousskov",
  title="{Open Pluggable Edge Services (OPES) Treatment of IAB Considerations}",
  howpublished="RFC 3914 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3914",
  pages="1--16",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3914.txt",
  key="RFC 3914",
  abstract={IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework.  This document describes how OPES addresses those considerations.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3914",
  }

@misc{rfc3915,
  author="S. Hollenbeck",
  title="{Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 3915 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3915",
  pages="1--23",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3915.txt",
  key="RFC 3915",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ``grace period'' policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN).  Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]},
  keywords="dns, name system",
  doi="10.17487/RFC3915",
  }

@misc{rfc3916,
  author="X. Xiao and D. McPherson and P. Pate",
  title="{Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)}",
  howpublished="RFC 3916 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3916",
  pages="1--19",
  year=2004,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3916.txt",
  key="RFC 3916",
  abstract={This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG).  It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay.  Requirements for pseudo-wire emulation of TDM (i.e., ``synchronous bit streams at rates defined by ITU G.702'') are defined in another document.  It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3916",
  }

@misc{rfc3917,
  author="J. Quittek and T. Zseby and B. Claise and S. Zander",
  title="{Requirements for IP Flow Information Export (IPFIX)}",
  howpublished="RFC 3917 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3917",
  pages="1--33",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3917.txt",
  key="RFC 3917",
  abstract={This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.  This memo provides information for the Internet community.},
  keywords="ipfix, routers, measurment, middleboxes",
  doi="10.17487/RFC3917",
  }

@misc{rfc3918,
  author="D. Stopp and B. Hickman",
  title="{Methodology for IP Multicast Benchmarking}",
  howpublished="RFC 3918 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3918",
  pages="1--31",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3918.txt",
  key="RFC 3918",
  abstract={The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.},
  doi="10.17487/RFC3918",
  }

@misc{rfc3919,
  author="E. Stephan and J. Palet",
  title="{Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)}",
  howpublished="RFC 3919 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3919",
  pages="1--8",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3919.txt",
  key="RFC 3919",
  abstract={This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895]. This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.},
  keywords="mib",
  doi="10.17487/RFC3919",
  }

@misc{rfc3920,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Core}",
  howpublished="RFC 3920 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3920",
  pages="1--30",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6120, updated by RFC 6122",
url="https://www.rfc-editor.org/rfc/rfc3920.txt",
  key="RFC 3920",
  abstract={This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints.  While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]},
  keywords="instant messaging, im, extensible markup language, xml, jabber",
  doi="10.17487/RFC3920",
  }

@misc{rfc3921,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence}",
  howpublished="RFC 3921 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3921",
  pages="1--107",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6121",
url="https://www.rfc-editor.org/rfc/rfc3921.txt",
  key="RFC 3921",
  abstract={This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]},
  keywords="instant messaging, im, extensible markup language, xml, jabber",
  doi="10.17487/RFC3921",
  }

@misc{rfc3922,
  author="P. Saint-Andre",
  title="{Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)}",
  howpublished="RFC 3922 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3922",
  pages="1--34",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3922.txt",
  key="RFC 3922",
  abstract={This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]},
  keywords="xml, extensible markup language, im, instant messaging, jabber",
  doi="10.17487/RFC3922",
  }

@misc{rfc3923,
  author="P. Saint-Andre",
  title="{End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 3923 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3923",
  pages="1--27",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3923.txt",
  key="RFC 3923",
  abstract={This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]},
  keywords="xml, extensible markup language, im, instant messaging, jabber",
  doi="10.17487/RFC3923",
  }

@misc{rfc3924,
  author="F. Baker and B. Foster and C. Sharp",
  title="{Cisco Architecture for Lawful Intercept in IP Networks}",
  howpublished="RFC 3924 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3924",
  pages="1--18",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3924.txt",
  key="RFC 3924",
  abstract={For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications.  Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide.  Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ.  This document describes Cisco's Architecture for supporting lawful intercept in IP networks.  It provides a general solution that has a minimum set of common interfaces.  This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3924",
  }

@misc{rfc3925,
  author="J. Littlefield",
  title="{Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)}",
  howpublished="RFC 3925 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3925",
  pages="1--9",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3925.txt",
  key="RFC 3925",
  abstract={The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors.  This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]},
  keywords="dhc, dhcp, class, vendor-specific",
  doi="10.17487/RFC3925",
  }

@misc{rfc3926,
  author="T. Paila and M. Luby and R. Lehtonen and V. Roca and R. Walsh",
  title="{FLUTE - File Delivery over Unidirectional Transport}",
  howpublished="RFC 3926 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3926",
  pages="1--35",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6726",
url="https://www.rfc-editor.org/rfc/rfc3926.txt",
  key="RFC 3926",
  abstract={This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks.  The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3926",
  }

@misc{rfc3927,
  author="S. Cheshire and B. Aboba and E. Guttman",
  title="{Dynamic Configuration of IPv4 Link-Local Addresses}",
  howpublished="RFC 3927 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3927",
  pages="1--33",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3927.txt",
  key="RFC 3927",
  abstract={To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]},
  keywords="ip network, ip address, 169.254/16",
  doi="10.17487/RFC3927",
  }

@misc{rfc3928,
  author="R. Megginson and M. Smith and O. Natkovich and J. Parham",
  title="{Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)}",
  howpublished="RFC 3928 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3928",
  pages="1--30",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3928.txt",
  key="RFC 3928",
  abstract={This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP).  The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3928",
  }

@misc{rfc3929,
  author="T. Hardie",
  title="{Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF}",
  howpublished="RFC 3929 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3929",
  pages="1--11",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3929.txt",
  key="RFC 3929",
  abstract={This document proposes an experimental set of alternative decision-making processes for use in IETF working groups.  There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself.  This document describes alternative mechanisms for reaching a decision in those cases.  This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3929",
  }

@misc{rfc3930,
  author="D. {Eastlake 3rd}",
  title="{The Protocol versus Document Points of View in Computer Protocols}",
  howpublished="RFC 3930 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3930",
  pages="1--15",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3930.txt",
  key="RFC 3930",
  abstract={This document contrasts two points of view: the ``document'' point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the ``protocol'' point of view where objects of interest are composite dynamic network messages.  Although each point of view has a place, adherence to a document point of view can be damaging to protocol design.  By understanding both points of view, conflicts between them may be clarified and reduced.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3930",
  }

@misc{rfc3931,
  author="J. Lau and M. Townsley and I. Goyret",
  title="{Layer Two Tunneling Protocol - Version 3 (L2TPv3)}",
  howpublished="RFC 3931 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3931",
  pages="1--94",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5641",
url="https://www.rfc-editor.org/rfc/rfc3931.txt",
  key="RFC 3931",
  abstract={This document describes ``version 3'' of the Layer Two Tunneling Protocol (L2TPv3).  L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes.  Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]},
  keywords="L2TP, ppp, point-to-point, protocol, packets",
  doi="10.17487/RFC3931",
  }

@misc{rfc3932,
  author="H. Alvestrand",
  title="{The IESG and RFC Editor Documents: Procedures}",
  howpublished="RFC 3932 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3932",
  pages="1--8",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5742",
url="https://www.rfc-editor.org/rfc/rfc3932.txt",
  key="RFC 3932",
  abstract={This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="independent submission",
  doi="10.17487/RFC3932",
  }

@misc{rfc3933,
  author="J. Klensin and S. Dawkins",
  title="{A Model for IETF Process Experiments}",
  howpublished="RFC 3933 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3933",
  pages="1--7",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3933.txt",
  key="RFC 3933",
  abstract={The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification.  The first mechanism has often proven to be too lightweight, the second too heavyweight.  This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a ``propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience'' model rather than those previously attempted.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3933",
  }

@misc{rfc3934,
  author="M. Wasserman",
  title="{Updates to RFC 2418 Regarding the Management of IETF Mailing Lists}",
  howpublished="RFC 3934 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3934",
  pages="1--5",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3934.txt",
  key="RFC 3934",
  abstract={This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists.  In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="BCP, WG, escape, clause, procedures",
  doi="10.17487/RFC3934",
  }

@misc{rfc3935,
  author="H. Alvestrand",
  title="{A Mission Statement for the IETF}",
  howpublished="RFC 3935 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3935",
  pages="1--7",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3935.txt",
  key="RFC 3935",
  abstract={This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3935",
  }

@misc{rfc3936,
  author="K. Kompella and J. Lang",
  title="{Procedures for Modifying the Resource reSerVation Protocol (RSVP)}",
  howpublished="RFC 3936 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3936",
  pages="1--7",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3936.txt",
  key="RFC 3936",
  abstract={This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP).  This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="resource, reservation, protocol, label, switched, paths",
  doi="10.17487/RFC3936",
  }

@misc{rfc3937,
  author="M. Steidl",
  title="{A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)}",
  howpublished="RFC 3937 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3937",
  pages="1--9",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3937.txt",
  key="RFC 3937",
  abstract={This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC).  These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3937",
  }

@misc{rfc3938,
  author="T. Hansen",
  title="{Video-Message Message-Context}",
  howpublished="RFC 3938 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3938",
  pages="1--4",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3938.txt",
  key="RFC 3938",
  abstract={The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message).  This specification extends the Message-Context header with one additional context value: ``video-message''.  A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]},
  keywords="user agent, ua",
  doi="10.17487/RFC3938",
  }

@misc{rfc3939,
  author="G. Parsons and J. Maruszak",
  title="{Calling Line Identification for Voice Mail Messages}",
  howpublished="RFC 3939 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3939",
  pages="1--11",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3939.txt",
  key="RFC 3939",
  abstract={This document describes a method for identifying the originating calling party in the headers of a stored voice mail message.  Two new header fields are defined for this purpose: Caller\_ID and Called\_Name.  Caller\_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message.  Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3939",
  }

@misc{rfc3940,
  author="B. Adamson and C. Bormann and M. Handley and J. Macker",
  title="{Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol}",
  howpublished="RFC 3940 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3940",
  pages="1--80",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5740",
url="https://www.rfc-editor.org/rfc/rfc3940.txt",
  key="RFC 3940",
  abstract={This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.  This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services.  NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal ``a priori'' coordination among senders and receivers.  A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP).  It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers.  The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.  The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3940",
  }

@misc{rfc3941,
  author="B. Adamson and C. Bormann and M. Handley and J. Macker",
  title="{Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks}",
  howpublished="RFC 3941 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3941",
  pages="1--36",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5401",
url="https://www.rfc-editor.org/rfc/rfc3941.txt",
  key="RFC 3941",
  abstract={This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols.  The rationale for NORM goals and assumptions are presented.  Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified.  These goals and challenges are resolved into a set of functional ``building blocks'' that address different aspects of NORM protocol operation.  It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3941",
  }

@misc{rfc3942,
  author="B. Volz",
  title="{Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options}",
  howpublished="RFC 3942 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3942",
  pages="1--7",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3942.txt",
  key="RFC 3942",
  abstract={This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939.  This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]},
  keywords="DHCP-BOOTP, Bootstrap",
  doi="10.17487/RFC3942",
  }

@misc{rfc3943,
  author="R. Friend",
  title="{Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)}",
  howpublished="RFC 3943 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3943",
  pages="1--13",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3943.txt",
  key="RFC 3943",
  abstract={The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol.  TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed.  This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS.  This document also defines the application of the LZS algorithm to the TLS Record Protocol.  This memo provides information for the Internet community.},
  keywords="lossless data compression algorithm, TLS Record Protocol",
  doi="10.17487/RFC3943",
  }

@misc{rfc3944,
  author="T. Johnson and S. Okubo and S. Campos",
  title="{H.350 Directory Services}",
  howpublished="RFC 3944 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3944",
  pages="1--30",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3944.txt",
  key="RFC 3944",
  abstract={The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols.  The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories.  A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.  Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community.  This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively.  The remaining sections are included only in this document, not in the ITU-T version.  This memo provides information for the Internet community.},
  keywords="ldap, directory services, h.350, h.323, h.320, h.235, sip",
  doi="10.17487/RFC3944",
  }

@misc{rfc3945,
  author="E. Mannie",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Architecture}",
  howpublished="RFC 3945 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3945",
  pages="1--69",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6002",
url="https://www.rfc-editor.org/rfc/rfc3945.txt",
  key="RFC 3945",
  abstract={Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3945",
  }

@misc{rfc3946,
  author="E. Mannie and D. Papadimitriou",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control}",
  howpublished="RFC 3946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3946",
  pages="1--26",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4606",
url="https://www.rfc-editor.org/rfc/rfc3946.txt",
  key="RFC 3946",
  abstract={This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling.  It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]},
  doi="10.17487/RFC3946",
  }

@misc{rfc3947,
  author="T. Kivinen and B. Swander and A. Huttunen and V. Volpe",
  title="{Negotiation of NAT-Traversal in the IKE}",
  howpublished="RFC 3947 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3947",
  pages="1--16",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3947.txt",
  key="RFC 3947",
  abstract={This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3947",
  }

@misc{rfc3948,
  author="A. Huttunen and B. Swander and V. Volpe and L. DiBurro and M. Stenberg",
  title="{UDP Encapsulation of IPsec ESP Packets}",
  howpublished="RFC 3948 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3948",
  pages="1--15",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3948.txt",
  key="RFC 3948",
  abstract={This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators.  ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios.  Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3948",
  }

@misc{rfc3949,
  author="R. Buckley and D. Venable and L. McIntyre and G. Parsons and J. Rafferty",
  title="{File Format for Internet Fax}",
  howpublished="RFC 3949 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3949",
  pages="1--84",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3949.txt",
  key="RFC 3949",
  abstract={This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS-TRACK]},
  keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions",
  doi="10.17487/RFC3949",
  }

@misc{rfc3950,
  author="L. McIntyre and G. Parsons and J. Rafferty",
  title="{Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration}",
  howpublished="RFC 3950 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3950",
  pages="1--8",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3950.txt",
  key="RFC 3950",
  abstract={This document describes the registration of the MIME sub-type image/tiff-fx.  The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]},
  keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions",
  doi="10.17487/RFC3950",
  }

@misc{rfc3951,
  author="S. Andersen and A. Duric and H. Astrom and R. Hagen and W. Kleijn and J. Linden",
  title="{Internet Low Bit Rate Codec (iLBC)}",
  howpublished="RFC 3951 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3951",
  pages="1--194",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3951.txt",
  key="RFC 3951",
  abstract={This document specifies a speech codec suitable for robust voice communication over IP.  The codec is developed by Global IP Sound (GIPS).  It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames.  The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3951",
  }

@misc{rfc3952,
  author="A. Duric and S. Andersen",
  title="{Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech}",
  howpublished="RFC 3952 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3952",
  pages="1--13",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3952.txt",
  key="RFC 3952",
  abstract={This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS).  Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC3952",
  }

@misc{rfc3953,
  author="J. Peterson",
  title="{Telephone Number Mapping (ENUM) Service Registration for Presence Services}",
  howpublished="RFC 3953 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3953",
  pages="1--7",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc3953.txt",
  key="RFC 3953",
  abstract={This document registers a Telephone Number Mapping (ENUM) service for presence.  Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, uri, provisioning pres",
  doi="10.17487/RFC3953",
  }

@misc{rfc3954,
  author="B. Claise",
  title="{Cisco Systems NetFlow Services Export Version 9}",
  howpublished="RFC 3954 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3954",
  pages="1--33",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3954.txt",
  key="RFC 3954",
  abstract={This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs.  The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner.  A template defines a collection of fields, with corresponding descriptions of structure and semantics.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3954",
  }

@misc{rfc3955,
  author="S. Leinen",
  title="{Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)}",
  howpublished="RFC 3955 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3955",
  pages="1--23",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3955.txt",
  key="RFC 3955",
  abstract={This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group.  The protocols are characterized and grouped in broad categories, and evaluated against specific requirements.  Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3955",
  }

@misc{rfc3956,
  author="P. Savola and B. Haberman",
  title="{Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address}",
  howpublished="RFC 3956 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3956",
  pages="1--18",
  year=2004,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7371",
url="https://www.rfc-editor.org/rfc/rfc3956.txt",
  key="RFC 3956",
  abstract={This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address.  For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism.  This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well.  This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC3956",
  }

@misc{rfc3957,
  author="C. Perkins and P. Calhoun",
  title="{Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4}",
  howpublished="RFC 3957 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3957",
  pages="1--27",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3957.txt",
  key="RFC 3957",
  abstract={Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers.  Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent.  When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node.  This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3957",
  }

@misc{rfc3958,
  author="L. Daigle and A. Newton",
  title="{Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)}",
  howpublished="RFC 3958 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3958",
  pages="1--25",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3958.txt",
  key="RFC 3958",
  abstract={This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks).  The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3958",
  }

@misc{rfc3959,
  author="G. Camarillo",
  title="{The Early Session Disposition Type for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3959",
  pages="1--11",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3959.txt",
  key="RFC 3959",
  abstract={This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP).  The treatment of ``early-session'' bodies is similar to the treatment of ``session'' bodies.  That is, they follow the offer/answer model.  Their only difference is that session descriptions whose disposition type is ``early-session'' are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3959",
  }

@misc{rfc3960,
  author="G. Camarillo and H. Schulzrinne",
  title="{Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3960 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3960",
  pages="1--13",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3960.txt",
  key="RFC 3960",
  abstract={This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model.  It also describes the inputs one needs to consider in defining local policies for ringing tone generation.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3960",
  }

@misc{rfc3961,
  author="K. Raeburn",
  title="{Encryption and Checksum Specifications for Kerberos 5}",
  howpublished="RFC 3961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3961",
  pages="1--50",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3961.txt",
  key="RFC 3961",
  abstract={This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves.  The document also defines several mechanisms.  Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect.  New mechanisms are presented here as well.  This document does NOT indicate which mechanisms may be considered ``required to implement''. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3961",
  }

@misc{rfc3962,
  author="K. Raeburn",
  title="{Advanced Encryption Standard (AES) Encryption for Kerberos 5}",
  howpublished="RFC 3962 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3962",
  pages="1--16",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3962.txt",
  key="RFC 3962",
  abstract={The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm.  This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]},
  keywords="kerberos cryptosystem suite",
  doi="10.17487/RFC3962",
  }

@misc{rfc3963,
  author="V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert",
  title="{Network Mobility (NEMO) Basic Support Protocol}",
  howpublished="RFC 3963 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3963",
  pages="1--33",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3963.txt",
  key="RFC 3963",
  abstract={This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet.  The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves.  It also allows every node in the Mobile Network to be reachable while moving around.  The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent.  The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]},
  keywords="mobile ipv6, session continuity",
  doi="10.17487/RFC3963",
  }

@misc{rfc3964,
  author="P. Savola and C. Patel",
  title="{Security Considerations for 6to4}",
  howpublished="RFC 3964 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3964",
  pages="1--41",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3964.txt",
  key="RFC 3964",
  abstract={The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks.  The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 (``IPv6-in-IPv4'') traffic from any node in the IPv4 internet.  This characteristic enables a number of security threats, mainly Denial of Service.  It also makes it easier for nodes to spoof IPv6 addresses.  This document discusses these issues in more detail and suggests enhancements to alleviate the problems.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3964",
  }

@misc{rfc3965,
  author="K. Toyoda and H. Ohno and J. Murai and D. Wing",
  title="{A Simple Mode of Facsimile Using Internet Mail}",
  howpublished="RFC 3965 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3965",
  pages="1--14",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3965.txt",
  key="RFC 3965",
  abstract={This specification provides for ``simple mode'' carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]},
  keywords="SMFAX-IM, data, file, format, e-mail",
  doi="10.17487/RFC3965",
  }

@misc{rfc3966,
  author="H. Schulzrinne",
  title="{The tel URI for Telephone Numbers}",
  howpublished="RFC 3966 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3966",
  pages="1--17",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5341",
url="https://www.rfc-editor.org/rfc/rfc3966.txt",
  key="RFC 3966",
  abstract={This document specifies the URI (Uniform Resource Identifier) scheme ``tel''.  The ``tel'' URI describes resources identified by telephone numbers.  This document obsoletes RFC 2806. [STANDARDS-TRACK]},
  keywords="uniform, resource, locator, schemes",
  doi="10.17487/RFC3966",
  }

@misc{rfc3967,
  author="R. Bush and T. Narten",
  title="{Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level}",
  howpublished="RFC 3967 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3967",
  pages="1--6",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4897, 8067",
url="https://www.rfc-editor.org/rfc/rfc3967.txt",
  key="RFC 3967",
  abstract={IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies).  For example, a standards track document may not have a normative reference to an informational RFC.  Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards.  This document clarifies and updates the procedure used in these circumstances.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  doi="10.17487/RFC3967",
  }

@misc{rfc3968,
  author="G. Camarillo",
  title="{The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3968 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3968",
  pages="1--8",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3968.txt",
  key="RFC 3968",
  abstract={This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values.  It also lists the already existing parameters and parameter values to be used as the initial entries for this registry.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3968",
  }

@misc{rfc3969,
  author="G. Camarillo",
  title="{The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 3969 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3969",
  pages="1--6",
  year=2004,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5727",
url="https://www.rfc-editor.org/rfc/rfc3969.txt",
  key="RFC 3969",
  abstract={This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values.  It also lists the already existing parameters to be used as initial values for that registry.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC3969",
  }

@misc{rfc3970,
  author="K. Kompella",
  title="{A Traffic Engineering (TE) MIB}",
  howpublished="RFC 3970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3970",
  pages="1--44",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3970.txt",
  key="RFC 3970",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3970",
  }

@misc{rfc3971,
  author="J. Arkko and J. Kempf and B. Zill and P. Nikander",
  title="{SEcure Neighbor Discovery (SEND)}",
  howpublished="RFC 3971 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3971",
  pages="1--56",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6494, 6495, 6980",
url="https://www.rfc-editor.org/rfc/rfc3971.txt",
  key="RFC 3971",
  abstract={IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors.  If not secured, NDP is vulnerable to various attacks.  This document specifies security mechanisms for NDP.  Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]},
  keywords="Neighbor Discovery Protocol, NDP",
  doi="10.17487/RFC3971",
  }

@misc{rfc3972,
  author="T. Aura",
  title="{Cryptographically Generated Addresses (CGA)}",
  howpublished="RFC 3972 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3972",
  pages="1--22",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4581, 4982",
url="https://www.rfc-editor.org/rfc/rfc3972.txt",
  key="RFC 3972",
  abstract={This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.  Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters.  The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier.  Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key.  The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]},
  keywords="Secure Neighbor Discovery, SEND",
  doi="10.17487/RFC3972",
  }

@misc{rfc3973,
  author="A. Adams and J. Nicholas and W. Siadak",
  title="{Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)}",
  howpublished="RFC 3973 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3973",
  pages="1--61",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3973.txt",
  key="RFC 3973",
  abstract={This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM).  PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers.  Prune messages are used to prevent future messages from propagating to routers without group membership information.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="multicast routing protocol, prune messages",
  doi="10.17487/RFC3973",
  }

@misc{rfc3974,
  author="M. Nakamura and J. Hagino",
  title="{SMTP Operational Experience in Mixed IPv4/v6 Environments}",
  howpublished="RFC 3974 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3974",
  pages="1--10",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3974.txt",
  key="RFC 3974",
  abstract={This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. This document does not define any new protocol. This memo provides information for the Internet community.},
  keywords="simple mail transfer protocol, dual stack, dualstack, ipv4, ipv6",
  doi="10.17487/RFC3974",
  }

@misc{rfc3975,
  author="G. Huston and I. Leuca",
  title="{OMA-IETF Standardization Collaboration}",
  howpublished="RFC 3975 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3975",
  pages="1--9",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3975.txt",
  key="RFC 3975",
  abstract={This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.},
  keywords="oopen mobile alliance, ietf, internet engineering task force",
  doi="10.17487/RFC3975",
  }

@misc{rfc3976,
  author="V. K. Gurbani and F. Haerens and V. Rastogi",
  title="{Interworking SIP and Intelligent Network (IN) Applications}",
  howpublished="RFC 3976 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3976",
  pages="1--25",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3976.txt",
  key="RFC 3976",
  abstract={Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN).  This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call.  The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN.  To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).  This memo provides information for the Internet community.},
  keywords="sip, intelligent network, call models, call model mapping, telephony services, public switched telephone network, pstn",
  doi="10.17487/RFC3976",
  }

@misc{rfc3977,
  author="C. Feather",
  title="{Network News Transfer Protocol (NNTP)}",
  howpublished="RFC 3977 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3977",
  pages="1--125",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6048",
url="https://www.rfc-editor.org/rfc/rfc3977.txt",
  key="RFC 3977",
  abstract={The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today.  This document is a replacement for RFC 977, and officially updates the protocol specification.  It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]},
  keywords="usenet, netnews",
  doi="10.17487/RFC3977",
  }

@misc{rfc3978,
  author="S. Bradner",
  title="{IETF Rights in Contributions}",
  howpublished="RFC 3978 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3978",
  pages="1--18",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5378, updated by RFC 4748",
url="https://www.rfc-editor.org/rfc/rfc3978.txt",
  key="RFC 3978",
  abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible.  This memo details the IETF policies on rights in Contributions to the IETF.  It also describes the objectives that the policies are designed to meet.  This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="intellectual property rights, copyright, ipr",
  doi="10.17487/RFC3978",
  }

@misc{rfc3979,
  author="S. Bradner",
  title="{Intellectual Property Rights in IETF Technology}",
  howpublished="RFC 3979 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="3979",
  pages="1--17",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4879",
url="https://www.rfc-editor.org/rfc/rfc3979.txt",
  key="RFC 3979",
  abstract={The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible.  The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders.  This memo details the IETF policies concerning IPR related to technology worked on within the IETF.  It also describes the objectives that the policies are designed to meet.  This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026.  This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipr, copyright",
  doi="10.17487/RFC3979",
  }

@misc{rfc3980,
  author="M. Krueger and M. Chadalapaka and R. Elliott",
  title="{T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names}",
  howpublished="RFC 3980 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3980",
  pages="1--8",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7143",
url="https://www.rfc-editor.org/rfc/rfc3980.txt",
  key="RFC 3980",
  abstract={Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP.  This document defines an additional iSCSI node name type format to enable use of the ``Network Address Authority'' (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS).  This document updates RFC 3720. [STANDARDS-TRACK]},
  keywords="internet small computer systems interface, scsi transport protocol",
  doi="10.17487/RFC3980",
  }

@misc{rfc3981,
  author="A. Newton and M. Sanz",
  title="{IRIS: The Internet Registry Information Service (IRIS) Core Protocol}",
  howpublished="RFC 3981 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3981",
  pages="1--52",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4992",
url="https://www.rfc-editor.org/rfc/rfc3981.txt",
  key="RFC 3981",
  abstract={This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries.  Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3981",
  }

@misc{rfc3982,
  author="A. Newton and M. Sanz",
  title="{IRIS:  A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)}",
  howpublished="RFC 3982 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3982",
  pages="1--50",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3982.txt",
  key="RFC 3982",
  abstract={This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information.  The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3982",
  }

@misc{rfc3983,
  author="A. Newton and M. Sanz",
  title="{Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 3983 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3983",
  pages="1--12",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3983.txt",
  key="RFC 3983",
  abstract={This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3983",
  }

@misc{rfc3984,
  author="S. Wenger and M.M. Hannuksela and T. Stockhammer and M. Westerlund and D. Singer",
  title="{RTP Payload Format for H.264 Video}",
  howpublished="RFC 3984 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3984",
  pages="1--83",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6184",
url="https://www.rfc-editor.org/rfc/rfc3984.txt",
  key="RFC 3984",
  abstract={This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec.  The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload.  The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]},
  keywords="ITU-T Recommendation H.264, ISO/IEC International Standard 14496-10",
  doi="10.17487/RFC3984",
  }

@misc{rfc3985,
  author="S. Bryant and P. Pate",
  title="{Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture}",
  howpublished="RFC 3985 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3985",
  pages="1--42",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc3985.txt",
  key="RFC 3985",
  abstract={This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3).  It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS.  It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3985",
  }

@misc{rfc3986,
  author="T. Berners-Lee and R. Fielding and L. Masinter",
  title="{Uniform Resource Identifier (URI): Generic Syntax}",
  howpublished="RFC 3986 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3986",
  pages="1--61",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6874, 7320",
url="https://www.rfc-editor.org/rfc/rfc3986.txt",
  key="RFC 3986",
  abstract={A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]},
  keywords="Internet, protocol, uniform, resource, identifier, www, world wide web",
  doi="10.17487/RFC3986",
  }

@misc{rfc3987,
  author="M. Duerst and M. Suignard",
  title="{Internationalized Resource Identifiers (IRIs)}",
  howpublished="RFC 3987 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3987",
  pages="1--46",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3987.txt",
  key="RFC 3987",
  abstract={This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.},
  keywords="uri, uniform resource identifier, Universal Character Set",
  doi="10.17487/RFC3987",
  }

@misc{rfc3988,
  author="B. Black and K. Kompella",
  title="{Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol}",
  howpublished="RFC 3988 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3988",
  pages="1--9",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3988.txt",
  key="RFC 3988",
  abstract={Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected.  As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR).  In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms.  This document specifies experimental extensions to LDP in support of LSP MTU discovery.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mtu, ldp, lsp, label switched path, label switching router, lsr",
  doi="10.17487/RFC3988",
  }

@misc{rfc3989,
  author="M. Stiemerling and J. Quittek and T. Taylor",
  title="{Middlebox Communications (MIDCOM) Protocol Semantics}",
  howpublished="RFC 3989 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3989",
  pages="1--70",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5189",
url="https://www.rfc-editor.org/rfc/rfc3989.txt",
  key="RFC 3989",
  abstract={This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs).  The semantics discussion does not include any specification of a concrete syntax or a transport protocol.  However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it.  The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions.  This memo provides information for the Internet community.},
  keywords="nat, network address translator, firewall",
  doi="10.17487/RFC3989",
  }

@misc{rfc3990,
  author="B. O'Hara and P. Calhoun and J. Kempf",
  title="{Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement}",
  howpublished="RFC 3990 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3990",
  pages="1--5",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3990.txt",
  key="RFC 3990",
  abstract={This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3990",
  }

@misc{rfc3991,
  author="B. Foster and F. Andreasen",
  title="{Media Gateway Control Protocol (MGCP) Redirect and Reset Package}",
  howpublished="RFC 3991 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3991",
  pages="1--11",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3991.txt",
  key="RFC 3991",
  abstract={The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time.  This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints.  It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order.  This memo provides information for the Internet community.},
  keywords="voice, IP, internet, VoIP",
  doi="10.17487/RFC3991",
  }

@misc{rfc3992,
  author="B. Foster and F. Andreasen",
  title="{Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism}",
  howpublished="RFC 3992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3992",
  pages="1--5",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3992.txt",
  key="RFC 3992",
  abstract={A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified.  The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures.  This memo provides information for the Internet community.},
  keywords="fault recovery",
  doi="10.17487/RFC3992",
  }

@misc{rfc3993,
  author="R. Johnson and T. Palaniappan and M. Stapp",
  title="{Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}",
  howpublished="RFC 3993 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3993",
  pages="1--7",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3993.txt",
  key="RFC 3993",
  abstract={This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option.  The suboption allows a DHCP relay agent to associate a stable ``Subscriber-ID'' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC3993",
  }

@misc{rfc3994,
  author="H. Schulzrinne",
  title="{Indication of Message Composition for Instant Messaging}",
  howpublished="RFC 3994 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3994",
  pages="1--13",
  year=2005,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3994.txt",
  key="RFC 3994",
  abstract={In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message.  This document defines a new status message content type and XML namespace that conveys information about a message being composed.  The status message can indicate the composition of a message of any type, including text, voice, or video.  The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]},
  keywords="im, status message content type, xml, extensible markup language",
  doi="10.17487/RFC3994",
  }

@misc{rfc3995,
  author="R. Herriot and T. Hastings",
  title="{Internet Printing Protocol (IPP): Event Notifications and Subscriptions}",
  howpublished="RFC 3995 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3995",
  pages="1--95",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3995.txt",
  key="RFC 3995",
  abstract={This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).  This extension allows a client to subscribe to printing related Events.  Subscriptions are modeled as Subscription Objects.  The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol).  A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information.  A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation.  Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS-TRACK]},
  keywords="optional, subscription events, subscription objects, asynchronous even notification",
  doi="10.17487/RFC3995",
  }

@misc{rfc3996,
  author="R. Herriot and T. Hastings and H. Lewis",
  title="{Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications}",
  howpublished="RFC 3996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3996",
  pages="1--31",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3996.txt",
  key="RFC 3996",
  abstract={This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910).  This document specifies the 'ippget' Pull Delivery Method for use with the ``Internet Printing Protocol (IPP): Event Notifications and Subscriptions'' specification (RFC 3995).  This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995.  The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]},
  keywords="pull delivery method, event notifications, event subscriptions",
  doi="10.17487/RFC3996",
  }

@misc{rfc3997,
  author="T. Hastings and R. K. deBry and H. Lewis",
  title="{Internet Printing Protocol (IPP): Requirements for IPP Notifications}",
  howpublished="RFC 3997 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3997",
  pages="1--17",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3997.txt",
  key="RFC 3997",
  abstract={This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP).  IPP is an application-level protocol that can be used for distributed printing on the Internet.  There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services.  This document provides a statement of the requirements for notifications as an optional part of an IPP Service.  This memo provides information for the Internet community.},
  keywords="model, directory services, notification requirements",
  doi="10.17487/RFC3997",
  }

@misc{rfc3998,
  author="C. Kugler and H. Lewis and T. Hastings",
  title="{Internet Printing Protocol (IPP): Job and Printer Administrative Operations}",
  howpublished="RFC 3998 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3998",
  pages="1--46",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3998.txt",
  key="RFC 3998",
  abstract={This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer.  Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]},
  keywords="system administration operations, Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer, Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After",
  doi="10.17487/RFC3998",
  }

@misc{rfc4001,
  author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder",
  title="{Textual Conventions for Internet Network Addresses}",
  howpublished="RFC 4001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4001",
  pages="1--22",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4001.txt",
  key="RFC 4001",
  abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information.  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="MIB, management information base, internet network layer addressing information",
  doi="10.17487/RFC4001",
  }

@misc{rfc4002,
  author="R. Brandner and L. Conroy and R. Stastny",
  title="{IANA Registration for Enumservice 'web' and 'ft'}",
  howpublished="RFC 4002 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4002",
  pages="1--10",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4002.txt",
  key="RFC 4002",
  abstract={This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]},
  keywords="URI schemes, uniform resource identifier, enum",
  doi="10.17487/RFC4002",
  }

@misc{rfc4003,
  author="L. Berger",
  title="{GMPLS Signaling Procedure for Egress Control}",
  howpublished="RFC 4003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4003",
  pages="1--5",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4003.txt",
  key="RFC 4003",
  abstract={This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP).  This control is also known as ``Egress Control''.  Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling.  This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]},
  keywords="lsp, label switch path, gmpls signaling",
  doi="10.17487/RFC4003",
  }

@misc{rfc4004,
  author="P. Calhoun and T. Johansson and C. Perkins and T. Hiller and P. McCann",
  title="{Diameter Mobile IPv4 Application}",
  howpublished="RFC 4004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4004",
  pages="1--53",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4004.txt",
  key="RFC 4004",
  abstract={This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node.  Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers.  Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]},
  keywords="internet protocol version 4, aaa, authentication, authorization, accounting, inter-realm, diameter accounting",
  doi="10.17487/RFC4004",
  }

@misc{rfc4005,
  author="P. Calhoun and G. Zorn and D. Spence and D. Mitton",
  title="{Diameter Network Access Server Application}",
  howpublished="RFC 4005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4005",
  pages="1--85",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7155",
url="https://www.rfc-editor.org/rfc/rfc4005.txt",
  key="RFC 4005",
  abstract={This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations. The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]},
  keywords="aaa, authentication, authorization, accounting, nas, diameter base, transport profile, extensible authentication protocol, radius",
  doi="10.17487/RFC4005",
  }

@misc{rfc4006,
  author="H. Hakala and L. Mattila and J-P. Koskinen and M. Stura and J. Loughney",
  title="{Diameter Credit-Control Application}",
  howpublished="RFC 4006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4006",
  pages="1--114",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4006.txt",
  key="RFC 4006",
  abstract={This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]},
  keywords="real-time credit-control",
  doi="10.17487/RFC4006",
  }

@misc{rfc4007,
  author="S. Deering and B. Haberman and T. Jinmei and E. Nordmark and B. Zill",
  title="{IPv6 Scoped Address Architecture}",
  howpublished="RFC 4007 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4007",
  pages="1--24",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7346",
url="https://www.rfc-editor.org/rfc/rfc4007.txt",
  key="RFC 4007",
  abstract={This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes.  According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]},
  keywords="architectural characteristics, expected behavior, textual representation",
  doi="10.17487/RFC4007",
  }

@misc{rfc4008,
  author="R. Rohit and P. Srisuresh and R. Raghunarayan and N. Pai and C. Wang",
  title="{Definitions of Managed Objects for Network Address Translators (NAT)}",
  howpublished="RFC 4008 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4008",
  pages="1--64",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7658",
url="https://www.rfc-editor.org/rfc/rfc4008.txt",
  key="RFC 4008",
  abstract={This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function.  This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]},
  keywords="mib, management information base",
  doi="10.17487/RFC4008",
  }

@misc{rfc4009,
  author="J. Park and S. Lee and J. Kim and J. Lee",
  title="{The SEED Encryption Algorithm}",
  howpublished="RFC 4009 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4009",
  pages="1--17",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4269",
url="https://www.rfc-editor.org/rfc/rfc4009.txt",
  key="RFC 4009",
  abstract={This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.  Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).  This memo provides information for the Internet community.},
  keywords="encryption algorithm, seed cbc, seed oid",
  doi="10.17487/RFC4009",
  }

@misc{rfc4010,
  author="J. Park and S. Lee and J. Kim and J. Lee",
  title="{Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 4010 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4010",
  pages="1--13",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4010.txt",
  key="RFC 4010",
  abstract={This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]},
  keywords="smime, secure/multipurpose internet mail extensions",
  doi="10.17487/RFC4010",
  }

@misc{rfc4011,
  author="S. Waldbusser and J. Saperia and T. Hongal",
  title="{Policy Based Management MIB}",
  howpublished="RFC 4011 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4011",
  pages="1--121",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4011.txt",
  key="RFC 4011",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]},
  keywords="management information base, Simple Network Management Protocol, snmp, infrastructures, scripting language, script execution environment",
  doi="10.17487/RFC4011",
  }

@misc{rfc4012,
  author="L. Blunk and J. Damas and F. Parent and A. Robachevsky",
  title="{Routing Policy Specification Language next generation (RPSLng)}",
  howpublished="RFC 4012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4012",
  pages="1--16",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7909",
url="https://www.rfc-editor.org/rfc/rfc4012.txt",
  key="RFC 4012",
  abstract={This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4012",
  }

@misc{rfc4013,
  author="K. Zeilenga",
  title="{SASLprep: Stringprep Profile for User Names and Passwords}",
  howpublished="RFC 4013 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4013",
  pages="1--6",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7613",
url="https://www.rfc-editor.org/rfc/rfc4013.txt",
  key="RFC 4013",
  abstract={This document describes how to prepare Unicode strings representing user names and passwords for comparison.  The document defines the ``SASLprep'' profile of the ``stringprep'' algorithm to be used for both user names and passwords.  This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]},
  keywords="unicode strings, saslprep, stringprep, sasl, simple authentication and security layer",
  doi="10.17487/RFC4013",
  }

@misc{rfc4014,
  author="R. Droms and J. Schnizlein",
  title="{Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option}",
  howpublished="RFC 4014 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4014",
  pages="1--8",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4014.txt",
  key="RFC 4014",
  abstract={The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server.  When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4014",
  }

@misc{rfc4015,
  author="R. Ludwig and A. Gurtov",
  title="{The Eifel Response Algorithm for TCP}",
  howpublished="RFC 4015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4015",
  pages="1--13",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4015.txt",
  key="RFC 4015",
  abstract={Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout.  It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent.  In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]},
  keywords="transmision control protocol",
  doi="10.17487/RFC4015",
  }

@misc{rfc4016,
  author="M. Parthasarathy",
  title="{Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements}",
  howpublished="RFC 4016 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4016",
  pages="1--15",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4016.txt",
  key="RFC 4016",
  abstract={This document discusses the threats to protocols used to carry authentication for network access.  The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.  This memo provides information for the Internet community.},
  keywords="authentication, network access",
  doi="10.17487/RFC4016",
  }

@misc{rfc4017,
  author="D. Stanley and J. Walker and B. Aboba",
  title="{Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs}",
  howpublished="RFC 4017 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4017",
  pages="1--11",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4017.txt",
  key="RFC 4017",
  abstract={The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP).  This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments.  The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes.  This memo provides information for the Internet community.},
  keywords="IEEE 802.11, wireless lan",
  doi="10.17487/RFC4017",
  }

@misc{rfc4018,
  author="M. Bakke and J. Hufferd and K. Voruganti and M. Krueger and T. Sperry",
  title="{Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)}",
  howpublished="RFC 4018 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4018",
  pages="1--23",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc4018.txt",
  key="RFC 4018",
  abstract={The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network.  This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]},
  keywords="scsi, slp",
  doi="10.17487/RFC4018",
  }

@misc{rfc4019,
  author="G. Pelletier",
  title="{RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite}",
  howpublished="RFC 4019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4019",
  pages="1--23",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4815",
url="https://www.rfc-editor.org/rfc/rfc4019.txt",
  key="RFC 4019",
  abstract={This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP.  These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]},
  keywords="rtp, udp-lite, ip, real-time transport protocol, user datagram protocol lite, internet protocol",
  doi="10.17487/RFC4019",
  }

@misc{rfc4020,
  author="K. Kompella and A. Zinin",
  title="{Early IANA Allocation of Standards Track Code Points}",
  howpublished="RFC 4020 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4020",
  pages="1--7",
  year=2005,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7120",
url="https://www.rfc-editor.org/rfc/rfc4020.txt",
  key="RFC 4020",
  abstract={This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the ``Standards Action'' IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4020",
  }

@misc{rfc4021,
  author="G. Klyne and J. Palme",
  title="{Registration of Mail and MIME Header Fields}",
  howpublished="RFC 4021 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4021",
  pages="1--54",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5322",
url="https://www.rfc-editor.org/rfc/rfc4021.txt",
  key="RFC 4021",
  abstract={This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]},
  keywords="IANA",
  doi="10.17487/RFC4021",
  }

@misc{rfc4022,
  author="R. Raghunarayan",
  title="{Management Information Base for the Transmission Control Protocol (TCP)}",
  howpublished="RFC 4022 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4022",
  pages="1--24",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4022.txt",
  key="RFC 4022",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner.  This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]},
  keywords="MIB-TCP, TCP, Simple Network Management Protocol, MIB",
  doi="10.17487/RFC4022",
  }

@misc{rfc4023,
  author="T. Worster and Y. Rekhter and E. Rosen",
  title="{Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)}",
  howpublished="RFC 4023 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4023",
  pages="1--14",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5332",
url="https://www.rfc-editor.org/rfc/rfc4023.txt",
  key="RFC 4023",
  abstract={Various applications of MPLS make use of label stacks with multiple entries.  In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers.  This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation).  Each of these is applicable in some circumstances. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4023",
  }

@misc{rfc4024,
  author="G. Parsons and J. Maruszak",
  title="{Voice Messaging Client Behaviour}",
  howpublished="RFC 4024 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4024",
  pages="1--9",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4024.txt",
  key="RFC 4024",
  abstract={This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message.  This memo provides information for the Internet community.},
  keywords="vpim, profile, internet mail, voice profile for internet mail, fax message",
  doi="10.17487/RFC4024",
  }

@misc{rfc4025,
  author="M. Richardson",
  title="{A Method for Storing IPsec Keying Material in DNS}",
  howpublished="RFC 4025 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4025",
  pages="1--12",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4025.txt",
  key="RFC 4025",
  abstract={This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. This record replaces the functionality of the sub-type \#4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4025",
  }

@misc{rfc4026,
  author="L. Andersson and T. Madsen",
  title="{Provider Provisioned Virtual Private Network (VPN) Terminology}",
  howpublished="RFC 4026 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4026",
  pages="1--20",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4026.txt",
  key="RFC 4026",
  abstract={The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.},
  keywords="l3vpn, l2vpn",
  doi="10.17487/RFC4026",
  }

@misc{rfc4027,
  author="S. Josefsson",
  title="{Domain Name System Media Types}",
  howpublished="RFC 4027 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4027",
  pages="1--6",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4027.txt",
  key="RFC 4027",
  abstract={This document registers the media types application/dns and text/dns in accordance with RFC 2048.  The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540.  The text/dns media type is used to identify master files as described in RFC 1035.  This memo provides information for the Internet community.},
  keywords="media type, application/dns, text/dns",
  doi="10.17487/RFC4027",
  }

@misc{rfc4028,
  author="S. Donovan and J. Rosenberg",
  title="{Session Timers in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4028 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4028",
  pages="1--27",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4028.txt",
  key="RFC 4028",
  abstract={This document defines an extension to the Session Initiation Protocol (SIP).  This extension allows for a periodic refresh of SIP sessions through a \\%re-INVITE or UPDATE request.  The refresh allows both user agents and proxies to determine whether the SIP session is still active.  The extension defines two new header fields: \\%Session-Expires, which conveys the lifetime of the session, and \\%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]},
  keywords="re-invite request, update request, session-expires, min-se",
  doi="10.17487/RFC4028",
  }

@misc{rfc4029,
  author="M. Lind and V. Ksinant and S. Park and A. Baudot and P. Savola",
  title="{Scenarios and Analysis for Introducing IPv6 into ISP Networks}",
  howpublished="RFC 4029 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4029",
  pages="1--28",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4029.txt",
  key="RFC 4029",
  abstract={This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service.  The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated.  Known challenges are also identified.  This memo provides information for the Internet community.},
  keywords="internet service provider, internet protocol",
  doi="10.17487/RFC4029",
  }

@misc{rfc4030,
  author="M. Stapp and T. Lemon",
  title="{The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}",
  howpublished="RFC 4030 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4030",
  pages="1--15",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4030.txt",
  key="RFC 4030",
  abstract={The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server.  This specification defines an authentication suboption for that option, containing a keyed hash in its payload.  The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4030",
  }

@misc{rfc4031,
  author="M. Carugi and D. McDysan",
  title="{Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)}",
  howpublished="RFC 4031 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4031",
  pages="1--50",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4031.txt",
  key="RFC 4031",
  abstract={This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs).  It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service.  This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services.  Toward this end, it first defines terminology and states general requirements.  Detailed requirements are expressed from a customer perspective as well as that of a service provider.  This memo provides information for the Internet community.},
  keywords="l3vpn, service provider, vpn",
  doi="10.17487/RFC4031",
  }

@misc{rfc4032,
  author="G. Camarillo and P. Kyzivat",
  title="{Update to the Session Initiation Protocol (SIP) Preconditions Framework}",
  howpublished="RFC 4032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4032",
  pages="1--10",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4032.txt",
  key="RFC 4032",
  abstract={This document updates RFC 3312, which defines the framework for preconditions in SIP.  We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]},
  keywords="qos, quality of service, precondition",
  doi="10.17487/RFC4032",
  }

@misc{rfc4033,
  author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose",
  title="{DNS Security Introduction and Requirements}",
  howpublished="RFC 4033 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4033",
  pages="1--21",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6014, 6840",
url="https://www.rfc-editor.org/rfc/rfc4033.txt",
  key="RFC 4033",
  abstract={The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]},
  keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions",
  doi="10.17487/RFC4033",
  }

@misc{rfc4034,
  author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose",
  title="{Resource Records for the DNS Security Extensions}",
  howpublished="RFC 4034 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4034",
  pages="1--29",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4470, 6014, 6840, 6944",
url="https://www.rfc-editor.org/rfc/rfc4034.txt",
  key="RFC 4034",
  abstract={This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]},
  keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions",
  doi="10.17487/RFC4034",
  }

@misc{rfc4035,
  author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose",
  title="{Protocol Modifications for the DNS Security Extensions}",
  howpublished="RFC 4035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4035",
  pages="1--53",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4470, 6014, 6840",
url="https://www.rfc-editor.org/rfc/rfc4035.txt",
  key="RFC 4035",
  abstract={This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]},
  keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions",
  doi="10.17487/RFC4035",
  }

@misc{rfc4036,
  author="W. Sawyer",
  title="{Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management}",
  howpublished="RFC 4036 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4036",
  pages="1--27",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4036.txt",
  key="RFC 4036",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems.  These managed objects facilitate protection of the cable network from misuse by subscribers.  The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]},
  keywords="mib, snmp, simple network management protocol",
  doi="10.17487/RFC4036",
  }

@misc{rfc4037,
  author="A. Rousskov",
  title="{Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core}",
  howpublished="RFC 4037 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4037",
  pages="1--56",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4037.txt",
  key="RFC 4037",
  abstract={This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP).  OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor.  OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation).  As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]},
  keywords="callout server",
  doi="10.17487/RFC4037",
  }

@misc{rfc4038,
  author="M-K. Shin and Y-G. Hong and J. Hagino and P. Savola and E. M. Castro",
  title="{Application Aspects of IPv6 Transition}",
  howpublished="RFC 4038 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4038",
  pages="1--33",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4038.txt",
  key="RFC 4038",
  abstract={As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications.  This document specifies scenarios and aspects of application transition.  It also proposes guidelines on how to develop IP version-independent applications during the transition period.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4038",
  }

@misc{rfc4039,
  author="S. Park and P. Kim and B. Volz",
  title="{Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)}",
  howpublished="RFC 4039 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4039",
  pages="1--10",
  year=2005,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4039.txt",
  key="RFC 4039",
  abstract={This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4039",
  }

@misc{rfc4040,
  author="R. Kreuter",
  title="{RTP Payload Format for a 64 kbit/s Transparent Call}",
  howpublished="RFC 4040 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4040",
  pages="1--8",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4040.txt",
  key="RFC 4040",
  abstract={This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called ``Clearmode''. It also serves as registration for a related MIME type called ``audio/clearmode''. ``Clearmode'' is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]},
  keywords="realtime transport protocol",
  doi="10.17487/RFC4040",
  }

@misc{rfc4041,
  author="A. Farrel",
  title="{Requirements for Morality Sections in Routing Area Drafts}",
  howpublished="RFC 4041 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4041",
  pages="1--8",
  year=2005,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4041.txt",
  key="RFC 4041",
  abstract={It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies a requirement for all new Routing Area Internet-Drafts to include a ``Morality Considerations'' section, and gives guidance on what that section should contain. This memo provides information for the Internet community.},
  keywords="moral values, moral code",
  doi="10.17487/RFC4041",
  }

@misc{rfc4042,
  author="M. Crispin",
  title="{UTF-9 and UTF-18 Efficient Transformation Formats of Unicode}",
  howpublished="RFC 4042 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4042",
  pages="1--9",
  year=2005,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4042.txt",
  key="RFC 4042",
  abstract={ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization. The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.},
  keywords="universal character set, ucs, codeopints, unicode, utf-7, utf-8, utf-16",
  doi="10.17487/RFC4042",
  }

@misc{rfc4043,
  author="D. Pinkas and T. Gindin",
  title="{Internet X.509 Public Key Infrastructure Permanent Identifier}",
  howpublished="RFC 4043 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4043",
  pages="1--15",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4043.txt",
  key="RFC 4043",
  abstract={This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]},
  keywords="subjectAltName extension, dn",
  doi="10.17487/RFC4043",
  }

@misc{rfc4044,
  author="K. McCloghrie",
  title="{Fibre Channel Management MIB}",
  howpublished="RFC 4044 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4044",
  pages="1--69",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4044.txt",
  key="RFC 4044",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]},
  keywords="management information base, fc-mgmt-mib",
  doi="10.17487/RFC4044",
  }

@misc{rfc4045,
  author="G. Bourdon",
  title="{Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)}",
  howpublished="RFC 4045 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4045",
  pages="1--28",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4045.txt",
  key="RFC 4045",
  abstract={The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets.  This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ppp, point-to-point protocol",
  doi="10.17487/RFC4045",
  }

@misc{rfc4046,
  author="M. Baugher and R. Canetti and L. Dondeti and F. Lindholm",
  title="{Multicast Security (MSEC) Group Key Management Architecture}",
  howpublished="RFC 4046 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4046",
  pages="1--38",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4046.txt",
  key="RFC 4046",
  abstract={This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols.  It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA.  The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs.  MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.  This memo provides information for the Internet community.},
  keywords="group security association, gsa",
  doi="10.17487/RFC4046",
  }

@misc{rfc4047,
  author="S. Allen and D. Wells",
  title="{MIME Sub-type Registrations for Flexible Image Transport System (FITS)}",
  howpublished="RFC 4047 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4047",
  pages="1--23",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4047.txt",
  key="RFC 4047",
  abstract={This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files.  The encoding is defined by the published FITS standard documents.  The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS.  This memo provides information for the Internet community.},
  keywords="multipurpose internet mail extensions, astronomical observations",
  doi="10.17487/RFC4047",
  }

@misc{rfc4048,
  author="B. Carpenter",
  title="{RFC 1888 Is Obsolete}",
  howpublished="RFC 4048 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4048",
  pages="1--4",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4548",
url="https://www.rfc-editor.org/rfc/rfc4048.txt",
  key="RFC 4048",
  abstract={This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty.  This memo provides information for the Internet community.},
  keywords="Internet, Protocol, Open, Systems, Interconnection",
  doi="10.17487/RFC4048",
  }

@misc{rfc4049,
  author="R. Housley",
  title="{BinaryTime: An Alternate Format for Representing Date and Time in ASN.1}",
  howpublished="RFC 4049 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4049",
  pages="1--7",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6019",
url="https://www.rfc-editor.org/rfc/rfc4049.txt",
  key="RFC 4049",
  abstract={This document specifies a new ASN.1 type for representing time: BinaryTime.  This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime.  CMS and the signing-time attribute are defined in RFC 3852.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="signing-time attribute, cryptographic message syntax, cms, SignedData, AuthenticatedData",
  doi="10.17487/RFC4049",
  }

@misc{rfc4050,
  author="S. Blake-Wilson and G. Karlinger and T. Kobayashi and Y. Wang",
  title="{Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures}",
  howpublished="RFC 4050 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4050",
  pages="1--19",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4050.txt",
  key="RFC 4050",
  abstract={This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures.  The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference.  This memo provides information for the Internet community.},
  keywords="elliptic curve digital signature algorithm, ecdsa, elliptic curve cryptography, ecc, xml, digital signatures, xml dsig, xml",
  doi="10.17487/RFC4050",
  }

@misc{rfc4051,
  author="D. {Eastlake 3rd}",
  title="{Additional XML Security Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 4051 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4051",
  pages="1--17",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6931",
url="https://www.rfc-editor.org/rfc/rfc4051.txt",
  key="RFC 4051",
  abstract={A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined.  These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]},
  keywords="digital signatures, encryption, canonicalization",
  doi="10.17487/RFC4051",
  }

@misc{rfc4052,
  author="L. Daigle and Internet Architecture Board",
  title="{IAB Processes for Management of IETF Liaison Relationships}",
  howpublished="RFC 4052 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4052",
  pages="1--9",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4052.txt",
  key="RFC 4052",
  abstract={This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora.  This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet architecture board, sdo, standards development organization",
  doi="10.17487/RFC4052",
  }

@misc{rfc4053,
  author="S. Trowbridge and S. Bradner and F. Baker",
  title="{Procedures for Handling Liaison Statements to and from the IETF}",
  howpublished="RFC 4053 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4053",
  pages="1--19",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4053.txt",
  key="RFC 4053",
  abstract={This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="sdo, standards develoopment organization",
  doi="10.17487/RFC4053",
  }

@misc{rfc4054,
  author="J. Strand and  A. Chiu",
  title="{Impairments and Other Constraints on Optical Layer Routing}",
  howpublished="RFC 4054 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4054",
  pages="1--29",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4054.txt",
  key="RFC 4054",
  abstract={Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS).  Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network.  This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints.  This memo provides information for the Internet community.},
  keywords="diversity, routing, path selection, impariment, ase, pmd, optical control plane, gmpls",
  doi="10.17487/RFC4054",
  }

@misc{rfc4055,
  author="J. Schaad and B. Kaliski and R. Housley",
  title="{Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 4055 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4055",
  pages="1--25",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5756",
url="https://www.rfc-editor.org/rfc/rfc4055.txt",
  key="RFC 4055",
  abstract={This document supplements RFC 3279.  It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) \#1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]},
  keywords="ASN.1, RSASSA-PSS, RSA probabilistic signature scheme, signature algorithm, RSAES-OAEP, RSA encryption scheme optimal asymmetric encryption padding, public-key cryptography standards, PKCS, pki",
  doi="10.17487/RFC4055",
  }

@misc{rfc4056,
  author="J. Schaad",
  title="{Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 4056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4056",
  pages="1--6",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4056.txt",
  key="RFC 4056",
  abstract={This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]},
  keywords="RSA probabilistic signature scheme, digital signature",
  doi="10.17487/RFC4056",
  }

@misc{rfc4057,
  author="J. Bound",
  title="{IPv6 Enterprise Network Scenarios}",
  howpublished="RFC 4057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4057",
  pages="1--17",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4057.txt",
  key="RFC 4057",
  abstract={This document describes the scenarios for IPv6 deployment within enterprise networks.  It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.  Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.  The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment.  The results of that analysis will be published in a separate document.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6",
  doi="10.17487/RFC4057",
  }

@misc{rfc4058,
  author="A. Yegin and Y. Ohba and R. Penno and G. Tsirtsis and C. Wang",
  title="{Protocol for Carrying Authentication for Network Access (PANA) Requirements}",
  howpublished="RFC 4058 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4058",
  pages="1--19",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4058.txt",
  key="RFC 4058",
  abstract={It is expected that future IP devices will have a variety of access technologies to gain network connectivity.  Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes.  In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links).  The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access.  This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.  This memo provides information for the Internet community.},
  keywords="network connectivity, link layer agnostic protocol",
  doi="10.17487/RFC4058",
  }

@misc{rfc4059,
  author="D. Linsenbardt and S. Pontius and A. Sturgeon",
  title="{Internet X.509 Public Key Infrastructure Warranty Certificate Extension}",
  howpublished="RFC 4059 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4059",
  pages="1--9",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4059.txt",
  key="RFC 4059",
  abstract={This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension.  This memo provides information for the Internet community.},
  keywords="certificate authority, ca, insurance policy",
  doi="10.17487/RFC4059",
  }

@misc{rfc4060,
  author="Q. Xie and D. Pearce",
  title="{RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding}",
  howpublished="RFC 4060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4060",
  pages="1--19",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4060.txt",
  key="RFC 4060",
  abstract={This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, dsr, distributed speeech recognition, xfe, extended front-end, xafe, extended advanced front-end",
  doi="10.17487/RFC4060",
  }

@misc{rfc4061,
  author="V. Manral and R. White and A. Shaikh",
  title="{Benchmarking Basic OSPF Single Router Control Plane Convergence}",
  howpublished="RFC 4061 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4061",
  pages="1--16",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4061.txt",
  key="RFC 4061",
  abstract={This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance. NOTE: In this document, the word ``convergence'' relates to single router control plane convergence only. This memo provides information for the Internet community.},
  keywords="spf time, adjacency formation time",
  doi="10.17487/RFC4061",
  }

@misc{rfc4062,
  author="V. Manral and R. White and A. Shaikh",
  title="{OSPF Benchmarking Terminology and Concepts}",
  howpublished="RFC 4062 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4062",
  pages="1--9",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4062.txt",
  key="RFC 4062",
  abstract={This document explains the terminology and concepts used in OSPF benchmarking.  Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol.  This memo provides information for the Internet community.},
  keywords="spf time, adjacency formation time",
  doi="10.17487/RFC4062",
  }

@misc{rfc4063,
  author="V. Manral and R. White and A. Shaikh",
  title="{Considerations When Using Basic OSPF Convergence Benchmarks}",
  howpublished="RFC 4063 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4063",
  pages="1--11",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4063.txt",
  key="RFC 4063",
  abstract={This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol.  There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested.  This memo provides information for the Internet community.},
  keywords="spf time, adjacency formation time",
  doi="10.17487/RFC4063",
  }

@misc{rfc4064,
  author="A. Patel and K. Leung",
  title="{Experimental Message, Extensions, and Error Codes for Mobile IPv4}",
  howpublished="RFC 4064 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4064",
  pages="1--11",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4064.txt",
  key="RFC 4064",
  abstract={Mobile IPv4 message types range from 0 to 255.  This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]},
  keywords="internet protocol, message types",
  doi="10.17487/RFC4064",
  }

@misc{rfc4065,
  author="J. Kempf",
  title="{Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations}",
  howpublished="RFC 4065 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4065",
  pages="1--8",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4065.txt",
  key="RFC 4065",
  abstract={The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers.  These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.  This document contains instructions to IANA about which allocations are required for the Seamoby protocols.  The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="candidate access router discovery, card, context transfer protocol, CXTP, ICMP",
  doi="10.17487/RFC4065",
  }

@misc{rfc4066,
  author="M. Liebsch and A. Singh and H. Chaskar and D. Funato and E. Shim",
  title="{Candidate Access Router Discovery (CARD)}",
  howpublished="RFC 4066 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4066",
  pages="1--46",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4066.txt",
  key="RFC 4066",
  abstract={To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover.  The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities.  This process is called ``candidate access router discovery'' (CARD).  At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover.  The protocol described in this document allows a mobile node to perform CARD.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mobile node, mn, cars, candidate ars",
  doi="10.17487/RFC4066",
  }

@misc{rfc4067,
  author="J. Loughney and M. Nakhjiri and C. Perkins and R. Koodli",
  title="{Context Transfer Protocol (CXTP)}",
  howpublished="RFC 4067 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4067",
  pages="1--33",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4067.txt",
  key="RFC 4067",
  abstract={This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers.  Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption.  Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mobile node, mn",
  doi="10.17487/RFC4067",
  }

@misc{rfc4068,
  author="R. Koodli",
  title="{Fast Handovers for Mobile IPv6}",
  howpublished="RFC 4068 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4068",
  pages="1--42",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5268",
url="https://www.rfc-editor.org/rfc/rfc4068.txt",
  key="RFC 4068",
  abstract={Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover.  During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations.  This ``handover latency'' resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP.  Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well.  This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures.  This document does not address improving the link switching latency.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="internet protocol version 6, access router, mobile node, mn",
  doi="10.17487/RFC4068",
  }

@misc{rfc4069,
  author="M. Dodge and B. Ray",
  title="{Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding}",
  howpublished="RFC 4069 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4069",
  pages="1--19",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4069.txt",
  key="RFC 4069",
  abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding.  It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]},
  keywords="mib, management information base, VDSL-LINE-MIB, VDSL-LINE-EXT-SCM-MIB",
  doi="10.17487/RFC4069",
  }

@misc{rfc4070,
  author="M. Dodge and B. Ray",
  title="{Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding}",
  howpublished="RFC 4070 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4070",
  pages="1--24",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4070.txt",
  key="RFC 4070",
  abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding.  It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]},
  keywords="management information base, mib, VDSL-LINE-MIB, VDSL-LINE-EXT-MCM-MIB",
  doi="10.17487/RFC4070",
  }

@misc{rfc4071,
  author="R. Austein and B. Wijnen",
  title="{Structure of the IETF Administrative Support Activity (IASA)}",
  howpublished="RFC 4071 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4071",
  pages="1--20",
  year=2005,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4371, 7691",
url="https://www.rfc-editor.org/rfc/rfc4071.txt",
  key="RFC 4071",
  abstract={This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC).  It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process.  It also defines the membership and selection rules for the IAOC.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="isoc, ietf administrative oversight committee, IAOC, ietf administrative director, iad",
  doi="10.17487/RFC4071",
  }

@misc{rfc4072,
  author="P. Eronen and T. Hiller and G. Zorn",
  title="{Diameter Extensible Authentication Protocol (EAP) Application}",
  howpublished="RFC 4072 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4072",
  pages="1--33",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7268, 8044",
url="https://www.rfc-editor.org/rfc/rfc4072.txt",
  key="RFC 4072",
  abstract={The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods.  This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]},
  keywords="command codes, avp, nas, network access server, back-end autentication server",
  doi="10.17487/RFC4072",
  }

@misc{rfc4073,
  author="R. Housley",
  title="{Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 4073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4073",
  pages="1--9",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4073.txt",
  key="RFC 4073",
  abstract={This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection.  If desired, attributes can be associated with the content. [STANDARDS-TRACK]},
  keywords="content collection",
  doi="10.17487/RFC4073",
  }

@misc{rfc4074,
  author="Y. Morishita and T. Jinmei",
  title="{Common Misbehavior Against DNS Queries for IPv6 Addresses}",
  howpublished="RFC 4074 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4074",
  pages="1--6",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4074.txt",
  key="RFC 4074",
  abstract={There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records.  Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack.  This memo describes details of known cases and discusses their effects.  This memo provides information for the Internet community.},
  keywords="resource records, aaaa, domain name service",
  doi="10.17487/RFC4074",
  }

@misc{rfc4075,
  author="V. Kalusivalingam",
  title="{Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6}",
  howpublished="RFC 4075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4075",
  pages="1--5",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4075.txt",
  key="RFC 4075",
  abstract={This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol, server addresses",
  doi="10.17487/RFC4075",
  }

@misc{rfc4076,
  author="T. Chown and S. Venaas and A. Vijayabhaskar",
  title="{Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 4076 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4076",
  pages="1--8",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4076.txt",
  key="RFC 4076",
  abstract={IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically.  However, further settings are not available.  If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used.  This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.  However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering.  This document is presented as a problem statement from which a solution should be proposed in a subsequent document.  This memo provides information for the Internet community.},
  keywords="internet protocol, stateless address autoconfiguration",
  doi="10.17487/RFC4076",
  }

@misc{rfc4077,
  author="A.B. Roach",
  title="{A Negative Acknowledgement Mechanism for Signaling Compression}",
  howpublished="RFC 4077 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4077",
  pages="1--16",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4077.txt",
  key="RFC 4077",
  abstract={This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed.  This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]},
  keywords="sigcomp, negative feedback",
  doi="10.17487/RFC4077",
  }

@misc{rfc4078,
  author="N. Earnshaw and S. Aoki and A. Ashley and W. Kameyama",
  title="{The TV-Anytime Content Reference Identifier (CRID)}",
  howpublished="RFC 4078 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4078",
  pages="1--10",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4078.txt",
  key="RFC 4078",
  abstract={The Uniform Resource Locator (URL) scheme ``CRID:'' has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet. The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition. This document reproduces the \\%TV-Anytime CRID definition found in the \\%TV-Anytime content referencing specification, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.},
  keywords="digital broadcasting, tv, radio, uri, uniform resource identifier, content referencing, storage systems",
  doi="10.17487/RFC4078",
  }

@misc{rfc4079,
  author="J. Peterson",
  title="{A Presence Architecture for the Distribution of GEOPRIV Location Objects}",
  howpublished="RFC 4079 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4079",
  pages="1--7",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4079.txt",
  key="RFC 4079",
  abstract={GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects.  GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications.  This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV.  This memo provides information for the Internet community.},
  keywords="using protocol",
  doi="10.17487/RFC4079",
  }

@misc{rfc4080,
  author="R. Hancock and G. Karagiannis and J. Loughney and S. Van den Bosch",
  title="{Next Steps in Signaling (NSIS): Framework}",
  howpublished="RFC 4080 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4080",
  pages="1--49",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4080.txt",
  key="RFC 4080",
  abstract={The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols. This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.},
  keywords="data flow, architectural framework, signaling protocols, signaling application",
  doi="10.17487/RFC4080",
  }

@misc{rfc4081,
  author="H. Tschofenig and D. Kroeselberg",
  title="{Security Threats for Next Steps in Signaling (NSIS)}",
  howpublished="RFC 4081 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4081",
  pages="1--28",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4081.txt",
  key="RFC 4081",
  abstract={This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite.  It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals.  This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4081",
  }

@misc{rfc4082,
  author="A. Perrig and D. Song and R. Canetti and J. D. Tygar and B. Briscoe",
  title="{Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction}",
  howpublished="RFC 4082 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4082",
  pages="1--22",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4082.txt",
  key="RFC 4082",
  abstract={This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties. This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.},
  keywords="data streams",
  doi="10.17487/RFC4082",
  }

@misc{rfc4083,
  author="M. Garcia-Martin",
  title="{Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4083 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4083",
  pages="1--36",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4083.txt",
  key="RFC 4083",
  abstract={The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS).  IMS is part of Release 5 of the 3GPP specifications.  Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network.  In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.  This memo provides information for the Internet community.},
  keywords="3GPP IP multimedia core network subsystem, ims, cellular networks",
  doi="10.17487/RFC4083",
  }

@misc{rfc4084,
  author="J. Klensin",
  title="{Terminology for Describing Internet Connectivity}",
  howpublished="RFC 4084 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4084",
  pages="1--11",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4084.txt",
  key="RFC 4084",
  abstract={As the Internet has evolved, many types of arrangements have been advertised and sold as ``Internet connectivity''.  Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion.  This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4084",
  }

@misc{rfc4085,
  author="D. Plonka",
  title="{Embedding Globally-Routable Internet Addresses Considered Harmful}",
  howpublished="RFC 4085 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4085",
  pages="1--10",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4085.txt",
  key="RFC 4085",
  abstract={This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives.  This document is intended to clarify best current practices in this regard.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4085",
  }

@misc{rfc4086,
  author="D. {Eastlake 3rd} and J. Schiller and S. Crocker",
  title="{Randomness Requirements for Security}",
  howpublished="RFC 4086 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4086",
  pages="1--48",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4086.txt",
  key="RFC 4086",
  abstract={Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="cryptographic algorithms, passwords, cryptographic keys, pseudo-random, random, numbers, seed",
  doi="10.17487/RFC4086",
  }

@misc{rfc4087,
  author="D. Thaler",
  title="{IP Tunnel MIB}",
  howpublished="RFC 4087 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4087",
  pages="1--25",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4087.txt",
  key="RFC 4087",
  abstract={This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks.  Extension MIB modules may be designed for managing protocol-specific objects.  Likewise, extension MIB modules may be designed for managing security-specific objects.  This MIB module does not support tunnels over non-IP networks.  Management of such tunnels may be supported by other MIB modules.  This memo obsoletes RFC 2667. [STANDARDS-TRACK]},
  keywords="management information base, internet protocol, tunnel-mib",
  doi="10.17487/RFC4087",
  }

@misc{rfc4088,
  author="D. Black and K. McCloghrie and J. Schoenwaelder",
  title="{Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 4088 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4088",
  pages="1--18",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4088.txt",
  key="RFC 4088",
  abstract={The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols. This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]},
  keywords="uri, uniform resource identifiers, snmp-uri",
  doi="10.17487/RFC4088",
  }

@misc{rfc4089,
  author="S. Hollenbeck and IAB and IESG",
  title="{IAB and IESG Recommendation for IETF Administrative Restructuring}",
  howpublished="RFC 4089 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4089",
  pages="1--55",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4089.txt",
  key="RFC 4089",
  abstract={This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.  The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004.  Further work has been done to revise and refine the structures proposed.  The recommendation is being published for the record.  This memo provides information for the Internet community.},
  keywords="internet architecture board, internet engineering steering group, internet engineering task force",
  doi="10.17487/RFC4089",
  }

@misc{rfc4090,
  author="P. Pan and G. Swallow and A. Atlas",
  title="{Fast Reroute Extensions to RSVP-TE for LSP Tunnels}",
  howpublished="RFC 4090 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4090",
  pages="1--38",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4090.txt",
  key="RFC 4090",
  abstract={This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]},
  keywords="resource reservation protocol, traffic engineering, lsp, label switch path, one-to-one backup, facility backup",
  doi="10.17487/RFC4090",
  }

@misc{rfc4091,
  author="G. Camarillo and J. Rosenberg",
  title="{The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework}",
  howpublished="RFC 4091 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4091",
  pages="1--7",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5245",
url="https://www.rfc-editor.org/rfc/rfc4091.txt",
  key="RFC 4091",
  abstract={This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework.  The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4091",
  }

@misc{rfc4092,
  author="G. Camarillo and J. Rosenberg",
  title="{Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4092 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4092",
  pages="1--6",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5245",
url="https://www.rfc-editor.org/rfc/rfc4092.txt",
  key="RFC 4092",
  abstract={This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP.  In particular, we define the sdp-anat SIP option-tag.  This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support.  To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]},
  keywords="sdp-anat, option-tag",
  doi="10.17487/RFC4092",
  }

@misc{rfc4093,
  author="F. Adrangi and H. Levkowetz",
  title="{Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways}",
  howpublished="RFC 4093 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4093",
  pages="1--19",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4093.txt",
  key="RFC 4093",
  abstract={Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions.  This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4093",
  }

@misc{rfc4094,
  author="J. Manner and X. Fu",
  title="{Analysis of Existing Quality-of-Service Signaling Protocols}",
  howpublished="RFC 4094 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4094",
  pages="1--45",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4094.txt",
  key="RFC 4094",
  abstract={This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network.  The goal here is to learn from them and to avoid common misconceptions.  Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.  This memo provides information for the Internet community.},
  keywords="qos, quality of service, rsvp, nsis, yessir, boomerang, daris, insignia, bgrp, sicap, mobility, performance, security",
  doi="10.17487/RFC4094",
  }

@misc{rfc4095,
  author="C. Malamud",
  title="{Attaching Meaning to Solicitation Class Keywords}",
  howpublished="RFC 4095 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4095",
  pages="1--11",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4095.txt",
  key="RFC 4095",
  abstract={This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as ``org.example.adv''. These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \\%``No-Solicit:'' header, which can contain one or more solicitation class keywords inserted by the sender. This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the ``example.org'' domain could use this mechanism to create a URI which contains detailed information about the ``org.example.adv'' solicitation class keyword. [STANDARDS-TRACK]},
  keywords="uri, uniform resource identifier, no soliciting smtp service extension, esmtp service extension, dynamic delegation discovery system, ddds, no-solicit",
  doi="10.17487/RFC4095",
  }

@misc{rfc4096,
  author="C. Malamud",
  title="{Policy-Mandated Labels Such as ``Adv:'' in Email Subject Headers Considered Ineffective At Best}",
  howpublished="RFC 4096 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4096",
  pages="1--14",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4096.txt",
  key="RFC 4096",
  abstract={This memo discusses policies that require certain labels to be inserted in the ``Subject:'' header of a mail message.  Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best.  This memo discusses an alternate, \\%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4096",
  }

@misc{rfc4097,
  author="M. Barnes",
  title="{Middlebox Communications (MIDCOM) Protocol Evaluation}",
  howpublished="RFC 4097 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4097",
  pages="1--44",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4097.txt",
  key="RFC 4097",
  abstract={This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol.  A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided.  Compliancy of each of the protocols against each requirement is detailed.  A conclusion summarizes how each of the protocols fares in the evaluation.  This memo provides information for the Internet community.},
  keywords="snmp, simple network management protocol, rsip, realm specific internet protocol, megaco, diameter, cops, common open policy service",
  doi="10.17487/RFC4097",
  }

@misc{rfc4098,
  author="H. Berkowitz and E. Davies and S. Hares and P. Krishnaswamy and M. Lepp",
  title="{Terminology for Benchmarking BGP Device Convergence in the Control Plane}",
  howpublished="RFC 4098 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4098",
  pages="1--36",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4098.txt",
  key="RFC 4098",
  abstract={This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device.  Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6.  Illustrative examples of each version are included where relevant.  This memo provides information for the Internet community.},
  keywords="border gateway protocol, benchmarking methodology, ebgp",
  doi="10.17487/RFC4098",
  }

@misc{rfc4101,
  author="E. Rescorla and IAB",
  title="{Writing Protocol Models}",
  howpublished="RFC 4101 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4101",
  pages="1--22",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4101.txt",
  key="RFC 4101",
  abstract={The IETF process depends on peer review.  However, IETF documents are generally written to be useful for implementors, not reviewers.  In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding.  This document describes an approach for providing protocol ``models'' that allow reviewers to quickly grasp the essence of a system.  This memo provides information for the Internet community.},
  keywords="document review",
  doi="10.17487/RFC4101",
  }

@misc{rfc4102,
  author="P. Jones",
  title="{Registration of the text/red MIME Sub-Type}",
  howpublished="RFC 4102 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4102",
  pages="1--6",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6354",
url="https://www.rfc-editor.org/rfc/rfc4102.txt",
  key="RFC 4102",
  abstract={This document defines the text/red MIME sub-type. ``Red'' is short for redundant.  The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]},
  keywords="rtp, real-time transport protocol",
  doi="10.17487/RFC4102",
  }

@misc{rfc4103,
  author="G. Hellstrom and P. Jones",
  title="{RTP Payload for Text Conversation}",
  howpublished="RFC 4103 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4103",
  pages="1--20",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4103.txt",
  key="RFC 4103",
  abstract={This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]},
  keywords="real-time, applications, video, audio, packets",
  doi="10.17487/RFC4103",
  }

@misc{rfc4104,
  author="M. Pana and A. Reyes and A. Barba and D. Moron and M. Brunner",
  title="{Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)}",
  howpublished="RFC 4104 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4104",
  pages="1--88",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4104.txt",
  key="RFC 4104",
  abstract={This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460).  These changes and extensions consist of new LDAP object classes and attribute types.  Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460.  The other schema items implement new concepts, not covered by RFC 3703.  This document updates RFC 3703. [STANDARDS-TRACK]},
  keywords="policy core lightweight directory access protocol, pcim, policy core information model, mapping classes",
  doi="10.17487/RFC4104",
  }

@misc{rfc4105,
  author="J.-L. Le Roux and J.-P. Vasseur and J. Boyle",
  title="{Requirements for Inter-Area MPLS Traffic Engineering}",
  howpublished="RFC 4105 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4105",
  pages="1--22",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4105.txt",
  key="RFC 4105",
  abstract={This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).  It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.  This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, mpls-te, mpls te",
  doi="10.17487/RFC4105",
  }

@misc{rfc4106,
  author="J. Viega and D. McGrew",
  title="{The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)}",
  howpublished="RFC 4106 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4106",
  pages="1--11",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4106.txt",
  key="RFC 4106",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication.  This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]},
  keywords="aes, advanced encryption standard",
  doi="10.17487/RFC4106",
  }

@misc{rfc4107,
  author="S. Bellovin and R. Housley",
  title="{Guidelines for Cryptographic Key Management}",
  howpublished="RFC 4107 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4107",
  pages="1--7",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4107.txt",
  key="RFC 4107",
  abstract={The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient.  This memo provides guidelines for making such decisions.  When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed.  If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="automated key management, manual key management",
  doi="10.17487/RFC4107",
  }

@misc{rfc4108,
  author="R. Housley",
  title="{Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages}",
  howpublished="RFC 4108 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4108",
  pages="1--61",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4108.txt",
  key="RFC 4108",
  abstract={This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components.  CMS is specified in RFC 3852.  A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication.  Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package.  A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package.  Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]},
  keywords="hardward module components, digital signature",
  doi="10.17487/RFC4108",
  }

@misc{rfc4109,
  author="P. Hoffman",
  title="{Algorithms for Internet Key Exchange version 1 (IKEv1)}",
  howpublished="RFC 4109 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4109",
  pages="1--5",
  year=2005,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4109.txt",
  key="RFC 4109",
  abstract={The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements.  The original specification allows weak security and suggests algorithms that are thinly implemented.  This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]},
  keywords="ike, ipsec, oakley, authentication, isakmp, internet security key management",
  doi="10.17487/RFC4109",
  }

@misc{rfc4110,
  author="R. Callon and M. Suzuki",
  title="{A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)}",
  howpublished="RFC 4110 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4110",
  pages="1--82",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4110.txt",
  key="RFC 4110",
  abstract={This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs).  This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs.  It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions.  Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4110",
  }

@misc{rfc4111,
  author="L. Fang",
  title="{Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)}",
  howpublished="RFC 4111 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4111",
  pages="1--45",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4111.txt",
  key="RFC 4111",
  abstract={This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs).  First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats.  It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers.  It also describes how these security attacks should be detected and reported.  It then discusses possible user requirements for security of a PPVPN service.  These user requirements translate into corresponding provider requirements.  In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations.  Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4111",
  }

@misc{rfc4112,
  author="D. {Eastlake 3rd}",
  title="{Electronic Commerce Modeling Language (ECML) Version 2 Specification}",
  howpublished="RFC 4112 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4112",
  pages="1--34",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4112.txt",
  key="RFC 4112",
  abstract={Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate.  A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated.  This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4112",
  }

@misc{rfc4113,
  author="B. Fenner and J. Flick",
  title="{Management Information Base for the User Datagram Protocol (UDP)}",
  howpublished="RFC 4113 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4113",
  pages="1--19",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4113.txt",
  key="RFC 4113",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner.  This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]},
  keywords="MIB-UDP, mib, UDP-MIB, internet protocol, ip",
  doi="10.17487/RFC4113",
  }

@misc{rfc4114,
  author="S. Hollenbeck",
  title="{E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 4114 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4114",
  pages="1--17",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4114.txt",
  key="RFC 4114",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]},
  keywords="shared central repository",
  doi="10.17487/RFC4114",
  }

@misc{rfc4115,
  author="O. Aboul-Magd and S. Rabie",
  title="{A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic}",
  howpublished="RFC 4115 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4115",
  pages="1--6",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4115.txt",
  key="RFC 4115",
  abstract={This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services.  This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services.  The marker defined here is different from previously defined markers in the handling of the in-profile traffic.  Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.  This memo provides information for the Internet community.},
  keywords="data services, service scenarios, metering algorithm, color-blind, color-aware",
  doi="10.17487/RFC4115",
  }

@misc{rfc4116,
  author="J. Abley and K. Lindqvist and E. Davies and B. Black and V. Gill",
  title="{IPv4 Multihoming Practices and Limitations}",
  howpublished="RFC 4116 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4116",
  pages="1--13",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4116.txt",
  key="RFC 4116",
  abstract={Multihoming is an essential component of service for many Internet sites.  This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).  This memo provides information for the Internet community.},
  keywords="internet protocol",
  doi="10.17487/RFC4116",
  }

@misc{rfc4117,
  author="G. Camarillo and E. Burger and H. Schulzrinne and A. van Wijk",
  title="{Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)}",
  howpublished="RFC 4117 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4117",
  pages="1--19",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4117.txt",
  key="RFC 4117",
  abstract={This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control.  This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.  This memo provides information for the Internet community.},
  keywords="deaf, hard of hearing, speech-impaired, hearing-impaired",
  doi="10.17487/RFC4117",
  }

@misc{rfc4118,
  author="L. Yang and P. Zerfos and E. Sadot",
  title="{Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)}",
  howpublished="RFC 4118 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4118",
  pages="1--41",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4118.txt",
  key="RFC 4118",
  abstract={This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.  This memo provides information for the Internet community.},
  keywords="IEEE 802.11, wireless lan",
  doi="10.17487/RFC4118",
  }

@misc{rfc4119,
  author="J. Peterson",
  title="{A Presence-based GEOPRIV Location Object Format}",
  howpublished="RFC 4119 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4119",
  pages="1--24",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5139, 5491, 7459",
url="https://www.rfc-editor.org/rfc/rfc4119.txt",
  key="RFC 4119",
  abstract={This document describes an object format for carrying geographical information on the Internet.  This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]},
  keywords="pidf, presence information data format",
  doi="10.17487/RFC4119",
  }

@misc{rfc4120,
  author="C. Neuman and T. Yu and S. Hartman and K. Raeburn",
  title="{The Kerberos Network Authentication Service (V5)}",
  howpublished="RFC 4120 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4120",
  pages="1--138",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4537, 5021, 5896, 6111, 6112, 6113, 6649, 6806, 7751, 8062, 8129",
url="https://www.rfc-editor.org/rfc/rfc4120.txt",
  key="RFC 4120",
  abstract={This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510.  This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]},
  keywords="KERBEROS, CAT,Security",
  doi="10.17487/RFC4120",
  }

@misc{rfc4121,
  author="L. Zhu and K. Jaganathan and S. Hartman",
  title="{The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2}",
  howpublished="RFC 4121 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4121",
  pages="1--20",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6112, 6542, 6649, 8062",
url="https://www.rfc-editor.org/rfc/rfc4121.txt",
  key="RFC 4121",
  abstract={This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism. RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]},
  keywords="GSSAPI-KER, cryptosystem",
  doi="10.17487/RFC4121",
  }

@misc{rfc4122,
  author="P. Leach and M. Mealling and R. Salz",
  title="{A Universally Unique IDentifier (UUID) URN Namespace}",
  howpublished="RFC 4122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4122",
  pages="1--32",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4122.txt",
  key="RFC 4122",
  abstract={This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]},
  keywords="uniform resource name, guid, globally unique identifier",
  doi="10.17487/RFC4122",
  }

@misc{rfc4123,
  author="H. Schulzrinne and C. Agboh",
  title="{Session Initiation Protocol (SIP)-H.323 Interworking Requirements}",
  howpublished="RFC 4123 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4123",
  pages="1--16",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4123.txt",
  key="RFC 4123",
  abstract={This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323.  This memo provides information for the Internet community.},
  keywords="SIP-H.323 IWF",
  doi="10.17487/RFC4123",
  }

@misc{rfc4124,
  author="F. Le Faucheur",
  title="{Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering}",
  howpublished="RFC 4124 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4124",
  pages="1--37",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4124.txt",
  key="RFC 4124",
  abstract={This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE).  This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those.  This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering.  These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]},
  keywords="DS-TE, igp, interior gateway protocol, extensions, rsvp, resource reservation protocol",
  doi="10.17487/RFC4124",
  }

@misc{rfc4125,
  author="F. Le Faucheur and W. Lai",
  title="{Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering}",
  howpublished="RFC 4125 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4125",
  pages="1--12",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4125.txt",
  key="RFC 4125",
  abstract={This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ds-te, maximum allocation model",
  doi="10.17487/RFC4125",
  }

@misc{rfc4126,
  author="J. Ash",
  title="{Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering \& Performance Comparisons}",
  howpublished="RFC 4126 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4126",
  pages="1--22",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4126.txt",
  key="RFC 4126",
  abstract={This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model.  Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented.  MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="diffserv-enabled mpls traffic engineering, ds-te, mar, bandwidth reservation, bandwidth allocation, bandwidth protection, performance evaluation, cac, network model",
  doi="10.17487/RFC4126",
  }

@misc{rfc4127,
  author="F. Le Faucheur",
  title="{Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering}",
  howpublished="RFC 4127 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4127",
  pages="1--13",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4127.txt",
  key="RFC 4127",
  abstract={This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ds-te, russian dolls model, multi-protocol label switching",
  doi="10.17487/RFC4127",
  }

@misc{rfc4128,
  author="W. Lai",
  title="{Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation}",
  howpublished="RFC 4128 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4128",
  pages="1--25",
  year=2005,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4128.txt",
  key="RFC 4128",
  abstract={``Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements'', RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models.  Two such models, the Maximum Allocation and the Russian Dolls, are described therein.  This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.  This memo provides information for the Internet community.},
  keywords="label switched path, lsp, lsp blocking, lsp preemption, lsp priority traffic overload, bandwidth efficiency, bandwidth sharing, bandwidth protection, class isolation, maximum allocation model, russian dolls model",
  doi="10.17487/RFC4128",
  }

@misc{rfc4129,
  author="R. Mukundan and K. Morneault and N. Mangalpally",
  title="{Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol}",
  howpublished="RFC 4129 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4129",
  pages="1--15",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4129.txt",
  key="RFC 4129",
  abstract={This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057.  DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network.  DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.  This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]},
  keywords="backhauling, isdn user adaptation, pbx, private branch exchanges",
  doi="10.17487/RFC4129",
  }

@misc{rfc4130,
  author="D. Moberg and R. Drummond",
  title="{MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)}",
  howpublished="RFC 4130 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4130",
  pages="1--47",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4130.txt",
  key="RFC 4130",
  abstract={This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335.  Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats.  The data is packaged using standard MIME structures.  Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts.  Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message.  This applicability statement is informally referred to as ``AS2'' because it is the second applicability statement, produced after ``AS1'', RFC 3335. [STANDARDS-TRACK]},
  keywords="hyper text transfer protocol, simple mail transfer protocol",
  doi="10.17487/RFC4130",
  }

@misc{rfc4131,
  author="S. Green and K. Ozawa and E. Cardona and A. Katsnelson",
  title="{Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus}",
  howpublished="RFC 4131 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4131",
  pages="1--85",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4131.txt",
  key="RFC 4131",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]},
  keywords="mib, snmp, simple network management protocol, docs-ietf-bpi2-mib",
  doi="10.17487/RFC4131",
  }

@misc{rfc4132,
  author="S. Moriai and A. Kato and M. Kanda",
  title="{Addition of Camellia Cipher Suites to Transport Layer Security (TLS)}",
  howpublished="RFC 4132 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4132",
  pages="1--7",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5932",
url="https://www.rfc-editor.org/rfc/rfc4132.txt",
  key="RFC 4132",
  abstract={This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]},
  keywords="camellia encryption algorithm",
  doi="10.17487/RFC4132",
  }

@misc{rfc4133,
  author="A. Bierman and K. McCloghrie",
  title="{Entity MIB (Version 3)}",
  howpublished="RFC 4133 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4133",
  pages="1--62",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6933",
url="https://www.rfc-editor.org/rfc/rfc4133.txt",
  key="RFC 4133",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent.  This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]},
  keywords="management information base, snmp, simple network management protocol",
  doi="10.17487/RFC4133",
  }

@misc{rfc4134,
  author="P. Hoffman",
  title="{Examples of S/MIME Messages}",
  howpublished="RFC 4134 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4134",
  pages="1--136",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4134.txt",
  key="RFC 4134",
  abstract={This document gives examples of message bodies formatted using S/MIME.  Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting).  It includes examples of many common CMS formats.  The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4134",
  }

@misc{rfc4135,
  author="JH. Choi and G. Daley",
  title="{Goals of Detecting Network Attachment in IPv6}",
  howpublished="RFC 4135 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4135",
  pages="1--9",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4135.txt",
  key="RFC 4135",
  abstract={When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity.  The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid.  During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed.  In this memo, this procedure is called Detecting Network Attachment (DNA).  DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.  This memo provides information for the Internet community.},
  keywords="dna, detecting attachment links, change detection",
  doi="10.17487/RFC4135",
  }

@misc{rfc4136,
  author="P. Pillay-Esnault",
  title="{OSPF Refresh and Flooding Reduction in Stable Topologies}",
  howpublished="RFC 4136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4136",
  pages="1--5",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4136.txt",
  key="RFC 4136",
  abstract={This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies. Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.},
  keywords="open shortest path first, link state advertisement, lsa, donotage",
  doi="10.17487/RFC4136",
  }

@misc{rfc4137,
  author="J. Vollbrecht and P. Eronen and N. Petroni and Y. Ohba",
  title="{State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator}",
  howpublished="RFC 4137 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4137",
  pages="1--51",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4137.txt",
  key="RFC 4137",
  abstract={This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative. The state machines are based on the EAP ``Switch'' model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP ``Switch'' model is given in the Introduction section. The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.},
  keywords="eap stand-alone authenticator, eap backend authenticator, eap full authenticator",
  doi="10.17487/RFC4137",
  }

@misc{rfc4138,
  author="P. Sarolahti and M. Kojo",
  title="{Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 4138 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4138",
  pages="1--23",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5682",
url="https://www.rfc-editor.org/rfc/rfc4138.txt",
  key="RFC 4138",
  abstract={Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data.  This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts.  F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate.  After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious.  It then decides whether to send new segments or retransmit unacknowledged segments.  The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout.  The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="tcp, transmission control protocol",
  doi="10.17487/RFC4138",
  }

@misc{rfc4139,
  author="D. Papadimitriou and J. Drake and J. Ash and A. Farrel and L. Ong",
  title="{Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)}",
  howpublished="RFC 4139 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4139",
  pages="1--16",
  year=2005,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4139.txt",
  key="RFC 4139",
  abstract={The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.},
  keywords="tdm, otn, control plane, call, connection",
  doi="10.17487/RFC4139",
  }

@misc{rfc4140,
  author="H. Soliman and C. Castelluccia and K. El Malki and L. Bellier",
  title="{Hierarchical Mobile IPv6 Mobility Management (HMIPv6)}",
  howpublished="RFC 4140 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4140",
  pages="1--29",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5380",
url="https://www.rfc-editor.org/rfc/rfc4140.txt",
  key="RFC 4140",
  abstract={This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling.  Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent.  The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="internet protocol version 6, neighbour discovery, neighbor discovery, mobility anchor point, map",
  doi="10.17487/RFC4140",
  }

@misc{rfc4141,
  author="K. Toyoda and D. Crocker",
  title="{SMTP and MIME Extensions for Content Conversion}",
  howpublished="RFC 4141 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4141",
  pages="1--26",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4141.txt",
  key="RFC 4141",
  abstract={A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred.  Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white).  In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary.  This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]},
  keywords="esmtp, simple mail transfer protocol, extended simple mail transfer protocol, multipurpose internet mail extensions",
  doi="10.17487/RFC4141",
  }

@misc{rfc4142,
  author="D. Crocker and G. Klyne",
  title="{Full-mode Fax Profile for Internet Mail (FFPIM)}",
  howpublished="RFC 4142 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4142",
  pages="1--9",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4142.txt",
  key="RFC 4142",
  abstract={Classic facsimile document exchange represents both a set of technical specifications and a class of service.  Previous work has replicated some of that service class as a profile within Internet mail.  The current specification defines ``full mode'' carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile.  These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]},
  keywords="facsimile, full mode, internet mail",
  doi="10.17487/RFC4142",
  }

@misc{rfc4143,
  author="K. Toyoda and D. Crocker",
  title="{Facsimile Using Internet Mail (IFAX) Service of ENUM}",
  howpublished="RFC 4143 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4143",
  pages="1--5",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4143.txt",
  key="RFC 4143",
  abstract={This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.  IFax is ``facsimile using Internet mail''.  For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system.  This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]},
  keywords="naptr, enum naming authority pointer, facsimile using internet mail, dns, domain name system",
  doi="10.17487/RFC4143",
  }

@misc{rfc4144,
  author="D. {Eastlake 3rd}",
  title="{How to Gain Prominence and Influence in Standards Organizations}",
  howpublished="RFC 4144 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4144",
  pages="1--9",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4144.txt",
  key="RFC 4144",
  abstract={This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4144",
  }

@misc{rfc4145,
  author="D. Yon and G. Camarillo",
  title="{TCP-Based Media Transport in the Session Description Protocol (SDP)}",
  howpublished="RFC 4145 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4145",
  pages="1--15",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4572",
url="https://www.rfc-editor.org/rfc/rfc4145.txt",
  key="RFC 4145",
  abstract={This document describes how to express media transport over TCP using the Session Description Protocol (SDP).  It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]},
  keywords="setup, connection, reestablishment",
  doi="10.17487/RFC4145",
  }

@misc{rfc4146,
  author="R. Gellens",
  title="{Simple New Mail Notification}",
  howpublished="RFC 4146 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4146",
  pages="1--5",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4146.txt",
  key="RFC 4146",
  abstract={This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client. In brief, the server sends the string ``nm\_notifyuser'' CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.},
  keywords="mail client, nm\_notifyuser",
  doi="10.17487/RFC4146",
  }

@misc{rfc4147,
  author="G. Huston",
  title="{Proposed Changes to the Format of the IANA IPv6 Registry}",
  howpublished="RFC 4147 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4147",
  pages="1--10",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4147.txt",
  key="RFC 4147",
  abstract={This document proposes a revised format for the IANA IPv6 address registries.  Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format.  The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6, address format, address architecture",
  doi="10.17487/RFC4147",
  }

@misc{rfc4148,
  author="E. Stephan",
  title="{IP Performance Metrics (IPPM) Metrics Registry}",
  howpublished="RFC 4148 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4148",
  pages="1--14",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6248",
url="https://www.rfc-editor.org/rfc/rfc4148.txt",
  key="RFC 4148",
  abstract={This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF. This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here. IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet protocol, object identities, iana-ippm-metrics-registry-mib",
  doi="10.17487/RFC4148",
  }

@misc{rfc4149,
  author="C. Kalbfleisch and R. Cole and D. Romascanu",
  title="{Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms}",
  howpublished="RFC 4149 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4149",
  pages="1--39",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4149.txt",
  key="RFC 4149",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]},
  keywords="sspm, mib, management information base, sspm mib",
  doi="10.17487/RFC4149",
  }

@misc{rfc4150,
  author="R. Dietz and R. Cole",
  title="{Transport Performance Metrics MIB}",
  howpublished="RFC 4150 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4150",
  pages="1--57",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4150.txt",
  key="RFC 4150",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions.  The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents.  The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]},
  keywords="managgement information base, tpm, tpm-mib",
  doi="10.17487/RFC4150",
  }

@misc{rfc4151,
  author="T. Kindberg and S. Hawke",
  title="{The 'tag' URI Scheme}",
  howpublished="RFC 4151 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4151",
  pages="1--11",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4151.txt",
  key="RFC 4151",
  abstract={This document describes the ``tag'' Uniform Resource Identifier (URI) scheme.  Tag URIs (also known as ``tags'') are designed to be unique across space and time while being tractable to humans.  They are distinct from most other URIs in that they have no authoritative resolution mechanism.  A tag may be used purely as an entity identifier.  Furthermore, using tags has some advantages over the common practice of using ``http'' URIs as identifiers for non-HTTP-accessible resources.  This memo provides information for the Internet community.},
  keywords="uniform resource identifier, entity identifier",
  doi="10.17487/RFC4151",
  }

@misc{rfc4152,
  author="K. Tesink and R. Fox",
  title="{A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code}",
  howpublished="RFC 4152 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4152",
  pages="1--7",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4152.txt",
  key="RFC 4152",
  abstract={This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI.  The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213.  The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers.  The CLEI code identifies communications equipment by specifying product type and features.  There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number).  This memo provides information for the Internet community.},
  keywords="ansi, ansi t1.213",
  doi="10.17487/RFC4152",
  }

@misc{rfc4153,
  author="K. Fujimura and M. Terada and D. {Eastlake 3rd}",
  title="{XML Voucher: Generic Voucher Language}",
  howpublished="RFC 4153 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4153",
  pages="1--21",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4153.txt",
  key="RFC 4153",
  abstract={This document specifies rules for defining voucher properties in XML syntax.  A voucher is a logical entity that represents a right to claim goods or services.  A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions.  This memo provides information for the Internet community.},
  keywords="extensible markup language, logical entity",
  doi="10.17487/RFC4153",
  }

@misc{rfc4154,
  author="M. Terada and K. Fujimura",
  title="{Voucher Trading System Application Programming Interface (VTS-API)}",
  howpublished="RFC 4154 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4154",
  pages="1--32",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4154.txt",
  key="RFC 4154",
  abstract={This document specifies the Voucher Trading System Application Programming Interface (VTS-API).  The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation.  The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates.  This process is often necessary in the course of payment and/or delivery transactions.  This memo provides information for the Internet community.},
  keywords="wallet, transfer, redeem",
  doi="10.17487/RFC4154",
  }

@misc{rfc4155,
  author="E. Hall",
  title="{The application/mbox Media Type}",
  howpublished="RFC 4155 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4155",
  pages="1--9",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4155.txt",
  key="RFC 4155",
  abstract={This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048.  This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.  This memo provides information for the Internet community.},
  keywords="mbox database",
  doi="10.17487/RFC4155",
  }

@misc{rfc4156,
  author="P. Hoffman",
  title="{The wais URI Scheme}",
  howpublished="RFC 4156 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4156",
  pages="1--4",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4156.txt",
  key="RFC 4156",
  abstract={This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.  This memo defines a Historic Document for the Internet community.},
  keywords="uniform resource identifier",
  doi="10.17487/RFC4156",
  }

@misc{rfc4157,
  author="P. Hoffman",
  title="{The prospero URI Scheme}",
  howpublished="RFC 4157 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4157",
  pages="1--4",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4157.txt",
  key="RFC 4157",
  abstract={This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.  This memo defines a Historic Document for the Internet community.},
  keywords="uniform resource identifier",
  doi="10.17487/RFC4157",
  }

@misc{rfc4158,
  author="M. Cooper and Y. Dzambasow and P. Hesse and S. Joseph and R. Nicholas",
  title="{Internet X.509 Public Key Infrastructure: Certification Path Building}",
  howpublished="RFC 4158 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4158",
  pages="1--81",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4158.txt",
  key="RFC 4158",
  abstract={This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications.  By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.  This memo provides information for the Internet community.},
  keywords="certification path discovery, path discovery, certificate path building, certificate path discovery",
  doi="10.17487/RFC4158",
  }

@misc{rfc4159,
  author="G. Huston",
  title="{Deprecation of ``ip6.int''}",
  howpublished="RFC 4159 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4159",
  pages="1--3",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4159.txt",
  key="RFC 4159",
  abstract={This document advises of the deprecation of the use of ``ip6.int'' for Standards Conformant IPv6 implementations.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipv6, dns, domain name system",
  doi="10.17487/RFC4159",
  }

@misc{rfc4160,
  author="K. Mimura and K. Yokoyama and T. Satoh and C. Kanaide and C. Allocchio",
  title="{Internet Fax Gateway Requirements}",
  howpublished="RFC 4160 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4160",
  pages="1--13",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4160.txt",
  key="RFC 4160",
  abstract={To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an ``Internet Fax Gateway'' is required.  This document provides recommendations for the functionality of Internet Fax Gateways.  In this context, an ``offramp gateway'' provides facsimile data transmission from i-fax to GSTN fax; vice versa, an ``onramp gateway'' provides data transmission form GSTN fax to i-fax.  The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN.  This memo provides information for the Internet community.},
  keywords="general switched telephone network facsimile service, gstn fax, internet fax service, i-fax, onramp gateway",
  doi="10.17487/RFC4160",
  }

@misc{rfc4161,
  author="K. Mimura and K. Yokoyama and T. Satoh and K. Watanabe and C. Kanaide",
  title="{Guidelines for Optional Services for Internet Fax Gateways}",
  howpublished="RFC 4161 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4161",
  pages="1--12",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4161.txt",
  key="RFC 4161",
  abstract={To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an ``Internet Fax Gateway'' is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an ``offramp gateway'' provides facsimile data transmission from i-fax to GSTN fax; vice versa, an ``onramp gateway'' provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN. This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.},
  keywords="general switched telephone network acsimile service, gstn fax, internet fax service, i-fax, offramp gateway, onramp gateway",
  doi="10.17487/RFC4161",
  }

@misc{rfc4162,
  author="H.J. Lee and J.H. Yoon and J.I. Lee",
  title="{Addition of SEED Cipher Suites to Transport Layer Security (TLS)}",
  howpublished="RFC 4162 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4162",
  pages="1--6",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4162.txt",
  key="RFC 4162",
  abstract={This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]},
  keywords="encryption algorithm, ciphersuite",
  doi="10.17487/RFC4162",
  }

@misc{rfc4163,
  author="L-E. Jonsson",
  title="{RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression}",
  howpublished="RFC 4163 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4163",
  pages="1--9",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4163.txt",
  key="RFC 4163",
  abstract={This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group.  The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns.  The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.  This memo provides information for the Internet community.},
  keywords="transmission control protocol, internet protocol, compression, performance considerations, intellectual property rights, ipr",
  doi="10.17487/RFC4163",
  }

@misc{rfc4164,
  author="G. Pelletier",
  title="{RObust Header Compression (ROHC): Context Replication for ROHC Profiles}",
  howpublished="RFC 4164 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4164",
  pages="1--21",
  year=2005,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4164.txt",
  key="RFC 4164",
  abstract={This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095.  Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context.  Context replication is introduced to reduce the overhead of the context establishment procedure.  It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]},
  keywords="context initialization, short-lived",
  doi="10.17487/RFC4164",
  }

@misc{rfc4165,
  author="T. George and B. Bidulock and R. Dantu and H. Schwarzbauer and K. Morneault",
  title="{Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)}",
  howpublished="RFC 4165 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4165",
  pages="1--53",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4165.txt",
  key="RFC 4165",
  abstract={This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP).  This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol.  The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages.  The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]},
  keywords="ss7 over ip, ss7/ip, sigtran, m2ua",
  doi="10.17487/RFC4165",
  }

@misc{rfc4166,
  author="L. Coene and J. Pastor-Balbas",
  title="{Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement}",
  howpublished="RFC 4166 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4166",
  pages="1--23",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4166.txt",
  key="RFC 4166",
  abstract={This document describes the applicability of the several protocols developed under the signalling transport framework.  A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4166",
  }

@misc{rfc4167,
  author="A. Lindem",
  title="{Graceful OSPF Restart Implementation Report}",
  howpublished="RFC 4167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4167",
  pages="1--6",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4167.txt",
  key="RFC 4167",
  abstract={Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted.  This document provides an implementation report for this extension to the base OSPF protocol.  This memo provides information for the Internet community.},
  keywords="open shortest path first",
  doi="10.17487/RFC4167",
  }

@misc{rfc4168,
  author="J. Rosenberg and H. Schulzrinne and G. Camarillo",
  title="{The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4168 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4168",
  pages="1--10",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4168.txt",
  key="RFC 4168",
  abstract={This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities.  SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies.  As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]},
  keywords="transport mechanism",
  doi="10.17487/RFC4168",
  }

@misc{rfc4169,
  author="V. Torvinen and J. Arkko and M. Naslund",
  title="{Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2}",
  howpublished="RFC 4169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4169",
  pages="1--13",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4169.txt",
  key="RFC 4169",
  abstract={HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS.  This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication.  This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310).  This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack.  This memo provides information for the Internet community.},
  keywords="tls, transport layer security, tunneled authentication, man-in-the-middle attacks",
  doi="10.17487/RFC4169",
  }

@misc{rfc4170,
  author="B. Thompson and T. Koren and D. Wing",
  title="{Tunneling Multiplexed Compressed RTP (TCRTP)}",
  howpublished="RFC 4170 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4170",
  pages="1--24",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4170.txt",
  key="RFC 4170",
  abstract={This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking.  The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="real-time transport protocol",
  doi="10.17487/RFC4170",
  }

@misc{rfc4171,
  author="J. Tseng and K. Gibbons and F. Travostino and C. Du Laney and J. Souza",
  title="{Internet Storage Name Service (iSNS)}",
  howpublished="RFC 4171 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4171",
  pages="1--123",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4171.txt",
  key="RFC 4171",
  abstract={This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network.  iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network.  iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices.  iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]},
  keywords="isns servers, isns clients, fibre channel devices, ifcp, intelligent storage discovery",
  doi="10.17487/RFC4171",
  }

@misc{rfc4172,
  author="C. Monia and R. Mullendore and F. Travostino and W. Jeong and M. Edwards",
  title="{iFCP - A Protocol for Internet Fibre Channel Storage Networking}",
  howpublished="RFC 4172 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4172",
  pages="1--111",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6172, 7146",
url="https://www.rfc-editor.org/rfc/rfc4172.txt",
  key="RFC 4172",
  abstract={This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network.  This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards.  The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]},
  keywords="gateway-to-gateway, fibre channel fabric, tcp, transport control protocol",
  doi="10.17487/RFC4172",
  }

@misc{rfc4173,
  author="P. Sarkar and D. Missimer and C. Sapuntzakis",
  title="{Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol}",
  howpublished="RFC 4173 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4173",
  pages="1--12",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc4173.txt",
  key="RFC 4173",
  abstract={Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP.  This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol.  The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]},
  keywords="scsi, tcp, transport control protocol, boot server",
  doi="10.17487/RFC4173",
  }

@misc{rfc4174,
  author="C. Monia and J. Tseng and K. Gibbons",
  title="{The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service}",
  howpublished="RFC 4174 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4174",
  pages="1--13",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc4174.txt",
  key="RFC 4174",
  abstract={This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4.  iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network.  iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]},
  keywords="isns, internet storage name service, iscsi, internet scsi, ifcp, internet fibre channel, storage devices",
  doi="10.17487/RFC4174",
  }

@misc{rfc4175,
  author="L. Gharai and C. Perkins",
  title="{RTP Payload Format for Uncompressed Video}",
  howpublished="RFC 4175 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4175",
  pages="1--18",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4421",
url="https://www.rfc-editor.org/rfc/rfc4175.txt",
  key="RFC 4175",
  abstract={This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP.  It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M.  The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]},
  keywords="packetization scheme, real-time transport protocol, real time transport protocol, smpte, society of motion picture television engineers, video formats",
  doi="10.17487/RFC4175",
  }

@misc{rfc4176,
  author="Y. El Mghazli and T. Nadeau and M. Boucadair and K. Chan and A. Gonguet",
  title="{Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management}",
  howpublished="RFC 4176 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4176",
  pages="1--21",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4176.txt",
  key="RFC 4176",
  abstract={This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs).  This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions.  The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4176",
  }

@misc{rfc4177,
  author="G. Huston",
  title="{Architectural Approaches to Multi-homing for IPv6}",
  howpublished="RFC 4177 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4177",
  pages="1--36",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4177.txt",
  key="RFC 4177",
  abstract={This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite.  The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing.  It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.  This memo provides information for the Internet community.},
  keywords="internet protocol",
  doi="10.17487/RFC4177",
  }

@misc{rfc4178,
  author="L. Zhu and P. Leach and K. Jaganathan and W. Ingersoll",
  title="{The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism}",
  howpublished="RFC 4178 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4178",
  pages="1--22",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4178.txt",
  key="RFC 4178",
  abstract={This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers. This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]},
  keywords="generic, service, application, security, program, interface",
  doi="10.17487/RFC4178",
  }

@misc{rfc4179,
  author="S. Kang",
  title="{Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)}",
  howpublished="RFC 4179 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4179",
  pages="1--7",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4179.txt",
  key="RFC 4179",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA.  This memo provides information for the Internet community.},
  keywords="nca, national computerization agency, digital resources",
  doi="10.17487/RFC4179",
  }

@misc{rfc4180,
  author="Y. Shafranovich",
  title="{Common Format and MIME Type for Comma-Separated Values (CSV) Files}",
  howpublished="RFC 4180 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4180",
  pages="1--8",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7111",
url="https://www.rfc-editor.org/rfc/rfc4180.txt",
  key="RFC 4180",
  abstract={This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type ``text/csv''.  This memo provides information for the Internet community.},
  keywords="text/csv",
  doi="10.17487/RFC4180",
  }

@misc{rfc4181,
  author="C. Heard",
  title="{Guidelines for Authors and Reviewers of MIB Documents}",
  howpublished="RFC 4181 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4181",
  pages="1--42",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4841",
url="https://www.rfc-editor.org/rfc/rfc4181.txt",
  key="RFC 4181",
  abstract={This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules.  Applicable portions may be used as a basis for reviews of other MIB documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="standards-track specifications, management information base, review",
  doi="10.17487/RFC4181",
  }

@misc{rfc4182,
  author="E. Rosen",
  title="{Removing a Restriction on the use of MPLS Explicit NULL}",
  howpublished="RFC 4182 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4182",
  pages="1--7",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5462, 7274",
url="https://www.rfc-editor.org/rfc/rfc4182.txt",
  key="RFC 4182",
  abstract={The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as ``IPv4 Explicit NULL'' and a reserved label value known as ``IPv6 Explicit NULL''. Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. This document updates RFC 3032. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, ipv4 explicit null",
  doi="10.17487/RFC4182",
  }

@misc{rfc4183,
  author="E. Warnicke",
  title="{A Suggested Scheme for DNS Resolution of Networks and Gateways}",
  howpublished="RFC 4183 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4183",
  pages="1--9",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4183.txt",
  key="RFC 4183",
  abstract={This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network.  This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.  This memo provides information for the Internet community.},
  keywords="domain name space, ip address, internet protocol address, netmask, first-hop router, subnet",
  doi="10.17487/RFC4183",
  }

@misc{rfc4184,
  author="B. Link and T. Hager and J. Flaks",
  title="{RTP Payload Format for AC-3 Audio}",
  howpublished="RFC 4184 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4184",
  pages="1--13",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4184.txt",
  key="RFC 4184",
  abstract={This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard.  AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media.  The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]},
  keywords="real time transport protocol, audio compression",
  doi="10.17487/RFC4184",
  }

@misc{rfc4185,
  author="J. Klensin",
  title="{National and Local Characters for DNS Top Level Domain (TLD) Names}",
  howpublished="RFC 4185 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4185",
  pages="1--19",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4185.txt",
  key="RFC 4185",
  abstract={In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about ``multilingual'' or ``internationalized'' top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script.  This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes.  It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties.  The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language.  It is not restricted to language- or country-specific ``multilingual'' TLDs in the language(s) and script(s) of that country.  This memo provides information for the Internet community.},
  keywords="domain name system, multilingual, internationalized, local translation",
  doi="10.17487/RFC4185",
  }

@misc{rfc4186,
  author="H. Haverinen and J. Salowey",
  title="{Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)}",
  howpublished="RFC 4186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4186",
  pages="1--92",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4186.txt",
  key="RFC 4186",
  abstract={This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM).  GSM is a second generation mobile network standard.  The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets.  The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.  This memo provides information for the Internet community.},
  keywords="3gpp",
  doi="10.17487/RFC4186",
  }

@misc{rfc4187,
  author="J. Arkko and H. Haverinen",
  title="{Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)}",
  howpublished="RFC 4187 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4187",
  pages="1--79",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5448",
url="https://www.rfc-editor.org/rfc/rfc4187.txt",
  key="RFC 4187",
  abstract={This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.},
  keywords="3gpp, universal mobile telecommunications system, umts",
  doi="10.17487/RFC4187",
  }

@misc{rfc4188,
  author="K. Norseth and E. Bell",
  title="{Definitions of Managed Objects for Bridges}",
  howpublished="RFC 4188 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4188",
  pages="1--44",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4188.txt",
  key="RFC 4188",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. This memo obsoletes RFC 1493. [STANDARDS-TRACK]},
  keywords="BRIDGE-MIB, SNMP, MIB, standard, standards, management information base",
  doi="10.17487/RFC4188",
  }

@misc{rfc4189,
  author="K. Ono and S. Tachimoto",
  title="{Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4189 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4189",
  pages="1--12",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4189.txt",
  key="RFC 4189",
  abstract={A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message.  The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content.  This situation requires a mechanism called ``end-to-middle security'' to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security.  This document defines a set of requirements for a mechanism to achieve end-to-middle security.  This memo provides information for the Internet community.},
  keywords="user agent, ua, intermediaries",
  doi="10.17487/RFC4189",
  }

@misc{rfc4190,
  author="K. Carlberg and I. Brown and C. Beard",
  title="{Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony}",
  howpublished="RFC 4190 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4190",
  pages="1--28",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4190.txt",
  key="RFC 4190",
  abstract={This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony.  We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models.  From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols.  Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document.  These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.  This memo provides information for the Internet community.},
  keywords="disaster communications, prioritized voip",
  doi="10.17487/RFC4190",
  }

@misc{rfc4191,
  author="R. Draves and D. Thaler",
  title="{Default Router Preferences and More-Specific Routes}",
  howpublished="RFC 4191 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4191",
  pages="1--15",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4191.txt",
  key="RFC 4191",
  abstract={This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts.  This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links.  The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]},
  keywords="router advertisement",
  doi="10.17487/RFC4191",
  }

@misc{rfc4192,
  author="F. Baker and E. Lear and R. Droms",
  title="{Procedures for Renumbering an IPv6 Network without a Flag Day}",
  howpublished="RFC 4192 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4192",
  pages="1--22",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4192.txt",
  key="RFC 4192",
  abstract={This document describes a procedure that can be used to renumber a network from one prefix to another.  It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a ``make-before-break'' transition, as well as addresses naming and configuration management issues.  It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.  This memo provides information for the Internet community.},
  keywords="prefix, internet protocol, network interface, make-before-break, enterprise, connecting routers",
  doi="10.17487/RFC4192",
  }

@misc{rfc4193,
  author="R. Hinden and B. Haberman",
  title="{Unique Local IPv6 Unicast Addresses}",
  howpublished="RFC 4193 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4193",
  pages="1--16",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4193.txt",
  key="RFC 4193",
  abstract={This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site.  These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]},
  keywords="internet protocol, local communication",
  doi="10.17487/RFC4193",
  }

@misc{rfc4194,
  author="J. Strombergson and L. Walleij and P. Faltstrom",
  title="{The S Hexdump Format}",
  howpublished="RFC 4194 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4194",
  pages="1--13",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4194.txt",
  key="RFC 4194",
  abstract={This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation.  SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]},
  keywords="shf, standard hex format, secure hash standard, shs, sha-1, nist fips 180-2, binary data, dump format, hexadecimal, intel hex format, s-rec, extensible markup language, xml",
  doi="10.17487/RFC4194",
  }

@misc{rfc4195,
  author="W. Kameyama",
  title="{A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum}",
  howpublished="RFC 4195 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4195",
  pages="1--6",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4195.txt",
  key="RFC 4195",
  abstract={This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents.  This memo provides information for the Internet community.},
  keywords="digital broadcasting, tv, radio, storage systems, metadata, schemas",
  doi="10.17487/RFC4195",
  }

@misc{rfc4196,
  author="H.J. Lee and J.H. Yoon and S.L. Lee and J.I. Lee",
  title="{The SEED Cipher Algorithm and Its Use with IPsec}",
  howpublished="RFC 4196 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4196",
  pages="1--12",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4196.txt",
  key="RFC 4196",
  abstract={This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="ipsec esp, encryption algorithm",
  doi="10.17487/RFC4196",
  }

@misc{rfc4197,
  author="M. Riegel",
  title="{Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks}",
  howpublished="RFC 4197 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4197",
  pages="1--24",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4197.txt",
  key="RFC 4197",
  abstract={This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks.  It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3).  It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.  This memo provides information for the Internet community.},
  keywords="digital signatures, plesiochronous digital hierarchy, sonet, synchronous optical network, sdh, synchronous digital hierarchy, pwe3, pseudo wire emulation",
  doi="10.17487/RFC4197",
  }

@misc{rfc4198,
  author="D. Tessman",
  title="{A Uniform Resource Name (URN) Namespace for Federated Content}",
  howpublished="RFC 4198 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4198",
  pages="1--7",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4198.txt",
  key="RFC 4198",
  abstract={This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.  A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members.  This memo provides information for the Internet community.},
  keywords="content resource, content collections",
  doi="10.17487/RFC4198",
  }

@misc{rfc4201,
  author="K. Kompella and Y. Rekhter and L. Berger",
  title="{Link Bundling in MPLS Traffic Engineering (TE)}",
  howpublished="RFC 4201 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4201",
  pages="1--12",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4201.txt",
  key="RFC 4201",
  abstract={For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP).  Such cases are handled by using the link bundling construct, which is described in this document.  This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, generalized multiprotocol label switching, gmpls, lsp, label switched path, interface identification tlvs",
  doi="10.17487/RFC4201",
  }

@misc{rfc4202,
  author="K. Kompella and Y. Rekhter",
  title="{Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 4202 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4202",
  pages="1--27",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6001, 6002, 7074",
url="https://www.rfc-editor.org/rfc/rfc4202.txt",
  key="RFC 4202",
  abstract={This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS).  This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]},
  keywords="open shortest path first",
  doi="10.17487/RFC4202",
  }

@misc{rfc4203,
  author="K. Kompella and Y. Rekhter",
  title="{OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 4203 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4203",
  pages="1--11",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6001, 6002, 7074",
url="https://www.rfc-editor.org/rfc/rfc4203.txt",
  key="RFC 4203",
  abstract={This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]},
  keywords="open shortest path first",
  doi="10.17487/RFC4203",
  }

@misc{rfc4204,
  author="J. Lang",
  title="{Link Management Protocol (LMP)}",
  howpublished="RFC 4204 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4204",
  pages="1--86",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6898",
url="https://www.rfc-editor.org/rfc/rfc4204.txt",
  key="RFC 4204",
  abstract={For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link.  Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques.  This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links.  Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]},
  keywords="gmpls, sonet, sdh, discovery, link verification, fault managment, control channel management, link property correlation, traffic engineering links, trace monitoring",
  doi="10.17487/RFC4204",
  }

@misc{rfc4205,
  author="K. Kompella and Y. Rekhter",
  title="{Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 4205 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4205",
  pages="1--11",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5307",
url="https://www.rfc-editor.org/rfc/rfc4205.txt",
  key="RFC 4205",
  abstract={This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  This memo provides information for the Internet community.},
  doi="10.17487/RFC4205",
  }

@misc{rfc4206,
  author="K. Kompella and Y. Rekhter",
  title="{Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)}",
  howpublished="RFC 4206 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4206",
  pages="1--14",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6001, 6107",
url="https://www.rfc-editor.org/rfc/rfc4206.txt",
  key="RFC 4206",
  abstract={To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]},
  keywords="lsr, label switching router, te lsp, fa, forwarding adjacency",
  doi="10.17487/RFC4206",
  }

@misc{rfc4207,
  author="J. Lang and D. Papadimitriou",
  title="{Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages}",
  howpublished="RFC 4207 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4207",
  pages="1--15",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6898",
url="https://www.rfc-editor.org/rfc/rfc4207.txt",
  key="RFC 4207",
  abstract={This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]},
  keywords="gmpls, discovery, link verification, fault management, control channel management, link property correlation, traffic engineering links, trace monitoring",
  doi="10.17487/RFC4207",
  }

@misc{rfc4208,
  author="G. Swallow and J. Drake and H. Ishimatsu and Y. Rekhter",
  title="{Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model}",
  howpublished="RFC 4208 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4208",
  pages="1--13",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4208.txt",
  key="RFC 4208",
  abstract={Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies.  These protocols can be used to support a number of deployment scenarios.  This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]},
  keywords="lsp, label switched paths, routing protocol, signaling protocol",
  doi="10.17487/RFC4208",
  }

@misc{rfc4209,
  author="A. Fredette and J. Lang",
  title="{Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems}",
  howpublished="RFC 4209 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4209",
  pages="1--16",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6898",
url="https://www.rfc-editor.org/rfc/rfc4209.txt",
  key="RFC 4209",
  abstract={The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links.  In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing.  This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS).  These extensions are intended to satisfy the ``Optical Link Interface Requirements'' described in a companion document. [STANDARDS-TRACK]},
  keywords="te, traffic engineering, peer nodes, ols, optical link interface requirements",
  doi="10.17487/RFC4209",
  }

@misc{rfc4210,
  author="C. Adams and S. Farrell and T. Kause and T. Mononen",
  title="{Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)}",
  howpublished="RFC 4210 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4210",
  pages="1--95",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6712",
url="https://www.rfc-editor.org/rfc/rfc4210.txt",
  key="RFC 4210",
  abstract={This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP).  Protocol messages are defined for X.509v3 certificate creation and management.  CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]},
  keywords="PKICMP, cryptographic authentication, pkix, pki, X.509v3, certificate creation, certificate management, ca, certification authority",
  doi="10.17487/RFC4210",
  }

@misc{rfc4211,
  author="J. Schaad",
  title="{Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)}",
  howpublished="RFC 4211 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4211",
  pages="1--40",
  year=2005,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4211.txt",
  key="RFC 4211",
  abstract={This document describes the Certificate Request Message Format (CRMF) syntax and semantics.  This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production.  The request will typically include a public key and the associated registration information.  This document does not define a certificate request protocol. [STANDARDS-TRACK]},
  keywords="X.509-CRMF, certification authority, ca, registration authority, ra, pkix, pki, certificate production, crmf, security, encryption, authenticaion",
  doi="10.17487/RFC4211",
  }

@misc{rfc4212,
  author="M. Blinov and C. Adams",
  title="{Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols}",
  howpublished="RFC 4212 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4212",
  pages="1--19",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4212.txt",
  key="RFC 4212",
  abstract={The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols.  These protocols are primarily focused on X.509v3 public-key certificates.  However, it is sometimes desirable to manage certificates in alternative formats as well.  This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols.  It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC).  This memo provides information for the Internet community.},
  keywords="X.509v3, public-key certificates, crmf, certificate request message format, pkix certificate management protocol, pkix-cmp, certificate management messages over cms, cmc",
  doi="10.17487/RFC4212",
  }

@misc{rfc4213,
  author="E. Nordmark and R. Gilligan",
  title="{Basic Transition Mechanisms for IPv6 Hosts and Routers}",
  howpublished="RFC 4213 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4213",
  pages="1--27",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4213.txt",
  key="RFC 4213",
  abstract={This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. [STANDARDS-TRACK]},
  keywords="TRANS-IPV6, ipv4, dual sack, configured tunneling",
  doi="10.17487/RFC4213",
  }

@misc{rfc4214,
  author="F. Templin and T. Gleeson and M. Talwar and D. Thaler",
  title="{Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}",
  howpublished="RFC 4214 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4214",
  pages="1--14",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5214",
url="https://www.rfc-editor.org/rfc/rfc4214.txt",
  key="RFC 4214",
  abstract={The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks.  ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers.  ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ISATAP], ipv4, link layer, nbma, non-broadcast multiple access",
  doi="10.17487/RFC4214",
  }

@misc{rfc4215,
  author="J. Wiljakka",
  title="{Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks}",
  howpublished="RFC 4215 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4215",
  pages="1--24",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4215.txt",
  key="RFC 4215",
  abstract={This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.},
  keywords="internet protocol, gprs, general packet radio service, global system for mobile communications, gsm, universal mobile telecommunications system, umts, wideband code division multiple access, wcdma",
  doi="10.17487/RFC4215",
  }

@misc{rfc4216,
  author="R. Zhang and J.-P. Vasseur",
  title="{MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements}",
  howpublished="RFC 4216 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4216",
  pages="1--29",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4216.txt",
  key="RFC 4216",
  abstract={This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE).  Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.  This memo provides information for the Internet community.},
  keywords="inter-as, mpls-te",
  doi="10.17487/RFC4216",
  }

@misc{rfc4217,
  author="P. Ford-Hutchinson",
  title="{Securing FTP with TLS}",
  howpublished="RFC 4217 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4217",
  pages="1--29",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4217.txt",
  key="RFC 4217",
  abstract={This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, ``The TLS Protocol Version 1.0.'', and the extensions to the FTP protocol defined by RFC 2228, ``FTP Security Extensions''. It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, ``SMTP Service Extension for Secure SMTP over Transport Layer Security'', and HTTP in RFC 2817, ``Upgrading to TLS Within HTTP/1.1.''. This specification is in accordance with RFC 959, ``File Transfer Protocol''. It relies on RFC 2246, ``The TLS Protocol Version 1.0.'', and RFC 2228, ``FTP Security Extensions''. [STANDARDS-TRACK]},
  keywords="security, authentication, file transfer protocol, transport layer security",
  doi="10.17487/RFC4217",
  }

@misc{rfc4218,
  author="E. Nordmark and T. Li",
  title="{Threats Relating to IPv6 Multihoming Solutions}",
  howpublished="RFC 4218 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4218",
  pages="1--31",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4218.txt",
  key="RFC 4218",
  abstract={This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.},
  keywords="security threats, internet protocol version 6",
  doi="10.17487/RFC4218",
  }

@misc{rfc4219,
  author="E. Lear",
  title="{Things Multihoming in IPv6 (MULTI6) Developers Should Think About}",
  howpublished="RFC 4219 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4219",
  pages="1--12",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4219.txt",
  key="RFC 4219",
  abstract={This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6.  The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.  This memo provides information for the Internet community.},
  keywords="security threats, internet protocol version 6",
  doi="10.17487/RFC4219",
  }

@misc{rfc4220,
  author="M. Dubuc and T. Nadeau and J. Lang",
  title="{Traffic Engineering Link Management Information Base}",
  howpublished="RFC 4220 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4220",
  pages="1--54",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4220.txt",
  key="RFC 4220",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]},
  keywords="mib, network management protocols, te, te-link-std-mib",
  doi="10.17487/RFC4220",
  }

@misc{rfc4221,
  author="T. Nadeau and C. Srinivasan and A. Farrel",
  title="{Multiprotocol Label Switching (MPLS) Management Overview}",
  howpublished="RFC 4221 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4221",
  pages="1--32",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4221.txt",
  key="RFC 4221",
  abstract={A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.},
  keywords="mib, management information base, management architecture, network management",
  doi="10.17487/RFC4221",
  }

@misc{rfc4222,
  author="G. Choudhury",
  title="{Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance}",
  howpublished="RFC 4222 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4222",
  pages="1--15",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4222.txt",
  key="RFC 4222",
  abstract={This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol.  The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="open shortest path first, lsa, link state advertisement",
  doi="10.17487/RFC4222",
  }

@misc{rfc4223,
  author="P. Savola",
  title="{Reclassification of RFC 1863 to Historic}",
  howpublished="RFC 4223 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4223",
  pages="1--3",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4223.txt",
  key="RFC 4223",
  abstract={This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status.  This memo also obsoletes RFC 1863.  This memo provides information for the Internet community.},
  keywords="BGP-IDRP, border, gateway, protocol, inter-domain, routing",
  doi="10.17487/RFC4223",
  }

@misc{rfc4224,
  author="G. Pelletier and L-E. Jonsson and K. Sandlund",
  title="{RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets}",
  howpublished="RFC 4224 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4224",
  pages="1--21",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4224.txt",
  key="RFC 4224",
  abstract={RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles).  One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering.  This document discusses aspects of using ROHC over channels that can reorder packets.  It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4224",
  }

@misc{rfc4225,
  author="P. Nikander and J. Arkko and T. Aura and G. Montenegro and E. Nordmark",
  title="{Mobile IP Version 6 Route Optimization Security Design Background}",
  howpublished="RFC 4225 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4225",
  pages="1--37",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4225.txt",
  key="RFC 4225",
  abstract={This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002. The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.},
  keywords="mipv6, mip",
  doi="10.17487/RFC4225",
  }

@misc{rfc4226,
  author="D. M'Raihi and M. Bellare and F. Hoornaert and D. Naccache and O. Ranen",
  title="{HOTP: An HMAC-Based One-Time Password Algorithm}",
  howpublished="RFC 4226 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4226",
  pages="1--37",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4226.txt",
  key="RFC 4226",
  abstract={This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications. This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.},
  keywords="hashed message authentication code, security analysis, oath, open authentication, authentication, OATH",
  doi="10.17487/RFC4226",
  }

@misc{rfc4227,
  author="E. O'Tuathail and M. Rose",
  title="{Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 4227 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4227",
  pages="1--21",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4227.txt",
  key="RFC 4227",
  abstract={This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]},
  keywords="xml, extensible markup language, remote procedure calling, rpc, asynchronous event notification, unacknowledged messages, binding",
  doi="10.17487/RFC4227",
  }

@misc{rfc4228,
  author="A. Rousskov",
  title="{Requirements for an IETF Draft Submission Toolset}",
  howpublished="RFC 4228 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4228",
  pages="1--31",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4228.txt",
  key="RFC 4228",
  abstract={This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.  This memo provides information for the Internet community.},
  keywords="automation, tool",
  doi="10.17487/RFC4228",
  }

@misc{rfc4229,
  author="M. Nottingham and J. Mogul",
  title="{HTTP Header Field Registrations}",
  howpublished="RFC 4229 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4229",
  pages="1--53",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4229.txt",
  key="RFC 4229",
  abstract={This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864.  This memo provides information for the Internet community.},
  keywords="hyper text transfer protocol",
  doi="10.17487/RFC4229",
  }

@misc{rfc4230,
  author="H. Tschofenig and R. Graveman",
  title="{RSVP Security Properties}",
  howpublished="RFC 4230 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4230",
  pages="1--48",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4230.txt",
  key="RFC 4230",
  abstract={This document summarizes the security properties of RSVP.  The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.  This memo provides information for the Internet community.},
  keywords="resource reservation protocol",
  doi="10.17487/RFC4230",
  }

@misc{rfc4231,
  author="M. Nystrom",
  title="{Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512}",
  howpublished="RFC 4231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4231",
  pages="1--9",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4231.txt",
  key="RFC 4231",
  abstract={This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes.  It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols.  The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]},
  keywords="message authentication codes, message authentication schemes",
  doi="10.17487/RFC4231",
  }

@misc{rfc4233,
  author="K. Morneault and S. Rengasami and M. Kalla and G. Sidebottom",
  title="{Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer}",
  howpublished="RFC 4233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4233",
  pages="1--73",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5133",
url="https://www.rfc-editor.org/rfc/rfc4233.txt",
  key="RFC 4233",
  abstract={This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. This document obsoletes RFC 3057. [STANDARDS-TRACK]},
  keywords="stream control transmission protocol, sctp, signaling gateway, sg, media gateway controller, mgc, signaling, media, gateway, interface",
  doi="10.17487/RFC4233",
  }

@misc{rfc4234,
  author="D. Crocker and P. Overell",
  title="{Augmented BNF for Syntax Specifications: ABNF}",
  howpublished="RFC 4234 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4234",
  pages="1--16",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5234",
url="https://www.rfc-editor.org/rfc/rfc4234.txt",
  key="RFC 4234",
  abstract={Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity, with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]},
  keywords="ABNF], backus-naur form, augmented backus-naur form, rule definitions, encoding, core lexical analyzer, electronic mail",
  doi="10.17487/RFC4234",
  }

@misc{rfc4235,
  author="J. Rosenberg and H. Schulzrinne and R. Mahy",
  title="{An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4235 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4235",
  pages="1--39",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7463",
url="https://www.rfc-editor.org/rfc/rfc4235.txt",
  key="RFC 4235",
  abstract={This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package.  The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]},
  keywords="sip events, dialog package",
  doi="10.17487/RFC4235",
  }

@misc{rfc4236,
  author="A. Rousskov and M. Stecher",
  title="{HTTP Adaptation with Open Pluggable Edge Services (OPES)}",
  howpublished="RFC 4236 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4236",
  pages="1--27",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4236.txt",
  key="RFC 4236",
  abstract={Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol.  This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation.  Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]},
  keywords="callout protocol, ocp, opes tracing, opes bypass",
  doi="10.17487/RFC4236",
  }

@misc{rfc4237,
  author="G. Vaudreuil",
  title="{Voice Messaging Directory Service}",
  howpublished="RFC 4237 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4237",
  pages="1--13",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4237.txt",
  key="RFC 4237",
  abstract={This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient. The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]},
  keywords="vpim, voice profile for internet mail",
  doi="10.17487/RFC4237",
  }

@misc{rfc4238,
  author="G. Vaudreuil",
  title="{Voice Message Routing Service}",
  howpublished="RFC 4238 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4238",
  pages="1--10",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4238.txt",
  key="RFC 4238",
  abstract={Voice messaging is traditionally addressed using telephone number addressing.  This document describes two techniques for routing voice messages based on a telephone number.  The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient.  However, this service will take time to become widely deployed in the near term.  This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]},
  keywords="vpim, telephone number addressing, voice profile and intenret mail, vpim directory",
  doi="10.17487/RFC4238",
  }

@misc{rfc4239,
  author="S. McRae and G. Parsons",
  title="{Internet Voice Messaging (IVM)}",
  howpublished="RFC 4239 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4239",
  pages="1--11",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4239.txt",
  key="RFC 4239",
  abstract={This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure. The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]},
  keywords="voicemail, vpim, voice profile for internet mail",
  doi="10.17487/RFC4239",
  }

@misc{rfc4240,
  author="E. Burger and J. Van Dyke and A. Spitzer",
  title="{Basic Network Media Services with SIP}",
  howpublished="RFC 4240 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4240",
  pages="1--24",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4240.txt",
  key="RFC 4240",
  abstract={In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner. This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.},
  keywords="session initiation protocol, network media services, media servers, application servers",
  doi="10.17487/RFC4240",
  }

@misc{rfc4241,
  author="Y. Shirasaki and S. Miyakawa and T. Yamasaki and A. Takenouchi",
  title="{A Model of IPv6/IPv4 Dual Stack Internet Access Service}",
  howpublished="RFC 4241 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4241",
  pages="1--10",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4241.txt",
  key="RFC 4241",
  abstract={This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users.  In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically.  The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.  This memo provides information for the Internet community.},
  keywords="user network specification, ntt communications, adsl, cpe, customer preises equipment",
  doi="10.17487/RFC4241",
  }

@misc{rfc4242,
  author="S. Venaas and T. Chown and B. Volz",
  title="{Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 4242 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4242",
  pages="1--8",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4242.txt",
  key="RFC 4242",
  abstract={This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.  It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC4242",
  }

@misc{rfc4243,
  author="M. Stapp and R. Johnson and T. Palaniappan",
  title="{Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}",
  howpublished="RFC 4243 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4243",
  pages="1--7",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4243.txt",
  key="RFC 4243",
  abstract={This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option.  The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4243",
  }

@misc{rfc4244,
  author="M. Barnes",
  title="{An Extension to the Session Initiation Protocol (SIP) for Request History Information}",
  howpublished="RFC 4244 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4244",
  pages="1--44",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7044",
url="https://www.rfc-editor.org/rfc/rfc4244.txt",
  key="RFC 4244",
  abstract={This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request.  This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user.  This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]},
  keywords="history-info, retarget, enhanced services, voicemail, automatic call distribution",
  doi="10.17487/RFC4244",
  }

@misc{rfc4245,
  author="O. Levin and R. Even",
  title="{High-Level Requirements for Tightly Coupled SIP Conferencing}",
  howpublished="RFC 4245 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4245",
  pages="1--12",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4245.txt",
  key="RFC 4245",
  abstract={This document examines a wide range of conferencing requirements for tightly coupled SIP conferences.  Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed.  Together, these documents will provide a guide for building interoperable SIP conferencing applications.  This memo provides information for the Internet community.},
  keywords="session initiation protocol",
  doi="10.17487/RFC4245",
  }

@misc{rfc4246,
  author="M. Dolan",
  title="{International Standard Audiovisual Number (ISAN) URN Definition}",
  howpublished="RFC 4246 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4246",
  pages="1--6",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4246.txt",
  key="RFC 4246",
  abstract={The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works.  This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN.  This memo provides information for the Internet community.},
  keywords="numbering system, international identification, audiovisual, uniform resource identifier",
  doi="10.17487/RFC4246",
  }

@misc{rfc4247,
  author="J. Ash and B. Goode and J. Hand and R. Zhang",
  title="{Requirements for Header Compression over MPLS}",
  howpublished="RFC 4247 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4247",
  pages="1--11",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4247.txt",
  key="RFC 4247",
  abstract={Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.  When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example.  Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC).  We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router.  This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router.  In this document, we give a problem statement, goals and requirements, and an example scenario.  This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, voip, voice over ip",
  doi="10.17487/RFC4247",
  }

@misc{rfc4248,
  author="P. Hoffman",
  title="{The telnet URI Scheme}",
  howpublished="RFC 4248 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4248",
  pages="1--4",
  year=2005,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4248.txt",
  key="RFC 4248",
  abstract={This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, url, uniform resource locators",
  doi="10.17487/RFC4248",
  }

@misc{rfc4249,
  author="B. Lilly",
  title="{Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components}",
  howpublished="RFC 4249 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4249",
  pages="1--14",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4249.txt",
  key="RFC 4249",
  abstract={Implementation of generators and parsers of header fields requires certain information about those fields.  Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields.  Lacking such explicit information, implementers may guess, and interoperability may suffer.  This memo identifies information useful to implementers of header field generators and parsers.  This memo provides information for the Internet community.},
  keywords="header field generator, header field parser",
  doi="10.17487/RFC4249",
  }

@misc{rfc4250,
  author="S. Lehtinen and C. Lonvick",
  title="{The Secure Shell (SSH) Protocol Assigned Numbers}",
  howpublished="RFC 4250 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4250",
  pages="1--20",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4250.txt",
  key="RFC 4250",
  abstract={This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol.  It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]},
  keywords="remote login",
  doi="10.17487/RFC4250",
  }

@misc{rfc4251,
  author="T. Ylonen and C. Lonvick",
  title="{The Secure Shell (SSH) Protocol Architecture}",
  howpublished="RFC 4251 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4251",
  pages="1--30",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4251.txt",
  key="RFC 4251",
  abstract={The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network.  This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents.  It also discusses the SSH algorithm naming system that allows local extensions.  The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy.  The User Authentication Protocol authenticates the client to the server.  The Connection Protocol multiplexes the encrypted tunnel into several logical channels.  Details of these protocols are described in separate documents. [STANDARDS-TRACK]},
  keywords="remote login, ssh algorithm",
  doi="10.17487/RFC4251",
  }

@misc{rfc4252,
  author="T. Ylonen and C. Lonvick",
  title="{The Secure Shell (SSH) Authentication Protocol}",
  howpublished="RFC 4252 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4252",
  pages="1--17",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4252.txt",
  key="RFC 4252",
  abstract={The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.  This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.  Additional authentication methods are described in separate documents.  The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]},
  keywords="remote login, public key, password, host-based client authentication",
  doi="10.17487/RFC4252",
  }

@misc{rfc4253,
  author="T. Ylonen and C. Lonvick",
  title="{The Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 4253 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4253",
  pages="1--32",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6668",
url="https://www.rfc-editor.org/rfc/rfc4253.txt",
  key="RFC 4253",
  abstract={The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]},
  keywords="remote login, encryption, server authentication, integrity protection, diffie-hellman key exchange, diffie hellman",
  doi="10.17487/RFC4253",
  }

@misc{rfc4254,
  author="T. Ylonen and C. Lonvick",
  title="{The Secure Shell (SSH) Connection Protocol}",
  howpublished="RFC 4254 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4254",
  pages="1--24",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4254.txt",
  key="RFC 4254",
  abstract={Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]},
  keywords="remote login, interactive login, remote execution, encrypted tunnel",
  doi="10.17487/RFC4254",
  }

@misc{rfc4255,
  author="J. Schlyter and W. Griffin",
  title="{Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints}",
  howpublished="RFC 4255 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4255",
  pages="1--9",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4255.txt",
  key="RFC 4255",
  abstract={This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC).  The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]},
  keywords="domain name system, dnssec, domain name system security",
  doi="10.17487/RFC4255",
  }

@misc{rfc4256,
  author="F. Cusack and M. Forssen",
  title="{Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)}",
  howpublished="RFC 4256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4256",
  pages="1--12",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4256.txt",
  key="RFC 4256",
  abstract={The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.  This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device).  The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]},
  keywords="remote login, alphanumeric input",
  doi="10.17487/RFC4256",
  }

@misc{rfc4257,
  author="G. Bernstein and E. Mannie and V. Sharma and E. Gray",
  title="{Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks}",
  howpublished="RFC 4257 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4257",
  pages="1--35",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4257.txt",
  key="RFC 4257",
  abstract={Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching.  One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.  This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks.  SDH/SONET networks make good examples of this process for a variety of reasons.  This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits.  New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed.  This memo provides information for the Internet community.},
  keywords="mpls, optical switching, sdh, sonet",
  doi="10.17487/RFC4257",
  }

@misc{rfc4258,
  author="D. Brungard",
  title="{Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)}",
  howpublished="RFC 4258 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4258",
  pages="1--22",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4258.txt",
  key="RFC 4258",
  abstract={The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.},
  keywords="control domain, hierarchy, multi-level, multi-layer, inter-domain, intra-domain, e-nni, i-nni, uni",
  doi="10.17487/RFC4258",
  }

@misc{rfc4259,
  author="M.-J. Montpetit and G. Fairhurst and H. Clausen and B. Collini-Nocker and H. Linder",
  title="{A Framework for Transmission of IP Datagrams over MPEG-2 Networks}",
  howpublished="RFC 4259 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4259",
  pages="1--42",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4259.txt",
  key="RFC 4259",
  abstract={This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.},
  keywords="digital television, dvb, digital video broadcast, atsc, advanced television systems committee",
  doi="10.17487/RFC4259",
  }

@misc{rfc4260,
  author="P. McCann",
  title="{Mobile IPv6 Fast Handovers for 802.11 Networks}",
  howpublished="RFC 4260 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4260",
  pages="1--15",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4260.txt",
  key="RFC 4260",
  abstract={This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.  This memo provides information for the Internet community.},
  keywords="link layer",
  doi="10.17487/RFC4260",
  }

@misc{rfc4261,
  author="J. Walker and A. Kulkarni",
  title="{Common Open Policy Service (COPS) Over Transport Layer Security (TLS)}",
  howpublished="RFC 4261 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4261",
  pages="1--14",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4261.txt",
  key="RFC 4261",
  abstract={This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet. This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]},
  keywords="client-accept message",
  doi="10.17487/RFC4261",
  }

@misc{rfc4262,
  author="S. Santesson",
  title="{X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities}",
  howpublished="RFC 4262 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4262",
  pages="1--5",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4262.txt",
  key="RFC 4262",
  abstract={This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280.  This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]},
  keywords="cryptographic capabilities",
  doi="10.17487/RFC4262",
  }

@misc{rfc4263,
  author="B. Lilly",
  title="{Media Subtype Registration for Media Type text/troff}",
  howpublished="RFC 4263 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4263",
  pages="1--16",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4263.txt",
  key="RFC 4263",
  abstract={A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4263",
  }

@misc{rfc4264,
  author="T. Griffin and G. Huston",
  title="{BGP Wedgies}",
  howpublished="RFC 4264 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4264",
  pages="1--10",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4264.txt",
  key="RFC 4264",
  abstract={It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner.  In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable.  Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner.  These stable, but unintended, BGP states are termed here ``BGP Wedgies''.  This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4264",
  }

@misc{rfc4265,
  author="B. Schliesser and T. Nadeau",
  title="{Definition of Textual Conventions for Virtual Private Network (VPN) Management}",
  howpublished="RFC 4265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4265",
  pages="1--6",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4265.txt",
  key="RFC 4265",
  abstract={This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]},
  keywords="tc",
  doi="10.17487/RFC4265",
  }

@misc{rfc4266,
  author="P. Hoffman",
  title="{The gopher URI Scheme}",
  howpublished="RFC 4266 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4266",
  pages="1--6",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4266.txt",
  key="RFC 4266",
  abstract={This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, url",
  doi="10.17487/RFC4266",
  }

@misc{rfc4267,
  author="M. Froumentin",
  title="{The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml}",
  howpublished="RFC 4267 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4267",
  pages="1--9",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4267.txt",
  key="RFC 4267",
  abstract={This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS).  This memo provides information for the Internet community.},
  keywords="voice browser, voice extensible markup language, voicexml, speech synthesis markup language, ssml, speech recognition grammar specification, srgs, call control xml, ccxml, pronunciation lexicon specification, pls",
  doi="10.17487/RFC4267",
  }

@misc{rfc4268,
  author="S. Chisholm and D. Perkins",
  title="{Entity State MIB}",
  howpublished="RFC 4268 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4268",
  pages="1--19",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4268.txt",
  key="RFC 4268",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities. In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="management information base, snmp, entity-state-tc-mib",
  doi="10.17487/RFC4268",
  }

@misc{rfc4269,
  author="H.J. Lee and S.J. Lee and J.H. Yoon and D.H. Cheon and J.I. Lee",
  title="{The SEED Encryption Algorithm}",
  howpublished="RFC 4269 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4269",
  pages="1--16",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4269.txt",
  key="RFC 4269",
  abstract={This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This document obsoletes RFC 4009. This memo provides information for the Internet community.},
  keywords="encryption algorithm, seed cbc, seed oid",
  doi="10.17487/RFC4269",
  }

@misc{rfc4270,
  author="P. Hoffman and B. Schneier",
  title="{Attacks on Cryptographic Hashes in Internet Protocols}",
  howpublished="RFC 4270 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4270",
  pages="1--12",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4270.txt",
  key="RFC 4270",
  abstract={Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how.  This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers.  This memo provides information for the Internet community.},
  keywords="collision attacks, hash algorithms, ip, digital certificates",
  doi="10.17487/RFC4270",
  }

@misc{rfc4271,
  author="Y. Rekhter and T. Li and S. Hares",
  title="{A Border Gateway Protocol 4 (BGP-4)}",
  howpublished="RFC 4271 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4271",
  pages="1--104",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6286, 6608, 6793, 7606, 7607, 7705",
url="https://www.rfc-editor.org/rfc/rfc4271.txt",
  key="RFC 4271",
  abstract={This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network ``class'' within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK]},
  keywords="BGP-4, routing",
  doi="10.17487/RFC4271",
  }

@misc{rfc4272,
  author="S. Murphy",
  title="{BGP Security Vulnerabilities Analysis}",
  howpublished="RFC 4272 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4272",
  pages="1--22",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4272.txt",
  key="RFC 4272",
  abstract={Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.},
  keywords="border gateway protocol, attacks, risks, insider threat",
  doi="10.17487/RFC4272",
  }

@misc{rfc4273,
  author="J. Haas and S. Hares",
  title="{Definitions of Managed Objects for BGP-4}",
  howpublished="RFC 4273 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4273",
  pages="1--32",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4273.txt",
  key="RFC 4273",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 ``Definitions of Managed Objects for the Border Gateway Protocol (Version 3)'', which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]},
  keywords="BGP-4-MIB, management information base, mib, border gateway protocol",
  doi="10.17487/RFC4273",
  }

@misc{rfc4274,
  author="D. Meyer and K. Patel",
  title="{BGP-4 Protocol Analysis}",
  howpublished="RFC 4274 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4274",
  pages="1--16",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4274.txt",
  key="RFC 4274",
  abstract={The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for ``the second report'', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4274",
  }

@misc{rfc4275,
  author="S. Hares and D. Hares",
  title="{BGP-4 MIB Implementation Survey}",
  howpublished="RFC 4275 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4275",
  pages="1--37",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4275.txt",
  key="RFC 4275",
  abstract={This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification.  This memo provides information for the Internet community.},
  keywords="border gateway protocol, management information base",
  doi="10.17487/RFC4275",
  }

@misc{rfc4276,
  author="S. Hares and A. Retana",
  title="{BGP-4 Implementation Report}",
  howpublished="RFC 4276 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4276",
  pages="1--97",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4276.txt",
  key="RFC 4276",
  abstract={This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia). The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4276",
  }

@misc{rfc4277,
  author="D. McPherson and K. Patel",
  title="{Experience with the BGP-4 Protocol}",
  howpublished="RFC 4277 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4277",
  pages="1--19",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4277.txt",
  key="RFC 4277",
  abstract={The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for ``the second report'', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4277",
  }

@misc{rfc4278,
  author="S. Bellovin and A. Zinin",
  title="{Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification}",
  howpublished="RFC 4278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4278",
  pages="1--7",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4278.txt",
  key="RFC 4278",
  abstract={The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization.  RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF.  This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, ``Protection of BGP Sessions via the TCP MD5 Signature Option''.  RFC 2385 will remain at the Proposed Standard level.  This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4278",
  }

@misc{rfc4279,
  author="P. Eronen and H. Tschofenig",
  title="{Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)}",
  howpublished="RFC 4279 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4279",
  pages="1--15",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4279.txt",
  key="RFC 4279",
  abstract={This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs).  These pre-shared keys are symmetric keys, shared in advance among the communicating parties.  The first set of ciphersuites uses only symmetric key operations for authentication.  The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]},
  keywords="psk, psks, symmetric keys, diffie-hellman",
  doi="10.17487/RFC4279",
  }

@misc{rfc4280,
  author="K. Chowdhury and P. Yegani and L. Madour",
  title="{Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers}",
  howpublished="RFC 4280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4280",
  pages="1--11",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4280.txt",
  key="RFC 4280",
  abstract={This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network.  BCMCS is being developed for Third generation (3G) cellular telephone networks.  Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service.  Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller.  This document defines the related options and option codes. [STANDARDS-TRACK]},
  keywords="bcmcs, 3g, third generation, cellular telephone, mobile node, mn",
  doi="10.17487/RFC4280",
  }

@misc{rfc4281,
  author="R. Gellens and D. Singer and P. Frojdh",
  title="{The Codecs Parameter for ``Bucket'' Media Types}",
  howpublished="RFC 4281 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4281",
  pages="1--29",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6381",
url="https://www.rfc-editor.org/rfc/rfc4281.txt",
  key="RFC 4281",
  abstract={Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered. This document adds a new parameter, ``codecs'', to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]},
  keywords="codec, container, audio, video, 3gpp, 3gpp2",
  doi="10.17487/RFC4281",
  }

@misc{rfc4282,
  author="B. Aboba and M. Beadles and J. Arkko and P. Eronen",
  title="{The Network Access Identifier}",
  howpublished="RFC 4282 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4282",
  pages="1--16",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7542",
url="https://www.rfc-editor.org/rfc/rfc4282.txt",
  key="RFC 4282",
  abstract={In order to provide roaming services, it is necessary to have a standardized method for identifying users.  This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. ``Roaming'' may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \\%customer-vendor relationship with only one.  Examples of where roaming capabilities might be required include ISP ``confederations'' and \\%ISP-provided corporate network access support.  This document is a revised version of RFC 2486, which originally defined NAIs.  Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]},
  keywords="NAI, nai, roaming, tunneling",
  doi="10.17487/RFC4282",
  }

@misc{rfc4283,
  author="A. Patel and K. Leung and M. Khalil and H. Akhtar and K. Chowdhury",
  title="{Mobile Node Identifier Option for Mobile IPv6 (MIPv6)}",
  howpublished="RFC 4283 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4283",
  pages="1--8",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4283.txt",
  key="RFC 4283",
  abstract={Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings.  Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address.  Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN).  This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]},
  keywords="mobility header, mobile nodes, correspondent nodes, home agents",
  doi="10.17487/RFC4283",
  }

@misc{rfc4284,
  author="F. Adrangi and V. Lortz and F. Bari and P. Eronen",
  title="{Identity Selection Hints for the Extensible Authentication Protocol (EAP)}",
  howpublished="RFC 4284 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4284",
  pages="1--14",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4284.txt",
  key="RFC 4284",
  abstract={The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker. The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.},
  keywords="nai, network access identifier",
  doi="10.17487/RFC4284",
  }

@misc{rfc4285,
  author="A. Patel and K. Leung and M. Khalil and H. Akhtar and K. Chowdhury",
  title="{Authentication Protocol for Mobile IPv6}",
  howpublished="RFC 4285 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4285",
  pages="1--19",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4285.txt",
  key="RFC 4285",
  abstract={IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).  MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent.  This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents.  The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.  This memo provides information for the Internet community.},
  keywords="ip security, ipsec, mip6, mobile node, home agent",
  doi="10.17487/RFC4285",
  }

@misc{rfc4286,
  author="B. Haberman and J. Martin",
  title="{Multicast Router Discovery}",
  howpublished="RFC 4286 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4286",
  pages="1--18",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4286.txt",
  key="RFC 4286",
  abstract={The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]},
  keywords="igmp, internet group management protocol, mld, multicast listener discovery, mrd",
  doi="10.17487/RFC4286",
  }

@misc{rfc4287,
  author="M. Nottingham and R. Sayre",
  title="{The Atom Syndication Format}",
  howpublished="RFC 4287 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4287",
  pages="1--43",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5988",
url="https://www.rfc-editor.org/rfc/rfc4287.txt",
  key="RFC 4287",
  abstract={This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]},
  keywords="xml-basd web content, metadata",
  doi="10.17487/RFC4287",
  }

@misc{rfc4288,
  author="N. Freed and J. Klensin",
  title="{Media Type Specifications and Registration Procedures}",
  howpublished="RFC 4288 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4288",
  pages="1--24",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6838",
url="https://www.rfc-editor.org/rfc/rfc4288.txt",
  key="RFC 4288",
  abstract={This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="mime, multipurpose internet mail extensions, media types",
  doi="10.17487/RFC4288",
  }

@misc{rfc4289,
  author="N. Freed and J. Klensin",
  title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}",
  howpublished="RFC 4289 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4289",
  pages="1--11",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4289.txt",
  key="RFC 4289",
  abstract={This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="media, types, external, body, access, content-transfer-encodings",
  doi="10.17487/RFC4289",
  }

@misc{rfc4290,
  author="J. Klensin",
  title="{Suggested Practices for Registration of Internationalized Domain Names (IDN)}",
  howpublished="RFC 4290 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4290",
  pages="1--28",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4290.txt",
  key="RFC 4290",
  abstract={This document explores the issues in the registration of internationalized domain names (IDNs).  The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names.  To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations.  This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names.  This memo provides information for the Internet community.},
  keywords="chinese domain names, japanese domain names, korean domain names",
  doi="10.17487/RFC4290",
  }

@misc{rfc4291,
  author="R. Hinden and S. Deering",
  title="{IP Version 6 Addressing Architecture}",
  howpublished="RFC 4291 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4291",
  pages="1--25",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5952, 6052, 7136, 7346, 7371, 8064",
url="https://www.rfc-editor.org/rfc/rfc4291.txt",
  key="RFC 4291",
  abstract={This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, ``IP Version 6 Addressing Architecture''. [STANDARDS-TRACK]},
  keywords="internet protocol version 6, unicast, anycast, multicast, node",
  doi="10.17487/RFC4291",
  }

@misc{rfc4292,
  author="B. Haberman",
  title="{IP Forwarding Table MIB}",
  howpublished="RFC 4292 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4292",
  pages="1--34",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4292.txt",
  key="RFC 4292",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner.  This document obsoletes RFC 2096. [STANDARDS-TRACK]},
  keywords="TABLE-MIB, Management, Information, Base, Internet, Protocol",
  doi="10.17487/RFC4292",
  }

@misc{rfc4293,
  author="S. Routhier",
  title="{Management Information Base for the Internet Protocol (IP)}",
  howpublished="RFC 4293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4293",
  pages="1--122",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4293.txt",
  key="RFC 4293",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner.  This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]},
  keywords="MIB-IP, IP, Simple, Network, Management, Protocol, MIB, ipv6, ICMPv6-MIB|, mib, internet, protocol, ip mib, ipv4 mib, ipv6 mib, icmp mib, icmpv6 mib",
  doi="10.17487/RFC4293",
  }

@misc{rfc4294,
  author="J. Loughney",
  title="{IPv6 Node Requirements}",
  howpublished="RFC 4294 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4294",
  pages="1--20",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6434, updated by RFC 5095",
url="https://www.rfc-editor.org/rfc/rfc4294.txt",
  key="RFC 4294",
  abstract={This document defines requirements for IPv6 nodes.  It is expected that IPv6 will be deployed in a wide range of devices and situations.  Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6",
  doi="10.17487/RFC4294",
  }

@misc{rfc4295,
  author="G. Keeni and K. Koide and K. Nagami and S. Gundavelli",
  title="{Mobile IPv6 Management Information Base}",
  howpublished="RFC 4295 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4295",
  pages="1--109",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4295.txt",
  key="RFC 4295",
  abstract={This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community.  In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]},
  keywords="mib, mipv6",
  doi="10.17487/RFC4295",
  }

@misc{rfc4296,
  author="S. Bailey and T. Talpey",
  title="{The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols}",
  howpublished="RFC 4296 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4296",
  pages="1--22",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4296.txt",
  key="RFC 4296",
  abstract={This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports.  This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols.  DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA).  RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.  This memo provides information for the Internet community.},
  keywords="rddp, warp",
  doi="10.17487/RFC4296",
  }

@misc{rfc4297,
  author="A. Romanow and J. Mogul and T. Talpey and S. Bailey",
  title="{Remote Direct Memory Access (RDMA) over IP Problem Statement}",
  howpublished="RFC 4297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4297",
  pages="1--20",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4297.txt",
  key="RFC 4297",
  abstract={Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application. This document examines this overhead, and addresses an architectural, IP-based ``copy avoidance'' solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.},
  keywords="overhead, copy avoidance",
  doi="10.17487/RFC4297",
  }

@misc{rfc4298,
  author="J.-H. Chen and W. Lee and J. Thyssen",
  title="{RTP Payload Format for BroadVoice Speech Codecs}",
  howpublished="RFC 4298 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4298",
  pages="1--14",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4298.txt",
  key="RFC 4298",
  abstract={This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs.  The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification.  The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]},
  keywords="real time transport, narroband, wideband, bv16 broadvoice16, sdp, session description protocol",
  doi="10.17487/RFC4298",
  }

@misc{rfc4301,
  author="S. Kent and K. Seo",
  title="{Security Architecture for the Internet Protocol}",
  howpublished="RFC 4301 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4301",
  pages="1--101",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6040, 7619",
url="https://www.rfc-editor.org/rfc/rfc4301.txt",
  key="RFC 4301",
  abstract={This document describes an updated version of the ``Security Architecture for IP'', which is designed to provide security services for traffic at the IP layer.  This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]},
  keywords="IPSEC, ipsec, authentication, encapsulation, IP, IPv4, IPv6, IP-layer, ip authentication header, ip security, IPsec, confidentiality, authentication integrity, anti-replay, ah, esp, encapsulating security payload, ike, internet key exchange, ikev2, esn, extended sequence number",
  doi="10.17487/RFC4301",
  }

@misc{rfc4302,
  author="S. Kent",
  title="{IP Authentication Header}",
  howpublished="RFC 4302 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4302",
  pages="1--34",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4302.txt",
  key="RFC 4302",
  abstract={This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6.  This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]},
  keywords="IP-AUTH, ipsec, Internet, Protocol, AH, security, IPv4, IPv6, ip security, confidentiality, authentication, integrity, anti-replay, ah, esp, encapsulating security payload, ike, internet key exchange, ikev2, esn, extended sequence number",
  doi="10.17487/RFC4302",
  }

@misc{rfc4303,
  author="S. Kent",
  title="{IP Encapsulating Security Payload (ESP)}",
  howpublished="RFC 4303 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4303",
  pages="1--44",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4303.txt",
  key="RFC 4303",
  abstract={This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]},
  keywords="ESP, ipsec, internet, protocol, encapsulating, security, ipv4, ipv6, ip security, confidentiality, authentication, integrity, anti-replay, ah, ip authentication header, ike, internet key exchange, ikev2, esn, extended sequence number",
  doi="10.17487/RFC4303",
  }

@misc{rfc4304,
  author="S. Kent",
  title="{Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)}",
  howpublished="RFC 4304 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4304",
  pages="1--5",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4304.txt",
  key="RFC 4304",
  abstract={The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay.  This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP).  These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]},
  keywords="ipsecurity, anti-replay, ah, ip authentication header, esp, encapsulating security payload, ike, internet key exchange, ikev2",
  doi="10.17487/RFC4304",
  }

@misc{rfc4305,
  author="D. {Eastlake 3rd}",
  title="{Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)}",
  howpublished="RFC 4305 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4305",
  pages="1--9",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4835",
url="https://www.rfc-editor.org/rfc/rfc4305.txt",
  key="RFC 4305",
  abstract={The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA).  To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]},
  keywords="ESP, ipsec, authentication, mechanism, header, security, architecture, payload, internet, protocol, encapsulating, ipv4, ipv6",
  doi="10.17487/RFC4305",
  }

@misc{rfc4306,
  author="C. Kaufman",
  title="{Internet Key Exchange (IKEv2) Protocol}",
  howpublished="RFC 4306 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4306",
  pages="1--99",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5996, updated by RFC 5282",
url="https://www.rfc-editor.org/rfc/rfc4306.txt",
  key="RFC 4306",
  abstract={This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]},
  keywords="ISAKMPSEC, ipsec, internet, protocol, security, association, key, management, ipsec, cryptography, authentication, IKE, oakley, isakmp",
  doi="10.17487/RFC4306",
  }

@misc{rfc4307,
  author="J. Schiller",
  title="{Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)}",
  howpublished="RFC 4307 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4307",
  pages="1--6",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4307.txt",
  key="RFC 4307",
  abstract={The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association.  However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]},
  keywords="ipsec, ike, internet key exchange",
  doi="10.17487/RFC4307",
  }

@misc{rfc4308,
  author="P. Hoffman",
  title="{Cryptographic Suites for IPsec}",
  howpublished="RFC 4308 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4308",
  pages="1--7",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4308.txt",
  key="RFC 4308",
  abstract={The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder.  There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms.  This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]},
  keywords="ike, internet key exchange, ikev2, security algorithms, ikev1",
  doi="10.17487/RFC4308",
  }

@misc{rfc4309,
  author="R. Housley",
  title="{Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)}",
  howpublished="RFC 4309 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4309",
  pages="1--13",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4309.txt",
  key="RFC 4309",
  abstract={This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]},
  keywords="cbc-mac mode, initialization vector, iv, confidentiality, data origin authentication, connectionless integrity",
  doi="10.17487/RFC4309",
  }

@misc{rfc4310,
  author="S. Hollenbeck",
  title="{Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 4310 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4310",
  pages="1--22",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5910",
url="https://www.rfc-editor.org/rfc/rfc4310.txt",
  key="RFC 4310",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]},
  keywords="dnssec, domain name system security extensions",
  doi="10.17487/RFC4310",
  }

@misc{rfc4311,
  author="R. Hinden and D. Thaler",
  title="{IPv6 Host-to-Router Load Sharing}",
  howpublished="RFC 4311 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4311",
  pages="1--5",
  year=2005,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4311.txt",
  key="RFC 4311",
  abstract={The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice.  This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]},
  keywords="internet protocol version 6, conceptual sending algorithm",
  doi="10.17487/RFC4311",
  }

@misc{rfc4312,
  author="A. Kato and S. Moriai and M. Kanda",
  title="{The Camellia Cipher Algorithm and Its Use With IPsec}",
  howpublished="RFC 4312 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4312",
  pages="1--8",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4312.txt",
  key="RFC 4312",
  abstract={This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]},
  keywords="cipher block chaining mode, initialization vector, iv, esp, encapsulating security payload, ip security",
  doi="10.17487/RFC4312",
  }

@misc{rfc4313,
  author="D. Oran",
  title="{Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources}",
  howpublished="RFC 4313 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4313",
  pages="1--20",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4313.txt",
  key="RFC 4313",
  abstract={This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams.  By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS).  Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams.  However, speech processing presents additional requirements that none of the extant IETF protocols address.  This memo provides information for the Internet community.},
  keywords="speech processing, audio streams, si, speaker identification, sv, speaker verification, tts, text to speech",
  doi="10.17487/RFC4313",
  }

@misc{rfc4314,
  author="A. Melnikov",
  title="{IMAP4 Access Control List (ACL) Extension}",
  howpublished="RFC 4314 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4314",
  pages="1--27",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4314.txt",
  key="RFC 4314",
  abstract={The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]},
  keywords="IMAP4-ACL, Control, List, interet message access protocol",
  doi="10.17487/RFC4314",
  }

@misc{rfc4315,
  author="M. Crispin",
  title="{Internet Message Access Protocol (IMAP) - UIDPLUS extension}",
  howpublished="RFC 4315 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4315",
  pages="1--8",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4315.txt",
  key="RFC 4315",
  abstract={The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations.  The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]},
  keywords="IMAP4UIDPL, internet, message, access, protocol, disconnected, operation",
  doi="10.17487/RFC4315",
  }

@misc{rfc4316,
  author="J. Reschke",
  title="{Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties}",
  howpublished="RFC 4316 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4316",
  pages="1--11",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4316.txt",
  key="RFC 4316",
  abstract={This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping.  Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="datatying, propfind",
  doi="10.17487/RFC4316",
  }

@misc{rfc4317,
  author="A. Johnston and R. Sparks",
  title="{Session Description Protocol (SDP) Offer/Answer Examples}",
  howpublished="RFC 4317 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4317",
  pages="1--24",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4317.txt",
  key="RFC 4317",
  abstract={This document gives examples of Session Description Protocol (SDP) offer/answer exchanges.  Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams.  The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types.  Common Third Party Call Control (3pcc) examples are also given.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4317",
  }

@misc{rfc4318,
  author="D. Levi and D. Harrington",
  title="{Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol}",
  howpublished="RFC 4318 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4318",
  pages="1--14",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4318.txt",
  key="RFC 4318",
  abstract={This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments.  The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]},
  keywords="management information base, simple network management protocol, transparent bridging, rstp-mib",
  doi="10.17487/RFC4318",
  }

@misc{rfc4319,
  author="C. Sikes and B. Ray and R. Abbi",
  title="{Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines}",
  howpublished="RFC 4319 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4319",
  pages="1--75",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4319.txt",
  key="RFC 4319",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.  This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276).  This document obsoletes RFC 3276. [STANDARDS-TRACK]},
  keywords="mib, management information base, hdsl2-shdsl-line-mib, interfaces",
  doi="10.17487/RFC4319",
  }

@misc{rfc4320,
  author="R. Sparks",
  title="{Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction}",
  howpublished="RFC 4320 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4320",
  pages="1--7",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4320.txt",
  key="RFC 4320",
  abstract={This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction.  These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic.  They also improve the robustness of SIP networks when elements stop responding.  These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4320",
  }

@misc{rfc4321,
  author="R. Sparks",
  title="{Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction}",
  howpublished="RFC 4321 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4321",
  pages="1--10",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4321.txt",
  key="RFC 4321",
  abstract={This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4321",
  }

@misc{rfc4322,
  author="M. Richardson and D.H. Redelmeier",
  title="{Opportunistic Encryption using the Internet Key Exchange (IKE)}",
  howpublished="RFC 4322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4322",
  pages="1--44",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4322.txt",
  key="RFC 4322",
  abstract={This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.},
  keywords="oe, linux frees/wan, ipsec, dns, domain name space, dns security",
  doi="10.17487/RFC4322",
  }

@misc{rfc4323,
  author="M. Patrick and W. Murwin",
  title="{Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)}",
  howpublished="RFC 4323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4323",
  pages="1--89",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4323.txt",
  key="RFC 4323",
  abstract={This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]},
  keywords="snmp, simple network management protocol, cm, cable modem, cmts, cable modem termination system, docs-ietf-qos-mib",
  doi="10.17487/RFC4323",
  }

@misc{rfc4324,
  author="D. Royer and G. Babics and S. Mansour",
  title="{Calendar Access Protocol (CAP)}",
  howpublished="RFC 4324 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4324",
  pages="1--131",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4324.txt",
  key="RFC 4324",
  abstract={The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS).  At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed.  In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work.  Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="calendar user, cu, calendar user agent, cua, ical, calender store, cs",
  doi="10.17487/RFC4324",
  }

@misc{rfc4325,
  author="S. Santesson and R. Housley",
  title="{Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension}",
  howpublished="RFC 4325 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4325",
  pages="1--7",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5280",
url="https://www.rfc-editor.org/rfc/rfc4325.txt",
  key="RFC 4325",
  abstract={This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension.  RFC 3280 defines the Authority Information Access certificate extension using the same syntax.  The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]},
  keywords="issuer certificate",
  doi="10.17487/RFC4325",
  }

@misc{rfc4326,
  author="G. Fairhurst and B. Collini-Nocker",
  title="{Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)}",
  howpublished="RFC 4326 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4326",
  pages="1--42",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7280",
url="https://www.rfc-editor.org/rfc/rfc4326.txt",
  key="RFC 4326",
  abstract={The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4326",
  }

@misc{rfc4327,
  author="M. Dubuc and T. Nadeau and J. Lang and E. McGinnis",
  title="{Link Management Protocol (LMP) Management Information Base (MIB)}",
  howpublished="RFC 4327 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4327",
  pages="1--82",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4631",
url="https://www.rfc-editor.org/rfc/rfc4327.txt",
  key="RFC 4327",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]},
  keywords="lmp-mib",
  doi="10.17487/RFC4327",
  }

@misc{rfc4328,
  author="D. Papadimitriou",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control}",
  howpublished="RFC 4328 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4328",
  pages="1--23",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7139",
url="https://www.rfc-editor.org/rfc/rfc4328.txt",
  key="RFC 4328",
  abstract={This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents.  It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]},
  keywords="otn, optical transport networks, pre-otn",
  doi="10.17487/RFC4328",
  }

@misc{rfc4329,
  author="B. Hoehrmann",
  title="{Scripting Media Types}",
  howpublished="RFC 4329 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4329",
  pages="1--15",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4329.txt",
  key="RFC 4329",
  abstract={This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.  This memo provides information for the Internet community.},
  keywords="JavaScript, EMACScript, mime, script, subtype",
  doi="10.17487/RFC4329",
  }

@misc{rfc4330,
  author="D. Mills",
  title="{Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI}",
  howpublished="RFC 4330 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4330",
  pages="1--27",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5905",
url="https://www.rfc-editor.org/rfc/rfc4330.txt",
  key="RFC 4330",
  abstract={This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868. This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.},
  keywords="NTP, time, computer, clock, synchronization",
  doi="10.17487/RFC4330",
  }

@misc{rfc4331,
  author="B. Korver and L. Dusseault",
  title="{Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections}",
  howpublished="RFC 4331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4331",
  pages="1--10",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4331.txt",
  key="RFC 4331",
  abstract={Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations.  This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]},
  keywords="webdav",
  doi="10.17487/RFC4331",
  }

@misc{rfc4332,
  author="K. Leung and A. Patel and G. Tsirtsis and E. Klovning",
  title="{Cisco's Mobile IPv4 Host Configuration Extensions}",
  howpublished="RFC 4332 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4332",
  pages="1--11",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4332.txt",
  key="RFC 4332",
  abstract={An IP device requires basic host configuration to be able to communicate.  For example, it will typically require an IP address and the address of a DNS server.  This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP).  However, both DHCP and PPP/IPCP provide host configuration based on the access network.  In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network.  The information to configure the host needs to be based on the home network.  This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages.  This memo provides information for the Internet community.},
  keywords="dynamic host configuration protocol, dhcp, point-to-point, ip control protocol, ppp, ipcp",
  doi="10.17487/RFC4332",
  }

@misc{rfc4333,
  author="G. Huston and B. Wijnen",
  title="{The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process}",
  howpublished="RFC 4333 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4333",
  pages="1--9",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4333.txt",
  key="RFC 4333",
  abstract={This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="iad, iasa, ietf administrative support activity, ietf administrative director",
  doi="10.17487/RFC4333",
  }

@misc{rfc4334,
  author="R. Housley and T. Moore",
  title="{Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)}",
  howpublished="RFC 4334 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4334",
  pages="1--11",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4334.txt",
  key="RFC 4334",
  abstract={This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs).  This document obsoletes RFC 3770. [STANDARDS-TRACK]},
  keywords="eap, extensible authentication protocol, wireless lan, wlan, system service identifier, ssid",
  doi="10.17487/RFC4334",
  }

@misc{rfc4335,
  author="J. Galbraith and P. Remaker",
  title="{The Secure Shell (SSH) Session Channel Break Extension}",
  howpublished="RFC 4335 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4335",
  pages="1--6",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4335.txt",
  key="RFC 4335",
  abstract={The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4335",
  }

@misc{rfc4336,
  author="S. Floyd and M. Handley and E. Kohler",
  title="{Problem Statement for the Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 4336 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4336",
  pages="1--22",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4336.txt",
  key="RFC 4336",
  abstract={This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control.  DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4336",
  }

@misc{rfc4337,
  author="Y Lim and D. Singer",
  title="{MIME Type Registration for MPEG-4}",
  howpublished="RFC 4337 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4337",
  pages="1--11",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6381",
url="https://www.rfc-editor.org/rfc/rfc4337.txt",
  key="RFC 4337",
  abstract={This document defines the standard MIME types associated with MP4 files.  It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4337",
  }

@misc{rfc4338,
  author="C. DeSanti and C. Carlson and R. Nixon",
  title="{Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel}",
  howpublished="RFC 4338 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4338",
  pages="1--33",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5494, 8064",
url="https://www.rfc-editor.org/rfc/rfc4338.txt",
  key="RFC 4338",
  abstract={This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]},
  keywords="link local address, link-local address",
  doi="10.17487/RFC4338",
  }

@misc{rfc4339,
  author="J. Jeong",
  title="{IPv6 Host Configuration of DNS Server Information Approaches}",
  howpublished="RFC 4339 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4339",
  pages="1--26",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4339.txt",
  key="RFC 4339",
  abstract={This document describes three approaches for IPv6 recursive DNS server address configuration.  It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers.  Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.  This memo provides information for the Internet community.},
  keywords="domain name server, internet protocol, address configuration, dhcpv6, dynamic host configuration protocol",
  doi="10.17487/RFC4339",
  }

@misc{rfc4340,
  author="E. Kohler and M. Handley and S. Floyd",
  title="{Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 4340 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4340",
  pages="1--129",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5595, 5596, 6335, 6773",
url="https://www.rfc-editor.org/rfc/rfc4340.txt",
  key="RFC 4340",
  abstract={The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams.  DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]},
  keywords="transport protocol",
  doi="10.17487/RFC4340",
  }

@misc{rfc4341,
  author="S. Floyd and E. Kohler",
  title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control}",
  howpublished="RFC 4341 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4341",
  pages="1--20",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4341.txt",
  key="RFC 4341",
  abstract={This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP).  CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]},
  keywords="transport protocol, amid, additive increase multiplicative decrease",
  doi="10.17487/RFC4341",
  }

@misc{rfc4342,
  author="S. Floyd and E. Kohler and J. Padhye",
  title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)}",
  howpublished="RFC 4342 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4342",
  pages="1--33",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5348, 6323",
url="https://www.rfc-editor.org/rfc/rfc4342.txt",
  key="RFC 4342",
  abstract={This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]},
  keywords="transport protocol, ecn, explicit congestion notification, ccid3",
  doi="10.17487/RFC4342",
  }

@misc{rfc4343,
  author="D. {Eastlake 3rd}",
  title="{Domain Name System (DNS) Case Insensitivity Clarification}",
  howpublished="RFC 4343 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4343",
  pages="1--10",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4343.txt",
  key="RFC 4343",
  abstract={Domain Name System (DNS) names are ``case insensitive''.  This document explains exactly what that means and provides a clear specification of the rules.  This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4343",
  }

@misc{rfc4344,
  author="M. Bellare and T. Kohno and C. Namprempre",
  title="{The Secure Shell (SSH) Transport Layer Encryption Modes}",
  howpublished="RFC 4344 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4344",
  pages="1--12",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4344.txt",
  key="RFC 4344",
  abstract={Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]},
  keywords="rekey",
  doi="10.17487/RFC4344",
  }

@misc{rfc4345,
  author="B. Harris",
  title="{Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 4345 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4345",
  pages="1--5",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4345.txt",
  key="RFC 4345",
  abstract={This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]},
  keywords="arcfour cipher, key scheduling algorithm",
  doi="10.17487/RFC4345",
  }

@misc{rfc4346,
  author="T. Dierks and E. Rescorla",
  title="{The Transport Layer Security (TLS) Protocol Version 1.1}",
  howpublished="RFC 4346 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4346",
  pages="1--87",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5246, updated by RFCs 4366, 4680, 4681, 5746, 6176, 7465, 7507, 7919",
url="https://www.rfc-editor.org/rfc/rfc4346.txt",
  key="RFC 4346",
  abstract={This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4346",
  }

@misc{rfc4347,
  author="E. Rescorla and N. Modadugu",
  title="{Datagram Transport Layer Security}",
  howpublished="RFC 4347 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4347",
  pages="1--25",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6347, updated by RFCs 5746, 7507",
url="https://www.rfc-editor.org/rfc/rfc4347.txt",
  key="RFC 4347",
  abstract={This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS-TRACK]},
  keywords="dtls",
  doi="10.17487/RFC4347",
  }

@misc{rfc4348,
  author="S. Ahmadi",
  title="{Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec}",
  howpublished="RFC 4348 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4348",
  pages="1--32",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4424",
url="https://www.rfc-editor.org/rfc/rfc4348.txt",
  key="RFC 4348",
  abstract={This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format. VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]},
  keywords="speech codec, variable-rate multicode wideband speech codec",
  doi="10.17487/RFC4348",
  }

@misc{rfc4349,
  author="C. Pignataro and M. Townsley",
  title="{High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)}",
  howpublished="RFC 4349 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4349",
  pages="1--11",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5641",
url="https://www.rfc-editor.org/rfc/rfc4349.txt",
  key="RFC 4349",
  abstract={The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks.  This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]},
  keywords="pseudowire",
  doi="10.17487/RFC4349",
  }

@misc{rfc4350,
  author="F. Hendrikx and C. Wallis",
  title="{A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government}",
  howpublished="RFC 4350 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4350",
  pages="1--11",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4350.txt",
  key="RFC 4350",
  abstract={This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government.  This memo provides information for the Internet community.},
  keywords="nid, namespace identification",
  doi="10.17487/RFC4350",
  }

@misc{rfc4351,
  author="G. Hellstrom and P. Jones",
  title="{Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream}",
  howpublished="RFC 4351 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4351",
  pages="1--20",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4351.txt",
  key="RFC 4351",
  abstract={This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting audio and text data within a single RTP session. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.},
  keywords="itu-t recommendation t.140",
  doi="10.17487/RFC4351",
  }

@misc{rfc4352,
  author="J. Sjoberg and M. Westerlund and A. Lakaniemi and S. Wenger",
  title="{RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec}",
  howpublished="RFC 4352 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4352",
  pages="1--38",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4352.txt",
  key="RFC 4352",
  abstract={This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals.  The AMR-WB+ codec is an audio extension of the AMR-WB speech codec.  It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech.  A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, audio signals",
  doi="10.17487/RFC4352",
  }

@misc{rfc4353,
  author="J. Rosenberg",
  title="{A Framework for Conferencing with the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4353 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4353",
  pages="1--29",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4353.txt",
  key="RFC 4353",
  abstract={The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.  These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents.  Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious.  Communications sessions with multiple participants, generally known as conferencing, are more complicated.  This document defines a framework for how such conferencing can occur.  This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4353",
  }

@misc{rfc4354,
  author="M. Garcia-Martin",
  title="{A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service}",
  howpublished="RFC 4354 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4354",
  pages="1--21",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4354.txt",
  key="RFC 4354",
  abstract={The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc.  This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service.  This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.  This memo provides information for the Internet community.},
  keywords="oma, open mobile alliance",
  doi="10.17487/RFC4354",
  }

@misc{rfc4355,
  author="R. Brandner and L. Conroy and R. Stastny",
  title="{IANA Registration for Enumservices email, fax, mms, ems, and sms}",
  howpublished="RFC 4355 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4355",
  pages="1--16",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4355.txt",
  key="RFC 4355",
  abstract={This document registers the Enumservices ``email'', ``fax'', ``sms'', ``ems'', and ``mms'' using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]},
  keywords="domain name system",
  doi="10.17487/RFC4355",
  }

@misc{rfc4356,
  author="R. Gellens",
  title="{Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail}",
  howpublished="RFC 4356 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4356",
  pages="1--31",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4356.txt",
  key="RFC 4356",
  abstract={The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail. One important difference between MMS and Internet Mail is that MMS uses headers that start with ``X-Mms-'' to carry a variety of user agent- and server-related information elements. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]},
  keywords="cellular telephone, x-mms",
  doi="10.17487/RFC4356",
  }

@misc{rfc4357,
  author="V. Popov and I. Kurepkin and S. Leontiev",
  title="{Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms}",
  howpublished="RFC 4357 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4357",
  pages="1--51",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4357.txt",
  key="RFC 4357",
  abstract={This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications.  This memo provides information for the Internet community.},
  keywords="cpalgs, public-key, one-way, hash, block, cipher, encyption, decryption, mac, hmac, prf, wrap, unwrap, ukm, kek, key, parameter, derivation, digest, cbc, counter, mode, digital, signature",
  doi="10.17487/RFC4357",
  }

@misc{rfc4358,
  author="D. Smith",
  title="{A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)}",
  howpublished="RFC 4358 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4358",
  pages="1--6",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4358.txt",
  key="RFC 4358",
  abstract={This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA).  OMA defines and manages resources that utilize this URN name model.  Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA).  This memo provides information for the Internet community.},
  keywords="nid, namespace identifier, omna, open mobile naming authority",
  doi="10.17487/RFC4358",
  }

@misc{rfc4359,
  author="B. Weis",
  title="{The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)}",
  howpublished="RFC 4359 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4359",
  pages="1--12",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4359.txt",
  key="RFC 4359",
  abstract={This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302.  The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property.  One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]},
  keywords="ip encapsulating security payload, digital signature",
  doi="10.17487/RFC4359",
  }

@misc{rfc4360,
  author="S. Sangli and D. Tappan and Y. Rekhter",
  title="{BGP Extended Communities Attribute}",
  howpublished="RFC 4360 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4360",
  pages="1--12",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7153, 7606",
url="https://www.rfc-editor.org/rfc/rfc4360.txt",
  key="RFC 4360",
  abstract={This document describes the ``extended community'' BGP-4 attribute.  This attribute provides a mechanism for labeling information carried in BGP-4.  These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4360",
  }

@misc{rfc4361,
  author="T. Lemon and B. Sommerfeld",
  title="{Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)}",
  howpublished="RFC 4361 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4361",
  pages="1--12",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc4361.txt",
  key="RFC 4361",
  abstract={This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol.  This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]},
  keywords="dhcpv6",
  doi="10.17487/RFC4361",
  }

@misc{rfc4362,
  author="L-E. Jonsson and G. Pelletier and K. Sandlund",
  title="{RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP}",
  howpublished="RFC 4362 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4362",
  pages="1--23",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4815",
url="https://www.rfc-editor.org/rfc/rfc4362.txt",
  key="RFC 4362",
  abstract={This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation.  The profile is built as an extension to the ROHC RTP profile.  It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format.  This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]},
  keywords="internet protocol, user datagram protocol, real-time transport protocol",
  doi="10.17487/RFC4362",
  }

@misc{rfc4363,
  author="D. Levi and D. Harrington",
  title="{Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions}",
  howpublished="RFC 4363 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4363",
  pages="1--99",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4363.txt",
  key="RFC 4363",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM). Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]},
  keywords="mib, management information base, mac bridges, traffic classes, enhanced multicast filtering, p-bridge-mib, q-bridge-mib",
  doi="10.17487/RFC4363",
  }

@misc{rfc4364,
  author="E. Rosen and Y. Rekhter",
  title="{BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 4364 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4364",
  pages="1--47",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4577, 4684, 5462",
url="https://www.rfc-editor.org/rfc/rfc4364.txt",
  key="RFC 4364",
  abstract={This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers.  This method uses a ``peer model'', in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no ``overlay'' visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other.  Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]},
  keywords="service provider, ip backbone, ce router, pe router, border, gateway, protocol, multiprotocol, label, switching, architecture, virtual, private, networks",
  doi="10.17487/RFC4364",
  }

@misc{rfc4365,
  author="E. Rosen",
  title="{Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 4365 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4365",
  pages="1--32",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4365.txt",
  key="RFC 4365",
  abstract={This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4365",
  }

@misc{rfc4366,
  author="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and T. Wright",
  title="{Transport Layer Security (TLS) Extensions}",
  howpublished="RFC 4366 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4366",
  pages="1--30",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5246, 6066, updated by RFC 5746",
url="https://www.rfc-editor.org/rfc/rfc4366.txt",
  key="RFC 4366",
  abstract={This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]},
  keywords="transport, protocol, layer, authentication, privacy",
  doi="10.17487/RFC4366",
  }

@misc{rfc4367,
  author="J. Rosenberg and IAB",
  title="{What's in a Name: False Assumptions about DNS Names}",
  howpublished="RFC 4367 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4367",
  pages="1--17",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4367.txt",
  key="RFC 4367",
  abstract={The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses.  These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users.  Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on.  There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names.  Those assumptions can often be false, resulting in a variety of failure conditions.  This document discusses this problem in more detail and makes recommendations on how it can be avoided.  This memo provides information for the Internet community.},
  keywords="domain name system",
  doi="10.17487/RFC4367",
  }

@misc{rfc4368,
  author="T. Nadeau and S. Hegde",
  title="{Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition}",
  howpublished="RFC 4368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4368",
  pages="1--22",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4368.txt",
  key="RFC 4368",
  abstract={This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]},
  keywords="management information base, mpls-lc-atm-std-mib, mpls-lc-fr-std-mib",
  doi="10.17487/RFC4368",
  }

@misc{rfc4369,
  author="K. Gibbons and C. Monia and J. Tseng and F. Travostino",
  title="{Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)}",
  howpublished="RFC 4369 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4369",
  pages="1--29",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6173",
url="https://www.rfc-editor.org/rfc/rfc4369.txt",
  key="RFC 4369",
  abstract={The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components.  The iFCP protocol is used between iFCP Gateways.  This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]},
  keywords="mib, management information base, snmp, simple network management protocol, ifcp gateway, ifcp-mgmt-mib",
  doi="10.17487/RFC4369",
  }

@misc{rfc4370,
  author="R. Weltman",
  title="{Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control}",
  howpublished="RFC 4370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4370",
  pages="1--5",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4370.txt",
  key="RFC 4370",
  abstract={This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control.  The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]},
  keywords="proxy authorization control",
  doi="10.17487/RFC4370",
  }

@misc{rfc4371,
  author="B. Carpenter and L. Lynch",
  title="{BCP 101 Update for IPR Trust}",
  howpublished="RFC 4371 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4371",
  pages="1--4",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4371.txt",
  key="RFC 4371",
  abstract={This document updates BCP 101 to take account of the new IETF Intellectual Property Trust.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4371",
  }

@misc{rfc4372,
  author="F. Adrangi and A. Lior and J. Korhonen and J. Loughney",
  title="{Chargeable User Identity}",
  howpublished="RFC 4372 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4372",
  pages="1--10",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4372.txt",
  key="RFC 4372",
  abstract={This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity.  This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]},
  keywords="radius, remote authentication dial-in user service, roaming transaction, home network",
  doi="10.17487/RFC4372",
  }

@misc{rfc4373,
  author="R. Harrison and J. Sermersheim and Y. Dong",
  title="{Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)}",
  howpublished="RFC 4373 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4373",
  pages="1--16",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4373.txt",
  key="RFC 4373",
  abstract={The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication. The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.},
  doi="10.17487/RFC4373",
  }

@misc{rfc4374,
  author="G. McCobb",
  title="{The application/xv+xml Media Type}",
  howpublished="RFC 4374 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4374",
  pages="1--6",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4374.txt",
  key="RFC 4374",
  abstract={This document describes the registration of the MIME sub-type application/xv+xml.  This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents.  This memo provides information for the Internet community.},
  keywords="mime, sub-type, media descriptor, xhtml+voice",
  doi="10.17487/RFC4374",
  }

@misc{rfc4375,
  author="K. Carlberg",
  title="{Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain}",
  howpublished="RFC 4375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4375",
  pages="1--8",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4375.txt",
  key="RFC 4375",
  abstract={This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain.  This document focuses on a specific set of administrative constraints and scope.  Solutions to these requirements are not presented in this document.  This memo provides information for the Internet community.},
  keywords="resource, transit domain, stub domain",
  doi="10.17487/RFC4375",
  }

@misc{rfc4376,
  author="P. Koskelainen and J. Ott and H. Schulzrinne and X. Wu",
  title="{Requirements for Floor Control Protocols}",
  howpublished="RFC 4376 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4376",
  pages="1--14",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4376.txt",
  key="RFC 4376",
  abstract={Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.  Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.  This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.  This memo provides information for the Internet community.},
  keywords="shared resources, multiparty conferences",
  doi="10.17487/RFC4376",
  }

@misc{rfc4377,
  author="T. Nadeau and M. Morrow and G. Swallow and D. Allan and S. Matsushima",
  title="{Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks}",
  howpublished="RFC 4377 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4377",
  pages="1--15",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4377.txt",
  key="RFC 4377",
  abstract={This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services.  These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4377",
  }

@misc{rfc4378,
  author="D. Allan and T. Nadeau",
  title="{A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)}",
  howpublished="RFC 4378 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4378",
  pages="1--11",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4378.txt",
  key="RFC 4378",
  abstract={This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS).  The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.  This memo provides information for the Internet community.},
  keywords="data plane, fcaps",
  doi="10.17487/RFC4378",
  }

@misc{rfc4379,
  author="K. Kompella and G. Swallow",
  title="{Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures}",
  howpublished="RFC 4379 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4379",
  pages="1--50",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8029, updated by RFCs 5462, 6424, 6425, 6426, 6829, 7506, 7537, 7743",
url="https://www.rfc-editor.org/rfc/rfc4379.txt",
  key="RFC 4379",
  abstract={This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs).  There are two parts to this document: information carried in an MPLS ``echo request'' and ``echo reply'' for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]},
  keywords="data plane",
  doi="10.17487/RFC4379",
  }

@misc{rfc4380,
  author="C. Huitema",
  title="{Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)}",
  howpublished="RFC 4380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4380",
  pages="1--53",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5991, 6081",
url="https://www.rfc-editor.org/rfc/rfc4380.txt",
  key="RFC 4380",
  abstract={We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service.  Running the service requires the help of ``Teredo servers'' and ``Teredo relays''.  The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the ``native'' IPv6 Internet.  The relays can also provide interoperability with hosts using other transition mechanisms such as ``6to4''. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4380",
  }

@misc{rfc4381,
  author="M. Behringer",
  title="{Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 4381 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4381",
  pages="1--22",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4381.txt",
  key="RFC 4381",
  abstract={This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.},
  keywords="service provider, atm, asynchronous transfer mode, frame relay",
  doi="10.17487/RFC4381",
  }

@misc{rfc4382,
  author="T. Nadeau and H. van der Linde",
  title="{MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base}",
  howpublished="RFC 4382 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4382",
  pages="1--44",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4382.txt",
  key="RFC 4382",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]},
  keywords="mib, management information base, multiprotocol label switching, label switching router, lsr, mpls-l3vpn-std-mib",
  doi="10.17487/RFC4382",
  }

@misc{rfc4383,
  author="M. Baugher and E. Carrara",
  title="{The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 4383 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4383",
  pages="1--19",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4383.txt",
  key="RFC 4383",
  abstract={This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]},
  keywords="multicast data stream, broadcast data stream",
  doi="10.17487/RFC4383",
  }

@misc{rfc4384,
  author="D. Meyer",
  title="{BGP Communities for Data Collection}",
  howpublished="RFC 4384 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4384",
  pages="1--12",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4384.txt",
  key="RFC 4384",
  abstract={BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes.  Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers.  With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system.  This memo defines standard (outbound) communities and their encodings for export to BGP route collectors.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4384",
  }

@misc{rfc4385,
  author="S. Bryant and G. Swallow and L. Martini and D. McPherson",
  title="{Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN}",
  howpublished="RFC 4385 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4385",
  pages="1--12",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5586",
url="https://www.rfc-editor.org/rfc/rfc4385.txt",
  key="RFC 4385",
  abstract={This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header.  The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, packet switched network, pseudowire associated channel header",
  doi="10.17487/RFC4385",
  }

@misc{rfc4386,
  author="S. Boeyen and P. Hallam-Baker",
  title="{Internet X.509 Public Key Infrastructure Repository Locator Service}",
  howpublished="RFC 4386 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4386",
  pages="1--6",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4386.txt",
  key="RFC 4386",
  abstract={This document defines a Public Key Infrastructure (PKI) repository locator service.  The service makes use of DNS SRV records defined in accordance with RFC 2782.  The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.},
  keywords="pki, public key infrastructure, dns srv",
  doi="10.17487/RFC4386",
  }

@misc{rfc4387,
  author="P. Gutmann",
  title="{Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP}",
  howpublished="RFC 4387 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4387",
  pages="1--25",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4387.txt",
  key="RFC 4387",
  abstract={The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI).  This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories.  Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]},
  keywords="pki, hypertext transfer protocol",
  doi="10.17487/RFC4387",
  }

@misc{rfc4388,
  author="R. Woundy and K. Kinnear",
  title="{Dynamic Host Configuration Protocol (DHCP) Leasequery}",
  howpublished="RFC 4388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4388",
  pages="1--27",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6148",
url="https://www.rfc-editor.org/rfc/rfc4388.txt",
  key="RFC 4388",
  abstract={A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients.  Other processes and devices that already make use of DHCPv4 may need to access this information.  The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]},
  keywords="dhcpv4, ip address",
  doi="10.17487/RFC4388",
  }

@misc{rfc4389,
  author="D. Thaler and M. Talwar and C. Patel",
  title="{Neighbor Discovery Proxies (ND Proxy)}",
  howpublished="RFC 4389 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4389",
  pages="1--18",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4389.txt",
  key="RFC 4389",
  abstract={Bridging multiple links into a single entity has several operational advantages.  A single subnet prefix is sufficient to support multiple physical links.  There is no need to allocate subnet numbers to the different networks, simplifying management.  Bridging some types of media requires network-layer support, however.  This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ndproxy",
  doi="10.17487/RFC4389",
  }

@misc{rfc4390,
  author="V. Kashyap",
  title="{Dynamic Host Configuration Protocol (DHCP) over InfiniBand}",
  howpublished="RFC 4390 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4390",
  pages="1--6",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4390.txt",
  key="RFC 4390",
  abstract={IP over Infiniband (IPoIB) link-layer address is 20 octets long.  This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message.  The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network.  This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]},
  keywords="bootstrap, boot, ipoib",
  doi="10.17487/RFC4390",
  }

@misc{rfc4391,
  author="J. Chu and V. Kashyap",
  title="{Transmission of IP over InfiniBand (IPoIB)}",
  howpublished="RFC 4391 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4391",
  pages="1--21",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc4391.txt",
  key="RFC 4391",
  abstract={This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB).  It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets.  The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses.  In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]},
  keywords="address resolution protocol, arp, ib",
  doi="10.17487/RFC4391",
  }

@misc{rfc4392,
  author="V. Kashyap",
  title="{IP over InfiniBand (IPoIB) Architecture}",
  howpublished="RFC 4392 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4392",
  pages="1--23",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4392.txt",
  key="RFC 4392",
  abstract={InfiniBand is a high-speed, channel-based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.},
  keywords="ib, ipv4, ipv6",
  doi="10.17487/RFC4392",
  }

@misc{rfc4393,
  author="H. Garudadri",
  title="{MIME Type Registrations for 3GPP2 Multimedia Files}",
  howpublished="RFC 4393 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4393",
  pages="1--7",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6381",
url="https://www.rfc-editor.org/rfc/rfc4393.txt",
  key="RFC 4393",
  abstract={This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]},
  keywords="third-generation partnership project 2",
  doi="10.17487/RFC4393",
  }

@misc{rfc4394,
  author="D. Fedyk and O. Aboul-Magd and D. Brungard and J. Lang and D. Papadimitriou",
  title="{A Transport Network View of the Link Management Protocol (LMP)}",
  howpublished="RFC 4394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4394",
  pages="1--18",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4394.txt",
  key="RFC 4394",
  abstract={The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links.  The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs).  This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work.  This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.  This memo provides information for the Internet community.},
  keywords="gmpls, ason, discovery, sdh, otn, sonet, pdh",
  doi="10.17487/RFC4394",
  }

@misc{rfc4395,
  author="T. Hansen and T. Hardie and L. Masinter",
  title="{Guidelines and Registration Procedures for New URI Schemes}",
  howpublished="RFC 4395 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4395",
  pages="1--15",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7595",
url="https://www.rfc-editor.org/rfc/rfc4395.txt",
  key="RFC 4395",
  abstract={This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes.  It also updates the process and IANA registry for URI schemes.  It obsoletes both RFC 2717 and RFC 2718.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="uniform resource identifier, syntax, semantics",
  doi="10.17487/RFC4395",
  }

@misc{rfc4396,
  author="J. Rey and Y. Matsui",
  title="{RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text}",
  howpublished="RFC 4396 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4396",
  pages="1--66",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4396.txt",
  key="RFC 4396",
  abstract={This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text.  3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file.  Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations.  In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]},
  keywords="3GPP, 3GPP timed text, streaming,  real-time streaming, titling, decorated text, scrolling text, karaoke, hyperlinked text, highlighted text, blinking text, highlight color, text delay, text style, text box, text wrap, text sample, sample descriptions, modifier boxes, UTF-8, UTF-16",
  doi="10.17487/RFC4396",
  }

@misc{rfc4397,
  author="I. Bryskin and A. Farrel",
  title="{A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture}",
  howpublished="RFC 4397 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4397",
  pages="1--19",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4397.txt",
  key="RFC 4397",
  abstract={Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.},
  doi="10.17487/RFC4397",
  }

@misc{rfc4398,
  author="S. Josefsson",
  title="{Storing Certificates in the Domain Name System (DNS)}",
  howpublished="RFC 4398 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4398",
  pages="1--17",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc4398.txt",
  key="RFC 4398",
  abstract={Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates.  A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]},
  keywords="SC-DNS, cryptology, authenticity",
  doi="10.17487/RFC4398",
  }

@misc{rfc4401,
  author="N. Williams",
  title="{A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)}",
  howpublished="RFC 4401 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4401",
  pages="1--8",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4401.txt",
  key="RFC 4401",
  abstract={This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context.  The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]},
  keywords="secure session layer, message integrity check, mic",
  doi="10.17487/RFC4401",
  }

@misc{rfc4402,
  author="N. Williams",
  title="{A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism}",
  howpublished="RFC 4402 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4402",
  pages="1--5",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7802",
url="https://www.rfc-editor.org/rfc/rfc4402.txt",
  key="RFC 4402",
  abstract={This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4402",
  }

@misc{rfc4403,
  author="B. Bergeson and K. Boogert and V. Nanjundaswamy",
  title="{Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)}",
  howpublished="RFC 4403 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4403",
  pages="1--42",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4403.txt",
  key="RFC 4403",
  abstract={This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory.  It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.  This memo provides information for the Internet community.},
  keywords="LDAPv3",
  doi="10.17487/RFC4403",
  }

@misc{rfc4404,
  author="R. Natarajan and A. Rijhsinghani",
  title="{Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)}",
  howpublished="RFC 4404 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4404",
  pages="1--33",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4404.txt",
  key="RFC 4404",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]},
  keywords="mib, management information base, fcip-mgmt-mib",
  doi="10.17487/RFC4404",
  }

@misc{rfc4405,
  author="E. Allman and H. Katz",
  title="{SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message}",
  howpublished="RFC 4405 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4405",
  pages="1--14",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4405.txt",
  key="RFC 4405",
  abstract={This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message.  The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream.  This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="spam, spoofing, phishing",
  doi="10.17487/RFC4405",
  }

@misc{rfc4406,
  author="J. Lyon and M. Wong",
  title="{Sender ID: Authenticating E-Mail}",
  howpublished="RFC 4406 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4406",
  pages="1--19",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4406.txt",
  key="RFC 4406",
  abstract={Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- ``spoofed'' in this case means that the address is used without the permission of the domain owner.  This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="simple mail transfer protocol, spam, spoofing",
  doi="10.17487/RFC4406",
  }

@misc{rfc4407,
  author="J. Lyon",
  title="{Purported Responsible Address in E-Mail Messages}",
  howpublished="RFC 4407 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4407",
  pages="1--7",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4407.txt",
  key="RFC 4407",
  abstract={This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered.  This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.},
  keywords="pra, purported responsible address",
  doi="10.17487/RFC4407",
  }

@misc{rfc4408,
  author="M. Wong and W. Schlitt",
  title="{Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1}",
  howpublished="RFC 4408 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4408",
  pages="1--48",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7208, updated by RFC 6652",
url="https://www.rfc-editor.org/rfc/rfc4408.txt",
  key="RFC 4408",
  abstract={E-mail on the Internet can be forged in a number of ways.  In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands.  This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="spoofing, spf",
  doi="10.17487/RFC4408",
  }

@misc{rfc4409,
  author="R. Gellens and J. Klensin",
  title="{Message Submission for Mail}",
  howpublished="RFC 4409 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4409",
  pages="1--17",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6409",
url="https://www.rfc-editor.org/rfc/rfc4409.txt",
  key="RFC 4409",
  abstract={This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay and final delivery are unaffected, and continue to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]},
  keywords="smtp, simle mail transfer protocol, ua, user agent",
  doi="10.17487/RFC4409",
  }

@misc{rfc4410,
  author="M. Pullen and F. Zhao and D. Cohen",
  title="{Selectively Reliable Multicast Protocol (SRMP)}",
  howpublished="RFC 4410 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4410",
  pages="1--30",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4410.txt",
  key="RFC 4410",
  abstract={The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection.  SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery.  SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer.  Selection between reliable and best-effort messages is performed by the application.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="transport, best-effort, srt, selectively reliable transport",
  doi="10.17487/RFC4410",
  }

@misc{rfc4411,
  author="J. Polk",
  title="{Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events}",
  howpublished="RFC 4411 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4411",
  pages="1--22",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4411.txt",
  key="RFC 4411",
  abstract={This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS).  This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]},
  keywords="Resource-Priority, preempt, preempted, Q.850, preconditions",
  doi="10.17487/RFC4411",
  }

@misc{rfc4412,
  author="H. Schulzrinne and J. Polk",
  title="{Communications Resource Priority for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4412 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4412",
  pages="1--36",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7134",
url="https://www.rfc-editor.org/rfc/rfc4412.txt",
  key="RFC 4412",
  abstract={This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, ``Resource-Priority'' and ``Accept-Resource-Priority''.  The ``Resource-Priority'' header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies.  It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]},
  keywords="RP, RPH, preferential, preempt, preempted, preemption, queue, DSN, DRSN, WPS, ETS, Q.735, Q735, disaster, I.255, flash, flash-override",
  doi="10.17487/RFC4412",
  }

@misc{rfc4413,
  author="M. West and S. McCann",
  title="{TCP/IP Field Behavior}",
  howpublished="RFC 4413 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4413",
  pages="1--44",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4413.txt",
  key="RFC 4413",
  abstract={This memo describes TCP/IP field behavior in the context of header compression.  Header compression is possible because most header fields do not vary randomly from packet to packet.  Many of the fields exhibit static behavior or change in a more or less predictable way.  When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail.  An example of this analysis can be seen in RFC 3095.  This memo performs a similar role for the compression of TCP/IP headers.  This memo provides information for the Internet community.},
  keywords="transmission control protocol, header compression",
  doi="10.17487/RFC4413",
  }

@misc{rfc4414,
  author="A. Newton",
  title="{An ENUM Registry Type for the Internet Registry Information Service (IRIS)}",
  howpublished="RFC 4414 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4414",
  pages="1--51",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4414.txt",
  key="RFC 4414",
  abstract={This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information.  The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4414",
  }

@misc{rfc4415,
  author="R. Brandner and L. Conroy and R. Stastny",
  title="{IANA Registration for Enumservice Voice}",
  howpublished="RFC 4415 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4415",
  pages="1--8",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4415.txt",
  key="RFC 4415",
  abstract={This document registers the Enumservice ``voice'' (which has a defined subtype ``tel''), as per the IANA registration process defined in the ENUM specification RFC 3761.  This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, uri, voice call, audio call",
  doi="10.17487/RFC4415",
  }

@misc{rfc4416,
  author="J. Wong",
  title="{Goals for Internet Messaging to Support Diverse Service Environments}",
  howpublished="RFC 4416 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4416",
  pages="1--43",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4416.txt",
  key="RFC 4416",
  abstract={This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail. The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols. The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.},
  keywords="IMAP, protocol extensions, messaging, wireless, handheld, telephone user interface, multi-modal, LEMONADE, extension principles, history, background, motivation, cellular, interworking, constraints, TUI, WUI, client, MMS",
  doi="10.17487/RFC4416",
  }

@misc{rfc4417,
  author="P. Resnick and P. Saint-Andre",
  title="{Report of the 2004 IAB Messaging Workshop}",
  howpublished="RFC 4417 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4417",
  pages="1--20",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4417.txt",
  key="RFC 4417",
  abstract={This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging.  The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.  The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done.  This report summarizes the discussions and conclusions of the workshop and of the IAB.  This memo provides information for the Internet community.},
  keywords="internet architecture board, internet messaging",
  doi="10.17487/RFC4417",
  }

@misc{rfc4418,
  author="T. Krovetz",
  title="{UMAC: Message Authentication Code using Universal Hashing}",
  howpublished="RFC 4418 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4418",
  pages="1--27",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4418.txt",
  key="RFC 4418",
  abstract={This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, a ``universal'' hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal ``cryptographic'' component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.},
  doi="10.17487/RFC4418",
  }

@misc{rfc4419,
  author="M. Friedl and N. Provos and W. Simpson",
  title="{Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 4419 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4419",
  pages="1--10",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4419.txt",
  key="RFC 4419",
  abstract={This memo describes a new key exchange method for the Secure Shell (SSH) protocol.  It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client.  The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4419",
  }

@misc{rfc4420,
  author="A. Farrel and D. Papadimitriou and J.-P. Vasseur and A. Ayyangar",
  title="{Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)}",
  howpublished="RFC 4420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4420",
  pages="1--21",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5420",
url="https://www.rfc-editor.org/rfc/rfc4420.txt",
  key="RFC 4420",
  abstract={Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION\_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]},
  keywords="SESSION\_ATTRIBUTE",
  doi="10.17487/RFC4420",
  }

@misc{rfc4421,
  author="C. Perkins",
  title="{RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes}",
  howpublished="RFC 4421 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4421",
  pages="1--4",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4421.txt",
  key="RFC 4421",
  abstract={The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP.  This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]},
  keywords="realtime transport protocol, video stream",
  doi="10.17487/RFC4421",
  }

@misc{rfc4422,
  author="A. Melnikov and  K. Zeilenga",
  title="{Simple Authentication and Security Layer (SASL)}",
  howpublished="RFC 4422 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4422",
  pages="1--33",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4422.txt",
  key="RFC 4422",
  abstract={The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. [STANDARDS-TRACK]},
  keywords="SASL, encryption, protocol specific",
  doi="10.17487/RFC4422",
  }

@misc{rfc4423,
  author="R. Moskowitz and P. Nikander",
  title="{Host Identity Protocol (HIP) Architecture}",
  howpublished="RFC 4423 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4423",
  pages="1--24",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4423.txt",
  key="RFC 4423",
  abstract={This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers.  Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them.  The roles of this new namespace in the protocols are defined.  The memo describes the thinking of the authors as of Fall 2003.  The architecture may have evolved since.  This document represents one stable point in that evolution of understanding.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4423",
  }

@misc{rfc4424,
  author="S. Ahmadi",
  title="{Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec}",
  howpublished="RFC 4424 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4424",
  pages="1--8",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4424.txt",
  key="RFC 4424",
  abstract={This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348. The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]},
  keywords="speech codec, variable-rate multicode wideband speech codec",
  doi="10.17487/RFC4424",
  }

@misc{rfc4425,
  author="A. Klemets",
  title="{RTP Payload Format for Video Codec 1 (VC-1)}",
  howpublished="RFC 4425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4425",
  pages="1--36",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4425.txt",
  key="RFC 4425",
  abstract={This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.  SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]},
  keywords="smpte 421m, wmv, wmv9, vc-9",
  doi="10.17487/RFC4425",
  }

@misc{rfc4426,
  author="J. Lang and B. Rajagopalan and D. Papadimitriou",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification}",
  howpublished="RFC 4426 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4426",
  pages="1--23",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4426.txt",
  key="RFC 4426",
  abstract={This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration).  Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4426",
  }

@misc{rfc4427,
  author="E. Mannie and D. Papadimitriou",
  title="{Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 4427 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4427",
  pages="1--22",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4427.txt",
  key="RFC 4427",
  abstract={This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration).  The terminology is independent of the underlying transport technologies covered by GMPLS.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4427",
  }

@misc{rfc4428,
  author="D. Papadimitriou and E. Mannie",
  title="{Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)}",
  howpublished="RFC 4428 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4428",
  pages="1--47",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4428.txt",
  key="RFC 4428",
  abstract={This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group.  A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427.  This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4428",
  }

@misc{rfc4429,
  author="N. Moore",
  title="{Optimistic Duplicate Address Detection (DAD) for IPv6}",
  howpublished="RFC 4429 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4429",
  pages="1--17",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7527",
url="https://www.rfc-editor.org/rfc/rfc4429.txt",
  key="RFC 4429",
  abstract={Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes.  The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]},
  keywords="internet protocol version 6, stateless address autoconfiguration, neighbor discovery",
  doi="10.17487/RFC4429",
  }

@misc{rfc4430,
  author="S. Sakane and K. Kamada and M. Thomas and J. Vilhuber",
  title="{Kerberized Internet Negotiation of Keys (KINK)}",
  howpublished="RFC 4430 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4430",
  pages="1--40",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4430.txt",
  key="RFC 4430",
  abstract={This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol.  KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system.  KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]},
  keywords="ike, internet key exchange",
  doi="10.17487/RFC4430",
  }

@misc{rfc4431,
  author="M. Andrews and S. Weiler",
  title="{The DNSSEC Lookaside Validation (DLV) DNS Resource Record}",
  howpublished="RFC 4431 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4431",
  pages="1--4",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4431.txt",
  key="RFC 4431",
  abstract={This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain.  This memo provides information for the Internet community.},
  keywords="dns, domain name space",
  doi="10.17487/RFC4431",
  }

@misc{rfc4432,
  author="B. Harris",
  title="{RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 4432 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4432",
  pages="1--8",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4432.txt",
  key="RFC 4432",
  abstract={This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.  It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]},
  keywords="rivest-sharmir-adleman, public key encryption",
  doi="10.17487/RFC4432",
  }

@misc{rfc4433,
  author="M. Kulkarni and A. Patel and K. Leung",
  title="{Mobile IPv4 Dynamic Home Agent (HA) Assignment}",
  howpublished="RFC 4433 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4433",
  pages="1--25",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4433.txt",
  key="RFC 4433",
  abstract={Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN).  This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection.  The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]},
  keywords="internet protocol, messaging",
  doi="10.17487/RFC4433",
  }

@misc{rfc4434,
  author="P. Hoffman",
  title="{The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)}",
  howpublished="RFC 4434 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4434",
  pages="1--6",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4434.txt",
  key="RFC 4434",
  abstract={Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES).  This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]},
  keywords="security, ipsec, advanced encryption standard, mac, message authentication code",
  doi="10.17487/RFC4434",
  }

@misc{rfc4435,
  author="Y. Nomura and R. Walsh and J-P. Luoma and H. Asaeda and H. Schulzrinne",
  title="{A Framework for the Usage of Internet Media Guides (IMGs)}",
  howpublished="RFC 4435 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4435",
  pages="1--22",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4435.txt",
  key="RFC 4435",
  abstract={This document defines a framework for the delivery of Internet Media Guides (IMGs).  An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format.  This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.  This memo provides information for the Internet community.},
  keywords="session description protocol, sdp, sdpng",
  doi="10.17487/RFC4435",
  }

@misc{rfc4436,
  author="B. Aboba and J. Carlson and S. Cheshire",
  title="{Detecting Network Attachment in IPv4 (DNAv4)}",
  howpublished="RFC 4436 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4436",
  pages="1--15",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4436.txt",
  key="RFC 4436",
  abstract={The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment.  This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC4436",
  }

@misc{rfc4437,
  author="J. Whitehead and G. Clemm and J. Reschke",
  title="{Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources}",
  howpublished="RFC 4437 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4437",
  pages="1--25",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4437.txt",
  key="RFC 4437",
  abstract={This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code.  A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource.  This specification does not address remapping of trees of resources or regular expression based redirections.  There are no integrity guarantees associated with redirect reference resources.  Other mechanisms can also be used to achieve the same functionality as this specification.  This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="http, hyper text transfer protocol",
  doi="10.17487/RFC4437",
  }

@misc{rfc4438,
  author="C. DeSanti and V. Gaonkar and H.K. Vivek and K. McCloghrie and S. Gai",
  title="{Fibre-Channel Name Server MIB}",
  howpublished="RFC 4438 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4438",
  pages="1--36",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4438.txt",
  key="RFC 4438",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network.  The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]},
  keywords="management information base, T11-fc-name-server-mib",
  doi="10.17487/RFC4438",
  }

@misc{rfc4439,
  author="C. DeSanti and V. Gaonkar and K. McCloghrie and S. Gai",
  title="{Fibre Channel Fabric Address Manager MIB}",
  howpublished="RFC 4439 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4439",
  pages="1--40",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4439.txt",
  key="RFC 4439",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]},
  keywords="management information base, t11-tc-mib, t11-fc-fabric-addr-mgr-mib",
  doi="10.17487/RFC4439",
  }

@misc{rfc4440,
  author="S. Floyd and V. Paxson and A. Falk and IAB",
  title="{IAB Thoughts on the Role of the Internet Research Task Force (IRTF)}",
  howpublished="RFC 4440 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4440",
  pages="1--13",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4440.txt",
  key="RFC 4440",
  abstract={This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF.  This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF.  This memo provides information for the Internet community.},
  keywords="internet architecture board",
  doi="10.17487/RFC4440",
  }

@misc{rfc4441,
  author="B. Aboba",
  title="{The IEEE 802/IETF Relationship}",
  howpublished="RFC 4441 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4441",
  pages="1--22",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7241",
url="https://www.rfc-editor.org/rfc/rfc4441.txt",
  key="RFC 4441",
  abstract={Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications.  This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.  This memo provides information for the Internet community.},
  keywords="snmp, aaa, simple network management protocol, authentication, authorization, accounting",
  doi="10.17487/RFC4441",
  }

@misc{rfc4442,
  author="S. Fries and H. Tschofenig",
  title="{Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)}",
  howpublished="RFC 4442 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4442",
  pages="1--18",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4442.txt",
  key="RFC 4442",
  abstract={TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms. This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]},
  keywords="authentication, mikey, multimedia internet keying protocol",
  doi="10.17487/RFC4442",
  }

@misc{rfc4443,
  author="A. Conta and S. Deering and M. Gupta",
  title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification}",
  howpublished="RFC 4443 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4443",
  pages="1--24",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 4884",
url="https://www.rfc-editor.org/rfc/rfc4443.txt",
  key="RFC 4443",
  abstract={This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4443",
  }

@misc{rfc4444,
  author="J. Parker",
  title="{Management Information Base for Intermediate System to Intermediate System (IS-IS)}",
  howpublished="RFC 4444 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4444",
  pages="1--103",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4444.txt",
  key="RFC 4444",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]},
  keywords="mib, routing protocol, isis-mib",
  doi="10.17487/RFC4444",
  }

@misc{rfc4445,
  author="J. Welch and J. Clark",
  title="{A Proposed Media Delivery Index (MDI)}",
  howpublished="RFC 4445 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4445",
  pages="1--10",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4445.txt",
  key="RFC 4445",
  abstract={This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss.  It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow.  For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4445",
  }

@misc{rfc4446,
  author="L. Martini",
  title="{IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)}",
  howpublished="RFC 4446 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4446",
  pages="1--9",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4446.txt",
  key="RFC 4446",
  abstract={This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group.  Detailed IANA allocation instructions are also included in this document.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4446",
  }

@misc{rfc4447,
  author="L. Martini and E. Rosen and N. El-Aawar and T. Smith and G. Heron",
  title="{Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)}",
  howpublished="RFC 4447 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4447",
  pages="1--33",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8077, updated by RFCs 6723, 6870, 7358",
url="https://www.rfc-editor.org/rfc/rfc4447.txt",
  key="RFC 4447",
  abstract={Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be ``emulated'' over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over ``pseudowires''.  It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network.  This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]},
  keywords="mpls, multiprotocol label switching protocol, pdu, protocol data units",
  doi="10.17487/RFC4447",
  }

@misc{rfc4448,
  author="L. Martini and E. Rosen and N. El-Aawar and G. Heron",
  title="{Encapsulation Methods for Transport of Ethernet over MPLS Networks}",
  howpublished="RFC 4448 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4448",
  pages="1--24",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc4448.txt",
  key="RFC 4448",
  abstract={An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network.  This enables service providers to offer ``emulated'' Ethernet services over existing MPLS networks.  This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire.  It also specifies the procedures for using a PW to provide a ``point-to-point Ethernet'' service. [STANDARDS-TRACK]},
  keywords="pw, pseudowire, pdu, protocol data units",
  doi="10.17487/RFC4448",
  }

@misc{rfc4449,
  author="C. Perkins",
  title="{Securing Mobile IPv6 Route Optimization Using a Static Shared Key}",
  howpublished="RFC 4449 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4449",
  pages="1--7",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4449.txt",
  key="RFC 4449",
  abstract={A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]},
  keywords="mobile node, correspondent node, binding management key, binding updates",
  doi="10.17487/RFC4449",
  }

@misc{rfc4450,
  author="E. Lear and H. Alvestrand",
  title="{Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents}",
  howpublished="RFC 4450 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4450",
  pages="1--11",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4450.txt",
  key="RFC 4450",
  abstract={This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today.  The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4450",
  }

@misc{rfc4451,
  author="D. McPherson and V. Gill",
  title="{BGP MULTI\_EXIT\_DISC (MED) Considerations}",
  howpublished="RFC 4451 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4451",
  pages="1--13",
  year=2006,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4451.txt",
  key="RFC 4451",
  abstract={The BGP MULTI\_EXIT\_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies. This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.},
  keywords="border gateway protocol",
  doi="10.17487/RFC4451",
  }

@misc{rfc4452,
  author="H. Van de Sompel and T. Hammond and E. Neylon and S. Weibel",
  title="{The ``info'' URI Scheme for Information Assets with Identifiers in Public Namespaces}",
  howpublished="RFC 4452 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4452",
  pages="1--17",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4452.txt",
  key="RFC 4452",
  abstract={This document defines the ``info'' Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.  Namespaces participating in the ``info'' URI scheme are regulated by an ``info'' Registry mechanism.  This memo provides information for the Internet community.},
  keywords="uniform resource identifier",
  doi="10.17487/RFC4452",
  }

@misc{rfc4453,
  author="J. Rosenberg and G. Camarillo and D. Willis",
  title="{Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4453 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4453",
  pages="1--8",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4453.txt",
  key="RFC 4453",
  abstract={The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence.  In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient.  Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks.  This document identifies a set of requirements for extensions to SIP that add consent-based communications.  This memo provides information for the Internet community.},
  keywords="sip extensions",
  doi="10.17487/RFC4453",
  }

@misc{rfc4454,
  author="S. Singh and M. Townsley and C. Pignataro",
  title="{Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}",
  howpublished="RFC 4454 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4454",
  pages="1--26",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5641",
url="https://www.rfc-editor.org/rfc/rfc4454.txt",
  key="RFC 4454",
  abstract={The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks.  This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]},
  keywords="extensible tunneling protocol",
  doi="10.17487/RFC4454",
  }

@misc{rfc4455,
  author="M. Hallak-Stamler and M. Bakke and Y. Lederman and M. Krueger and K. McCloghrie",
  title="{Definition of Managed Objects for Small Computer System Interface (SCSI) Entities}",
  howpublished="RFC 4455 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4455",
  pages="1--88",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4455.txt",
  key="RFC 4455",
  abstract={This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community.  In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]},
  keywords="mib, management information base, scsi-mib",
  doi="10.17487/RFC4455",
  }

@misc{rfc4456,
  author="T. Bates and E. Chen and R. Chandra",
  title="{BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)}",
  howpublished="RFC 4456 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4456",
  pages="1--12",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7606",
url="https://www.rfc-editor.org/rfc/rfc4456.txt",
  key="RFC 4456",
  abstract={The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as ``route reflection'' to alleviate the need for ``full mesh'' Internal BGP (IBGP). This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]},
  keywords="BGP-RR, Border, Gateway, Protocol, autonomous, system",
  doi="10.17487/RFC4456",
  }

@misc{rfc4457,
  author="G. Camarillo and G. Blanco",
  title="{The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)}",
  howpublished="RFC 4457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4457",
  pages="1--8",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4457.txt",
  key="RFC 4457",
  abstract={This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header).  This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request.  This memo provides information for the Internet community.},
  keywords="3gpp, third generation partnership project, 3rd generation partnership project, ims, ip multimedia subsystem",
  doi="10.17487/RFC4457",
  }

@misc{rfc4458,
  author="C. Jennings and F. Audet and J. Elwell",
  title="{Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)}",
  howpublished="RFC 4458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4458",
  pages="1--21",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8119",
url="https://www.rfc-editor.org/rfc/rfc4458.txt",
  key="RFC 4458",
  abstract={The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems.  This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.  This memo provides information for the Internet community.},
  keywords="universal resource identifiers",
  doi="10.17487/RFC4458",
  }

@misc{rfc4459,
  author="P. Savola",
  title="{MTU and Fragmentation Issues with In-the-Network Tunneling}",
  howpublished="RFC 4459 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4459",
  pages="1--14",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4459.txt",
  key="RFC 4459",
  abstract={Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.  This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4459",
  }

@misc{rfc4460,
  author="R. Stewart and I. Arias-Rodriguez and K. Poon and A. Caro and M. Tuexen",
  title="{Stream Control Transmission Protocol (SCTP) Specification Errata and Issues}",
  howpublished="RFC 4460 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4460",
  pages="1--109",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4460.txt",
  key="RFC 4460",
  abstract={This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes.  This document provides deltas to RFC 2960 and is organized in a time-based way.  The issues are listed in the order they were brought up.  Because some text is changed several times, the last delta in the text is the one that should be applied.  In addition to the delta, a description of the problem and the details of the solution are also provided.  This memo provides information for the Internet community.},
  keywords="SCTP, IP, internet, transport, packet, network",
  doi="10.17487/RFC4460",
  }

@misc{rfc4461,
  author="S. Yasukawa",
  title="{Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)}",
  howpublished="RFC 4461 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4461",
  pages="1--30",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4461.txt",
  key="RFC 4461",
  abstract={This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution-specific details or application-specific requirements in this document. The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.},
  keywords="p2mp, multiprotocol label switching",
  doi="10.17487/RFC4461",
  }

@misc{rfc4462,
  author="J. Hutzelman and J. Salowey and J. Galbraith and V. Welch",
  title="{Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol}",
  howpublished="RFC 4462 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4462",
  pages="1--29",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4462.txt",
  key="RFC 4462",
  abstract={The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4462",
  }

@misc{rfc4463,
  author="S. Shanmugham and P. Monaco and B. Eberman",
  title="{A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks}",
  howpublished="RFC 4463 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4463",
  pages="1--86",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4463.txt",
  key="RFC 4463",
  abstract={This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.},
  doi="10.17487/RFC4463",
  }

@misc{rfc4464,
  author="A. Surtees and M. West",
  title="{Signaling Compression (SigComp) Users' Guide}",
  howpublished="RFC 4464 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4464",
  pages="1--43",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4464.txt",
  key="RFC 4464",
  abstract={This document provides an informational guide for users of the Signaling Compression (SigComp) protocol.  The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4464",
  }

@misc{rfc4465,
  author="A. Surtees and M. West",
  title="{Signaling Compression (SigComp) Torture Tests}",
  howpublished="RFC 4465 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4465",
  pages="1--68",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4465.txt",
  key="RFC 4465",
  abstract={This document provides a set of ``torture tests'' for implementers of the Signaling Compression (SigComp) protocol.  The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms.  Tests are also provided for other SigComp entities such as the dispatcher and the state handler.  This memo provides information for the Internet community.},
  keywords="SigComp Universal Decompressor Virtual Machine",
  doi="10.17487/RFC4465",
  }

@misc{rfc4466,
  author="A. Melnikov and C. Daboo",
  title="{Collected Extensions to IMAP4 ABNF}",
  howpublished="RFC 4466 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4466",
  pages="1--17",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6237, 7377",
url="https://www.rfc-editor.org/rfc/rfc4466.txt",
  key="RFC 4466",
  abstract={Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4466",
  }

@misc{rfc4467,
  author="M. Crispin",
  title="{Internet Message Access Protocol (IMAP) - URLAUTH Extension}",
  howpublished="RFC 4467 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4467",
  pages="1--18",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5092, 5550",
url="https://www.rfc-editor.org/rfc/rfc4467.txt",
  key="RFC 4467",
  abstract={This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server that supports this extension indicates this with a capability name of ``URLAUTH''. [STANDARDS-TRACK]},
  keywords="imap url, imapurl",
  doi="10.17487/RFC4467",
  }

@misc{rfc4468,
  author="C. Newman",
  title="{Message Submission BURL Extension}",
  howpublished="RFC 4468 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4468",
  pages="1--14",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5248",
url="https://www.rfc-editor.org/rfc/rfc4468.txt",
  key="RFC 4468",
  abstract={The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery.  This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server.  This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]},
  keywords="URLAUTH, IMAP, IMAPURL, Forward-without-download, mobile-client, lemonade",
  doi="10.17487/RFC4468",
  }

@misc{rfc4469,
  author="P. Resnick",
  title="{Internet Message Access Protocol (IMAP) CATENATE Extension}",
  howpublished="RFC 4469 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4469",
  pages="1--13",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5550",
url="https://www.rfc-editor.org/rfc/rfc4469.txt",
  key="RFC 4469",
  abstract={The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server.  Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]},
  keywords="append",
  doi="10.17487/RFC4469",
  }

@misc{rfc4470,
  author="S. Weiler and J. Ihren",
  title="{Minimally Covering NSEC Records and DNSSEC On-line Signing}",
  howpublished="RFC 4470 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4470",
  pages="1--8",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4470.txt",
  key="RFC 4470",
  abstract={This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034.  By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]},
  keywords="dns security, domain name system",
  doi="10.17487/RFC4470",
  }

@misc{rfc4471,
  author="G. Sisson and B. Laurie",
  title="{Derivation of DNS Name Predecessor and Successor}",
  howpublished="RFC 4471 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4471",
  pages="1--23",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4471.txt",
  key="RFC 4471",
  abstract={This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name.  These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain namespace, dynamic nsec, dnssec",
  doi="10.17487/RFC4471",
  }

@misc{rfc4472,
  author="A. Durand and J. Ihren and P. Savola",
  title="{Operational Considerations and Issues with IPv6 DNS}",
  howpublished="RFC 4472 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4472",
  pages="1--29",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4472.txt",
  key="RFC 4472",
  abstract={This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues.  This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.  This memo provides information for the Internet community.},
  keywords="domain name system, internet protocol version 6",
  doi="10.17487/RFC4472",
  }

@misc{rfc4473,
  author="Y. Nomura and R. Walsh and J-P. Luoma and J. Ott and H. Schulzrinne",
  title="{Requirements for Internet Media Guides (IMGs)}",
  howpublished="RFC 4473 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4473",
  pages="1--23",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4473.txt",
  key="RFC 4473",
  abstract={This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications.  These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.  This memo provides information for the Internet community.},
  keywords="media-on-deman, multicast",
  doi="10.17487/RFC4473",
  }

@misc{rfc4474,
  author="J. Peterson and  C. Jennings",
  title="{Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4474 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4474",
  pages="1--41",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4474.txt",
  key="RFC 4474",
  abstract={The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP messages.  It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]},
  keywords="security, identity, identity-info",
  doi="10.17487/RFC4474",
  }

@misc{rfc4475,
  author="R. Sparks and A. Hawrylyshen and A. Johnston and J. Rosenberg and H. Schulzrinne",
  title="{Session Initiation Protocol (SIP) Torture Test Messages}",
  howpublished="RFC 4475 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4475",
  pages="1--53",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4475.txt",
  key="RFC 4475",
  abstract={This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and ``torture'' a SIP implementation.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4475",
  }

@misc{rfc4476,
  author="C. Francis and D. Pinkas",
  title="{Attribute Certificate (AC) Policies Extension}",
  howpublished="RFC 4476 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4476",
  pages="1--11",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4476.txt",
  key="RFC 4476",
  abstract={This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC).  The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]},
  keywords="acp, attribute certificate policies",
  doi="10.17487/RFC4476",
  }

@misc{rfc4477,
  author="T. Chown and S. Venaas and C. Strauf",
  title="{Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues}",
  howpublished="RFC 4477 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4477",
  pages="1--14",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4477.txt",
  key="RFC 4477",
  abstract={A node may have support for communications using IPv4 and/or IPv6 protocols.  Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP).  The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6.  This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers.  The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.  This memo provides information for the Internet community.},
  keywords="internet protocol",
  doi="10.17487/RFC4477",
  }

@misc{rfc4478,
  author="Y. Nir",
  title="{Repeated Authentication in Internet Key Exchange (IKEv2) Protocol}",
  howpublished="RFC 4478 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4478",
  pages="1--5",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4478.txt",
  key="RFC 4478",
  abstract={This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2].  With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically.  The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer.  This document describes a mechanism to perform this function.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="lifetime",
  doi="10.17487/RFC4478",
  }

@misc{rfc4479,
  author="J. Rosenberg",
  title="{A Data Model for Presence}",
  howpublished="RFC 4479 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4479",
  pages="1--35",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4479.txt",
  key="RFC 4479",
  abstract={This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents.  The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]},
  keywords="simple, sip, session initiation protocol",
  doi="10.17487/RFC4479",
  }

@misc{rfc4480,
  author="H. Schulzrinne and V. Gurbani and P. Kyzivat and J. Rosenberg",
  title="{RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)}",
  howpublished="RFC 4480 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4480",
  pages="1--37",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4480.txt",
  key="RFC 4480",
  abstract={The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4480",
  }

@misc{rfc4481,
  author="H. Schulzrinne",
  title="{Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals}",
  howpublished="RFC 4481 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4481",
  pages="1--9",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4481.txt",
  key="RFC 4481",
  abstract={The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4481",
  }

@misc{rfc4482,
  author="H. Schulzrinne",
  title="{CIPID: Contact Information for the Presence Information Data Format}",
  howpublished="RFC 4482 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4482",
  pages="1--11",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4482.txt",
  key="RFC 4482",
  abstract={The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]},
  keywords="pidf",
  doi="10.17487/RFC4482",
  }

@misc{rfc4483,
  author="E. Burger",
  title="{A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages}",
  howpublished="RFC 4483 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4483",
  pages="1--17",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4483.txt",
  key="RFC 4483",
  abstract={This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP).  These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]},
  keywords="universal resource locator, mime, external-body access-type",
  doi="10.17487/RFC4483",
  }

@misc{rfc4484,
  author="J. Peterson and J. Polk and D. Sicker and H. Tschofenig",
  title="{Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4484 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4484",
  pages="1--15",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4484.txt",
  key="RFC 4484",
  abstract={This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP).  While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session.  This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.  This memo provides information for the Internet community.},
  keywords="policy decision",
  doi="10.17487/RFC4484",
  }

@misc{rfc4485,
  author="J. Rosenberg and H. Schulzrinne",
  title="{Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4485 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4485",
  pages="1--23",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4485.txt",
  key="RFC 4485",
  abstract={The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet.  Part of this flexibility is the ease with which it can be extended.  In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions.  This document outlines a set of such guidelines for authors of SIP extensions.  This memo provides information for the Internet community.},
  keywords="interactive communication",
  doi="10.17487/RFC4485",
  }

@misc{rfc4486,
  author="E. Chen and V. Gillet",
  title="{Subcodes for BGP Cease Notification Message}",
  howpublished="RFC 4486 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4486",
  pages="1--6",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4486.txt",
  key="RFC 4486",
  abstract={This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]},
  keywords="border gateway protocol, bgp peers",
  doi="10.17487/RFC4486",
  }

@misc{rfc4487,
  author="F. Le and S. Faccin and B. Patil and H. Tschofenig",
  title="{Mobile IPv6 and Firewalls: Problem Statement}",
  howpublished="RFC 4487 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4487",
  pages="1--16",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4487.txt",
  key="RFC 4487",
  abstract={This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks. The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.},
  keywords="3g, mobile networks",
  doi="10.17487/RFC4487",
  }

@misc{rfc4488,
  author="O. Levin",
  title="{Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription}",
  howpublished="RFC 4488 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4488",
  pages="1--8",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4488.txt",
  key="RFC 4488",
  abstract={The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER.  These notifications are not needed in all cases.  This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4488",
  }

@misc{rfc4489,
  author="J-S. Park and M-K. Shin and H-J. Kim",
  title="{A Method for Generating Link-Scoped IPv6 Multicast Addresses}",
  howpublished="RFC 4489 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4489",
  pages="1--6",
  year=2006,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4489.txt",
  key="RFC 4489",
  abstract={This document specifies an extension to the multicast addressing architecture of the IPv6 protocol.  The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses.  When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined.  After that, each node can generate its unique multicast addresses automatically without conflicts.  The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses.  This memo updates RFC 3306. [STANDARDS-TRACK]},
  keywords="iid, interface identifiers",
  doi="10.17487/RFC4489",
  }

@misc{rfc4490,
  author="S. Leontiev and G. Chudov",
  title="{Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 4490 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4490",
  pages="1--29",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4490.txt",
  key="RFC 4490",
  abstract={This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS).  The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]},
  keywords="CPCMS, S/MIME, PKIX, X.509, certificate, CRL, revocation, public-key, one-way, hash, block, cipher, encryption, decryption, MAC, HMAC, PRF, wrap, unwrap, UKM, KEK, key, Diffie-Hellman, agreement, transport, parameter, derivation, digest, CBC, counter, mode, digital, signature",
  doi="10.17487/RFC4490",
  }

@misc{rfc4491,
  author="S. Leontiev and D. Shefanovski",
  title="{Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile}",
  howpublished="RFC 4491 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4491",
  pages="1--20",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4491.txt",
  key="RFC 4491",
  abstract={This document supplements RFC 3279.  It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]},
  keywords="PKIX, X.509, CPPK, public-key, one-way hash function, block cipher, encryption, decryption, key derivation, parameter, message digest, digital signature, 34.310, 34.311, 34.310-95, 34.310-2004, 34.311-95",
  doi="10.17487/RFC4491",
  }

@misc{rfc4492,
  author="S. Blake-Wilson and N. Bolyard and V. Gupta and C. Hawk and B. Moeller",
  title="{Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)}",
  howpublished="RFC 4492 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4492",
  pages="1--35",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5246, 7027, 7919",
url="https://www.rfc-editor.org/rfc/rfc4492.txt",
  key="RFC 4492",
  abstract={This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol.  In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.  This memo provides information for the Internet community.},
  keywords="ecdh, elliptic curve diffie-hellman, elliptic curve digital signature algorithm, ecdsa",
  doi="10.17487/RFC4492",
  }

@misc{rfc4493,
  author="JH. Song and R. Poovendran and J. Lee and T. Iwata",
  title="{The AES-CMAC Algorithm}",
  howpublished="RFC 4493 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4493",
  pages="1--20",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4493.txt",
  key="RFC 4493",
  abstract={The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa.  This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES).  This new authentication algorithm is named AES-CMAC.  The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community.  This memo provides information for the Internet community.},
  keywords="cipher-based message authentication code, omac1, one-key cbc mac1, advanced encryption algorithm",
  doi="10.17487/RFC4493",
  }

@misc{rfc4494,
  author="JH. Song and R. Poovendran and J. Lee",
  title="{The AES-CMAC-96 Algorithm and Its Use with IPsec}",
  howpublished="RFC 4494 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4494",
  pages="1--8",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4494.txt",
  key="RFC 4494",
  abstract={The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa.  OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC).  This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols.  This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]},
  keywords="cipher-basd message authentication code, one-key cbc-mac1, omac1, xcbc, extended cipher block chaining, advanced encryption standard",
  doi="10.17487/RFC4494",
  }

@misc{rfc4495,
  author="J. Polk and S. Dhesikan",
  title="{A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow}",
  howpublished="RFC 4495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4495",
  pages="1--21",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4495.txt",
  key="RFC 4495",
  abstract={This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation.  This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels.  This specification is an extension of RFC 2205. [STANDARDS-TRACK]},
  keywords="rsvpv1",
  doi="10.17487/RFC4495",
  }

@misc{rfc4496,
  author="M. Stecher and A. Barbir",
  title="{Open Pluggable Edge Services (OPES) SMTP Use Cases}",
  howpublished="RFC 4496 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4496",
  pages="1--12",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4496.txt",
  key="RFC 4496",
  abstract={The Open Pluggable Edge Services (OPES) framework is application agnostic.  Application-specific adaptations extend that framework.  This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4496",
  }

@misc{rfc4497,
  author="J. Elwell and F. Derks and P. Mourot and O. Rousseau",
  title="{Interworking between the Session Initiation Protocol (SIP) and QSIG}",
  howpublished="RFC 4497 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4497",
  pages="1--65",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4497.txt",
  key="RFC 4497",
  abstract={This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks).  SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include, in particular, telephone calls.  QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs).  QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="telecommunication networks, enterprise networks, signalling",
  doi="10.17487/RFC4497",
  }

@misc{rfc4498,
  author="G. Keeni",
  title="{The Managed Object Aggregation MIB}",
  howpublished="RFC 4498 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4498",
  pages="1--29",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4498.txt",
  key="RFC 4498",
  abstract={This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community.  In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="management information base, aggregate mib, time aggregate mib",
  doi="10.17487/RFC4498",
  }

@misc{rfc4501,
  author="S. Josefsson",
  title="{Domain Name System Uniform Resource Identifiers}",
  howpublished="RFC 4501 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4501",
  pages="1--10",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4501.txt",
  key="RFC 4501",
  abstract={This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]},
  keywords="dns, uri",
  doi="10.17487/RFC4501",
  }

@misc{rfc4502,
  author="S. Waldbusser",
  title="{Remote Network Monitoring Management Information Base Version 2}",
  howpublished="RFC 4502 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4502",
  pages="1--142",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4502.txt",
  key="RFC 4502",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]},
  keywords="RMON-MIB, RMON, MIB",
  doi="10.17487/RFC4502",
  }

@misc{rfc4503,
  author="M. Boesgaard and M. Vesterager and E. Zenner",
  title="{A Description of the Rabbit Stream Cipher Algorithm}",
  howpublished="RFC 4503 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4503",
  pages="1--12",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4503.txt",
  key="RFC 4503",
  abstract={This document describes the encryption algorithm Rabbit.  It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV).  The method was published in 2003 and has been subject to public security and performance revision.  Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed.  This memo provides information for the Internet community.},
  keywords="iv, initialization vector, encryption algorithm",
  doi="10.17487/RFC4503",
  }

@misc{rfc4504,
  author="H. Sinnreich and  S. Lass and C. Stredicke",
  title="{SIP Telephony Device Requirements and Configuration}",
  howpublished="RFC 4504 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4504",
  pages="1--37",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4504.txt",
  key="RFC 4504",
  abstract={This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.},
  keywords="session initiation protocol, pc, pda, analog",
  doi="10.17487/RFC4504",
  }

@misc{rfc4505,
  author="K. Zeilenga",
  title="{Anonymous Simple Authentication and Security Layer (SASL) Mechanism}",
  howpublished="RFC 4505 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4505",
  pages="1--9",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4505.txt",
  key="RFC 4505",
  abstract={On the Internet, it is common practice to permit anonymous access to various services.  Traditionally, this has been done with a plain-text password mechanism using ``anonymous'' as the user name and using optional trace information, such as an email address, as the password.  As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]},
  keywords="SASL-ANON, Simple, Authentication, Security, Layer",
  doi="10.17487/RFC4505",
  }

@misc{rfc4506,
  author="M. Eisler",
  title="{XDR: External Data Representation Standard}",
  howpublished="RFC 4506 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4506",
  pages="1--27",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4506.txt",
  key="RFC 4506",
  abstract={This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted.  This document obsoletes RFC 1832. [STANDARDS-TRACK]},
  keywords="XDR, rpc, onc, open network computing",
  doi="10.17487/RFC4506",
  }

@misc{rfc4507,
  author="J. Salowey and H. Zhou and P. Eronen and H. Tschofenig",
  title="{Transport Layer Security (TLS) Session Resumption without Server-Side State}",
  howpublished="RFC 4507 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4507",
  pages="1--17",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5077",
url="https://www.rfc-editor.org/rfc/rfc4507.txt",
  key="RFC 4507",
  abstract={This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \\%per-client session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4507",
  }

@misc{rfc4508,
  author="O. Levin and A. Johnston",
  title="{Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method}",
  howpublished="RFC 4508 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4508",
  pages="1--6",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4508.txt",
  key="RFC 4508",
  abstract={The SIP ``Caller Preferences'' extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request.  The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request.  This document extends the REFER method to use the mechanism of RFC 3840.  By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]},
  keywords="caller preferences",
  doi="10.17487/RFC4508",
  }

@misc{rfc4509,
  author="W. Hardaker",
  title="{Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)}",
  howpublished="RFC 4509 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4509",
  pages="1--7",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4509.txt",
  key="RFC 4509",
  abstract={This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs).  DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]},
  keywords="domain name system, dns, dnskey",
  doi="10.17487/RFC4509",
  }

@misc{rfc4510,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map}",
  howpublished="RFC 4510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4510",
  pages="1--7",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4510.txt",
  key="RFC 4510",
  abstract={The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models.  This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]},
  keywords="LDAPV3, LDAv3, x.500, LDAP3-ATD, syntax, LDAP3-UTF8, x.500, ASN.1, string format, STR-LDAP, LDAP-URL, Lightweight Directory Access Protocol, Universal Resource Locator",
  doi="10.17487/RFC4510",
  }

@misc{rfc4511,
  author="J. Sermersheim",
  title="{Lightweight Directory Access Protocol (LDAP): The Protocol}",
  howpublished="RFC 4511 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4511",
  pages="1--68",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4511.txt",
  key="RFC 4511",
  abstract={This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP).  LDAP provides access to distributed directory services that act in accordance with X.500 data and service models.  These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]},
  keywords="LDAP, TLS, LDAPv3, LDAv3, x.500",
  doi="10.17487/RFC4511",
  }

@misc{rfc4512,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP): Directory Information Models}",
  howpublished="RFC 4512 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4512",
  pages="1--52",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4512.txt",
  key="RFC 4512",
  abstract={The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models.  This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]},
  keywords="LDAv3, x.500, LDAPv3, LDAP3-ATD, syntax, elective extensions, mechanisms",
  doi="10.17487/RFC4512",
  }

@misc{rfc4513,
  author="R. Harrison",
  title="{Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms}",
  howpublished="RFC 4513 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4513",
  pages="1--34",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4513.txt",
  key="RFC 4513",
  abstract={This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation. This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism. This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes. This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]},
  keywords="LDAP, TLS",
  doi="10.17487/RFC4513",
  }

@misc{rfc4514,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names}",
  howpublished="RFC 4514 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4514",
  pages="1--15",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4514.txt",
  key="RFC 4514",
  abstract={The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory.  This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names.  The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]},
  keywords="LDAP3-UTF8, LDAPv3, x.500, ASN.1, string, format",
  doi="10.17487/RFC4514",
  }

@misc{rfc4515,
  author="M. Smith and T. Howes",
  title="{Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters}",
  howpublished="RFC 4515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4515",
  pages="1--12",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4515.txt",
  key="RFC 4515",
  abstract={Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network.  This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]},
  keywords="STR-LDAP, STRLDAP, LDAPv3, X.500, BER, ASN.1",
  doi="10.17487/RFC4515",
  }

@misc{rfc4516,
  author="M. Smith and T. Howes",
  title="{Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator}",
  howpublished="RFC 4516 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4516",
  pages="1--15",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4516.txt",
  key="RFC 4516",
  abstract={This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]},
  keywords="LDAP-URL, LDAPURL, LDAP search, URL, URI, LDAPv3",
  doi="10.17487/RFC4516",
  }

@misc{rfc4517,
  author="S. Legg",
  title="{Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules}",
  howpublished="RFC 4517 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4517",
  pages="1--53",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4517.txt",
  key="RFC 4517",
  abstract={Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values.  The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules.  Matching rules specify an argument, an assertion value, which also has a defined syntax.  This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]},
  keywords="LDAP3-ATD, LDAv3, x.500, syntax,",
  doi="10.17487/RFC4517",
  }

@misc{rfc4518,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation}",
  howpublished="RFC 4518 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4518",
  pages="1--14",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4518.txt",
  key="RFC 4518",
  abstract={The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed.  This led to a number of usability and interoperability problems.  This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4518",
  }

@misc{rfc4519,
  author="A. Sciberras",
  title="{Lightweight Directory Access Protocol (LDAP): Schema for User Applications}",
  howpublished="RFC 4519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4519",
  pages="1--35",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4519.txt",
  key="RFC 4519",
  abstract={This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification.  It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages.  These objects are widely used as a basis for the schema in many LDAP directories.  This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]},
  keywords="Lightweight Directory Access Protocol, syntax",
  doi="10.17487/RFC4519",
  }

@misc{rfc4520,
  author="K. Zeilenga",
  title="{Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)}",
  howpublished="RFC 4520 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4520",
  pages="1--19",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4520.txt",
  key="RFC 4520",
  abstract={This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP).  The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4520",
  }

@misc{rfc4521,
  author="K. Zeilenga",
  title="{Considerations for Lightweight Directory Access Protocol (LDAP) Extensions}",
  howpublished="RFC 4521 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4521",
  pages="1--16",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4521.txt",
  key="RFC 4521",
  abstract={The Lightweight Directory Access Protocol (LDAP) is extensible.  It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas.  This document discusses considerations for designers of LDAP extensions.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4521",
  }

@misc{rfc4522,
  author="S. Legg",
  title="{Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option}",
  howpublished="RFC 4522 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4522",
  pages="1--8",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4522.txt",
  key="RFC 4522",
  abstract={Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type).  A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations.  This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values.  This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]},
  keywords="ber, ldap-specific encoding",
  doi="10.17487/RFC4522",
  }

@misc{rfc4523,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates}",
  howpublished="RFC 4523 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4523",
  pages="1--24",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4523.txt",
  key="RFC 4523",
  abstract={This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP).  The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]},
  keywords="LDAP3-ATD, LDAv3, x.500, syntax, pkix",
  doi="10.17487/RFC4523",
  }

@misc{rfc4524,
  author="K. Zeilenga",
  title="{COSINE LDAP/X.500 Schema}",
  howpublished="RFC 4524 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4524",
  pages="1--25",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4524.txt",
  key="RFC 4524",
  abstract={This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects. This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]},
  keywords="Naming",
  doi="10.17487/RFC4524",
  }

@misc{rfc4525,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension}",
  howpublished="RFC 4525 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4525",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4525.txt",
  key="RFC 4525",
  abstract={This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability.  This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension.  This memo provides information for the Internet community.},
  keywords="pre-read, post-read, control extension",
  doi="10.17487/RFC4525",
  }

@misc{rfc4526,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters}",
  howpublished="RFC 4526 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4526",
  pages="1--5",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4526.txt",
  key="RFC 4526",
  abstract={This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems.  The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]},
  keywords="x.500, string representation",
  doi="10.17487/RFC4526",
  }

@misc{rfc4527,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Read Entry Controls}",
  howpublished="RFC 4527 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4527",
  pages="1--8",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4527.txt",
  key="RFC 4527",
  abstract={This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation.  The client may request to read the entry before and/or after the modifications are applied.  These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4527",
  }

@misc{rfc4528,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Assertion Control}",
  howpublished="RFC 4528 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4528",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4528.txt",
  key="RFC 4528",
  abstract={This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true.  It can be used to construct ``test and set'', ``test and clear'', and other conditional operations. [STANDARDS-TRACK]},
  keywords="test and set, test and clear",
  doi="10.17487/RFC4528",
  }

@misc{rfc4529,
  author="K. Zeilenga",
  title="{Requesting Attributes by Object Class in the Lightweight Directory Access Protocol}",
  howpublished="RFC 4529 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4529",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4529.txt",
  key="RFC 4529",
  abstract={The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description.  This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4529",
  }

@misc{rfc4530,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute}",
  howpublished="RFC 4530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4530",
  pages="1--8",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4530.txt",
  key="RFC 4530",
  abstract={This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax.  The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object.  Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]},
  keywords="x.500, universally unique identifier",
  doi="10.17487/RFC4530",
  }

@misc{rfc4531,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Turn Operation}",
  howpublished="RFC 4531 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4531",
  pages="1--9",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4531.txt",
  key="RFC 4531",
  abstract={This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or ``turn'') the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="turn request, turn response",
  doi="10.17487/RFC4531",
  }

@misc{rfc4532,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) ``Who am I?'' Operation}",
  howpublished="RFC 4532 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4532",
  pages="1--7",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4532.txt",
  key="RFC 4532",
  abstract={This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity.  This mechanism is specified as an LDAP extended operation called the LDAP ``Who am I?'' operation. [STANDARDS-TRACK]},
  keywords="authorization identity",
  doi="10.17487/RFC4532",
  }

@misc{rfc4533,
  author="K. Zeilenga and J.H. Choi",
  title="{The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation}",
  howpublished="RFC 4533 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4533",
  pages="1--32",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4533.txt",
  key="RFC 4533",
  abstract={This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation.  The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT).  It supports both polling for changes and listening for changes.  The operation is defined as an extension of the LDAP Search Operation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="dit, directory information tree",
  doi="10.17487/RFC4533",
  }

@misc{rfc4534,
  author="A Colegrove and H Harney",
  title="{Group Security Policy Token v1}",
  howpublished="RFC 4534 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4534",
  pages="1--33",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4534.txt",
  key="RFC 4534",
  abstract={The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group.  Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security.  This document specifies the structure of such a token. [STANDARDS-TRACK]},
  keywords="cryptographic group",
  doi="10.17487/RFC4534",
  }

@misc{rfc4535,
  author="H. Harney and U. Meth and A. Colegrove and G. Gross",
  title="{GSAKMP: Group Secure Association Key Management Protocol}",
  howpublished="RFC 4535 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4535",
  pages="1--106",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4535.txt",
  key="RFC 4535",
  abstract={This document specifies the Group Secure Association Key Management Protocol (GSAKMP).  The GSAKMP provides a security framework for creating and managing cryptographic groups on a network.  It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group.  It also generates group keys. [STANDARDS-TRACK]},
  keywords="security framework, cryptographic network",
  doi="10.17487/RFC4535",
  }

@misc{rfc4536,
  author="P. Hoschka",
  title="{The application/smil and application/smil+xml Media Types}",
  howpublished="RFC 4536 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4536",
  pages="1--8",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4536.txt",
  key="RFC 4536",
  abstract={This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1).  SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation.  This memo provides information for the Internet community.},
  keywords="synchronized multimedia integration language",
  doi="10.17487/RFC4536",
  }

@misc{rfc4537,
  author="L. Zhu and P. Leach and K. Jaganathan",
  title="{Kerberos Cryptosystem Negotiation Extension}",
  howpublished="RFC 4537 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4537",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4537.txt",
  key="RFC 4537",
  abstract={This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4537",
  }

@misc{rfc4538,
  author="J. Rosenberg",
  title="{Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4538 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4538",
  pages="1--17",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4538.txt",
  key="RFC 4538",
  abstract={This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog.  This header field is used in requests that create SIP dialogs.  It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers.  The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]},
  keywords="tdialog",
  doi="10.17487/RFC4538",
  }

@misc{rfc4539,
  author="T. Edwards",
  title="{Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)}",
  howpublished="RFC 4539 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4539",
  pages="1--6",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4539.txt",
  key="RFC 4539",
  abstract={This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF).  MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4539",
  }

@misc{rfc4540,
  author="M. Stiemerling and J. Quittek and C. Cadar",
  title="{NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0}",
  howpublished="RFC 4540 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4540",
  pages="1--67",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4540.txt",
  key="RFC 4540",
  abstract={This document describes a protocol for controlling middleboxes such as firewalls and network address translators.  It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989.  Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="midcom",
  doi="10.17487/RFC4540",
  }

@misc{rfc4541,
  author="M. Christensen and K. Kimball and F. Solensky",
  title="{Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches}",
  howpublished="RFC 4541 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4541",
  pages="1--16",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4541.txt",
  key="RFC 4541",
  abstract={This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches.  These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping.  Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.  This memo provides information for the Internet community.},
  keywords="igmpv3, mldv2",
  doi="10.17487/RFC4541",
  }

@misc{rfc4542,
  author="F. Baker and J. Polk",
  title="{Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite}",
  howpublished="RFC 4542 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4542",
  pages="1--42",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5865",
url="https://www.rfc-editor.org/rfc/rfc4542.txt",
  key="RFC 4542",
  abstract={RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.},
  keywords="ieps, internet emergency preparedness service, call admission control, cac, phb, per hop behavior, multi-level precedence and preemption, mlpp, government emergency telecommunication service, gets",
  doi="10.17487/RFC4542",
  }

@misc{rfc4543,
  author="D. McGrew and J. Viega",
  title="{The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH}",
  howpublished="RFC 4543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4543",
  pages="1--14",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4543.txt",
  key="RFC 4543",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH).  GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]},
  keywords="encapsulating security payload, gcm, galois/counter mode, authentication header",
  doi="10.17487/RFC4543",
  }

@misc{rfc4544,
  author="M. Bakke and M. Krueger and T. McSweeney and J. Muchow",
  title="{Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)}",
  howpublished="RFC 4544 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4544",
  pages="1--83",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7147",
url="https://www.rfc-editor.org/rfc/rfc4544.txt",
  key="RFC 4544",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]},
  keywords="tcp/ip, scsi",
  doi="10.17487/RFC4544",
  }

@misc{rfc4545,
  author="M. Bakke and J. Muchow",
  title="{Definitions of Managed Objects for IP Storage User Identity Authorization}",
  howpublished="RFC 4545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4545",
  pages="1--43",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4545.txt",
  key="RFC 4545",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols.  This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements.  It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]},
  keywords="mib, management information base, snmp, tcp/ip, ips-auth-mib",
  doi="10.17487/RFC4545",
  }

@misc{rfc4546,
  author="D. Raftus and E. Cardona",
  title="{Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces}",
  howpublished="RFC 4546 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4546",
  pages="1--139",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4546.txt",
  key="RFC 4546",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]},
  keywords="cmts, cm, upstream, downstream, tdma, atdma, scdma, quality of service, channel utilizazation",
  doi="10.17487/RFC4546",
  }

@misc{rfc4547,
  author="A. Ahmad and G. Nakanishi",
  title="{Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems}",
  howpublished="RFC 4547 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4547",
  pages="1--40",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4547.txt",
  key="RFC 4547",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]},
  keywords="snmp, simple network management protocol, mib, smiv2, DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB",
  doi="10.17487/RFC4547",
  }

@misc{rfc4548,
  author="E. Gray and J. Rutemiller and G. Swallow",
  title="{Internet Code Point (ICP) Assignments for NSAP Addresses}",
  howpublished="RFC 4548 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4548",
  pages="1--9",
  year=2006,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4548.txt",
  key="RFC 4548",
  abstract={This document is intended to accomplish two highly inter-related tasks: to establish an ``initial'' Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values.  In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888.  In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the ``IETF consensus'' assignment policy in making future ICP assignments. [STANDARDS-TRACK]},
  keywords="network service access point",
  doi="10.17487/RFC4548",
  }

@misc{rfc4549,
  author="A. Melnikov",
  title="{Synchronization Operations for Disconnected IMAP4 Clients}",
  howpublished="RFC 4549 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4549",
  pages="1--35",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4549.txt",
  key="RFC 4549",
  abstract={This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the ``driver'' portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy. This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process. This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.},
  keywords="internet message access protocol",
  doi="10.17487/RFC4549",
  }

@misc{rfc4550,
  author="S. Maes and A. Melnikov",
  title="{Internet Email to Support Diverse Service Environments (Lemonade) Profile}",
  howpublished="RFC 4550 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4550",
  pages="1--23",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5550",
url="https://www.rfc-editor.org/rfc/rfc4550.txt",
  key="RFC 4550",
  abstract={This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server. The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]},
  keywords="internet message access protocol,",
  doi="10.17487/RFC4550",
  }

@misc{rfc4551,
  author="A. Melnikov and S. Hole",
  title="{IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization}",
  howpublished="RFC 4551 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4551",
  pages="1--25",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7162",
url="https://www.rfc-editor.org/rfc/rfc4551.txt",
  key="RFC 4551",
  abstract={Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]},
  keywords="internet mail access protocol",
  doi="10.17487/RFC4551",
  }

@misc{rfc4552,
  author="M. Gupta and N. Melam",
  title="{Authentication/Confidentiality for OSPFv3}",
  howpublished="RFC 4552 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4552",
  pages="1--15",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4552.txt",
  key="RFC 4552",
  abstract={This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]},
  keywords="open shortest path first, authentication header, encapsulating security payload, ah/esp",
  doi="10.17487/RFC4552",
  }

@misc{rfc4553,
  author="A. Vainshtein and YJ. Stein",
  title="{Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)}",
  howpublished="RFC 4553 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4553",
  pages="1--27",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4553.txt",
  key="RFC 4553",
  abstract={This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]},
  keywords="SAToP, pseudowires, circuit emulation, structure-agnostic emulation",
  doi="10.17487/RFC4553",
  }

@misc{rfc4554,
  author="T. Chown",
  title="{Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks}",
  howpublished="RFC 4554 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4554",
  pages="1--11",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4554.txt",
  key="RFC 4554",
  abstract={Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation.  This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment.  In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology.  The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.  This memo provides information for the Internet community.},
  keywords="Virtual Local Area Network",
  doi="10.17487/RFC4554",
  }

@misc{rfc4555,
  author="P. Eronen",
  title="{IKEv2 Mobility and Multihoming Protocol (MOBIKE)}",
  howpublished="RFC 4555 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4555",
  pages="1--33",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4555.txt",
  key="RFC 4555",
  abstract={This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2).  MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change.  A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another.  Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]},
  keywords="internet key exchange, ipsec, internet protocol security, vpn, virtual private networks",
  doi="10.17487/RFC4555",
  }

@misc{rfc4556,
  author="L. Zhu and B. Tung",
  title="{Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}",
  howpublished="RFC 4556 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4556",
  pages="1--42",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6112, 8062",
url="https://www.rfc-editor.org/rfc/rfc4556.txt",
  key="RFC 4556",
  abstract={This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification.  These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4556",
  }

@misc{rfc4557,
  author="L. Zhu and K. Jaganathan and N. Williams",
  title="{Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}",
  howpublished="RFC 4557 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4557",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4557.txt",
  key="RFC 4557",
  abstract={This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol.  These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4557",
  }

@misc{rfc4558,
  author="Z. Ali and R. Rahman and D. Prairie and D. Papadimitriou",
  title="{Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement}",
  howpublished="RFC 4558 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4558",
  pages="1--7",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4558.txt",
  key="RFC 4558",
  abstract={Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered.  Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE).  Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios.  The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]},
  keywords="Multi-Protocol Label Switching, mpls, Generalized  Multi-Protocol Label Switching, gmpls, Traffic Engineering, te, rsvp-te, gr, graceful restart",
  doi="10.17487/RFC4558",
  }

@misc{rfc4559,
  author="K. Jaganathan and L. Zhu and J. Brezak",
  title="{SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows}",
  howpublished="RFC 4559 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4559",
  pages="1--8",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4559.txt",
  key="RFC 4559",
  abstract={This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of ``negotiate'' is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.  This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism.  Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.  This memo provides information for the Internet community.},
  keywords="msie, microsoft internet explorer, iis, internet information services, simple and protected negotiate, nt lan manager",
  doi="10.17487/RFC4559",
  }

@misc{rfc4560,
  author="J. Quittek and K. White",
  title="{Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations}",
  howpublished="RFC 4560 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4560",
  pages="1--100",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4560.txt",
  key="RFC 4560",
  abstract={This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]},
  keywords="mib, management information base, DISMAN-PING-MIB DEFINITIONS, DISMAN-TRACEROUTE-MIB DEFINITIONS, DISMAN-NSLOOKUP-MIB DEFINITIONS",
  doi="10.17487/RFC4560",
  }

@misc{rfc4561,
  author="J.-P. Vasseur and Z. Ali and S. Sivabalan",
  title="{Definition of a Record Route Object (RRO) Node-Id Sub-Object}",
  howpublished="RFC 4561 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4561",
  pages="1--10",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4561.txt",
  key="RFC 4561",
  abstract={In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR).  However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS).  Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR).  This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue.  The MPLS Fast Reroute mechanism mentioned in this document refers to the ``Facility backup'' MPLS TE Fast Reroute method. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching traffic engineering, plr, point of local repair, igp, interior gateway protocol, as, autonomous system, abr, area border router, asbr, autonomous system border router",
  doi="10.17487/RFC4561",
  }

@misc{rfc4562,
  author="T. Melsen and S. Blake",
  title="{MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network}",
  howpublished="RFC 4562 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4562",
  pages="1--13",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4562.txt",
  key="RFC 4562",
  abstract={This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment. The mechanism - called ``MAC-Forced Forwarding'' - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.},
  keywords="Ethernet, Access Network, ARP, DHCP",
  doi="10.17487/RFC4562",
  }

@misc{rfc4563,
  author="E. Carrara and V. Lehtovirta and K. Norrman",
  title="{The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 4563 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4563",
  pages="1--10",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6309",
url="https://www.rfc-editor.org/rfc/rfc4563.txt",
  key="RFC 4563",
  abstract={This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol.  This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]},
  keywords="security, key management, multicast, broadcast, MBMS",
  doi="10.17487/RFC4563",
  }

@misc{rfc4564,
  author="S. Govindan and H. Cheng and ZH. Yao and WH. Zhou and L. Yang",
  title="{Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)}",
  howpublished="RFC 4564 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4564",
  pages="1--32",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4564.txt",
  key="RFC 4564",
  abstract={This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP).  The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol.  The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs.  This memo provides information for the Internet community.},
  keywords="wlan, wireless local area network",
  doi="10.17487/RFC4564",
  }

@misc{rfc4565,
  author="D. Loher and D. Nelson and O. Volinsky and B. Sarikaya",
  title="{Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols}",
  howpublished="RFC 4565 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4565",
  pages="1--31",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4565.txt",
  key="RFC 4565",
  abstract={This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team.  The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.  his memo provides information for the Internet community.},
  doi="10.17487/RFC4565",
  }

@misc{rfc4566,
  author="M. Handley and V. Jacobson and C. Perkins",
  title="{SDP: Session Description Protocol}",
  howpublished="RFC 4566 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4566",
  pages="1--49",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4566.txt",
  key="RFC 4566",
  abstract={This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]},
  keywords="SDP, mbone, internet, multicast, backbone, multimedia, internet addresses syntax",
  doi="10.17487/RFC4566",
  }

@misc{rfc4567,
  author="J. Arkko and F. Lindholm and M. Naslund and K. Norrman and E. Carrara",
  title="{Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)}",
  howpublished="RFC 4567 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4567",
  pages="1--30",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4567.txt",
  key="RFC 4567",
  abstract={This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]},
  keywords="key management protocol, multimedia internet keying, mikey",
  doi="10.17487/RFC4567",
  }

@misc{rfc4568,
  author="F. Andreasen and M. Baugher and D. Wing",
  title="{Session Description Protocol (SDP) Security Descriptions for Media Streams}",
  howpublished="RFC 4568 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4568",
  pages="1--44",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4568.txt",
  key="RFC 4568",
  abstract={This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams.  The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange.  The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams.  The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]},
  keywords="srtp, secure real-time transport protocol",
  doi="10.17487/RFC4568",
  }

@misc{rfc4569,
  author="G. Camarillo",
  title="{Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag}",
  howpublished="RFC 4569 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4569",
  pages="1--4",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4569.txt",
  key="RFC 4569",
  abstract={This document registers with the IANA a new media feature tag associated with the 'message' media type.  This media feature tag indicates that a particular device supports 'message' as a streaming media type.  Media feature tags can be used to route calls to devices that support certain features.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4569",
  }

@misc{rfc4570,
  author="B. Quinn and R. Finlayson",
  title="{Session Description Protocol (SDP) Source Filters}",
  howpublished="RFC 4570 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4570",
  pages="1--14",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4570.txt",
  key="RFC 4570",
  abstract={This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination ``connection'' addresses.  It defines the syntax and semantics for an SDP ``source-filter'' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations.  In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]},
  keywords="internet protocol, ip, source-filter, ssm, source-specific multicast",
  doi="10.17487/RFC4570",
  }

@misc{rfc4571,
  author="J. Lazzaro",
  title="{Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport}",
  howpublished="RFC 4571 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4571",
  pages="1--9",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4571.txt",
  key="RFC 4571",
  abstract={This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP).  The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]},
  keywords="TCP-based media transport, TCP tunnel, transmission control protocol",
  doi="10.17487/RFC4571",
  }

@misc{rfc4572,
  author="J. Lennox",
  title="{Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)}",
  howpublished="RFC 4572 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4572",
  pages="1--17",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8122",
url="https://www.rfc-editor.org/rfc/rfc4572.txt",
  key="RFC 4572",
  abstract={This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document extends and updates RFC 4145. [STANDARDS-TRACK]},
  keywords="setup, connection, reestablishment",
  doi="10.17487/RFC4572",
  }

@misc{rfc4573,
  author="R. Even and A. Lochbaum",
  title="{MIME Type Registration for RTP Payload Format for H.224}",
  howpublished="RFC 4573 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4573",
  pages="1--7",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4573.txt",
  key="RFC 4573",
  abstract={In conversational video applications, far-end camera control protocol is used by participants to control the remote camera.  The protocol that is commonly used is ITU H.281 over H.224.  The document registers the H224 media type.  It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]},
  keywords="real time transport protocol, itu h.281, h.224, far-end camera control",
  doi="10.17487/RFC4573",
  }

@misc{rfc4574,
  author="O. Levin and G. Camarillo",
  title="{The Session Description Protocol (SDP) Label Attribute}",
  howpublished="RFC 4574 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4574",
  pages="1--8",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4574.txt",
  key="RFC 4574",
  abstract={This document defines a new Session Description Protocol (SDP) media-level attribute: ``label''.  The ``label'' attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP.  The sender of the SDP document can attach the ``label'' attribute to a particular media stream or streams.  The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]},
  keywords="media level attribute, media stream",
  doi="10.17487/RFC4574",
  }

@misc{rfc4575,
  author="J. Rosenberg and H. Schulzrinne and O. Levin",
  title="{A Session Initiation Protocol (SIP) Event Package for Conference State}",
  howpublished="RFC 4575 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4575",
  pages="1--48",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4575.txt",
  key="RFC 4575",
  abstract={This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package.  The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI).  Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]},
  keywords="conference event package, uri, uniform resource identifier",
  doi="10.17487/RFC4575",
  }

@misc{rfc4576,
  author="E. Rosen and P. Psenak and P. Pillay-Esnault",
  title="{Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 4576 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4576",
  pages="1--7",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4576.txt",
  key="RFC 4576",
  abstract={This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides ``BGP/MPLS IP VPN'' service to a customer and the customer uses OSPFv2 to advertise its routes to the SP.  In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE.  The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers.  The routes are then converted back to OSPF routes sent via OSPF to other CE routers.  As a result of this conversion, some of the information needed to prevent loops may be lost.  A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE.  This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]},
  keywords="service provider, sp, provider edge, pe",
  doi="10.17487/RFC4576",
  }

@misc{rfc4577,
  author="E. Rosen and P. Psenak and P. Pillay-Esnault",
  title="{OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 4577 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4577",
  pages="1--25",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4577.txt",
  key="RFC 4577",
  abstract={Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a ``BGP/MPLS IP VPN''. The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol. This document updates RFC 4364. [STANDARDS-TRACK]},
  keywords="ce, open shortest path first, mpls, Multiprotocol Label Switching",
  doi="10.17487/RFC4577",
  }

@misc{rfc4578,
  author="M. Johnston and S. Venaas",
  title="{Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)}",
  howpublished="RFC 4578 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4578",
  pages="1--7",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4578.txt",
  key="RFC 4578",
  abstract={We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client.  This memo provides information for the Internet community.},
  keywords="efi, extensible firmware interface",
  doi="10.17487/RFC4578",
  }

@misc{rfc4579,
  author="A. Johnston and O. Levin",
  title="{Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents}",
  howpublished="RFC 4579 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4579",
  pages="1--43",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4579.txt",
  key="RFC 4579",
  abstract={This specification defines conferencing call control features for the Session Initiation Protocol (SIP).  This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works.  The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs.  The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams.  The usage of the isfocus feature tag is defined.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ua, conference-unaware, conference-aware, focus",
  doi="10.17487/RFC4579",
  }

@misc{rfc4580,
  author="B. Volz",
  title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option}",
  howpublished="RFC 4580 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4580",
  pages="1--6",
  year=2006,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4580.txt",
  key="RFC 4580",
  abstract={This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  The option allows a DHCPv6 relay agent to associate a stable ``Subscriber-ID'' with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4580",
  }

@misc{rfc4581,
  author="M. Bagnulo and J. Arkko",
  title="{Cryptographically Generated Addresses (CGA) Extension Field Format}",
  howpublished="RFC 4581 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4581",
  pages="1--4",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4581.txt",
  key="RFC 4581",
  abstract={This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions.  This document updates RFC 3972. [STANDARDS-TRACK]},
  keywords="tlv",
  doi="10.17487/RFC4581",
  }

@misc{rfc4582,
  author="G. Camarillo and J. Ott and K. Drage",
  title="{The Binary Floor Control Protocol (BFCP)}",
  howpublished="RFC 4582 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4582",
  pages="1--65",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4582.txt",
  key="RFC 4582",
  abstract={Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]},
  keywords="conference",
  doi="10.17487/RFC4582",
  }

@misc{rfc4583,
  author="G. Camarillo",
  title="{Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams}",
  howpublished="RFC 4583 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4583",
  pages="1--12",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4583.txt",
  key="RFC 4583",
  abstract={This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions.  User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. [STANDARDS-TRACK]},
  keywords="bfcp stream",
  doi="10.17487/RFC4583",
  }

@misc{rfc4584,
  author="S. Chakrabarti and E. Nordmark",
  title="{Extension to Sockets API for Mobile IPv6}",
  howpublished="RFC 4584 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4584",
  pages="1--25",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4584.txt",
  key="RFC 4584",
  abstract={This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6. Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.},
  keywords="advanced socket api, mobility header messages, hom address destination, routing header type 2, socket applications",
  doi="10.17487/RFC4584",
  }

@misc{rfc4585,
  author="J. Ott and S. Wenger and N. Sato and C. Burmeister and J. Rey",
  title="{Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)}",
  howpublished="RFC 4585 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4585",
  pages="1--51",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5506, 8108",
url="https://www.rfc-editor.org/rfc/rfc4585.txt",
  key="RFC 4585",
  abstract={Real-time media streams that use RTP are, to some degree, resilient against packet losses.  Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term.  This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented.  This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]},
  keywords="media stream, feedback based error, audio visual profile",
  doi="10.17487/RFC4585",
  }

@misc{rfc4586,
  author="C. Burmeister and R. Hakenberg and A. Miyazaki and J. Ott and N. Sato and S. Fukunaga",
  title="{Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations}",
  howpublished="RFC 4586 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4586",
  pages="1--28",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4586.txt",
  key="RFC 4586",
  abstract={This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF.  Unicast and multicast topologies are considered as well as several protocol and environment configurations.  The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.  This memo provides information for the Internet community.},
  keywords="Real-time Transport Protocol",
  doi="10.17487/RFC4586",
  }

@misc{rfc4587,
  author="R. Even",
  title="{RTP Payload Format for H.261 Video Streams}",
  howpublished="RFC 4587 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4587",
  pages="1--17",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4587.txt",
  key="RFC 4587",
  abstract={This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format. This specification obsoletes RFC 2032. [STANDARDS-TRACK]},
  keywords="RTP-H.261, real-time transport protocol, sdp, session description protocol",
  doi="10.17487/RFC4587",
  }

@misc{rfc4588,
  author="J. Rey and D. Leon and A. Miyazaki and V. Varsa and R. Hakenberg",
  title="{RTP Retransmission Payload Format}",
  howpublished="RFC 4588 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4588",
  pages="1--35",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4588.txt",
  key="RFC 4588",
  abstract={RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds.  This document describes an RTP payload format for performing retransmissions.  Retransmitted RTP packets are sent in a separate stream from the original RTP stream.  It is assumed that feedback from receivers to senders is available.  In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]},
  keywords="real time transport protocol, rtcp, real-time transport control protocol, RTP/AVPF",
  doi="10.17487/RFC4588",
  }

@misc{rfc4589,
  author="H. Schulzrinne and H. Tschofenig",
  title="{Location Types Registry}",
  howpublished="RFC 4589 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4589",
  pages="1--12",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4589.txt",
  key="RFC 4589",
  abstract={This document creates a registry for describing the types of places a human or end system might be found.  The registry is then referenced by other protocols that need a common set of location terms as protocol constants.  Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4589",
  }

@misc{rfc4590,
  author="B. Sterman and D. Sadolevsky and D. Schwartz and D. Williams and W. Beck",
  title="{RADIUS Extension for Digest Authentication}",
  howpublished="RFC 4590 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4590",
  pages="1--32",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5090",
url="https://www.rfc-editor.org/rfc/rfc4590.txt",
  key="RFC 4590",
  abstract={This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]},
  keywords="remote authentication dial-in user service, sip, http",
  doi="10.17487/RFC4590",
  }

@misc{rfc4591,
  author="M. Townsley and G. Wilkie and S. Booth and S. Bryant and J. Lau",
  title="{Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}",
  howpublished="RFC 4591 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4591",
  pages="1--14",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5641",
url="https://www.rfc-editor.org/rfc/rfc4591.txt",
  key="RFC 4591",
  abstract={The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks.  This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]},
  keywords="data link protocols, frame encapsulation, virtual-circuit creation and deletion, status change notification",
  doi="10.17487/RFC4591",
  }

@misc{rfc4592,
  author="E. Lewis",
  title="{The Role of Wildcards in the Domain Name System}",
  howpublished="RFC 4592 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4592",
  pages="1--20",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4592.txt",
  key="RFC 4592",
  abstract={This is an update to the wildcard definition of RFC 1034.  The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed.  The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]},
  keywords="cname",
  doi="10.17487/RFC4592",
  }

@misc{rfc4593,
  author="A. Barbir and S. Murphy and Y. Yang",
  title="{Generic Threats to Routing Protocols}",
  howpublished="RFC 4593 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4593",
  pages="1--22",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4593.txt",
  key="RFC 4593",
  abstract={Routing protocols are subject to attacks that can harm individual users or network operations as a whole.  This document provides a description and a summary of generic threats that affect routing protocols in general.  This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately.  This memo provides information for the Internet community.},
  keywords="threat sources, threat capability, threat action, threat consequences",
  doi="10.17487/RFC4593",
  }

@misc{rfc4594,
  author="J. Babiarz and K. Chan and F. Baker",
  title="{Configuration Guidelines for DiffServ Service Classes}",
  howpublished="RFC 4594 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4594",
  pages="1--57",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5865",
url="https://www.rfc-editor.org/rfc/rfc4594.txt",
  key="RFC 4594",
  abstract={This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms.  There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.  This memo provides information for the Internet community.},
  keywords="differentiated services code points, traffic conditioners, per-hop behaviors, phb, dscp, active queue management, aqm",
  doi="10.17487/RFC4594",
  }

@misc{rfc4595,
  author="F. Maino and D. Black",
  title="{Use of IKEv2 in the Fibre Channel Security Association Management Protocol}",
  howpublished="RFC 4595 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4595",
  pages="1--16",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4595.txt",
  key="RFC 4595",
  abstract={This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol.  This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types.  This document specifies these IKEv2 extensions and allocates identifiers for them.  Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.  This memo provides information for the Internet community.},
  keywords="internet key exchange",
  doi="10.17487/RFC4595",
  }

@misc{rfc4596,
  author="J. Rosenberg and P. Kyzivat",
  title="{Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension}",
  howpublished="RFC 4596 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4596",
  pages="1--40",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4596.txt",
  key="RFC 4596",
  abstract={This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP).  It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4596",
  }

@misc{rfc4597,
  author="R. Even and N. Ismail",
  title="{Conferencing Scenarios}",
  howpublished="RFC 4597 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4597",
  pages="1--17",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4597.txt",
  key="RFC 4597",
  abstract={This document describes multimedia conferencing scenarios.  It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions.  These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group.  This memo provides information for the Internet community.},
  keywords="multimedia, voice, video, text, interactive text, xcon",
  doi="10.17487/RFC4597",
  }

@misc{rfc4598,
  author="B. Link",
  title="{Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio}",
  howpublished="RFC 4598 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4598",
  pages="1--17",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4598.txt",
  key="RFC 4598",
  abstract={This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data.  E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media.  E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats.  The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]},
  keywords="encoded audio data, multichannel audio coding format",
  doi="10.17487/RFC4598",
  }

@misc{rfc4601,
  author="B. Fenner and M. Handley and H. Holbrook and I. Kouvelas",
  title="{Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)}",
  howpublished="RFC 4601 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4601",
  pages="1--150",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7761, updated by RFCs 5059, 5796, 6226",
url="https://www.rfc-editor.org/rfc/rfc4601.txt",
  key="RFC 4601",
  abstract={This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]},
  keywords="PIM-SM, routing, message, type, timers, flags",
  doi="10.17487/RFC4601",
  }

@misc{rfc4602,
  author="T. Pusateri",
  title="{Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis}",
  howpublished="RFC 4602 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4602",
  pages="1--8",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4602.txt",
  key="RFC 4602",
  abstract={This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4602",
  }

@misc{rfc4603,
  author="G. Zorn and G. Weber and R. Foltak",
  title="{Additional Values for the NAS-Port-Type Attribute}",
  howpublished="RFC 4603 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4603",
  pages="1--5",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4603.txt",
  key="RFC 4603",
  abstract={This document defines a set of values for the NAS-Port-Type RADIUS Attribute.  This memo provides information for the Internet community.},
  keywords="radius, Remote Authentication Dial-In User Service",
  doi="10.17487/RFC4603",
  }

@misc{rfc4604,
  author="H. Holbrook and B. Cain and B. Haberman",
  title="{Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast}",
  howpublished="RFC 4604 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4604",
  pages="1--11",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4604.txt",
  key="RFC 4604",
  abstract={The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively.  Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission.  This document defines the notion of an ``SSM-aware'' router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast.  This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]},
  keywords="ssm",
  doi="10.17487/RFC4604",
  }

@misc{rfc4605,
  author="B. Fenner and H. He and B. Haberman and H. Sandick",
  title="{Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding (``IGMP/MLD Proxying'')}",
  howpublished="RFC 4605 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4605",
  pages="1--12",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4605.txt",
  key="RFC 4605",
  abstract={In certain topologies, it is not necessary to run a multicast routing protocol.  It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information.  This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4605",
  }

@misc{rfc4606,
  author="E. Mannie and D. Papadimitriou",
  title="{Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control}",
  howpublished="RFC 4606 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4606",
  pages="1--25",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6344",
url="https://www.rfc-editor.org/rfc/rfc4606.txt",
  key="RFC 4606",
  abstract={This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4606",
  }

@misc{rfc4607,
  author="H. Holbrook and B. Cain",
  title="{Source-Specific Multicast for IP}",
  howpublished="RFC 4607 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4607",
  pages="1--19",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4607.txt",
  key="RFC 4607",
  abstract={IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols.  For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.  This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]},
  keywords="ipv4, ssm, ipv6",
  doi="10.17487/RFC4607",
  }

@misc{rfc4608,
  author="D. Meyer and R. Rockell and G. Shepherd",
  title="{Source-Specific Protocol Independent Multicast in 232/8}",
  howpublished="RFC 4608 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4608",
  pages="1--7",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4608.txt",
  key="RFC 4608",
  abstract={IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols.  This document defines operational recommendations to ensure source-specific behavior within the 232/8 range.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ip, ssm",
  doi="10.17487/RFC4608",
  }

@misc{rfc4609,
  author="P. Savola and R. Lehtonen and D. Meyer",
  title="{Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements}",
  howpublished="RFC 4609 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4609",
  pages="1--23",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4609.txt",
  key="RFC 4609",
  abstract={This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures.  Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism.  This memo also describes enhancements to the protocol operations that mitigate the identified threats.  This memo provides information for the Internet community.},
  keywords="security threats, intra-domain, inter-domain, any-source multicast, asm, source-specific multicast, ssm, embedded rendezvous point, embedded-rp",
  doi="10.17487/RFC4609",
  }

@misc{rfc4610,
  author="D. Farinacci and Y. Cai",
  title="{Anycast-RP Using Protocol Independent Multicast (PIM)}",
  howpublished="RFC 4610 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4610",
  pages="1--12",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4610.txt",
  key="RFC 4610",
  abstract={This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only.  Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]},
  keywords="rendezvous point, rp, msdp register, multicast source discovery, register-stop",
  doi="10.17487/RFC4610",
  }

@misc{rfc4611,
  author="M. McBride and J. Meylor and D. Meyer",
  title="{Multicast Source Discovery Protocol (MSDP) Deployment Scenarios}",
  howpublished="RFC 4611 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4611",
  pages="1--14",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4611.txt",
  key="RFC 4611",
  abstract={This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="pim-sm, protocol independent multicast sparse mode",
  doi="10.17487/RFC4611",
  }

@misc{rfc4612,
  author="P. Jones and H. Tamura",
  title="{Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration}",
  howpublished="RFC 4612 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4612",
  pages="1--8",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4612.txt",
  key="RFC 4612",
  abstract={This document defines the MIME sub-type audio/t38.  The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38.  This memo defines a Historic Document for the Internet community.},
  keywords="itu-t recommendation t.38, sdp, session description protocol",
  doi="10.17487/RFC4612",
  }

@misc{rfc4613,
  author="P. Frojdh and U. Lindgren and M. Westerlund",
  title="{Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI)}",
  howpublished="RFC 4613 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4613",
  pages="1--6",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4613.txt",
  key="RFC 4613",
  abstract={This document serves to register a media type for Downloadable Sounds.  This memo provides information for the Internet community.},
  keywords="dls",
  doi="10.17487/RFC4613",
  }

@misc{rfc4614,
  author="M. Duke and R. Braden and W. Eddy and E. Blanton",
  title="{A Roadmap for Transmission Control Protocol (TCP) Specification Documents}",
  howpublished="RFC 4614 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4614",
  pages="1--33",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7414, updated by RFC 6247",
url="https://www.rfc-editor.org/rfc/rfc4614.txt",
  key="RFC 4614",
  abstract={This document contains a ``roadmap'' to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP).  This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series.  This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4614",
  }

@misc{rfc4615,
  author="J. Song and R. Poovendran and J. Lee and T. Iwata",
  title="{The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)}",
  howpublished="RFC 4615 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4615",
  pages="1--7",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4615.txt",
  key="RFC 4615",
  abstract={Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES).  This memo describes such an algorithm, called AES-CMAC-PRF-128.  It supports fixed and variable key sizes. [STANDARDS-TRACK]},
  keywords="ipsec, ip security, pseudo-random function",
  doi="10.17487/RFC4615",
  }

@misc{rfc4616,
  author="K. Zeilenga",
  title="{The PLAIN Simple Authentication and Security Layer (SASL) Mechanism}",
  howpublished="RFC 4616 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4616",
  pages="1--11",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4616.txt",
  key="RFC 4616",
  abstract={This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism.  The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]},
  keywords="data confidentiality",
  doi="10.17487/RFC4616",
  }

@misc{rfc4617,
  author="J. Kornijenko",
  title="{A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project}",
  howpublished="RFC 4617 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4617",
  pages="1--8",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4617.txt",
  key="RFC 4617",
  abstract={This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS).  This memo provides information for the Internet community.},
  keywords="general contractor, Olimps LTD, subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange Technologies LTD, RIX, Microlink LTD",
  doi="10.17487/RFC4617",
  }

@misc{rfc4618,
  author="L. Martini and E. Rosen and G. Heron and A. Malis",
  title="{Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks}",
  howpublished="RFC 4618 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4618",
  pages="1--16",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4618.txt",
  key="RFC 4618",
  abstract={A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol.  This enables service providers to offer ``emulated'' HDLC, or PPP link services over existing MPLS networks.  This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]},
  keywords="pw, pseudowire, point to point protocol, pdu, packet data unit",
  doi="10.17487/RFC4618",
  }

@misc{rfc4619,
  author="L. Martini and C. Kawa and A. Malis",
  title="{Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks}",
  howpublished="RFC 4619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4619",
  pages="1--19",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4619.txt",
  key="RFC 4619",
  abstract={A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN).  This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]},
  keywords="pseudowire, psn, packet switched network, pw",
  doi="10.17487/RFC4619",
  }

@misc{rfc4620,
  author="M. Crawford and  B. Haberman",
  title="{IPv6 Node Information Queries}",
  howpublished="RFC 4620 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4620",
  pages="1--14",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4620.txt",
  key="RFC 4620",
  abstract={This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name.  IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="internet protocol version 6",
  doi="10.17487/RFC4620",
  }

@misc{rfc4621,
  author="T. Kivinen and H. Tschofenig",
  title="{Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol}",
  howpublished="RFC 4621 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4621",
  pages="1--30",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4621.txt",
  key="RFC 4621",
  abstract={The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.},
  keywords="internet key exchange",
  doi="10.17487/RFC4621",
  }

@misc{rfc4622,
  author="P. Saint-Andre",
  title="{Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 4622 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4622",
  pages="1--23",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5122",
url="https://www.rfc-editor.org/rfc/rfc4622.txt",
  key="RFC 4622",
  abstract={This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]},
  keywords="Extensible Messaging and Presence Protocol, Internationalized Resource Identifier, Uniform Resource Identifier, Jabber, xmpp, iri, uri",
  doi="10.17487/RFC4622",
  }

@misc{rfc4623,
  author="A. Malis and M. Townsley",
  title="{Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly}",
  howpublished="RFC 4623 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4623",
  pages="1--17",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4623.txt",
  key="RFC 4623",
  abstract={This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4623",
  }

@misc{rfc4624,
  author="B. Fenner and D. Thaler",
  title="{Multicast Source Discovery Protocol (MSDP) MIB}",
  howpublished="RFC 4624 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4624",
  pages="1--32",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4624.txt",
  key="RFC 4624",
  abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="management information base, MSDP-MIB",
  doi="10.17487/RFC4624",
  }

@misc{rfc4625,
  author="C. DeSanti and K. McCloghrie and S. Kode and S. Gai",
  title="{Fibre Channel Routing Information MIB}",
  howpublished="RFC 4625 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4625",
  pages="1--22",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4625.txt",
  key="RFC 4625",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-ROUTE-MIB",
  doi="10.17487/RFC4625",
  }

@misc{rfc4626,
  author="C. DeSanti and V. Gaonkar and K. McCloghrie and S. Gai",
  title="{MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol}",
  howpublished="RFC 4626 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4626",
  pages="1--36",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4626.txt",
  key="RFC 4626",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-FSPF-MIB",
  doi="10.17487/RFC4626",
  }

@misc{rfc4627,
  author="D. Crockford",
  title="{The application/json Media Type for JavaScript Object Notation (JSON)}",
  howpublished="RFC 4627 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4627",
  pages="1--10",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7159",
url="https://www.rfc-editor.org/rfc/rfc4627.txt",
  key="RFC 4627",
  abstract={JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.  This memo provides information for the Internet community.},
  keywords="data interchange format, ECMAScript Programming Language Standard",
  doi="10.17487/RFC4627",
  }

@misc{rfc4628,
  author="R. Even",
  title="{RTP Payload Format for H.263 Moving RFC 2190 to Historic Status}",
  howpublished="RFC 4628 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4628",
  pages="1--5",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4628.txt",
  key="RFC 4628",
  abstract={The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190.  This specification discusses why to move RFC 2190 to historic status.  This memo provides information for the Internet community.},
  keywords="real-time transport protocol, itu-t, itu telecommunication standardization sector, transfer",
  doi="10.17487/RFC4628",
  }

@misc{rfc4629,
  author="J. Ott and C. Bormann and G. Sullivan and S. Wenger and R. Even",
  title="{RTP Payload Format for ITU-T Rec. H.263 Video}",
  howpublished="RFC 4629 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4629",
  pages="1--29",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4629.txt",
  key="RFC 4629",
  abstract={This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec. The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, multicast, unicast, sdp, session description protocol",
  doi="10.17487/RFC4629",
  }

@misc{rfc4630,
  author="R. Housley and S. Santesson",
  title="{Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 4630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4630",
  pages="1--6",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5280",
url="https://www.rfc-editor.org/rfc/rfc4630.txt",
  key="RFC 4630",
  abstract={This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280.  The use of UTF8String and PrintableString are the preferred encoding.  The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]},
  keywords="utf8string, printablestring",
  doi="10.17487/RFC4630",
  }

@misc{rfc4631,
  author="M. Dubuc and T. Nadeau and J. Lang and E. McGinnis and A. Farrel",
  title="{Link Management Protocol (LMP) Management Information Base (MIB)}",
  howpublished="RFC 4631 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4631",
  pages="1--83",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4631.txt",
  key="RFC 4631",
  abstract={This document provides minor corrections to and obsoletes RFC 4327. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]},
  keywords="lmp-mib",
  doi="10.17487/RFC4631",
  }

@misc{rfc4632,
  author="V. Fuller and T. Li",
  title="{Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan}",
  howpublished="RFC 4632 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4632",
  pages="1--27",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4632.txt",
  key="RFC 4632",
  abstract={This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.  This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="CIDR-STRA, global routing state",
  doi="10.17487/RFC4632",
  }

@misc{rfc4633,
  author="S. Hartman",
  title="{Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists}",
  howpublished="RFC 4633 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4633",
  pages="1--7",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4633.txt",
  key="RFC 4633",
  abstract={Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists.  This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC4633",
  }

@misc{rfc4634,
  author="D. {Eastlake 3rd} and T. Hansen",
  title="{US Secure Hash Algorithms (SHA and HMAC-SHA)}",
  howpublished="RFC 4634 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4634",
  pages="1--108",
  year=2006,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6234",
url="https://www.rfc-editor.org/rfc/rfc4634.txt",
  key="RFC 4634",
  abstract={The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2. Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.},
  keywords="fips, federal information processing standard, sha-224, sha-256, sha-384, sha-512",
  doi="10.17487/RFC4634",
  }

@misc{rfc4635,
  author="D. {Eastlake 3rd}",
  title="{HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers}",
  howpublished="RFC 4635 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4635",
  pages="1--8",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4635.txt",
  key="RFC 4635",
  abstract={Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.  Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms.  This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]},
  keywords="dns, resource record, rr, cryptographic message authentication code, cmac",
  doi="10.17487/RFC4635",
  }

@misc{rfc4636,
  author="C. Perkins",
  title="{Foreign Agent Error Extension for Mobile IPv4}",
  howpublished="RFC 4636 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4636",
  pages="1--6",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4636.txt",
  key="RFC 4636",
  abstract={This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4.  Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent.  The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC4636",
  }

@misc{rfc4638,
  author="P. Arberg and D. Kourkouzelis and M. Duckett and T. Anschutz and J. Moisand",
  title="{Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)}",
  howpublished="RFC 4638 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4638",
  pages="1--9",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4638.txt",
  key="RFC 4638",
  abstract={The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492.  This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4638",
  }

@misc{rfc4639,
  author="R. Woundy and K. Marez",
  title="{Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems}",
  howpublished="RFC 4639 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4639",
  pages="1--88",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4639.txt",
  key="RFC 4639",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems. This memo obsoletes RFC 2669. [STANDARDS-TRACK]},
  keywords="snmp, simple network management protocol",
  doi="10.17487/RFC4639",
  }

@misc{rfc4640,
  author="A. Patel and G. Giaretta",
  title="{Problem Statement for bootstrapping Mobile IPv6 (MIPv6)}",
  howpublished="RFC 4640 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4640",
  pages="1--22",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4640.txt",
  key="RFC 4640",
  abstract={A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent.  The process of obtaining this information is called bootstrapping.  This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6, mobile node",
  doi="10.17487/RFC4640",
  }

@misc{rfc4641,
  author="O. Kolkman and R. Gieben",
  title="{DNSSEC Operational Practices}",
  howpublished="RFC 4641 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4641",
  pages="1--35",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6781",
url="https://www.rfc-editor.org/rfc/rfc4641.txt",
  key="RFC 4641",
  abstract={This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.},
  keywords="dns, domain name space, security extensions, zone administrator, DNS-SOC, cryptology, resource records, rrs",
  doi="10.17487/RFC4641",
  }

@misc{rfc4642,
  author="K. Murchison and J. Vinocur and C. Newman",
  title="{Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)}",
  howpublished="RFC 4642 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4642",
  pages="1--14",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8143",
url="https://www.rfc-editor.org/rfc/rfc4642.txt",
  key="RFC 4642",
  abstract={This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS).  The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]},
  keywords="encryption, single link confidentiality",
  doi="10.17487/RFC4642",
  }

@misc{rfc4643,
  author="J. Vinocur and K. Murchison",
  title="{Network News Transfer Protocol (NNTP) Extension for Authentication}",
  howpublished="RFC 4643 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4643",
  pages="1--24",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4643.txt",
  key="RFC 4643",
  abstract={This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session. This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]},
  keywords="authinfo user/pass, authinfo simple, authinfo generic, sasl, simple authentication and security layer",
  doi="10.17487/RFC4643",
  }

@misc{rfc4644,
  author="J. Vinocur and K. Murchison",
  title="{Network News Transfer Protocol (NNTP) Extension for Streaming Feeds}",
  howpublished="RFC 4644 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4644",
  pages="1--14",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4644.txt",
  key="RFC 4644",
  abstract={This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as ``streaming'') transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency. This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]},
  keywords="check, takethis, mode stream",
  doi="10.17487/RFC4644",
  }

@misc{rfc4645,
  author="D. Ewell",
  title="{Initial Language Subtag Registry}",
  howpublished="RFC 4645 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4645",
  pages="1--7",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4645.txt",
  key="RFC 4645",
  abstract={This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages.  Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion.  This memo provides information for the Internet community.},
  keywords="iana",
  doi="10.17487/RFC4645",
  }

@misc{rfc4646,
  author="A. Phillips and M. Davis",
  title="{Tags for Identifying Languages}",
  howpublished="RFC 4646 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4646",
  pages="1--59",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5646",
url="https://www.rfc-editor.org/rfc/rfc4646.txt",
  key="RFC 4646",
  abstract={This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Lang-Tag",
  doi="10.17487/RFC4646",
  }

@misc{rfc4647,
  author="A. Phillips and M. Davis",
  title="{Matching of Language Tags}",
  howpublished="RFC 4647 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4647",
  pages="1--20",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4647.txt",
  key="RFC 4647",
  abstract={This document describes a syntax, called a ``language-range'', for specifying items in a user's list of language preferences.  It also describes different mechanisms for comparing and matching these to language tags.  Two kinds of matching mechanisms, filtering and lookup, are defined.  Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag.  Possible applications include language negotiation or content selection.  This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Lang-Tag",
  doi="10.17487/RFC4647",
  }

@misc{rfc4648,
  author="S. Josefsson",
  title="{The Base16, Base32, and Base64 Data Encodings}",
  howpublished="RFC 4648 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4648",
  pages="1--18",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4648.txt",
  key="RFC 4648",
  abstract={This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]},
  keywords="schemes, data, line-feeds, alphabets, base encoding, hex",
  doi="10.17487/RFC4648",
  }

@misc{rfc4649,
  author="B. Volz",
  title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option}",
  howpublished="RFC 4649 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4649",
  pages="1--6",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4649.txt",
  key="RFC 4649",
  abstract={This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4649",
  }

@misc{rfc4650,
  author="M. Euchner",
  title="{HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 4650 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4650",
  pages="1--27",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4650.txt",
  key="RFC 4650",
  abstract={This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830.  In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged.  This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]},
  keywords="Multicast security, MIKEY, key management, Diffie-Hellman, key agreement, HMAC",
  doi="10.17487/RFC4650",
  }

@misc{rfc4651,
  author="C. Vogt and J. Arkko",
  title="{A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization}",
  howpublished="RFC 4651 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4651",
  pages="1--31",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4651.txt",
  key="RFC 4651",
  abstract={This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This memo provides information for the Internet community.},
  keywords="Mobile IPv6, Route Optimization, Enhancement, Mobility, Handoff, IP Address Tests, Protected Tunnels, Optimistic Behavior, Proactive IP Address Tests, Concurrent Care-of Address Tests, Diverted Routing, Credit-Based Authorization, Heuristic Monitoring, Crypto-Based Identifiers, Pre-Configuration, Semi-Permanent Security Associations, Delegation, Mobile Networks, Location Privacy",
  doi="10.17487/RFC4651",
  }

@misc{rfc4652,
  author="D. Papadimitriou and L.Ong and J. Sadler and S. Shew and D. Ward",
  title="{Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements}",
  howpublished="RFC 4652 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4652",
  pages="1--22",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4652.txt",
  key="RFC 4652",
  abstract={The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.},
  keywords="gmpls, generalized multiprotocol label switching, otn, optical transport networks, sonet, sdh, synchronous optical network, synchronous digital hierarchy, itu-t",
  doi="10.17487/RFC4652",
  }

@misc{rfc4653,
  author="S. Bhandarkar and A. L. N. Reddy and M. Allman and E. Blanton",
  title="{Improving the Robustness of TCP to Non-Congestion Events}",
  howpublished="RFC 4653 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4653",
  pages="1--18",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4653.txt",
  key="RFC 4653",
  abstract={This document specifies Non-Congestion Robustness (NCR) for TCP.  In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion.  One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.  However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance.  TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering.  This document specifies the changes to TCP, as well as the costs and benefits of these modifications.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ncr, non-congestion robustness, transmission control protocol",
  doi="10.17487/RFC4653",
  }

@misc{rfc4654,
  author="J. Widmer and M. Handley",
  title="{TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification}",
  howpublished="RFC 4654 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4654",
  pages="1--32",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4654.txt",
  key="RFC 4654",
  abstract={This document specifies TCP-Friendly Multicast Congestion Control (TFMCC).  TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment.  It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.  TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="streaming media, multicase, ip, internet protocol",
  doi="10.17487/RFC4654",
  }

@misc{rfc4655,
  author="A. Farrel and J.-P. Vasseur and J. Ash",
  title="{A Path Computation Element (PCE)-Based Architecture}",
  howpublished="RFC 4655 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4655",
  pages="1--40",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4655.txt",
  key="RFC 4655",
  abstract={Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.},
  keywords="traffic engineering",
  doi="10.17487/RFC4655",
  }

@misc{rfc4656,
  author="S. Shalunov and B. Teitelbaum and A. Karp and J. Boote and M. Zekauskas",
  title="{A One-way Active Measurement Protocol (OWAMP)}",
  howpublished="RFC 4656 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4656",
  pages="1--56",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7717, 7718",
url="https://www.rfc-editor.org/rfc/rfc4656.txt",
  key="RFC 4656",
  abstract={The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss.  High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA).  OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]},
  keywords="unidirectional characteristics, one-way, gps, cdma",
  doi="10.17487/RFC4656",
  }

@misc{rfc4657,
  author="J. Ash and J.L. Le Roux",
  title="{Path Computation Element (PCE) Communication Protocol Generic Requirements}",
  howpublished="RFC 4657 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4657",
  pages="1--21",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4657.txt",
  key="RFC 4657",
  abstract={The PCE model is described in the ``PCE Architecture'' document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs).  This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable.  Subsequent documents will specify application-specific requirements for the PCE communication protocol.  This memo provides information for the Internet community.},
  keywords="pce architecture, pcc, path computation client",
  doi="10.17487/RFC4657",
  }

@misc{rfc4659,
  author="J. De Clercq and D. Ooms and M. Carugi and F. Le Faucheur",
  title="{BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN}",
  howpublished="RFC 4659 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4659",
  pages="1--18",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4659.txt",
  key="RFC 4659",
  abstract={This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the ``BGP/MPLS IP VPN'' method for support of IPv6. In BGP/MPLS IP VPN, ``Multiprotocol BGP'' is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in ``Multiprotocol BGP''. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]},
  keywords="service provider, border gateway protocol, multiprotocol label switching",
  doi="10.17487/RFC4659",
  }

@misc{rfc4660,
  author="H. Khartabil and E. Leppanen and M. Lonnfors and J. Costa-Requena",
  title="{Functional Description of Event Notification Filtering}",
  howpublished="RFC 4660 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4660",
  pages="1--31",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6665",
url="https://www.rfc-editor.org/rfc/rfc4660.txt",
  key="RFC 4660",
  abstract={The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]},
  keywords="event state subscription, presence, filter criteria",
  doi="10.17487/RFC4660",
  }

@misc{rfc4661,
  author="H. Khartabil and E. Leppanen and M. Lonnfors and J. Costa-Requena",
  title="{An Extensible Markup Language (XML)-Based Format for Event Notification Filtering}",
  howpublished="RFC 4661 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4661",
  pages="1--24",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4661.txt",
  key="RFC 4661",
  abstract={The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource.  The document does not describe a mechanism whereby filtering of event notification information can be achieved.  Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered.  In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain.  This document presents a format in the form of an XML document. [STANDARDS-TRACK]},
  keywords="event state subscription, presence, filter criteria",
  doi="10.17487/RFC4661",
  }

@misc{rfc4662,
  author="A. B. Roach and B. Campbell and J. Rosenberg",
  title="{A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists}",
  howpublished="RFC 4662 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4662",
  pages="1--39",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4662.txt",
  key="RFC 4662",
  abstract={This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources.  Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4662",
  }

@misc{rfc4663,
  author="D. Harrington",
  title="{Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG}",
  howpublished="RFC 4663 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4663",
  pages="1--22",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4663.txt",
  key="RFC 4663",
  abstract={This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.  This memo provides information for the Internet community.},
  keywords="management information base",
  doi="10.17487/RFC4663",
  }

@misc{rfc4664,
  author="L. Andersson and E. Rosen",
  title="{Framework for Layer 2 Virtual Private Networks (L2VPNs)}",
  howpublished="RFC 4664 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4664",
  pages="1--44",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4664.txt",
  key="RFC 4664",
  abstract={This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs).  This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4664",
  }

@misc{rfc4665,
  author="W. Augustyn and Y. Serbest",
  title="{Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks}",
  howpublished="RFC 4665 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4665",
  pages="1--32",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4665.txt",
  key="RFC 4665",
  abstract={This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs).  It first provides taxonomy and terminology and states generic and general service requirements.  It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS).  Detailed requirements are expressed from both a customer as well as a service provider perspectives.  This memo provides information for the Internet community.},
  keywords="l2vpn, ppvpn, virtual private wire service, vpws, virtual private lan service, vpls",
  doi="10.17487/RFC4665",
  }

@misc{rfc4666,
  author="K. Morneault and J. Pastor-Balbas",
  title="{Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)}",
  howpublished="RFC 4666 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4666",
  pages="1--124",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4666.txt",
  key="RFC 4666",
  abstract={This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol.  Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains.  This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications.  It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport.  This document obsoletes RFC 3332. [STANDARDS-TRACK]},
  keywords="mtp, isup, sccp, sctp, stream control tranmission protocol, mgc, media gateway protocol, st, signalling gateway",
  doi="10.17487/RFC4666",
  }

@misc{rfc4667,
  author="W. Luo",
  title="{Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)}",
  howpublished="RFC 4667 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4667",
  pages="1--15",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4667.txt",
  key="RFC 4667",
  abstract={The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols.  One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN).  This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]},
  keywords="L2VPN, L2TP, L2TPv3, pseudowire, forwarder",
  doi="10.17487/RFC4667",
  }

@misc{rfc4668,
  author="D. Nelson",
  title="{RADIUS Authentication Client MIB for IPv6}",
  howpublished="RFC 4668 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4668",
  pages="1--24",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4668.txt",
  key="RFC 4668",
  abstract={This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]},
  keywords="management information base, security, remote access dialin user service, RADIUS-AUTH-CLIENT-MIB",
  doi="10.17487/RFC4668",
  }

@misc{rfc4669,
  author="D. Nelson",
  title="{RADIUS Authentication Server MIB for IPv6}",
  howpublished="RFC 4669 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4669",
  pages="1--25",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4669.txt",
  key="RFC 4669",
  abstract={This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers. This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]},
  keywords="management information base, security, remote access dialin user service, RADIUS-AUTH-SERVER-MIB",
  doi="10.17487/RFC4669",
  }

@misc{rfc4670,
  author="D. Nelson",
  title="{RADIUS Accounting Client MIB for IPv6}",
  howpublished="RFC 4670 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4670",
  pages="1--23",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4670.txt",
  key="RFC 4670",
  abstract={This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients. This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.},
  keywords="management information base, security, remote access dialin user service, RADIUS-ACC-CLIENT-MIB",
  doi="10.17487/RFC4670",
  }

@misc{rfc4671,
  author="D. Nelson",
  title="{RADIUS Accounting Server MIB for IPv6}",
  howpublished="RFC 4671 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4671",
  pages="1--24",
  year=2006,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4671.txt",
  key="RFC 4671",
  abstract={This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers. This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.},
  keywords="management information base, security, remote access dialin user service, RADIUS-ACC-SERVER-MIB",
  doi="10.17487/RFC4671",
  }

@misc{rfc4672,
  author="S. De Cnodder and N. Jonnala and M. Chiba",
  title="{RADIUS Dynamic Authorization Client MIB}",
  howpublished="RFC 4672 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4672",
  pages="1--24",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4672.txt",
  key="RFC 4672",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576.  This memo provides information for the Internet community.},
  keywords="remote authentication dial-in user service, dac, dynamic authorization client, RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS, management information base",
  doi="10.17487/RFC4672",
  }

@misc{rfc4673,
  author="S. De Cnodder and N. Jonnala and M. Chiba",
  title="{RADIUS Dynamic Authorization Server MIB}",
  howpublished="RFC 4673 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4673",
  pages="1--24",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4673.txt",
  key="RFC 4673",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576.  This memo provides information for the Internet community.},
  keywords="management information base, remote authentication dial-in user service, RADIUS-DYNAUTH-SERVER-MIB",
  doi="10.17487/RFC4673",
  }

@misc{rfc4674,
  author="J.L. Le Roux",
  title="{Requirements for Path Computation Element (PCE) Discovery}",
  howpublished="RFC 4674 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4674",
  pages="1--19",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4674.txt",
  key="RFC 4674",
  abstract={This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection.  It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.  This memo provides information for the Internet community.},
  keywords="path computation client, pcc",
  doi="10.17487/RFC4674",
  }

@misc{rfc4675,
  author="P. Congdon and M. Sanchez and B. Aboba",
  title="{RADIUS Attributes for Virtual LAN and Priority Support}",
  howpublished="RFC 4675 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4675",
  pages="1--15",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4675.txt",
  key="RFC 4675",
  abstract={This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks.  These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]},
  keywords="remote authentication dial-in user service, local area network",
  doi="10.17487/RFC4675",
  }

@misc{rfc4676,
  author="H. Schulzrinne",
  title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information}",
  howpublished="RFC 4676 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4676",
  pages="1--19",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4776",
url="https://www.rfc-editor.org/rfc/rfc4676.txt",
  key="RFC 4676",
  abstract={This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server.  The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information.  The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]},
  keywords="lci, local configuration information",
  doi="10.17487/RFC4676",
  }

@misc{rfc4677,
  author="P. Hoffman and S. Harris",
  title="{The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force}",
  howpublished="RFC 4677 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4677",
  pages="1--50",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6722",
url="https://www.rfc-editor.org/rfc/rfc4677.txt",
  key="RFC 4677",
  abstract={This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process.  It is not a formal IETF process document but instead an informational overview.  This memo provides information for the Internet community.},
  keywords="meeting",
  doi="10.17487/RFC4677",
  }

@misc{rfc4678,
  author="A. Bivens",
  title="{Server/Application State Protocol v1}",
  howpublished="RFC 4678 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4678",
  pages="1--48",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4678.txt",
  key="RFC 4678",
  abstract={Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion.  Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work.  The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.  This memo provides information for the Internet community.},
  keywords="sasp, server/application state protocol",
  doi="10.17487/RFC4678",
  }

@misc{rfc4679,
  author="V. Mammoliti and G. Zorn and P. Arberg and R. Rennison",
  title="{DSL Forum Vendor-Specific RADIUS Attributes}",
  howpublished="RFC 4679 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4679",
  pages="1--25",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4679.txt",
  key="RFC 4679",
  abstract={This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum. These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.},
  keywords="remote authentication dial-in user service, vsa, dsl, digital subscriber line",
  doi="10.17487/RFC4679",
  }

@misc{rfc4680,
  author="S. Santesson",
  title="{TLS Handshake Message for Supplemental Data}",
  howpublished="RFC 4680 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4680",
  pages="1--9",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4680.txt",
  key="RFC 4680",
  abstract={This specification defines a TLS handshake message for exchange of supplemental application data.  TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server.  Then, the supplemental data handshake message is used to exchange the data.  Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]},
  keywords="transport layer security",
  doi="10.17487/RFC4680",
  }

@misc{rfc4681,
  author="S. Santesson and A. Medvinsky and J. Ball",
  title="{TLS User Mapping Extension}",
  howpublished="RFC 4681 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4681",
  pages="1--11",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4681.txt",
  key="RFC 4681",
  abstract={This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680.  One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database.  Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]},
  keywords="transport layer security, handshake message, upndomainhint",
  doi="10.17487/RFC4681",
  }

@misc{rfc4682,
  author="E. Nechamkin and J-F. Mule",
  title="{Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices}",
  howpublished="RFC 4682 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4682",
  pages="1--60",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4682.txt",
  key="RFC 4682",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]},
  keywords="mib, snmp, simple network management protocol, PKTC-IETF-MTA-MIB",
  doi="10.17487/RFC4682",
  }

@misc{rfc4683,
  author="J. Park and J. Lee and H.. Lee and S. Park and T. Polk",
  title="{Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)}",
  howpublished="RFC 4683 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4683",
  pages="1--20",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4683.txt",
  key="RFC 4683",
  abstract={This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate. The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]},
  keywords="subjectaltname, privacy-sensitive, identifiers, pepsi",
  doi="10.17487/RFC4683",
  }

@misc{rfc4684,
  author="P. Marques and R. Bonica and L. Fang and L. Martini and R. Raszuk and K. Patel and J. Guichard",
  title="{Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)}",
  howpublished="RFC 4684 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4684",
  pages="1--14",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4684.txt",
  key="RFC 4684",
  abstract={This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information.  This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system.  This document updates RFC 4364. [STANDARDS-TRACK]},
  keywords="mp-bgp, bgp speakers, route target",
  doi="10.17487/RFC4684",
  }

@misc{rfc4685,
  author="J. Snell",
  title="{Atom Threading Extensions}",
  howpublished="RFC 4685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4685",
  pages="1--12",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4685.txt",
  key="RFC 4685",
  abstract={This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]},
  keywords="atom syndication format, extension, threading, syndication",
  doi="10.17487/RFC4685",
  }

@misc{rfc4686,
  author="J. Fenton",
  title="{Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)}",
  howpublished="RFC 4686 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4686",
  pages="1--29",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4686.txt",
  key="RFC 4686",
  abstract={This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail.  It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks.  This memo provides information for the Internet community.},
  keywords="email, attack, authentication, signature, ssp",
  doi="10.17487/RFC4686",
  }

@misc{rfc4687,
  author="S. Yasukawa and A. Farrel and D. King and T. Nadeau",
  title="{Operations and Management (OAM) Requirements  for Point-to-Multipoint MPLS Networks}",
  howpublished="RFC 4687 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4687",
  pages="1--14",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4687.txt",
  key="RFC 4687",
  abstract={Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical. For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network. This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, pwmp, lsp, p2mp mpls lsp",
  doi="10.17487/RFC4687",
  }

@misc{rfc4688,
  author="S. Rushing",
  title="{A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D}",
  howpublished="RFC 4688 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4688",
  pages="1--8",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4688.txt",
  key="RFC 4688",
  abstract={This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4688",
  }

@misc{rfc4689,
  author="S. Poretsky and J. Perser and S. Erramilli and S. Khurana",
  title="{Terminology for Benchmarking Network-layer Traffic Control Mechanisms}",
  howpublished="RFC 4689 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4689",
  pages="1--34",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4689.txt",
  key="RFC 4689",
  abstract={This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria.  The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms.  Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.  This memo provides information for the Internet community.},
  keywords="packet classification",
  doi="10.17487/RFC4689",
  }

@misc{rfc4690,
  author="J. Klensin and P. Faltstrom and C. Karp and IAB",
  title="{Review and Recommendations for Internationalized Domain Names (IDNs)}",
  howpublished="RFC 4690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4690",
  pages="1--37",
  year=2006,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4690.txt",
  key="RFC 4690",
  abstract={This note describes issues raised by the deployment and use of Internationalized Domain Names.  It describes problems both at the time of registration and for use of those names in the DNS.  It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF.  In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.  This memo provides information for the Internet community.},
  keywords="dns, domain namespace, idna, internationalizing domain names in applications",
  doi="10.17487/RFC4690",
  }

@misc{rfc4691,
  author="L. Andersson",
  title="{Guidelines for Acting as an IETF Liaison to Another Organization}",
  howpublished="RFC 4691 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4691",
  pages="1--14",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4691.txt",
  key="RFC 4691",
  abstract={Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed.  The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052.  This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them.  This memo provides information for the Internet community.},
  keywords="internet engineering task force, sdo, standards development organization, consortium, industrial forum",
  doi="10.17487/RFC4691",
  }

@misc{rfc4692,
  author="G. Huston",
  title="{Considerations on the IPv6 Host Density Metric}",
  howpublished="RFC 4692 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4692",
  pages="1--17",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4692.txt",
  key="RFC 4692",
  abstract={This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks.  This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol.  Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6, ipv6 unicast address blocks",
  doi="10.17487/RFC4692",
  }

@misc{rfc4693,
  author="H. Alvestrand",
  title="{IETF Operational Notes}",
  howpublished="RFC 4693 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4693",
  pages="1--10",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6393",
url="https://www.rfc-editor.org/rfc/rfc4693.txt",
  key="RFC 4693",
  abstract={This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page. It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.},
  keywords="ION",
  doi="10.17487/RFC4693",
  }

@misc{rfc4694,
  author="J. Yu",
  title="{Number Portability Parameters for the ``tel'' URI}",
  howpublished="RFC 4694 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4694",
  pages="1--15",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4694.txt",
  key="RFC 4694",
  abstract={This document defines five parameters in the ``tel'' Uniform Resource Identifier (URI) to carry the number portability (NP)-related information.  Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, np",
  doi="10.17487/RFC4694",
  }

@misc{rfc4695,
  author="J. Lazzaro and J. Wawrzynek",
  title="{RTP Payload Format for MIDI}",
  howpublished="RFC 4695 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4695",
  pages="1--169",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6295",
url="https://www.rfc-editor.org/rfc/rfc4695.txt",
  key="RFC 4695",
  abstract={This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language.  The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable.  The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming).  The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss.  Stream behavior, including the MIDI rendering method, may be customized during session setup.  The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]},
  keywords="asc, content streaming, DLS 2, General MIDI, MIDI, MIDI file, MIDI file streaming, MIDI light control, MIDI rendering, MIDI ringtone, MIDI streaming MIDI sequencer, MIDI time code, MIDI timecode, MIDI Manufacturers Association, MMA mpeg4-generic MPEG 4, MPEG 4 Structured Audio, MPEG 4 Synthetic Coding, MTC, musical notes, network musical performance, recovery journal, Show Control, sonification, ringtone, rtp-midi, RTP, RTP MIDI, SMPTE time code, SMPTE timecode, Standard MIDI Files, XMF",
  doi="10.17487/RFC4695",
  }

@misc{rfc4696,
  author="J. Lazzaro and J. Wawrzynek",
  title="{An Implementation Guide for RTP MIDI}",
  howpublished="RFC 4696 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4696",
  pages="1--38",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4696.txt",
  key="RFC 4696",
  abstract={This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format.  The memo presents its advice in the context of a network musical performance application.  In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room.  Underlying the performances are RTP MIDI sessions over unicast UDP.  Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail.  Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]},
  keywords="checkpoint packet, checkpoint history, guard packets, jitter, keep-alive packets, MIDI, musical telepresence, network musical performance, NMP, receiving algorithm, recovery journal, recovery journal receiving structure, recovery journal sending structure, RTP, RTP MIDI, queuing MIDI, sending algorithm, sending MIDI, telepresence",
  doi="10.17487/RFC4696",
  }

@misc{rfc4697,
  author="M. Larson and P. Barber",
  title="{Observed DNS Resolution Misbehavior}",
  howpublished="RFC 4697 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4697",
  pages="1--18",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4697.txt",
  key="RFC 4697",
  abstract={This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers.  We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries.  The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="domain name system, tld, top level domain",
  doi="10.17487/RFC4697",
  }

@misc{rfc4698,
  author="E. Gunduz and A. Newton and S. Kerr",
  title="{IRIS: An Address Registry (areg) Type for the Internet Registry Information Service}",
  howpublished="RFC 4698 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4698",
  pages="1--48",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4698.txt",
  key="RFC 4698",
  abstract={This document describes an IRIS registry schema for IP address and Autonomous System Number information.  The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS-TRACK]},
  keywords="ip address, autonomous system number, internet protocol address",
  doi="10.17487/RFC4698",
  }

@misc{rfc4701,
  author="M. Stapp and T. Lemon and A. Gustafsson",
  title="{A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)}",
  howpublished="RFC 4701 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4701",
  pages="1--12",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5494",
url="https://www.rfc-editor.org/rfc/rfc4701.txt",
  key="RFC 4701",
  abstract={It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases.  Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise.  To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer.  This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the ``DHCID'' RR. [STANDARDS-TRACK]},
  keywords="dns fqdn, fully qualified domain name",
  doi="10.17487/RFC4701",
  }

@misc{rfc4702,
  author="M. Stapp and B. Volz and Y. Rekhter",
  title="{The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option}",
  howpublished="RFC 4702 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4702",
  pages="1--17",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4702.txt",
  key="RFC 4702",
  abstract={This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]},
  keywords="dhcpv4, dns rr",
  doi="10.17487/RFC4702",
  }

@misc{rfc4703,
  author="M. Stapp and B. Volz",
  title="{Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients}",
  howpublished="RFC 4703 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4703",
  pages="1--13",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4703.txt",
  key="RFC 4703",
  abstract={The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names.  To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS.  This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]},
  keywords="dynamic assignment, dns, dhcid dns rr",
  doi="10.17487/RFC4703",
  }

@misc{rfc4704,
  author="B. Volz",
  title="{The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option}",
  howpublished="RFC 4704 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4704",
  pages="1--15",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4704.txt",
  key="RFC 4704",
  abstract={This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]},
  keywords="dns rr",
  doi="10.17487/RFC4704",
  }

@misc{rfc4705,
  author="R. Housley and A. Corry",
  title="{GigaBeam High-Speed Radio Link Encryption}",
  howpublished="RFC 4705 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4705",
  pages="1--15",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4705.txt",
  key="RFC 4705",
  abstract={This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products.  The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.  This memo provides information for the Internet community.},
  keywords="key management, wifiber, radio link",
  doi="10.17487/RFC4705",
  }

@misc{rfc4706,
  author="M. Morgenstern and M. Dodge and S. Baillie and U. Bonollo",
  title="{Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)}",
  howpublished="RFC 4706 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4706",
  pages="1--167",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4706.txt",
  key="RFC 4706",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing parameters of the ``Asymmetric Digital Subscriber Line'' family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]},
  keywords="mib, management information base, adsl2+, ADSL2-LINE-TC-MIB, ADSL2-LINE-MIB",
  doi="10.17487/RFC4706",
  }

@misc{rfc4707,
  author="P. Grau and V. Heinau and H. Schlichting and R. Schuettler",
  title="{Netnews Administration System (NAS)}",
  howpublished="RFC 4707 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4707",
  pages="1--49",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4707.txt",
  key="RFC 4707",
  abstract={The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol. The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user. NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.},
  keywords="news servers, news administrator, news reader",
  doi="10.17487/RFC4707",
  }

@misc{rfc4708,
  author="A. Miller",
  title="{CellML Media Type}",
  howpublished="RFC 4708 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4708",
  pages="1--7",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4708.txt",
  key="RFC 4708",
  abstract={This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language.  This memo provides information for the Internet community.},
  keywords="media format, mathematical model, mathematical modelling, mathematical modeling, content MathML, markup languages, bioengineering, biology",
  doi="10.17487/RFC4708",
  }

@misc{rfc4709,
  author="J. Reschke",
  title="{Mounting Web Distributed Authoring and Versioning (WebDAV) Servers}",
  howpublished="RFC 4709 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4709",
  pages="1--15",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4709.txt",
  key="RFC 4709",
  abstract={In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server. This document specifies a mechanism and a document format that enables WebDAV servers to send ``mounting'' information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.},
  keywords="drag-and-drop",
  doi="10.17487/RFC4709",
  }

@misc{rfc4710,
  author="A. Siddiqui and D. Romascanu and E. Golovinsky",
  title="{Real-time Application Quality-of-Service Monitoring (RAQMON) Framework}",
  howpublished="RFC 4710 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4710",
  pages="1--36",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4710.txt",
  key="RFC 4710",
  abstract={There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices.  This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP).  This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]},
  keywords="internet protocol, end-devices, qos, quality of service, snmp, simple network management protocol",
  doi="10.17487/RFC4710",
  }

@misc{rfc4711,
  author="A. Siddiqui and D. Romascanu and E. Golovinsky",
  title="{Real-time Application Quality-of-Service Monitoring (RAQMON) MIB}",
  howpublished="RFC 4711 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4711",
  pages="1--38",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4711.txt",
  key="RFC 4711",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  The document proposes an extension to the Remote Monitoring MIB, RFC 2819.  In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]},
  keywords="management information base, remote monitoring mib, qos, RAQMON-MIB",
  doi="10.17487/RFC4711",
  }

@misc{rfc4712,
  author="A. Siddiqui and D. Romascanu and E. Golovinsky and M. Rahman and Y. Kim",
  title="{Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)}",
  howpublished="RFC 4712 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4712",
  pages="1--48",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4712.txt",
  key="RFC 4712",
  abstract={This memo specifies two transport mappings of the \\%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]},
  keywords="mib, management information base, snmp, simple network management protocol, rds, raqmon data source, qos, RAQMON-RDS-MIB",
  doi="10.17487/RFC4712",
  }

@misc{rfc4713,
  author="X. Lee and W. Mao and E. Chen and N. Hsu and J. Klensin",
  title="{Registration and Administration Recommendations for Chinese Domain Names}",
  howpublished="RFC 4713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4713",
  pages="1--9",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4713.txt",
  key="RFC 4713",
  abstract={Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms.  The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration.  This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names.  The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese.  This memo provides information for the Internet community.},
  keywords="cdn, sc, simplified chinese, tc, traditional chinese",
  doi="10.17487/RFC4713",
  }

@misc{rfc4714,
  author="A. Mankin and S. Hayes",
  title="{Requirements for IETF Technical Publication Service}",
  howpublished="RFC 4714 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4714",
  pages="1--24",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4714.txt",
  key="RFC 4714",
  abstract={The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation.  Technical publication is the process by which that output is disseminated to the community at large.  As such, it is important to understand the requirements on the publication process.  This memo provides information for the Internet community.},
  keywords="internet engineering task force",
  doi="10.17487/RFC4714",
  }

@misc{rfc4715,
  author="M. Munakata and S. Schubert and T. Ohba",
  title="{The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI}",
  howpublished="RFC 4715 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4715",
  pages="1--14",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4715.txt",
  key="RFC 4715",
  abstract={Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases.  To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress.  This memo provides information for the Internet community.},
  keywords="uniform resource identifier, isup, isdn user part",
  doi="10.17487/RFC4715",
  }

@misc{rfc4716,
  author="J. Galbraith and R. Thayer",
  title="{The Secure Shell (SSH) Public Key File Format}",
  howpublished="RFC 4716 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4716",
  pages="1--10",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4716.txt",
  key="RFC 4716",
  abstract={This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.},
  doi="10.17487/RFC4716",
  }

@misc{rfc4717,
  author="L. Martini and J. Jayakumar and M. Bocci and N. El-Aawar and J. Brayley and G. Koleyni",
  title="{Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks}",
  howpublished="RFC 4717 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4717",
  pages="1--40",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4717.txt",
  key="RFC 4717",
  abstract={An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network.  This enables service providers to offer ``emulated'' ATM services over existing MPLS networks.  This document specifies methods for the encapsulation of ATM cells within a pseudowire.  It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]},
  keywords="pw, pseudowire, multiprotocol label switching",
  doi="10.17487/RFC4717",
  }

@misc{rfc4718,
  author="P. Eronen and P. Hoffman",
  title="{IKEv2 Clarifications and Implementation Guidelines}",
  howpublished="RFC 4718 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4718",
  pages="1--58",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5996",
url="https://www.rfc-editor.org/rfc/rfc4718.txt",
  key="RFC 4718",
  abstract={This document clarifies many areas of the IKEv2 specification.  It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations.  The purpose of this document is to encourage the development of interoperable implementations.  This memo provides information for the Internet community.},
  keywords="internet key exchange",
  doi="10.17487/RFC4718",
  }

@misc{rfc4719,
  author="R. Aggarwal and M. Townsley and M. Dos Santos",
  title="{Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}",
  howpublished="RFC 4719 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4719",
  pages="1--14",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5641",
url="https://www.rfc-editor.org/rfc/rfc4719.txt",
  key="RFC 4719",
  abstract={This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3).  This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames.  The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]},
  keywords="port-to-port, vlan",
  doi="10.17487/RFC4719",
  }

@misc{rfc4720,
  author="A. Malis and D. Allan and N. Del Regno",
  title="{Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention}",
  howpublished="RFC 4720 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4720",
  pages="1--9",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4720.txt",
  key="RFC 4720",
  abstract={This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]},
  keywords="fcs",
  doi="10.17487/RFC4720",
  }

@misc{rfc4721,
  author="C. Perkins and P. Calhoun and J. Bharatia",
  title="{Mobile IPv4 Challenge/Response Extensions (Revised)}",
  howpublished="RFC 4721 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4721",
  pages="1--26",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4721.txt",
  key="RFC 4721",
  abstract={Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]},
  keywords="chap",
  doi="10.17487/RFC4721",
  }

@misc{rfc4722,
  author="J. Van Dyke and E. Burger and A. Spitzer",
  title="{Media Server Control Markup Language (MSCML) and Protocol}",
  howpublished="RFC 4722 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4722",
  pages="1--81",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5022",
url="https://www.rfc-editor.org/rfc/rfc4722.txt",
  key="RFC 4722",
  abstract={Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions.  MSCML presents an application-level control model, as opposed to device-level control models.  One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.  This memo provides information for the Internet community.},
  keywords="sip, ivr, interactive voice response",
  doi="10.17487/RFC4722",
  }

@misc{rfc4723,
  author="T. Kosonen and T. White",
  title="{Registration of Media Type audio/mobile-xmf}",
  howpublished="RFC 4723 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4723",
  pages="1--8",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4723.txt",
  key="RFC 4723",
  abstract={The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications.  Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration.  This document registers the media type audio/mobile-xmf.  This memo provides information for the Internet community.},
  keywords="mma, midi manufacturers association, association of musical electronices industry, amei, MIDI, Musical Instrument Digital Interface",
  doi="10.17487/RFC4723",
  }

@misc{rfc4724,
  author="S. Sangli and E. Chen and R. Fernando and J. Scudder and Y. Rekhter",
  title="{Graceful Restart Mechanism for BGP}",
  howpublished="RFC 4724 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4724",
  pages="1--15",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4724.txt",
  key="RFC 4724",
  abstract={This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed ``Graceful Restart Capability'', is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]},
  keywords="border gateway protocol, end-of-rib, bgp restart",
  doi="10.17487/RFC4724",
  }

@misc{rfc4725,
  author="A. Mayrhofer and B. Hoeneisen",
  title="{ENUM Validation Architecture}",
  howpublished="RFC 4725 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4725",
  pages="1--17",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4725.txt",
  key="RFC 4725",
  abstract={An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ``validation''.  This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure.  This memo provides information for the Internet community.},
  keywords="E.164, Registry, Registrar, Registrant, Assignee",
  doi="10.17487/RFC4725",
  }

@misc{rfc4726,
  author="A. Farrel and J.-P. Vasseur and A. Ayyangar",
  title="{A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering}",
  howpublished="RFC 4726 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4726",
  pages="1--22",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4726.txt",
  key="RFC 4726",
  abstract={This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.},
  keywords="mpls, mpls-te, te, lsp, label switched path",
  doi="10.17487/RFC4726",
  }

@misc{rfc4727,
  author="B. Fenner",
  title="{Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers}",
  howpublished="RFC 4727 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4727",
  pages="1--11",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4727.txt",
  key="RFC 4727",
  abstract={When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment.  This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4727",
  }

@misc{rfc4728,
  author="D. Johnson and Y. Hu and D. Maltz",
  title="{The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4}",
  howpublished="RFC 4728 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4728",
  pages="1--107",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4728.txt",
  key="RFC 4728",
  abstract={The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes.  DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration.  The protocol is composed of the two main mechanisms of ``Route Discovery'' and ``Route Maintenance'', which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.  All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use.  The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.  Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only ``soft state'' in routing, and very rapid recovery when routes in the network change.  The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility.  This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="route discovery, route maintenance",
  doi="10.17487/RFC4728",
  }

@misc{rfc4729,
  author="M. Abel",
  title="{A Uniform Resource Name (URN) Namespace for  the Near Field Communication (NFC) Forum}",
  howpublished="RFC 4729 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4729",
  pages="1--7",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4729.txt",
  key="RFC 4729",
  abstract={This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum.  The NFC Forum defines and manages resources that utilize this URN identification model.  Management activities for these and other resource types are provided by the NFC Forum Technical Committee.  This memo provides information for the Internet community.},
  keywords="forum technical committee",
  doi="10.17487/RFC4729",
  }

@misc{rfc4730,
  author="E. Burger and M. Dolly",
  title="{A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)}",
  howpublished="RFC 4730 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4730",
  pages="1--56",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4730.txt",
  key="RFC 4730",
  abstract={This document describes a SIP Event Package ``kpml'' that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML).  The kpml Event Package may be used to support applications consistent with the principles defined in the document titled ``A Framework for Application Interaction in the Session Initiation Protocol (SIP)''.  The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA).  The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server.  The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]},
  keywords="ua, user agent, dtmf, dual tone multi-frequency",
  doi="10.17487/RFC4730",
  }

@misc{rfc4731,
  author="A. Melnikov and D. Cridland",
  title="{IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned}",
  howpublished="RFC 4731 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4731",
  pages="1--6",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4731.txt",
  key="RFC 4731",
  abstract={This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned.  The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]},
  keywords="uid search, uid",
  doi="10.17487/RFC4731",
  }

@misc{rfc4732,
  author="M. Handley and E. Rescorla and IAB",
  title="{Internet Denial-of-Service Considerations}",
  howpublished="RFC 4732 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4732",
  pages="1--38",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4732.txt",
  key="RFC 4732",
  abstract={This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems.  The aim is to encourage protocol designers and network engineers towards designs that are more robust.  We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.  This memo provides information for the Internet community.},
  keywords="dos",
  doi="10.17487/RFC4732",
  }

@misc{rfc4733,
  author="H. Schulzrinne and T. Taylor",
  title="{RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals}",
  howpublished="RFC 4733 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4733",
  pages="1--49",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4734, 5244",
url="https://www.rfc-editor.org/rfc/rfc4733.txt",
  key="RFC 4733",
  abstract={This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use. This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]},
  keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency",
  doi="10.17487/RFC4733",
  }

@misc{rfc4734,
  author="H. Schulzrinne and T. Taylor",
  title="{Definition of Events for Modem, Fax, and Text Telephony Signals}",
  howpublished="RFC 4734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4734",
  pages="1--47",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4734.txt",
  key="RFC 4734",
  abstract={This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload.  It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]},
  keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency",
  doi="10.17487/RFC4734",
  }

@misc{rfc4735,
  author="T. Taylor",
  title="{Example Media Types for Use in Documentation}",
  howpublished="RFC 4735 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4735",
  pages="1--6",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4735.txt",
  key="RFC 4735",
  abstract={This document is registration for the 'example' media type and 'example' subtypes within the standards tree.  The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]},
  keywords="media type, example",
  doi="10.17487/RFC4735",
  }

@misc{rfc4736,
  author="JP. Vasseur and Y. Ikejiri and R. Zhang",
  title="{Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)}",
  howpublished="RFC 4736 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4736",
  pages="1--14",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4736.txt",
  key="RFC 4736",
  abstract={This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE).  This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path).  The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.  This memo provides information for the Internet community.},
  keywords="rsvp-te, te lsp path",
  doi="10.17487/RFC4736",
  }

@misc{rfc4737,
  author="A. Morton and L. Ciavattone and G. Ramachandran and S. Shalunov and J. Perser",
  title="{Packet Reordering Metrics}",
  howpublished="RFC 4737 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4737",
  pages="1--45",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6248",
url="https://www.rfc-editor.org/rfc/rfc4737.txt",
  key="RFC 4737",
  abstract={This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis.  It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics.  The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.  Additional metrics quantify the frequency of reordering and the distance between separate occurrences.  We then define a metric oriented toward assessment of reordering effects on TCP.  Several examples of evaluation using the various sample metrics are included.  An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]},
  keywords="ippm",
  doi="10.17487/RFC4737",
  }

@misc{rfc4738,
  author="D. Ignjatic and L. Dondeti and F. Audet and P. Lin",
  title="{MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 4738 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4738",
  pages="1--19",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4738.txt",
  key="RFC 4738",
  abstract={The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange.  In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder.  In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance.  We propose a new MIKEY mode that works well in such scenarios.  This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members).  This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]},
  keywords="MIKEY, SRTP, key management, group key distribution, RSA-R",
  doi="10.17487/RFC4738",
  }

@misc{rfc4739,
  author="P. Eronen and J. Korhonen",
  title="{Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol}",
  howpublished="RFC 4739 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4739",
  pages="1--11",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4739.txt",
  key="RFC 4739",
  abstract={The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods.  Currently, each endpoint uses only one of these mechanisms to authenticate itself.  This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism.  This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user.  When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC4739",
  }

@misc{rfc4740,
  author="M. Garcia-Martin and M. Belinchon and M. Pallares-Lopez and C. Canales-Valenzuela and K. Tammi",
  title="{Diameter Session Initiation Protocol (SIP) Application}",
  howpublished="RFC 4740 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4740",
  pages="1--72",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4740.txt",
  key="RFC 4740",
  abstract={This document specifies the Diameter Session Initiation Protocol (SIP) application.  This is a Diameter application that allows a Diameter client to request authentication and authorization information.  This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]},
  keywords="authentication, authorization, diameter client",
  doi="10.17487/RFC4740",
  }

@misc{rfc4741,
  author="R. Enns",
  title="{NETCONF Configuration Protocol}",
  howpublished="RFC 4741 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4741",
  pages="1--95",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6241",
url="https://www.rfc-editor.org/rfc/rfc4741.txt",
  key="RFC 4741",
  abstract={The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]},
  keywords="network configuration protocol, network device, xml, extensible markup language, rpc, remote procedure call",
  doi="10.17487/RFC4741",
  }

@misc{rfc4742,
  author="M. Wasserman and T. Goddard",
  title="{Using the NETCONF Configuration Protocol over Secure SHell (SSH)}",
  howpublished="RFC 4742 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4742",
  pages="1--10",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6242",
url="https://www.rfc-editor.org/rfc/rfc4742.txt",
  key="RFC 4742",
  abstract={This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]},
  keywords="network configuration protocol",
  doi="10.17487/RFC4742",
  }

@misc{rfc4743,
  author="T. Goddard",
  title="{Using NETCONF over the Simple Object Access Protocol (SOAP)}",
  howpublished="RFC 4743 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4743",
  pages="1--20",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4743.txt",
  key="RFC 4743",
  abstract={The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments.  Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP).  NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems.  Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]},
  keywords="NETCONF, XMLCONF, SOAP, device managment, XML, Extensible Markup Language",
  doi="10.17487/RFC4743",
  }

@misc{rfc4744,
  author="E. Lear and K. Crozier",
  title="{Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 4744 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4744",
  pages="1--10",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4744.txt",
  key="RFC 4744",
  abstract={This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]},
  keywords="XML, Configuration, Network Management, Extensible Markup Language",
  doi="10.17487/RFC4744",
  }

@misc{rfc4745,
  author="H. Schulzrinne and H. Tschofenig and J. Morris and J. Cuellar and J. Polk and J. Rosenberg",
  title="{Common Policy: A Document Format for Expressing Privacy Preferences}",
  howpublished="RFC 4745 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4745",
  pages="1--32",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4745.txt",
  key="RFC 4745",
  abstract={This document defines a framework for authorization policies controlling access to application-specific data.  This framework combines common location- and presence-specific authorization aspects.  An XML schema specifies the language in which common policy rules are represented.  The common policy framework can be extended to other application domains. [STANDARDS-TRACK]},
  keywords="rules, conditions, permissions",
  doi="10.17487/RFC4745",
  }

@misc{rfc4746,
  author="T. Clancy and W. Arbaugh",
  title="{Extensible Authentication Protocol (EAP) Password Authenticated Exchange}",
  howpublished="RFC 4746 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4746",
  pages="1--30",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4746.txt",
  key="RFC 4746",
  abstract={This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange).  This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange.  This memo provides information for the Internet community.},
  keywords="EAP-PAX, password authenticated exchange, key exchange",
  doi="10.17487/RFC4746",
  }

@misc{rfc4747,
  author="S. Kipp and G. Ramkumar and K. McCloghrie",
  title="{The Virtual Fabrics MIB}",
  howpublished="RFC 4747 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4747",
  pages="1--20",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4747.txt",
  key="RFC 4747",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-VIRTUAL-FABRIC-MIB, fibre channel network, virtual fabric",
  doi="10.17487/RFC4747",
  }

@misc{rfc4748,
  author="S. Bradner",
  title="{RFC 3978 Update to Recognize the IETF Trust}",
  howpublished="RFC 4748 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4748",
  pages="1--4",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5378",
url="https://www.rfc-editor.org/rfc/rfc4748.txt",
  key="RFC 4748",
  abstract={This document updates RFC 3978 ``IETF Rights in Contributions'' to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights. This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipr, intellectual property rights, copyright",
  doi="10.17487/RFC4748",
  }

@misc{rfc4749,
  author="A. Sollaud",
  title="{RTP Payload Format for the G.729.1 Audio Codec}",
  howpublished="RFC 4749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4749",
  pages="1--14",
  year=2006,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5459",
url="https://www.rfc-editor.org/rfc/rfc4749.txt",
  key="RFC 4749",
  abstract={This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec.  A media type registration is included for this payload format. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, itu-t, international telecommunication union",
  doi="10.17487/RFC4749",
  }

@misc{rfc4750,
  author="D. Joyal and P. Galecki and S. Giacalone and R. Coltun and F. Baker",
  title="{OSPF Version 2 Management Information Base}",
  howpublished="RFC 4750 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4750",
  pages="1--121",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4750.txt",
  key="RFC 4750",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]},
  keywords="OSPF-MIB, Open Shortest Path First, SPF, MIB, routing, network management mib, OSPF-MIB, OSPF-TRAP-MIB",
  doi="10.17487/RFC4750",
  }

@misc{rfc4752,
  author="A. Melnikov",
  title="{The Kerberos V5 (``GSSAPI'') Simple Authentication and Security Layer (SASL) Mechanism}",
  howpublished="RFC 4752 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4752",
  pages="1--10",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4752.txt",
  key="RFC 4752",
  abstract={The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL. This document replaces Section 7.2 of RFC 2222, the definition of the ``GSSAPI'' SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]},
  keywords="SASL, encryption, protocol, specific",
  doi="10.17487/RFC4752",
  }

@misc{rfc4753,
  author="D. Fu and J. Solinas",
  title="{ECP Groups For IKE and IKEv2}",
  howpublished="RFC 4753 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4753",
  pages="1--16",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5903",
url="https://www.rfc-editor.org/rfc/rfc4753.txt",
  key="RFC 4753",
  abstract={This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.  Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic.  These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards.  In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups.  This memo provides information for the Internet community.},
  keywords="elliptic curve, Diffie-Hellman, suite b, nist curve",
  doi="10.17487/RFC4753",
  }

@misc{rfc4754,
  author="D. Fu and J. Solinas",
  title="{IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)}",
  howpublished="RFC 4754 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4754",
  pages="1--15",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4754.txt",
  key="RFC 4754",
  abstract={This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols.  ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods.  This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]},
  keywords="suite b",
  doi="10.17487/RFC4754",
  }

@misc{rfc4755,
  author="V. Kashyap",
  title="{IP over InfiniBand: Connected Mode}",
  howpublished="RFC 4755 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4755",
  pages="1--13",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4755.txt",
  key="RFC 4755",
  abstract={This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4755",
  }

@misc{rfc4756,
  author="A. Li",
  title="{Forward Error Correction Grouping Semantics in Session Description Protocol}",
  howpublished="RFC 4756 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4756",
  pages="1--6",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5956",
url="https://www.rfc-editor.org/rfc/rfc4756.txt",
  key="RFC 4756",
  abstract={This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP).  The semantics defined in this document are to be used with ``Grouping of Media Lines in the Session Description Protocol'' (RFC 3388) to group together ``m'' lines in the same session. [STANDARDS-TRACK]},
  keywords="fec, sdp, media lines",
  doi="10.17487/RFC4756",
  }

@misc{rfc4757,
  author="K. Jaganathan and L. Zhu and J. Brezak",
  title="{The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows}",
  howpublished="RFC 4757 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4757",
  pages="1--18",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6649",
url="https://www.rfc-editor.org/rfc/rfc4757.txt",
  key="RFC 4757",
  abstract={The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.},
  keywords="md5 hmac",
  doi="10.17487/RFC4757",
  }

@misc{rfc4758,
  author="M. Nystroem",
  title="{Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1}",
  howpublished="RFC 4758 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4758",
  pages="1--54",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4758.txt",
  key="RFC 4758",
  abstract={This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no ``bits-on-the-wire'' have changed, the protocol specified herein is compatible with CT-KIP Version 1.0. CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.},
  keywords="rsa laboratories, one-time password specifications, otps",
  doi="10.17487/RFC4758",
  }

@misc{rfc4759,
  author="R. Stastny and R. Shockey and L. Conroy",
  title="{The ENUM Dip Indicator Parameter for the ``tel'' URI}",
  howpublished="RFC 4759 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4759",
  pages="1--8",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4759.txt",
  key="RFC 4759",
  abstract={This document defines a new parameter ``enumdi'' for the ``tel'' Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements.  A VoIP network element may receive a URI containing an E.164 number, where that URI contains an ``enumdi'' parameter.  The presence of the ``enumdi'' parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element.  Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]},
  keywords="DNS, E.164, telephone number",
  doi="10.17487/RFC4759",
  }

@misc{rfc4760,
  author="T. Bates and R. Chandra and D. Katz and Y. Rekhter",
  title="{Multiprotocol Extensions for BGP-4}",
  howpublished="RFC 4760 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4760",
  pages="1--12",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7606",
url="https://www.rfc-editor.org/rfc/rfc4760.txt",
  key="RFC 4760",
  abstract={This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.).  The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]},
  keywords="MEXT-BGP4, border gateway protocol, network layer protocols",
  doi="10.17487/RFC4760",
  }

@misc{rfc4761,
  author="K. Kompella and Y. Rekhter",
  title="{Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling}",
  howpublished="RFC 4761 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4761",
  pages="1--28",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc4761.txt",
  key="RFC 4761",
  abstract={Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]},
  keywords="border gateway protocol, transparent lan service, virtual private switched network, service provider",
  doi="10.17487/RFC4761",
  }

@misc{rfc4762,
  author="M. Lasserre and V. Kompella",
  title="{Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling}",
  howpublished="RFC 4762 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4762",
  pages="1--31",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4762.txt",
  key="RFC 4762",
  abstract={This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node. This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]},
  keywords="land area network, transparent lan service",
  doi="10.17487/RFC4762",
  }

@misc{rfc4763,
  author="M. Vanderveen and H. Soliman",
  title="{Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)}",
  howpublished="RFC 4763 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4763",
  pages="1--46",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4763.txt",
  key="RFC 4763",
  abstract={This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE).  This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748.  The specification has passed Designated Expert review for this IANA assignment.  This memo provides information for the Internet community.},
  keywords="IEEE 802.11i, user anonymity",
  doi="10.17487/RFC4763",
  }

@misc{rfc4764,
  author="F. Bersani and H. Tschofenig",
  title="{The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method}",
  howpublished="RFC 4764 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4764",
  pages="1--64",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4764.txt",
  key="RFC 4764",
  abstract={This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK).  EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over.  This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes.  EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="pre-shared key",
  doi="10.17487/RFC4764",
  }

@misc{rfc4765,
  author="H. Debar and D. Curry and B. Feinstein",
  title="{The Intrusion Detection Message Exchange Format (IDMEF)}",
  howpublished="RFC 4765 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4765",
  pages="1--157",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4765.txt",
  key="RFC 4765",
  abstract={The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.},
  keywords="intrusion detection, security, secure, exchange, intrusion, IDS, XML",
  doi="10.17487/RFC4765",
  }

@misc{rfc4766,
  author="M. Wood and M. Erlinger",
  title="{Intrusion Detection Message Exchange Requirements}",
  howpublished="RFC 4766 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4766",
  pages="1--25",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4766.txt",
  key="RFC 4766",
  abstract={The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.  This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed.  Scenarios are used to illustrate some requirements.  This memo provides information for the Internet community.},
  keywords="idmef, idwg, intrusion detection exchange format",
  doi="10.17487/RFC4766",
  }

@misc{rfc4767,
  author="B. Feinstein and G. Matthews",
  title="{The Intrusion Detection Exchange Protocol (IDXP)}",
  howpublished="RFC 4767 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4767",
  pages="1--28",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4767.txt",
  key="RFC 4767",
  abstract={This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities.  IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol.  The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data.  The IDMEF message elements are described in RFC 4765, ``The Intrusion Detection Message Exchange Format (IDMEF)'', a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="intrusion, intrusion detection, beep, security, ids, security protocol, secure protocol, secure exchange, idmef",
  doi="10.17487/RFC4767",
  }

@misc{rfc4768,
  author="S. Hartman",
  title="{Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming}",
  howpublished="RFC 4768 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4768",
  pages="1--12",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4768.txt",
  key="RFC 4768",
  abstract={The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization.  GSS-API authenticates two named parties to each other.  Names can be stored on access control lists (ACLs) to make authorization decisions.  Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API.  As people move within an organization or change their names, the name authenticated by GSS-API may change.  Using some sort of constant identifier would make ACLs more stable.  Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments.  Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication.  This document motivates extensions to GSS-API naming and describes the extensions under discussion.  This memo provides information for the Internet community.},
  keywords="acl, access control list",
  doi="10.17487/RFC4768",
  }

@misc{rfc4769,
  author="J. Livingood and R. Shockey",
  title="{IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information}",
  howpublished="RFC 4769 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4769",
  pages="1--13",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4769.txt",
  key="RFC 4769",
  abstract={This document registers the Enumservice type ``pstn'' and subtype ``tel'' using the URI scheme 'tel', as well as the subtype ``sip'' using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761.  This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]},
  keywords="tel, uri, uri scheme, sip",
  doi="10.17487/RFC4769",
  }

@misc{rfc4770,
  author="C. Jennings and J. Reschke",
  title="{vCard Extensions for Instant Messaging (IM)}",
  howpublished="RFC 4770 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4770",
  pages="1--7",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6350",
url="https://www.rfc-editor.org/rfc/rfc4770.txt",
  key="RFC 4770",
  abstract={This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications.  IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books.  It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]},
  keywords="impp, instant messaging and presence protocol",
  doi="10.17487/RFC4770",
  }

@misc{rfc4771,
  author="V. Lehtovirta and M. Naslund and K. Norrman",
  title="{Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 4771 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4771",
  pages="1--12",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4771.txt",
  key="RFC 4771",
  abstract={This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag.  The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize.  The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]},
  keywords="roc",
  doi="10.17487/RFC4771",
  }

@misc{rfc4772,
  author="S. Kelly",
  title="{Security Implications of Using the Data Encryption Standard (DES)}",
  howpublished="RFC 4772 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4772",
  pages="1--28",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4772.txt",
  key="RFC 4772",
  abstract={The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary.  As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES).  Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications.  While this is not always inappropriate, it frequently is.  This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4772",
  }

@misc{rfc4773,
  author="G. Huston",
  title="{Administration of the IANA Special Purpose IPv6 Address Block}",
  howpublished="RFC 4773 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4773",
  pages="1--5",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6890",
url="https://www.rfc-editor.org/rfc/rfc4773.txt",
  key="RFC 4773",
  abstract={This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4773",
  }

@misc{rfc4774,
  author="S. Floyd",
  title="{Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field}",
  howpublished="RFC 4774 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4774",
  pages="1--15",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6040",
url="https://www.rfc-editor.org/rfc/rfc4774.txt",
  key="RFC 4774",
  abstract={There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168.  This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.  This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4774",
  }

@misc{rfc4775,
  author="S. Bradner and B. Carpenter and T. Narten",
  title="{Procedures for Protocol Extensions and Variations}",
  howpublished="RFC 4775 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4775",
  pages="1--14",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4775.txt",
  key="RFC 4775",
  abstract={This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF. This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="sdo, standards development organization",
  doi="10.17487/RFC4775",
  }

@misc{rfc4776,
  author="H. Schulzrinne",
  title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information}",
  howpublished="RFC 4776 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4776",
  pages="1--19",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5774, 6848",
url="https://www.rfc-editor.org/rfc/rfc4776.txt",
  key="RFC 4776",
  abstract={This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server.  The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information.  The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]},
  keywords="lci, local configuration information",
  doi="10.17487/RFC4776",
  }

@misc{rfc4777,
  author="T. {Murphy Jr.} and P. Rieth and J. Stevens",
  title="{IBM's iSeries Telnet Enhancements}",
  howpublished="RFC 4777 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4777",
  pages="1--47",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4777.txt",
  key="RFC 4777",
  abstract={This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc. These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.},
  keywords="midrange business computer, telnet environment, client, server, printer",
  doi="10.17487/RFC4777",
  }

@misc{rfc4778,
  author="M. Kaeo",
  title="{Operational Security Current Practices in Internet Service Provider Environments}",
  howpublished="RFC 4778 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4778",
  pages="1--37",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4778.txt",
  key="RFC 4778",
  abstract={This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices.  The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.  This memo provides information for the Internet community.},
  keywords="isp",
  doi="10.17487/RFC4778",
  }

@misc{rfc4779,
  author="S. Asadullah and A. Ahmed and C. Popoviciu and P. Savola and J. Palet",
  title="{ISP IPv6 Deployment Scenarios in Broadband Access Networks}",
  howpublished="RFC 4779 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4779",
  pages="1--81",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4779.txt",
  key="RFC 4779",
  abstract={This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services.  Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document.  The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness.  In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.  This memo provides information for the Internet community.},
  keywords="v6ops, isp, ipv6, deployment, scenarios, broadband, networks",
  doi="10.17487/RFC4779",
  }

@misc{rfc4780,
  author="K. Lingle and J-F. Mule and J. Maeng and D. Walker",
  title="{Management Information Base for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4780 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4780",
  pages="1--83",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4780.txt",
  key="RFC 4780",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]},
  keywords="mib, registrar services, SIP-COMMON-MIB, SIP-TC-MIB, SIP-UA-MIB DEFINITIONS, SIP-SERVER-MIB",
  doi="10.17487/RFC4780",
  }

@misc{rfc4781,
  author="Y. Rekhter and R. Aggarwal",
  title="{Graceful Restart Mechanism for BGP with MPLS}",
  howpublished="RFC 4781 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4781",
  pages="1--10",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4781.txt",
  key="RFC 4781",
  abstract={A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document (``Graceful Restart Mechanism for BGP''). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]},
  keywords="border gateway protocol, multiprotocol label switching, nlri, bgp network layer reachability information",
  doi="10.17487/RFC4781",
  }

@misc{rfc4782,
  author="S. Floyd and M. Allman and A. Jain and P. Sarolahti",
  title="{Quick-Start for TCP and IP}",
  howpublished="RFC 4782 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4782",
  pages="1--82",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4782.txt",
  key="RFC 4782",
  abstract={This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request. This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC4782",
  }

@misc{rfc4783,
  author="L. Berger",
  title="{GMPLS - Communication of Alarm Information}",
  howpublished="RFC 4783 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4783",
  pages="1--19",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4783.txt",
  key="RFC 4783",
  abstract={This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR\_SPEC object. This document updates RFC 3473, ``Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions'', through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]},
  keywords="generalized multiprotocol label switching, gmpls-rsvp",
  doi="10.17487/RFC4783",
  }

@misc{rfc4784,
  author="C. Carroll and F. Quick",
  title="{Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks}",
  howpublished="RFC 4784 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4784",
  pages="1--45",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4784.txt",
  key="RFC 4784",
  abstract={The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.},
  keywords="mip, cryptographic keys, dmu",
  doi="10.17487/RFC4784",
  }

@misc{rfc4785,
  author="U. Blumenthal and P. Goel",
  title="{Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)}",
  howpublished="RFC 4785 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4785",
  pages="1--5",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4785.txt",
  key="RFC 4785",
  abstract={This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol.  These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]},
  keywords="cipher suite",
  doi="10.17487/RFC4785",
  }

@misc{rfc4786,
  author="J. Abley and K. Lindqvist",
  title="{Operation of Anycast Services}",
  howpublished="RFC 4786 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4786",
  pages="1--24",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4786.txt",
  key="RFC 4786",
  abstract={As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ROUTING, LOAD-BALANCING, LOAD-SHARING",
  doi="10.17487/RFC4786",
  }

@misc{rfc4787,
  author="F. Audet and C. Jennings",
  title="{Network Address Translation (NAT) Behavioral Requirements for Unicast UDP}",
  howpublished="RFC 4787 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4787",
  pages="1--29",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6888, 7857",
url="https://www.rfc-editor.org/rfc/rfc4787.txt",
  key="RFC 4787",
  abstract={This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently.  Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="nat, sip, udp",
  doi="10.17487/RFC4787",
  }

@misc{rfc4788,
  author="Q. Xie and R. Kapoor",
  title="{Enhancements to RTP Payload Formats for EVRC Family Codecs}",
  howpublished="RFC 4788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4788",
  pages="1--22",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5188",
url="https://www.rfc-editor.org/rfc/rfc4788.txt",
  key="RFC 4788",
  abstract={This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions.  In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP.  Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]},
  keywords="enhanced variable rate codec, real time transmission protocol, evrc-b, dtx, discontinuous transmission",
  doi="10.17487/RFC4788",
  }

@misc{rfc4789,
  author="J. Schoenwaelder and T. Jeffree",
  title="{Simple Network Management Protocol (SNMP) over IEEE 802 Networks}",
  howpublished="RFC 4789 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4789",
  pages="1--9",
  year=2006,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4789.txt",
  key="RFC 4789",
  abstract={This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks. This document obsoletes RFC 1089. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4789",
  }

@misc{rfc4790,
  author="C. Newman and M. Duerst and  A. Gulbrandsen",
  title="{Internet Application Protocol Collation Registry}",
  howpublished="RFC 4790 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4790",
  pages="1--26",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4790.txt",
  key="RFC 4790",
  abstract={Many Internet application protocols include string-based lookup, searching, or sorting operations.  However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF).  Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]},
  keywords="collation, sorting",
  doi="10.17487/RFC4790",
  }

@misc{rfc4791,
  author="C. Daboo and B. Desruisseaux and L. Dusseault",
  title="{Calendaring Extensions to WebDAV (CalDAV)}",
  howpublished="RFC 4791 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4791",
  pages="1--107",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5689, 6638, 6764, 7809, 7953",
url="https://www.rfc-editor.org/rfc/rfc4791.txt",
  key="RFC 4791",
  abstract={This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format.  This document defines the ``calendar-access'' feature of CalDAV. [STANDARDS-TRACK]},
  keywords="calsched, calsch, calcav, calendar, calendaring, scheduling, webdav, ical, icalendar, itip, text/calendar, http",
  doi="10.17487/RFC4791",
  }

@misc{rfc4792,
  author="S. Legg",
  title="{Encoding Instructions for the Generic String Encoding Rules (GSER)}",
  howpublished="RFC 4792 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4792",
  pages="1--9",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4792.txt",
  key="RFC 4792",
  abstract={Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules.  This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]},
  keywords="ASN.1",
  doi="10.17487/RFC4792",
  }

@misc{rfc4793,
  author="M. Nystroem",
  title="{The EAP Protected One-Time Password Protocol (EAP-POTP)}",
  howpublished="RFC 4793 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4793",
  pages="1--82",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4793.txt",
  key="RFC 4793",
  abstract={This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients.  The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2).  This memo provides information for the Internet community.},
  keywords="otp, extensible authentication protocol",
  doi="10.17487/RFC4793",
  }

@misc{rfc4794,
  author="B. Fenner",
  title="{RFC 1264 Is Obsolete}",
  howpublished="RFC 4794 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4794",
  pages="1--4",
  year=2006,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4794.txt",
  key="RFC 4794",
  abstract={RFC 1264 was written during what was effectively a completely different time in the life of the Internet.  It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties.  In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4794",
  }

@misc{rfc4795,
  author="B. Aboba and D. Thaler and L. Esibov",
  title="{Link-local Multicast Name Resolution (LLMNR)}",
  howpublished="RFC 4795 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4795",
  pages="1--31",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4795.txt",
  key="RFC 4795",
  abstract={The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible.  LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache.  Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4795",
  }

@misc{rfc4796,
  author="J. Hautakorpi and G. Camarillo",
  title="{The Session Description Protocol (SDP) Content Attribute}",
  howpublished="RFC 4796 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4796",
  pages="1--11",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4796.txt",
  key="RFC 4796",
  abstract={This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'.  The 'content' attribute defines the content of the media stream to a more detailed level than the media description line.  The sender of an SDP session description can attach the 'content' attribute to one or more media streams.  The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]},
  keywords="media attribute, content",
  doi="10.17487/RFC4796",
  }

@misc{rfc4797,
  author="Y. Rekhter and R. Bonica and E. Rosen",
  title="{Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks}",
  howpublished="RFC 4797 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4797",
  pages="1--10",
  year=2007,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4797.txt",
  key="RFC 4797",
  abstract={This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.},
  keywords="L3VPN GRE encapsulation",
  doi="10.17487/RFC4797",
  }

@misc{rfc4798,
  author="J. De Clercq and D. Ooms and S. Prevost and F. Le Faucheur",
  title="{Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)}",
  howpublished="RFC 4798 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4798",
  pages="1--14",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4798.txt",
  key="RFC 4798",
  abstract={This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud.  This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS.  The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4.  In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]},
  keywords="mp-bgp",
  doi="10.17487/RFC4798",
  }

@misc{rfc4801,
  author="T. Nadeau and A. Farrel",
  title="{Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management}",
  howpublished="RFC 4801 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4801",
  pages="1--9",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4801.txt",
  key="RFC 4801",
  abstract={This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information.  The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="management information base, mib, GMPLS-TC-STD-MIB",
  doi="10.17487/RFC4801",
  }

@misc{rfc4802,
  author="T. Nadeau and A. Farrel and  Ed.",
  title="{Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base}",
  howpublished="RFC 4802 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4802",
  pages="1--60",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4802.txt",
  key="RFC 4802",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]},
  keywords="mib, GMPLS-TE-STD-MIB, IANA-GMPLS-TC-MIB",
  doi="10.17487/RFC4802",
  }

@misc{rfc4803,
  author="T. Nadeau and A. Farrel",
  title="{Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base}",
  howpublished="RFC 4803 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4803",
  pages="1--42",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4803.txt",
  key="RFC 4803",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]},
  keywords="mib, GMPLS-LSR-STD-MIB, GMPLS-LABEL-STD-MIB",
  doi="10.17487/RFC4803",
  }

@misc{rfc4804,
  author="F. Le Faucheur",
  title="{Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels}",
  howpublished="RFC 4804 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4804",
  pages="1--31",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4804.txt",
  key="RFC 4804",
  abstract={RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations.  This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels.  This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations.  This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, traffic engineering, diffserv-aware mpls traffic engineering",
  doi="10.17487/RFC4804",
  }

@misc{rfc4805,
  author="O. Nicklass",
  title="{Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types}",
  howpublished="RFC 4805 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4805",
  pages="1--94",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4805.txt",
  key="RFC 4805",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 3895. [STANDARDS-TRACK]},
  keywords="mib, management information base, DS1-MIB",
  doi="10.17487/RFC4805",
  }

@misc{rfc4806,
  author="M. Myers and H. Tschofenig",
  title="{Online Certificate Status Protocol (OCSP) Extensions to IKEv2}",
  howpublished="RFC 4806 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4806",
  pages="1--11",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4806.txt",
  key="RFC 4806",
  abstract={While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the ``OCSP Content'' extension to IKEv2. A CERTREQ payload with ``OCSP Content'' identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same ``OCSP Content'' identifier. When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]},
  keywords="internet key exchange version 2",
  doi="10.17487/RFC4806",
  }

@misc{rfc4807,
  author="M. Baer and R. Charlet and W. Hardaker and R. Story and C. Wang",
  title="{IPsec Security Policy Database Configuration MIB}",
  howpublished="RFC 4807 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4807",
  pages="1--71",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4807.txt",
  key="RFC 4807",
  abstract={This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol.  The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall.  This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]},
  keywords="management information base, IPSEC-SPD-MIB",
  doi="10.17487/RFC4807",
  }

@misc{rfc4808,
  author="S. Bellovin",
  title="{Key Change Strategies for TCP-MD5}",
  howpublished="RFC 4808 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4808",
  pages="1--8",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4808.txt",
  key="RFC 4808",
  abstract={The TCP-MD5 option is most commonly used to secure BGP sessions between routers.  However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations.  We describe single-ended strategies that will permit (mostly) unsynchronized key changes.  This memo provides information for the Internet community.},
  keywords="bgp, border gateway protocol",
  doi="10.17487/RFC4808",
  }

@misc{rfc4809,
  author="C. Bonatti and S. Turner and G. Lebovitz",
  title="{Requirements for an IPsec Certificate Management Profile}",
  howpublished="RFC 4809 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4809",
  pages="1--45",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4809.txt",
  key="RFC 4809",
  abstract={This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems.  These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments.  It is intended that a standards track profile of a management protocol will be created to address many of these requirements.  This memo provides information for the Internet community.},
  keywords="internet protocol security",
  doi="10.17487/RFC4809",
  }

@misc{rfc4810,
  author="C. Wallace and U. Pordesch and R. Brandner",
  title="{Long-Term Archive Service Requirements}",
  howpublished="RFC 4810 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4810",
  pages="1--17",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4810.txt",
  key="RFC 4810",
  abstract={There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time.  Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature.  This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services.  This memo provides information for the Internet community.},
  keywords="data integrity, digital signatures",
  doi="10.17487/RFC4810",
  }

@misc{rfc4811,
  author="L. Nguyen and A. Roy and A. Zinin",
  title="{OSPF Out-of-Band Link State Database (LSDB) Resynchronization}",
  howpublished="RFC 4811 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4811",
  pages="1--10",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4811.txt",
  key="RFC 4811",
  abstract={OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network. This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.},
  keywords="open shortest path first",
  doi="10.17487/RFC4811",
  }

@misc{rfc4812,
  author="L. Nguyen and A. Roy and A. Zinin",
  title="{OSPF Restart Signaling}",
  howpublished="RFC 4812 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4812",
  pages="1--7",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4812.txt",
  key="RFC 4812",
  abstract={OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions. This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.},
  keywords="open shortest path first",
  doi="10.17487/RFC4812",
  }

@misc{rfc4813,
  author="B. Friedman and L. Nguyen and A. Roy and D. Yeung and A. Zinin",
  title="{OSPF Link-Local Signaling}",
  howpublished="RFC 4813 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4813",
  pages="1--10",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5613",
url="https://www.rfc-editor.org/rfc/rfc4813.txt",
  key="RFC 4813",
  abstract={OSPF is a link-state intra-domain routing protocol used in IP networks.  OSPF routers exchange information on a link using packets that follow a well-defined format.  The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations.  This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="open shortest path first",
  doi="10.17487/RFC4813",
  }

@misc{rfc4814,
  author="D. Newman and T. Player",
  title="{Hash and Stuffing: Overlooked Factors in Network Device Benchmarking}",
  howpublished="RFC 4814 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4814",
  pages="1--26",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4814.txt",
  key="RFC 4814",
  abstract={Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation.  However, current benchmarking practice overlooks two factors that have a profound impact on test results.  First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results.  Second, ``stuff'' bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results.  This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.  This memo provides information for the Internet community.},
  keywords="bmwg, benchmarking, testing, bit-stuffing, byte-stuffing",
  doi="10.17487/RFC4814",
  }

@misc{rfc4815,
  author="L-E. Jonsson and K. Sandlund and G. Pelletier and P. Kremer",
  title="{RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095}",
  howpublished="RFC 4815 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4815",
  pages="1--33",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4815.txt",
  key="RFC 4815",
  abstract={RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload).  Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations.  This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095.  In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]},
  keywords="ip, udp, user datagram protocol, rtp, realtime transport protocol, esp, encapsulation security payload",
  doi="10.17487/RFC4815",
  }

@misc{rfc4816,
  author="A. Malis and L. Martini and J. Brayley and T. Walsh",
  title="{Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service}",
  howpublished="RFC 4816 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4816",
  pages="1--5",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4816.txt",
  key="RFC 4816",
  abstract={The document describes a transparent cell transport service that makes use of the ``N-to-one'' cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4816",
  }

@misc{rfc4817,
  author="M. Townsley and C. Pignataro and S. Wainner and T. Seely and J. Young",
  title="{Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3}",
  howpublished="RFC 4817 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4817",
  pages="1--12",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4817.txt",
  key="RFC 4817",
  abstract={The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks.  This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation.  This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]},
  keywords="l2tpv3, multiprotocol label switching label stack, label stack",
  doi="10.17487/RFC4817",
  }

@misc{rfc4818,
  author="J. Salowey and R. Droms",
  title="{RADIUS Delegated-IPv6-Prefix Attribute}",
  howpublished="RFC 4818 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4818",
  pages="1--7",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4818.txt",
  key="RFC 4818",
  abstract={This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user.  This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]},
  keywords="remote authentication dial in user service, diameter",
  doi="10.17487/RFC4818",
  }

@misc{rfc4819,
  author="J. Galbraith and J. Van Dyke and J. Bright",
  title="{Secure Shell Public Key Subsystem}",
  howpublished="RFC 4819 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4819",
  pages="1--17",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4819.txt",
  key="RFC 4819",
  abstract={Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]},
  keywords="ssh, ssh2",
  doi="10.17487/RFC4819",
  }

@misc{rfc4820,
  author="M. Tuexen and R. Stewart and P. Lei",
  title="{Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 4820 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4820",
  pages="1--6",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4820.txt",
  key="RFC 4820",
  abstract={This document defines a padding chunk and a padding parameter and describes the required receiver side procedures.  The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size.  The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4820",
  }

@misc{rfc4821,
  author="M. Mathis and J. Heffner",
  title="{Packetization Layer Path MTU Discovery}",
  howpublished="RFC 4821 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4821",
  pages="1--32",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4821.txt",
  key="RFC 4821",
  abstract={This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]},
  keywords="maximum transmission unit, pmtud",
  doi="10.17487/RFC4821",
  }

@misc{rfc4822,
  author="R. Atkinson and M. Fanto",
  title="{RIPv2 Cryptographic Authentication}",
  howpublished="RFC 4822 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4822",
  pages="1--22",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4822.txt",
  key="RFC 4822",
  abstract={This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082.  This document obsoletes RFC 2082 and updates RFC 2453.  This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5.  Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]},
  keywords="RIP2-MD5, Routing Information Protocol, Encryption",
  doi="10.17487/RFC4822",
  }

@misc{rfc4823,
  author="T. Harding and R. Scott",
  title="{FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet}",
  howpublished="RFC 4823 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4823",
  pages="1--40",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4823.txt",
  key="RFC 4823",
  abstract={This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types.  Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts.  Authenticated acknowledgements employ multipart/signed replies to the original message.  This memo provides information for the Internet community.},
  keywords="applicability statement, as, business-to-business",
  doi="10.17487/RFC4823",
  }

@misc{rfc4824,
  author="J. Hofmueller and A. Bachmann and IO. zmoelnig",
  title="{The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)}",
  howpublished="RFC 4824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4824",
  pages="1--13",
  year=2007,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4824.txt",
  key="RFC 4824",
  abstract={This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).  This memo provides information for the Internet community.},
  keywords="internet protocol, april fools",
  doi="10.17487/RFC4824",
  }

@misc{rfc4825,
  author="J. Rosenberg",
  title="{The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)}",
  howpublished="RFC 4825 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4825",
  pages="1--71",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4825.txt",
  key="RFC 4825",
  abstract={This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP).  XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server.  XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]},
  keywords="sip, xml, http, rest, buddy list, simple, presence, data manipulation",
  doi="10.17487/RFC4825",
  }

@misc{rfc4826,
  author="J. Rosenberg",
  title="{Extensible Markup Language (XML) Formats for Representing Resource Lists}",
  howpublished="RFC 4826 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4826",
  pages="1--31",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4826.txt",
  key="RFC 4826",
  abstract={In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users.  One example is a resource list service.  If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender.  To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents.  One document contains service URIs, along with their service definition and a reference to the associated group of users.  The second document contains the user lists that are referenced from the first.  This list of users can be utilized by other applications and services.  Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]},
  keywords="http, sip, xml, rest, buddy list, simple, presence, data manipulation",
  doi="10.17487/RFC4826",
  }

@misc{rfc4827,
  author="M. Isomaki and E. Leppanen",
  title="{An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents}",
  howpublished="RFC 4827 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4827",
  pages="1--11",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4827.txt",
  key="RFC 4827",
  abstract={This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents.  It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]},
  keywords="PIDF, AUID, hard state, PUBLISH, SIP Presence, SIMPLE, pidf-manipulation, XCAP application usage",
  doi="10.17487/RFC4827",
  }

@misc{rfc4828,
  author="S. Floyd and E. Kohler",
  title="{TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant}",
  howpublished="RFC 4828 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4828",
  pages="1--46",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4828.txt",
  key="RFC 4828",
  abstract={This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently. Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.},
  keywords="transmission control protocol",
  doi="10.17487/RFC4828",
  }

@misc{rfc4829,
  author="J. de Oliveira and JP. Vasseur and L. Chen and C. Scoglio",
  title="{Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering}",
  howpublished="RFC 4829 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4829",
  pages="1--19",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4829.txt",
  key="RFC 4829",
  abstract={When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted.  The preempted LSPs are then rerouted by their respective \\%Head-end Label Switch Router (LSR).  This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted.  Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included.  This memo provides information for the Internet community.},
  keywords="traffic engineering label switched path, te lsp, multiprotocol label switching protocol",
  doi="10.17487/RFC4829",
  }

@misc{rfc4830,
  author="J. Kempf",
  title="{Problem Statement for Network-Based Localized Mobility Management (NETLMM)}",
  howpublished="RFC 4830 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4830",
  pages="1--13",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4830.txt",
  key="RFC 4830",
  abstract={Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available.  This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4830",
  }

@misc{rfc4831,
  author="J. Kempf",
  title="{Goals for Network-Based Localized Mobility Management (NETLMM)}",
  howpublished="RFC 4831 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4831",
  pages="1--14",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4831.txt",
  key="RFC 4831",
  abstract={In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4831",
  }

@misc{rfc4832,
  author="C. Vogt and J. Kempf",
  title="{Security Threats to Network-Based Localized Mobility Management (NETLMM)}",
  howpublished="RFC 4832 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4832",
  pages="1--12",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4832.txt",
  key="RFC 4832",
  abstract={This document discusses security threats to network-based localized mobility management.  Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node.  Threats to the former interface impact the localized mobility management protocol itself.  This memo provides information for the Internet community.},
  keywords="localized mobility anchor, mobile access gateway, compromise, impersonation, man in the middle, denial of service, IP spoofing",
  doi="10.17487/RFC4832",
  }

@misc{rfc4833,
  author="E. Lear and P. Eggert",
  title="{Timezone Options for DHCP}",
  howpublished="RFC 4833 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4833",
  pages="1--10",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4833.txt",
  key="RFC 4833",
  abstract={Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names.  This memo specifies DHCP options for each of those methods.  The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]},
  keywords="time offset, posix, tz database, tz",
  doi="10.17487/RFC4833",
  }

@misc{rfc4834,
  author="T. Morin",
  title="{Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)}",
  howpublished="RFC 4834 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4834",
  pages="1--37",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4834.txt",
  key="RFC 4834",
  abstract={This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs).  It specifies requirements both from the end user and service provider standpoints.  It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.  This memo provides information for the Internet community.},
  keywords="vpn, virtual private networks, l3",
  doi="10.17487/RFC4834",
  }

@misc{rfc4835,
  author="V. Manral",
  title="{Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)}",
  howpublished="RFC 4835 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4835",
  pages="1--10",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7321",
url="https://www.rfc-editor.org/rfc/rfc4835.txt",
  key="RFC 4835",
  abstract={The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA).  To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]},
  keywords="ESP, ipsec, authentication, mechanism, header, security, architecture, payload, internet, protocol, encapsulating, ipv4, ipv6",
  doi="10.17487/RFC4835",
  }

@misc{rfc4836,
  author="E. Beili",
  title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}",
  howpublished="RFC 4836 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4836",
  pages="1--67",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4836.txt",
  key="RFC 4836",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs).  This document obsoletes RFC 3636.  It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module.  In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]},
  keywords="MAU-MIB, IANA-MAU-MIB, management information base,",
  doi="10.17487/RFC4836",
  }

@misc{rfc4837,
  author="L. Khermosh",
  title="{Managed Objects of Ethernet Passive Optical Networks (EPON)}",
  howpublished="RFC 4837 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4837",
  pages="1--91",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4837.txt",
  key="RFC 4837",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets.  In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]},
  keywords="Ethernet Passive Optical Networks, pon, epon, IEEE802.3ah, 802.3ah, p2mp, mpcp, llid, onu, olt, optical access",
  doi="10.17487/RFC4837",
  }

@misc{rfc4838,
  author="V. Cerf and S. Burleigh and A. Hooke and L. Torgerson and R. Durst and K. Scott and K. Fall and H. Weiss",
  title="{Delay-Tolerant Networking Architecture}",
  howpublished="RFC 4838 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4838",
  pages="1--35",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4838.txt",
  key="RFC 4838",
  abstract={This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.  This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical.  We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects.  The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues.  This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.  This memo provides information for the Internet community.},
  keywords="disruption tolerant, irtf, interplanetary internet",
  doi="10.17487/RFC4838",
  }

@misc{rfc4839,
  author="G. Conboy and J. Rivlin and J. Ferraiolo",
  title="{Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF)}",
  howpublished="RFC 4839 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4839",
  pages="1--5",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4839.txt",
  key="RFC 4839",
  abstract={This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4839",
  }

@misc{rfc4840,
  author="B. Aboba and E. Davies and D. Thaler",
  title="{Multiple Encapsulation Methods Considered Harmful}",
  howpublished="RFC 4840 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4840",
  pages="1--27",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4840.txt",
  key="RFC 4840",
  abstract={This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.  This memo provides information for the Internet community.},
  keywords="iab, link-layer protocol, ip encapsulation, internet protocol encapsulation",
  doi="10.17487/RFC4840",
  }

@misc{rfc4841,
  author="C. Heard",
  title="{RFC 4181 Update to Recognize the IETF Trust}",
  howpublished="RFC 4841 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4841",
  pages="1--3",
  year=2007,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4841.txt",
  key="RFC 4841",
  abstract={This document updates RFC 4181, ``Guidelines for Authors and Reviewers of MIB Documents'', to recognize the creation of the IETF Trust.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="management information base,  standards-track specifications, mib review",
  doi="10.17487/RFC4841",
  }

@misc{rfc4842,
  author="A. Malis and P. Pate and R. Cohen and D. Zelig",
  title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)}",
  howpublished="RFC 4842 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4842",
  pages="1--43",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4842.txt",
  key="RFC 4842",
  abstract={This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching",
  doi="10.17487/RFC4842",
  }

@misc{rfc4843,
  author="P. Nikander and J. Laganier and F. Dupont",
  title="{An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)}",
  howpublished="RFC 4843 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4843",
  pages="1--14",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7343",
url="https://www.rfc-editor.org/rfc/rfc4843.txt",
  key="RFC 4843",
  abstract={This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC4843",
  }

@misc{rfc4844,
  author="L. Daigle and Internet Architecture Board",
  title="{The RFC Series and RFC Editor}",
  howpublished="RFC 4844 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4844",
  pages="1--20",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5741",
url="https://www.rfc-editor.org/rfc/rfc4844.txt",
  key="RFC 4844",
  abstract={This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.  This memo provides information for the Internet community.},
  keywords="technical publisher",
  doi="10.17487/RFC4844",
  }

@misc{rfc4845,
  author="L. Daigle and Internet Architecture Board",
  title="{Process for Publication of IAB RFCs}",
  howpublished="RFC 4845 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4845",
  pages="1--5",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4845.txt",
  key="RFC 4845",
  abstract={From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs).  This document defines the process by which those documents are produced, reviewed, and published in the RFC Series.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4845",
  }

@misc{rfc4846,
  author="J. Klensin and D. Thaler",
  title="{Independent Submissions to the RFC Editor}",
  howpublished="RFC 4846 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4846",
  pages="1--16",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5744",
url="https://www.rfc-editor.org/rfc/rfc4846.txt",
  key="RFC 4846",
  abstract={There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.  These documents, known as ``Independent Submissions'', serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants.  This document discusses the Independent Submission model and some reasons why it is important.  It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4846",
  }

@misc{rfc4847,
  author="T. Takeda",
  title="{Framework and Requirements for Layer 1 Virtual Private Networks}",
  howpublished="RFC 4847 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4847",
  pages="1--38",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4847.txt",
  key="RFC 4847",
  abstract={This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs. The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.},
  keywords="L1VPN",
  doi="10.17487/RFC4847",
  }

@misc{rfc4848,
  author="L. Daigle",
  title="{Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)}",
  howpublished="RFC 4848 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4848",
  pages="1--10",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4848.txt",
  key="RFC 4848",
  abstract={The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols.  Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]},
  keywords="service-parms, service parameters",
  doi="10.17487/RFC4848",
  }

@misc{rfc4849,
  author="P. Congdon and M. Sanchez and B. Aboba",
  title="{RADIUS Filter Rule Attribute}",
  howpublished="RFC 4849 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4849",
  pages="1--9",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4849.txt",
  key="RFC 4849",
  abstract={While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters.  However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly.  This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]},
  keywords="remote authentication dial in user service, nas-filter-rule",
  doi="10.17487/RFC4849",
  }

@misc{rfc4850,
  author="D. Wysochanski",
  title="{Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture}",
  howpublished="RFC 4850 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4850",
  pages="1--9",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7143",
url="https://www.rfc-editor.org/rfc/rfc4850.txt",
  key="RFC 4850",
  abstract={The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys.  This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability.  The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence.  The receiving node can then use this information for enhanced logging and support.  This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]},
  keywords="transport protocol, tcp, transmission control protocol",
  doi="10.17487/RFC4850",
  }

@misc{rfc4851,
  author="N. Cam-Winget and D. McGrew and J. Salowey and H. Zhou",
  title="{The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)}",
  howpublished="RFC 4851 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4851",
  pages="1--64",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4851.txt",
  key="RFC 4851",
  abstract={This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol.  EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.  This memo provides information for the Internet community.},
  keywords="eap",
  doi="10.17487/RFC4851",
  }

@misc{rfc4852,
  author="J. Bound and Y. Pouffary and S. Klynsma and T. Chown and D. Green",
  title="{IPv6 Enterprise Network Analysis - IP Layer 3 Focus}",
  howpublished="RFC 4852 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4852",
  pages="1--32",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4852.txt",
  key="RFC 4852",
  abstract={This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3.  These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity.  The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios.  Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise.  Then, a set of transition mechanisms are recommended for each notational network.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6, notational network",
  doi="10.17487/RFC4852",
  }

@misc{rfc4853,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS) Multiple Signer Clarification}",
  howpublished="RFC 4853 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4853",
  pages="1--5",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4853.txt",
  key="RFC 4853",
  abstract={This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852.  This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]},
  keywords="signeddata, digitally sign, authenticate, encrypt, arbitrary message content",
  doi="10.17487/RFC4853",
  }

@misc{rfc4854,
  author="P. Saint-Andre",
  title="{A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 4854 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4854",
  pages="1--9",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4854.txt",
  key="RFC 4854",
  abstract={This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF).  This memo provides information for the Internet community.},
  keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Instant Messaging, Presence, Uniform Resource Name, URN",
  doi="10.17487/RFC4854",
  }

@misc{rfc4855,
  author="S. Casner",
  title="{Media Type Registration of RTP Payload Formats}",
  howpublished="RFC 4855 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4855",
  pages="1--11",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4855.txt",
  key="RFC 4855",
  abstract={This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names.  This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]},
  keywords="realtime transport protocol, multipurpose internet mail extensions",
  doi="10.17487/RFC4855",
  }

@misc{rfc4856,
  author="S. Casner",
  title="{Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences}",
  howpublished="RFC 4856 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4856",
  pages="1--29",
  year=2007,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4856.txt",
  key="RFC 4856",
  abstract={This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences.  Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]},
  keywords="realtime transport protocol, multipurpose internet mail extensions",
  doi="10.17487/RFC4856",
  }

@misc{rfc4857,
  author="E. Fogelstroem and A. Jonsson and C. Perkins",
  title="{Mobile IPv4 Regional Registration}",
  howpublished="RFC 4857 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4857",
  pages="1--35",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4857.txt",
  key="RFC 4857",
  abstract={Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address.  This document describes a new kind of ``regional registrations'', i.e., registrations local to the visited domain.  The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain.  Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain.  This document is an optional extension to the Mobile IPv4 protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="GFA, gateway foreign agent",
  doi="10.17487/RFC4857",
  }

@misc{rfc4858,
  author="H. Levkowetz and D. Meyer and L. Eggert and A. Mankin",
  title="{Document Shepherding from Working Group Last Call to Publication}",
  howpublished="RFC 4858 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4858",
  pages="1--21",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4858.txt",
  key="RFC 4858",
  abstract={This document describes methodologies that have been designed to improve and facilitate IETF document flow processing.  It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication.  Before this, the Area Director responsible for the working group has traditionally filled the shepherding role.  This memo provides information for the Internet community.},
  keywords="document shepherding, ietf documents",
  doi="10.17487/RFC4858",
  }

@misc{rfc4859,
  author="A. Farrel",
  title="{Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object}",
  howpublished="RFC 4859 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4859",
  pages="1--5",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4859.txt",
  key="RFC 4859",
  abstract={This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4859",
  }

@misc{rfc4860,
  author="F. Le Faucheur and B. Davie and P. Bose and C. Christou and M. Davenport",
  title="{Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations}",
  howpublished="RFC 4860 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4860",
  pages="1--32",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4860.txt",
  key="RFC 4860",
  abstract={RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination.  RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud.  There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs).  However, this is not supported by the aggregate reservations defined in RFC 3175.  In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation.  Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address.  The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations.  This document also defines the procedures for such aggregation.  The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]},
  keywords="session object, session of interest, phb, per hop behavior",
  doi="10.17487/RFC4860",
  }

@misc{rfc4861,
  author="T. Narten and E. Nordmark and W. Simpson and H. Soliman",
  title="{Neighbor Discovery for IP version 6 (IPv6)}",
  howpublished="RFC 4861 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4861",
  pages="1--97",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028",
url="https://www.rfc-editor.org/rfc/rfc4861.txt",
  key="RFC 4861",
  abstract={This document specifies the Neighbor Discovery protocol for IP Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]},
  keywords="IPV6-ND, internet protocol, link-layer, link-layer address",
  doi="10.17487/RFC4861",
  }

@misc{rfc4862,
  author="S. Thomson and T. Narten and T. Jinmei",
  title="{IPv6 Stateless Address Autoconfiguration}",
  howpublished="RFC 4862 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4862",
  pages="1--30",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7527",
url="https://www.rfc-editor.org/rfc/rfc4862.txt",
  key="RFC 4862",
  abstract={This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6.  The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]},
  keywords="IPV6-AUTO, host, link-local, internet protocol version 6, link-local address, duplicate address detection",
  doi="10.17487/RFC4862",
  }

@misc{rfc4863,
  author="L. Martini and G. Swallow",
  title="{Wildcard Pseudowire Type}",
  howpublished="RFC 4863 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4863",
  pages="1--6",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4863.txt",
  key="RFC 4863",
  abstract={Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions.  For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint.  In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP.  In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP.  This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]},
  keywords="pw type, pw",
  doi="10.17487/RFC4863",
  }

@misc{rfc4864,
  author="G. Van de Velde and T. Hain and R. Droms and B. Carpenter and E. Klein",
  title="{Local Network Protection for IPv6}",
  howpublished="RFC 4864 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4864",
  pages="1--36",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4864.txt",
  key="RFC 4864",
  abstract={Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of ``amplifying'' available address space is not needed in IPv6.  In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site.  IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.  This memo provides information for the Internet community.},
  keywords="ipv6, address, protection, nat",
  doi="10.17487/RFC4864",
  }

@misc{rfc4865,
  author="G. White and G. Vaudreuil",
  title="{SMTP Submission Service Extension for Future Message Release}",
  howpublished="RFC 4865 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4865",
  pages="1--11",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4865.txt",
  key="RFC 4865",
  abstract={This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery.  This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future.  This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]},
  keywords="simple mail transfer protocol, future-release-integer",
  doi="10.17487/RFC4865",
  }

@misc{rfc4866,
  author="J. Arkko and C. Vogt and W. Haddad",
  title="{Enhanced Route Optimization for Mobile IPv6}",
  howpublished="RFC 4866 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4866",
  pages="1--54",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4866.txt",
  key="RFC 4866",
  abstract={This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]},
  keywords="mobility, cryptographically generated addresses, cga, credit-based authorization, cba",
  doi="10.17487/RFC4866",
  }

@misc{rfc4867,
  author="J. Sjoberg and M. Westerlund and A. Lakaniemi and Q. Xie",
  title="{RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs}",
  howpublished="RFC 4867 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4867",
  pages="1--59",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4867.txt",
  key="RFC 4867",
  abstract={This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals.  The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks.  In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email.  Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format.  This document obsoletes RFC 3267. [STANDARDS-TRACK]},
  keywords="interoperate, applications",
  doi="10.17487/RFC4867",
  }

@misc{rfc4868,
  author="S. Kelly and S. Frankel",
  title="{Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec}",
  howpublished="RFC 4868 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4868",
  pages="1--21",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4868.txt",
  key="RFC 4868",
  abstract={This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec.  These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2.  Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256.  The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]},
  keywords="hashed authentication mode, data authentication, integrity verification",
  doi="10.17487/RFC4868",
  }

@misc{rfc4869,
  author="L. Law and J. Solinas",
  title="{Suite B Cryptographic Suites for IPsec}",
  howpublished="RFC 4869 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4869",
  pages="1--9",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6379",
url="https://www.rfc-editor.org/rfc/rfc4869.txt",
  key="RFC 4869",
  abstract={This document proposes four optional cryptographic user interface suites (``UI suites'') for IPsec, similar to the two suites specified in RFC 4308.  The four new suites provide compatibility with the United States National Security Agency's Suite B specifications.  This memo provides information for the Internet community.},
  keywords="ui suites, user interface suites, elliptic curve, ike",
  doi="10.17487/RFC4869",
  }

@misc{rfc4870,
  author="M. Delany",
  title="{Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)}",
  howpublished="RFC 4870 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4870",
  pages="1--41",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4871",
url="https://www.rfc-editor.org/rfc/rfc4870.txt",
  key="RFC 4870",
  abstract={``DomainKeys'' creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email. This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of ``spam'' and ``phishing''. This memo defines a Historic Document for the Internet community.},
  doi="10.17487/RFC4870",
  }

@misc{rfc4871,
  author="E. Allman and J. Callas and M. Delany and M. Libbey and J. Fenton and M. Thomas",
  title="{DomainKeys Identified Mail (DKIM) Signatures}",
  howpublished="RFC 4871 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4871",
  pages="1--71",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6376, updated by RFC 5672",
url="https://www.rfc-editor.org/rfc/rfc4871.txt",
  key="RFC 4871",
  abstract={DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs).  The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today.  Protection of email identity may assist in the global control of ``spam'' and ``phishing''. [STANDARDS-TRACK]},
  keywords="internet mail, authentication, spam, phishing, spoofing, digital signature",
  doi="10.17487/RFC4871",
  }

@misc{rfc4872,
  author="J.P. Lang and Y. Rekhter and D. Papadimitriou",
  title="{RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery}",
  howpublished="RFC 4872 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4872",
  pages="1--47",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 4873, 6780",
url="https://www.rfc-editor.org/rfc/rfc4872.txt",
  key="RFC 4872",
  abstract={This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration.  A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]},
  keywords="resource reservation protocol, traffic engineering",
  doi="10.17487/RFC4872",
  }

@misc{rfc4873,
  author="L. Berger and I. Bryskin and D. Papadimitriou and A. Farrel",
  title="{GMPLS Segment Recovery}",
  howpublished="RFC 4873 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4873",
  pages="1--25",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4873.txt",
  key="RFC 4873",
  abstract={This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.  These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).  Implications and interactions with fast reroute are also addressed.  This document also updates the handling of NOTIFY\_REQUEST objects. [STANDARDS-TRACK]},
  keywords="generalized multipoint label switching, rsvp-te, resource reservation protocol, traffic engineering, NOTIFY\_REQUEST",
  doi="10.17487/RFC4873",
  }

@misc{rfc4874,
  author="CY. Lee and A. Farrel and S. De Cnodder",
  title="{Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)}",
  howpublished="RFC 4874 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4874",
  pages="1--27",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6001",
url="https://www.rfc-editor.org/rfc/rfc4874.txt",
  key="RFC 4874",
  abstract={This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). The RSVP-TE specification, ``RSVP-TE: Extensions to RSVP for LSP Tunnels'' (RFC 3209) and GMPLS extensions to RSVP-TE, ``Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions'' (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]},
  keywords="srlg, shared risk link groups",
  doi="10.17487/RFC4874",
  }

@misc{rfc4875,
  author="R. Aggarwal and D. Papadimitriou and S. Yasukawa",
  title="{Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)}",
  howpublished="RFC 4875 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4875",
  pages="1--53",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6510",
url="https://www.rfc-editor.org/rfc/rfc4875.txt",
  key="RFC 4875",
  abstract={This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]},
  keywords="p2mp, point-to-multipoint, traffic engineering",
  doi="10.17487/RFC4875",
  }

@misc{rfc4876,
  author="B. Neal-Joslin and L. Howard and M. Ansari",
  title="{A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents}",
  howpublished="RFC 4876 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4876",
  pages="1--39",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4876.txt",
  key="RFC 4876",
  abstract={This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents.  A set of attribute types and an object class are proposed.  In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support.  In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment.  This document is intended to be a skeleton for future documents that describe configuration of specific DUA services.  This memo provides information for the Internet community.},
  keywords="ldap, schema, profile, configuration, nameservice, nss, pam\_ldap, nss\_ldap, rfc2307, rfc 2307",
  doi="10.17487/RFC4876",
  }

@misc{rfc4877,
  author="V. Devarapalli and F. Dupont",
  title="{Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture}",
  howpublished="RFC 4877 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4877",
  pages="1--26",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4877.txt",
  key="RFC 4877",
  abstract={This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]},
  keywords="Bootstrapping, MIP6, Selector Granularity, Mobility Header, EAP Authentication",
  doi="10.17487/RFC4877",
  }

@misc{rfc4878,
  author="M. Squire",
  title="{Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces}",
  howpublished="RFC 4878 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4878",
  pages="1--58",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4878.txt",
  key="RFC 4878",
  abstract={This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards.  The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces.  This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]},
  keywords="efm, ethernet in the first mile, snmp, DOT3-OAM-MIB",
  doi="10.17487/RFC4878",
  }

@misc{rfc4879,
  author="T. Narten",
  title="{Clarification of the Third Party Disclosure Procedure in RFC 3979}",
  howpublished="RFC 4879 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4879",
  pages="1--4",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4879.txt",
  key="RFC 4879",
  abstract={This document clarifies and updates a single sentence in RFC 3979.  Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipr, copyright",
  doi="10.17487/RFC4879",
  }

@misc{rfc4880,
  author="J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer",
  title="{OpenPGP Message Format}",
  howpublished="RFC 4880 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4880",
  pages="1--90",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5581",
url="https://www.rfc-editor.org/rfc/rfc4880.txt",
  key="RFC 4880",
  abstract={This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]},
  keywords="public-key cryptography, symmetric cryptography",
  doi="10.17487/RFC4880",
  }

@misc{rfc4881,
  author="K. El Malki",
  title="{Low-Latency Handoffs in Mobile IPv4}",
  howpublished="RFC 4881 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4881",
  pages="1--64",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4881.txt",
  key="RFC 4881",
  abstract={Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents.  In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services.  The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs.  In addition, a combination of these two methods is described.  The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mip4",
  doi="10.17487/RFC4881",
  }

@misc{rfc4882,
  author="R. Koodli",
  title="{IP Address Location Privacy and Mobile IPv6: Problem Statement}",
  howpublished="RFC 4882 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4882",
  pages="1--11",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4882.txt",
  key="RFC 4882",
  abstract={In this document, we discuss location privacy as applicable to Mobile IPv6.  We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.  This memo provides information for the Internet community.},
  keywords="internet protocol, home address, care-of address",
  doi="10.17487/RFC4882",
  }

@misc{rfc4883,
  author="G. Feher and K. Nemeth and A. Korn and I. Cselenyi",
  title="{Benchmarking Terminology for Resource Reservation Capable Routers}",
  howpublished="RFC 4883 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4883",
  pages="1--24",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4883.txt",
  key="RFC 4883",
  abstract={The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers.  These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements.  This memo provides information for the Internet community.},
  keywords="intserv, integrated services, benchmarking methodologies",
  doi="10.17487/RFC4883",
  }

@misc{rfc4884,
  author="R. Bonica and D. Gan and D. Tappan and C. Pignataro",
  title="{Extended ICMP to Support Multi-Part Messages}",
  howpublished="RFC 4884 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4884",
  pages="1--19",
  year=2007,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4884.txt",
  key="RFC 4884",
  abstract={This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an ``original datagram'' field. The ``original datagram'' field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the ``original datagram'' field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]},
  keywords="internet control message protocol, length attribute",
  doi="10.17487/RFC4884",
  }

@misc{rfc4885,
  author="T. Ernst and H-Y. Lach",
  title="{Network Mobility Support Terminology}",
  howpublished="RFC 4885 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4885",
  pages="1--19",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4885.txt",
  key="RFC 4885",
  abstract={This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements.  This memo provides information for the Internet community.},
  keywords="nemo",
  doi="10.17487/RFC4885",
  }

@misc{rfc4886,
  author="T. Ernst",
  title="{Network Mobility Support Goals and Requirements}",
  howpublished="RFC 4886 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4886",
  pages="1--13",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4886.txt",
  key="RFC 4886",
  abstract={Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology.  Such a type of network is referred to as a mobile network.  With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment.  This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.  This memo provides information for the Internet community.},
  keywords="nemo",
  doi="10.17487/RFC4886",
  }

@misc{rfc4887,
  author="P. Thubert and R. Wakikawa and V. Devarapalli",
  title="{Network Mobility Home Network Models}",
  howpublished="RFC 4887 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4887",
  pages="1--19",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4887.txt",
  key="RFC 4887",
  abstract={This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support.  The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists.  This memo provides information for the Internet community.},
  keywords="nemo, mobile routers",
  doi="10.17487/RFC4887",
  }

@misc{rfc4888,
  author="C. Ng and P. Thubert and M. Watari and F. Zhao",
  title="{Network Mobility Route Optimization Problem Statement}",
  howpublished="RFC 4888 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4888",
  pages="1--26",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4888.txt",
  key="RFC 4888",
  abstract={With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away.  This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes.  Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions.  This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.  This memo provides information for the Internet community.},
  keywords="nemo",
  doi="10.17487/RFC4888",
  }

@misc{rfc4889,
  author="C. Ng and F. Zhao and M. Watari and P. Thubert",
  title="{Network Mobility Route Optimization Solution Space Analysis}",
  howpublished="RFC 4889 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4889",
  pages="1--38",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4889.txt",
  key="RFC 4889",
  abstract={With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away.  This results in increased length of packet route and increased packet delay in most cases.  To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO.  This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization.  This memo provides information for the Internet community.},
  keywords="nemo, mrha, mobile router and home agent, ro",
  doi="10.17487/RFC4889",
  }

@misc{rfc4890,
  author="E. Davies and J. Mohacsi",
  title="{Recommendations for Filtering ICMPv6 Messages in Firewalls}",
  howpublished="RFC 4890 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4890",
  pages="1--38",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4890.txt",
  key="RFC 4890",
  abstract={In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.},
  keywords="Internet Control Message Protocol version 6, ipv6, security, filter, firewall, icmpv6",
  doi="10.17487/RFC4890",
  }

@misc{rfc4891,
  author="R. Graveman and M. Parthasarathy and P. Savola and H. Tschofenig",
  title="{Using IPsec to Secure IPv6-in-IPv4 Tunnels}",
  howpublished="RFC 4891 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4891",
  pages="1--23",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4891.txt",
  key="RFC 4891",
  abstract={This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode.  No additional protocol extensions are described beyond those available with the IPsec framework.  This memo provides information for the Internet community.},
  keywords="internet protocol, internet protocol security, ip security",
  doi="10.17487/RFC4891",
  }

@misc{rfc4892,
  author="S. Woolf and D. Conrad",
  title="{Requirements for a Mechanism Identifying a Name Server Instance}",
  howpublished="RFC 4892 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4892",
  pages="1--8",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4892.txt",
  key="RFC 4892",
  abstract={With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators.  Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed.  This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism.  This memo provides information for the Internet community.},
  keywords="domain name service, dns name server",
  doi="10.17487/RFC4892",
  }

@misc{rfc4893,
  author="Q. Vohra and E. Chen",
  title="{BGP Support for Four-octet AS Number Space}",
  howpublished="RFC 4893 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4893",
  pages="1--10",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6793",
url="https://www.rfc-editor.org/rfc/rfc4893.txt",
  key="RFC 4893",
  abstract={Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP.  This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]},
  keywords="autonomous system, border gateway protocol",
  doi="10.17487/RFC4893",
  }

@misc{rfc4894,
  author="P. Hoffman",
  title="{Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec}",
  howpublished="RFC 4894 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4894",
  pages="1--11",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4894.txt",
  key="RFC 4894",
  abstract={This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms.  This memo provides information for the Internet community.},
  keywords="md5, pkix, certificates",
  doi="10.17487/RFC4894",
  }

@misc{rfc4895,
  author="M. Tuexen and R. Stewart and P. Lei and E. Rescorla",
  title="{Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 4895 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4895",
  pages="1--19",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4895.txt",
  key="RFC 4895",
  abstract={This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP).  This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver.  The new parameters are used to establish the shared keys. [STANDARDS-TRACK]},
  keywords="chunk type, shared keys, RANDOM, CHUNKS, HMAC-ALGO",
  doi="10.17487/RFC4895",
  }

@misc{rfc4896,
  author="A. Surtees and M. West and A.B. Roach",
  title="{Signaling Compression (SigComp) Corrections and Clarifications}",
  howpublished="RFC 4896 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4896",
  pages="1--28",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4896.txt",
  key="RFC 4896",
  abstract={This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems.  SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP).  This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]},
  keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine, algorithm",
  doi="10.17487/RFC4896",
  }

@misc{rfc4897,
  author="J. Klensin and S. Hartman",
  title="{Handling Normative References to Standards-Track Documents}",
  howpublished="RFC 4897 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4897",
  pages="1--6",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4897.txt",
  key="RFC 4897",
  abstract={The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher.  This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level.  The IETF agreed on a way to bypass this rule with RFC 3967.  This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely ``note and move on''.  The procedure in RFC 3967 still applies for downward references to other classes of documents.  In both cases, annotations should be added to such References.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4897",
  }

@misc{rfc4898,
  author="M. Mathis and J. Heffner and R. Raghunarayan",
  title="{TCP Extended Statistics MIB}",
  howpublished="RFC 4898 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4898",
  pages="1--75",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4898.txt",
  key="RFC 4898",
  abstract={This document describes extended performance statistics for TCP.  They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application.  If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself.  If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]},
  keywords="transmission control protocol, management information base, TCP-ESTATS-MIB",
  doi="10.17487/RFC4898",
  }

@misc{rfc4901,
  author="J. Ash and J. Hand and A. Malis",
  title="{Protocol Extensions for Header Compression over MPLS}",
  howpublished="RFC 4901 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4901",
  pages="1--34",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4901.txt",
  key="RFC 4901",
  abstract={This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path.  HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router).  Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers.  This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP.  This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols.  In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, hc",
  doi="10.17487/RFC4901",
  }

@misc{rfc4902,
  author="M. Stecher",
  title="{Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP}",
  howpublished="RFC 4902 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4902",
  pages="1--14",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4902.txt",
  key="RFC 4902",
  abstract={The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the ``SMTP adaptation with OPES'' document. The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.},
  doi="10.17487/RFC4902",
  }

@misc{rfc4903,
  author="D. Thaler",
  title="{Multi-Link Subnet Issues}",
  howpublished="RFC 4903 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4903",
  pages="1--17",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4903.txt",
  key="RFC 4903",
  abstract={There have been several proposals around the notion that a subnet may span multiple links connected by routers.  This memo documents the issues and potential problems that have been raised with such an approach.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4903",
  }

@misc{rfc4904,
  author="V. Gurbani and C. Jennings",
  title="{Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 4904 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4904",
  pages="1--19",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4904.txt",
  key="RFC 4904",
  abstract={This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs).  An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]},
  keywords="SIP TEL, Trunk group, trunkgroup, PSTN",
  doi="10.17487/RFC4904",
  }

@misc{rfc4905,
  author="L. Martini and E. Rosen and N. El-Aawar",
  title="{Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks}",
  howpublished="RFC 4905 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4905",
  pages="1--20",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4905.txt",
  key="RFC 4905",
  abstract={This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network.  This document describes the so-called ``draft-martini'' protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.  This memo defines a Historic Document for the Internet community.},
  keywords="multiprotocol label switching, pdu, protocol data unit, draft-martini",
  doi="10.17487/RFC4905",
  }

@misc{rfc4906,
  author="L. Martini and E. Rosen and N. El-Aawar",
  title="{Transport of Layer 2 Frames Over MPLS}",
  howpublished="RFC 4906 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="4906",
  pages="1--22",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4906.txt",
  key="RFC 4906",
  abstract={This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network.  This document describes the so-called ``draft-martini'' protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.  This memo defines a Historic Document for the Internet community.},
  keywords="multiprotocol label switching, pdu, protocol data unit, sonet, synchronized optical network",
  doi="10.17487/RFC4906",
  }

@misc{rfc4907,
  author="B. Aboba",
  title="{Architectural Implications of Link Indications}",
  howpublished="RFC 4907 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4907",
  pages="1--62",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4907.txt",
  key="RFC 4907",
  abstract={A link indication represents information provided by the link layer to higher layers regarding the state of the link.  This document describes the role of link indications within the Internet architecture.  While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance.  This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4907",
  }

@misc{rfc4908,
  author="K. Nagami and S. Uda and N. Ogashiwa and H. Esaki and R. Wakikawa and H. Ohnishi",
  title="{Multi-homing for small scale fixed network Using Mobile IP and NEMO}",
  howpublished="RFC 4908 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4908",
  pages="1--10",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4908.txt",
  key="RFC 4908",
  abstract={Multihoming technology improves the availability of host and network connectivity.  Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed.  This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963).  The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used.  In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="care-of addresses",
  doi="10.17487/RFC4908",
  }

@misc{rfc4909,
  author="L. Dondeti and D. Castleford and F. Hartung",
  title="{Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport}",
  howpublished="RFC 4909 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4909",
  pages="1--7",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 5410, 6309",
url="https://www.rfc-editor.org/rfc/rfc4909.txt",
  key="RFC 4909",
  abstract={This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification.  This memo provides information for the Internet community.},
  keywords="short-term key message, long-term key message, oma, bac, browser and content, broadcast",
  doi="10.17487/RFC4909",
  }

@misc{rfc4910,
  author="S. Legg and D. Prager",
  title="{Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)}",
  howpublished="RFC 4910 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4910",
  pages="1--80",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4910.txt",
  key="RFC 4910",
  abstract={This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type.  Rules for producing a canonical RXER encoding are also defined.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="extensible markup language, canonical rxer, crxer",
  doi="10.17487/RFC4910",
  }

@misc{rfc4911,
  author="S. Legg",
  title="{Encoding Instructions for the Robust XML Encoding Rules (RXER)}",
  howpublished="RFC 4911 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4911",
  pages="1--91",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4911.txt",
  key="RFC 4911",
  abstract={This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element.  Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification.  Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="extensible markup language, asn.1, abstract syntax notation one, robust xml encoding rules, rxer, canonical robust xml encoding rules, crxer, asn.x",
  doi="10.17487/RFC4911",
  }

@misc{rfc4912,
  author="S. Legg",
  title="{Abstract Syntax Notation X (ASN.X)}",
  howpublished="RFC 4912 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4912",
  pages="1--165",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4912.txt",
  key="RFC 4912",
  abstract={Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications.  ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="extensible markup language, asn.1, abstract syntax notation one, robust xml encoding rules, rxer",
  doi="10.17487/RFC4912",
  }

@misc{rfc4913,
  author="S. Legg",
  title="{Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)}",
  howpublished="RFC 4913 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4913",
  pages="1--9",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4913.txt",
  key="RFC 4913",
  abstract={Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="extensible markup language",
  doi="10.17487/RFC4913",
  }

@misc{rfc4914,
  author="S. Legg",
  title="{Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)}",
  howpublished="RFC 4914 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4914",
  pages="1--38",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4914.txt",
  key="RFC 4914",
  abstract={Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="extensible markup language",
  doi="10.17487/RFC4914",
  }

@misc{rfc4915,
  author="P. Psenak and S. Mirtorabi and A. Roy and L. Nguyen and P. Pillay-Esnault",
  title="{Multi-Topology (MT) Routing in OSPF}",
  howpublished="RFC 4915 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4915",
  pages="1--20",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4915.txt",
  key="RFC 4915",
  abstract={This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]},
  keywords="open shortest path first",
  doi="10.17487/RFC4915",
  }

@misc{rfc4916,
  author="J. Elwell",
  title="{Connected Identity in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 4916 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4916",
  pages="1--24",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4916.txt",
  key="RFC 4916",
  abstract={This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service.  Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field.  The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway.  This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]},
  keywords="user agent, ua, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC4916",
  }

@misc{rfc4917,
  author="V. Sastry and K. Leung and A. Patel",
  title="{Mobile IPv4 Message String Extension}",
  howpublished="RFC 4917 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4917",
  pages="1--7",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4917.txt",
  key="RFC 4917",
  abstract={This document specifies a new extension for use in Mobile IPv4.  This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages.  This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]},
  keywords="home agent, foreign agent, registration reply",
  doi="10.17487/RFC4917",
  }

@misc{rfc4918,
  author="L. Dusseault",
  title="{HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 4918 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4918",
  pages="1--127",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5689",
url="https://www.rfc-editor.org/rfc/rfc4918.txt",
  key="RFC 4918",
  abstract={Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]},
  keywords="WEBDAV, hypertext, transfer, protocol, web, content",
  doi="10.17487/RFC4918",
  }

@misc{rfc4919,
  author="N. Kushalnagar and G. Montenegro and C. Schumacher",
  title="{IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals}",
  howpublished="RFC 4919 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4919",
  pages="1--12",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4919.txt",
  key="RFC 4919",
  abstract={This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks.  The set of goals enumerated in this document form an initial set only.  This memo provides information for the Internet community.},
  keywords="ieee 802.15.4",
  doi="10.17487/RFC4919",
  }

@misc{rfc4920,
  author="A. Farrel and A. Satyanarayana and A. Iwata and N. Fujita and G. Ash",
  title="{Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE}",
  howpublished="RFC 4920 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4920",
  pages="1--38",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4920.txt",
  key="RFC 4920",
  abstract={In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in ``RSVP-TE: Extensions to RSVP for LSP Tunnels'', RFC 3209, and GMPLS signaling as defined in ``Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description'', RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, generalized multiprotocol label switching, traffic engineered, te, lsp, label switched path",
  doi="10.17487/RFC4920",
  }

@misc{rfc4923,
  author="F. Baker and P. Bose",
  title="{Quality of Service (QoS) Signaling in a Nested Virtual Private Network}",
  howpublished="RFC 4923 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4923",
  pages="1--38",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4923.txt",
  key="RFC 4923",
  abstract={Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence.  This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998.  This memo provides information for the Internet community.},
  keywords="vpn, nested vpn, integrated services",
  doi="10.17487/RFC4923",
  }

@misc{rfc4924,
  author="B. Aboba and E. Davies",
  title="{Reflections on Internet Transparency}",
  howpublished="RFC 4924 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4924",
  pages="1--15",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4924.txt",
  key="RFC 4924",
  abstract={This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues.  Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication.  This document provides some specific illustrations of those potential impacts.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4924",
  }

@misc{rfc4925,
  author="X. Li and S. Dawkins and D. Ward and A. Durand",
  title="{Softwire Problem Statement}",
  howpublished="RFC 4925 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4925",
  pages="1--23",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4925.txt",
  key="RFC 4925",
  abstract={This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks.  The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of ``IPv4/IPv6'' and ``IPv6/IPv4'' transition problems.  This document describes the specific problems (``Hubs and Spokes'' and ``Mesh'') that will be solved by the standards developed by the Softwires Working Group.  Some requirements (and non-requirements) are also identified to better describe the specific problem scope.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4925",
  }

@misc{rfc4926,
  author="T.Kalin and M.Molina",
  title="{A URN Namespace for GEANT}",
  howpublished="RFC 4926 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4926",
  pages="1--9",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4926.txt",
  key="RFC 4926",
  abstract={This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates.  This memo provides information for the Internet community.},
  keywords="uniform resource name, dante",
  doi="10.17487/RFC4926",
  }

@misc{rfc4927,
  author="J.-L. Le Roux",
  title="{Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering}",
  howpublished="RFC 4927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4927",
  pages="1--12",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4927.txt",
  key="RFC 4927",
  abstract={For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas.  An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas.  In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path.  One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths.  The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses.  This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation.  It complements the generic requirements for a PCE Communication Protocol.  This memo provides information for the Internet community.},
  keywords="gmpls, te-lsp, traffic engineered label switched path, pce, path computation element",
  doi="10.17487/RFC4927",
  }

@misc{rfc4928,
  author="G. Swallow and S. Bryant and L. Andersson",
  title="{Avoiding Equal Cost Multipath Treatment in MPLS Networks}",
  howpublished="RFC 4928 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4928",
  pages="1--8",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc4928.txt",
  key="RFC 4928",
  abstract={This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks.  This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths.  These recommendations rely on inspection of the IP version number field in packets.  Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ecmp",
  doi="10.17487/RFC4928",
  }

@misc{rfc4929,
  author="L. Andersson and A. Farrel",
  title="{Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures}",
  howpublished="RFC 4929 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4929",
  pages="1--23",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4929.txt",
  key="RFC 4929",
  abstract={This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols.  This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work.  This document does not modify IETF processes.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4929",
  }

@misc{rfc4930,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 4930 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4930",
  pages="1--72",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5730",
url="https://www.rfc-editor.org/rfc/rfc4930.txt",
  key="RFC 4930",
  abstract={This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document includes a protocol specification, an object mapping template, and an XML media type registration.  This document obsoletes RFC 3730. [STANDARDS-TRACK]},
  keywords="shared framework mapping",
  doi="10.17487/RFC4930",
  }

@misc{rfc4931,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}",
  howpublished="RFC 4931 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4931",
  pages="1--46",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5731",
url="https://www.rfc-editor.org/rfc/rfc4931.txt",
  key="RFC 4931",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.  This document obsoletes RFC 3731. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC4931",
  }

@misc{rfc4932,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Host Mapping}",
  howpublished="RFC 4932 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4932",
  pages="1--30",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5732",
url="https://www.rfc-editor.org/rfc/rfc4932.txt",
  key="RFC 4932",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.  This document obsoletes RFC 3732. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC4932",
  }

@misc{rfc4933,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Contact Mapping}",
  howpublished="RFC 4933 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4933",
  pages="1--43",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5733",
url="https://www.rfc-editor.org/rfc/rfc4933.txt",
  key="RFC 4933",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository.  Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.  This document obsoletes RFC 3733. [STANDARDS-TRACK]},
  keywords="syntax, semantics",
  doi="10.17487/RFC4933",
  }

@misc{rfc4934,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Transport Over TCP}",
  howpublished="RFC 4934 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4934",
  pages="1--10",
  year=2007,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5734",
url="https://www.rfc-editor.org/rfc/rfc4934.txt",
  key="RFC 4934",
  abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.  This document obsoletes RFC 3734. [STANDARDS-TRACK]},
  keywords="mapping, client, server, tls, transport layer security",
  doi="10.17487/RFC4934",
  }

@misc{rfc4935,
  author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai",
  title="{Fibre Channel Fabric Configuration Server MIB}",
  howpublished="RFC 4935 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4935",
  pages="1--50",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4935.txt",
  key="RFC 4935",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-FABRIC-CONFIG-SERVER-MIB",
  doi="10.17487/RFC4935",
  }

@misc{rfc4936,
  author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai",
  title="{Fibre Channel Zone Server MIB}",
  howpublished="RFC 4936 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4936",
  pages="1--84",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4936.txt",
  key="RFC 4936",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-FABRIC-LOCK-MIB, T11-FC-ZONE-SERVER-MIB",
  doi="10.17487/RFC4936",
  }

@misc{rfc4937,
  author="P. Arberg and V. Mammoliti",
  title="{IANA Considerations for PPP over Ethernet (PPPoE)}",
  howpublished="RFC 4937 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4937",
  pages="1--6",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4937.txt",
  key="RFC 4937",
  abstract={This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4937",
  }

@misc{rfc4938,
  author="B. Berry and H. Holgate",
  title="{PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics}",
  howpublished="RFC 4938 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4938",
  pages="1--17",
  year=2007,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5578",
url="https://www.rfc-editor.org/rfc/rfc4938.txt",
  key="RFC 4938",
  abstract={This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report.  This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4938",
  }

@misc{rfc4939,
  author="K. Gibbons and G. Ramkumar and S. Kipp",
  title="{Definitions of Managed Objects for iSNS (Internet Storage Name Service)}",
  howpublished="RFC 4939 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4939",
  pages="1--80",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4939.txt",
  key="RFC 4939",
  abstract={The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage.  This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]},
  keywords="mib, management information base, iscsi, internet small computer system interface, ifcp, internet fibre channel protocol, ISNS-MIB",
  doi="10.17487/RFC4939",
  }

@misc{rfc4940,
  author="K. Kompella and B. Fenner",
  title="{IANA Considerations for OSPF}",
  howpublished="RFC 4940 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4940",
  pages="1--15",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4940.txt",
  key="RFC 4940",
  abstract={This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="open shortest path first",
  doi="10.17487/RFC4940",
  }

@misc{rfc4941,
  author="T. Narten and R. Draves and S. Krishnan",
  title="{Privacy Extensions for Stateless Address Autoconfiguration in IPv6}",
  howpublished="RFC 4941 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4941",
  pages="1--23",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4941.txt",
  key="RFC 4941",
  abstract={Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers.  Addresses are formed by combining network prefixes with an interface identifier.  On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it.  On other interface types, the interface identifier is generated through other means, for example, via random number generation.  This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier.  Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier.  Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]},
  keywords="privacy, anonymity, unlinkability, crypto-based address changing",
  doi="10.17487/RFC4941",
  }

@misc{rfc4942,
  author="E. Davies and S. Krishnan and P. Savola",
  title="{IPv6 Transition/Co-existence Security Considerations}",
  howpublished="RFC 4942 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4942",
  pages="1--41",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4942.txt",
  key="RFC 4942",
  abstract={The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. This memo provides information for the Internet community.},
  keywords="internet protocol version 6, dual-protocol network, ipv4",
  doi="10.17487/RFC4942",
  }

@misc{rfc4943,
  author="S. Roy and A. Durand and J. Paugh",
  title="{IPv6 Neighbor Discovery On-Link Assumption Considered Harmful}",
  howpublished="RFC 4943 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4943",
  pages="1--8",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4943.txt",
  key="RFC 4943",
  abstract={This document describes the historical and background information behind the removal of the ``on-link assumption'' from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6).  According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link.  This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router).  This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6",
  doi="10.17487/RFC4943",
  }

@misc{rfc4944,
  author="G. Montenegro and N. Kushalnagar and J. Hui and D. Culler",
  title="{Transmission of IPv6 Packets over IEEE 802.15.4 Networks}",
  howpublished="RFC 4944 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4944",
  pages="1--30",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6282, 6775, 8025, 8066",
url="https://www.rfc-editor.org/rfc/rfc4944.txt",
  key="RFC 4944",
  abstract={This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.  Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]},
  keywords="internet protocol version 6, link-local address, stateless autoconfiguration",
  doi="10.17487/RFC4944",
  }

@misc{rfc4945,
  author="B. Korver",
  title="{The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX}",
  howpublished="RFC 4945 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4945",
  pages="1--43",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4945.txt",
  key="RFC 4945",
  abstract={The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application.  This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec.  The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly.  This document addresses those issues.  The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]},
  keywords="internet key exchange, public key infrastructure for x.509, ipsec",
  doi="10.17487/RFC4945",
  }

@misc{rfc4946,
  author="J. Snell",
  title="{Atom License Extension}",
  howpublished="RFC 4946 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4946",
  pages="1--8",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4946.txt",
  key="RFC 4946",
  abstract={This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="atom syndication format, atom feeds, atom entries",
  doi="10.17487/RFC4946",
  }

@misc{rfc4947,
  author="G. Fairhurst and M. Montpetit",
  title="{Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks}",
  howpublished="RFC 4947 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4947",
  pages="1--41",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4947.txt",
  key="RFC 4947",
  abstract={This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.},
  keywords="encapsulate, motion picture experts group, unidirectional link protocol, UniDirectional Link Routing, address resolution protocol",
  doi="10.17487/RFC4947",
  }

@misc{rfc4948,
  author="L. Andersson and E. Davies and L. Zhang",
  title="{Report from the IAB workshop on Unwanted Traffic March 9-10, 2006}",
  howpublished="RFC 4948 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4948",
  pages="1--43",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4948.txt",
  key="RFC 4948",
  abstract={This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic.  The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA.  The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions.  It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic.  This memo provides information for the Internet community.},
  keywords="spam, botnet",
  doi="10.17487/RFC4948",
  }

@misc{rfc4949,
  author="R. Shirey",
  title="{Internet Security Glossary, Version 2}",
  howpublished="RFC 4949 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4949",
  pages="1--365",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4949.txt",
  key="RFC 4949",
  abstract={This Glossary provides definitions, abbreviations, and explanations of terminology for information system security.  The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026).  The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.},
  keywords="abbreviation, clarity, definition, dictionary, language, punctuation, synonym, terminology, writing",
  doi="10.17487/RFC4949",
  }

@misc{rfc4950,
  author="R. Bonica and D. Gan and D. Tappan and C. Pignataro",
  title="{ICMP Extensions for Multiprotocol Label Switching}",
  howpublished="RFC 4950 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4950",
  pages="1--8",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4950.txt",
  key="RFC 4950",
  abstract={This memo defines an extension object that can be appended to selected multi-part ICMP messages.  This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]},
  keywords="Internet Control Message Protocol",
  doi="10.17487/RFC4950",
  }

@misc{rfc4951,
  author="V. Jain",
  title="{Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) ``failover''}",
  howpublished="RFC 4951 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4951",
  pages="1--26",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4951.txt",
  key="RFC 4951",
  abstract={Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints.  Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection.  When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection.  Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available.  Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]},
  keywords="control connection, layer 2  connectivity",
  doi="10.17487/RFC4951",
  }

@misc{rfc4952,
  author="J. Klensin and Y. Ko",
  title="{Overview and Framework for Internationalized Email}",
  howpublished="RFC 4952 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4952",
  pages="1--20",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6530, updated by RFC 5336",
url="https://www.rfc-editor.org/rfc/rfc4952.txt",
  key="RFC 4952",
  abstract={Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses.  This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses.  These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data.  The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.  This memo provides information for the Internet community.},
  keywords="smtp",
  doi="10.17487/RFC4952",
  }

@misc{rfc4953,
  author="J. Touch",
  title="{Defending TCP Against Spoofing Attacks}",
  howpublished="RFC 4953 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4953",
  pages="1--28",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4953.txt",
  key="RFC 4953",
  abstract={Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing).  TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers.  For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number.  The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks.  This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment.  This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.  This memo provides information for the Internet community.},
  keywords="rst, transport control protocol",
  doi="10.17487/RFC4953",
  }

@misc{rfc4954,
  author="R. Siemborski and A. Melnikov",
  title="{SMTP Service Extension for Authentication}",
  howpublished="RFC 4954 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4954",
  pages="1--20",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5248",
url="https://www.rfc-editor.org/rfc/rfc4954.txt",
  key="RFC 4954",
  abstract={This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554. [STANDARDS-TRACK]},
  keywords="simple mail transport protocol, security layer, sasl",
  doi="10.17487/RFC4954",
  }

@misc{rfc4955,
  author="D. Blacka",
  title="{DNS Security (DNSSEC) Experiments}",
  howpublished="RFC 4955 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4955",
  pages="1--7",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4955.txt",
  key="RFC 4955",
  abstract={This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]},
  keywords="domain namespace",
  doi="10.17487/RFC4955",
  }

@misc{rfc4956,
  author="R. Arends and M. Kosters and D. Blacka",
  title="{DNS Security (DNSSEC) Opt-In}",
  howpublished="RFC 4956 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4956",
  pages="1--17",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4956.txt",
  key="RFC 4956",
  abstract={In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured.  Maintaining this cryptography is not always practical or necessary.  This document describes an experimental ``Opt-In'' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain namespace",
  doi="10.17487/RFC4956",
  }

@misc{rfc4957,
  author="S. Krishnan and N. Montavont and E. Njedjou and S. Veerepalli and A. Yegin",
  title="{Link-Layer Event Notifications for Detecting Network Attachments}",
  howpublished="RFC 4957 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4957",
  pages="1--18",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4957.txt",
  key="RFC 4957",
  abstract={Certain network access technologies are capable of providing various types of link-layer status information to IP.  Link-layer event notifications can help IP expeditiously detect configuration changes.  This document provides a non-exhaustive catalogue of information available from well-known access technologies.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4957",
  }

@misc{rfc4958,
  author="K. Carlberg",
  title="{A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain}",
  howpublished="RFC 4958 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4958",
  pages="1--28",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4958.txt",
  key="RFC 4958",
  abstract={This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain.  Comments about their potential usage as well as their current deployment are provided to the reader.  Specific solutions are not presented.  This memo provides information for the Internet community.},
  keywords="priority, prioritization, preferential service",
  doi="10.17487/RFC4958",
  }

@misc{rfc4959,
  author="R. Siemborski and A. Gulbrandsen",
  title="{IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response}",
  howpublished="RFC 4959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4959",
  pages="1--7",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4959.txt",
  key="RFC 4959",
  abstract={To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]},
  keywords="imap authenticate, internet message access protocol",
  doi="10.17487/RFC4959",
  }

@misc{rfc4960,
  author="R. Stewart",
  title="{Stream Control Transmission Protocol}",
  howpublished="RFC 4960 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4960",
  pages="1--152",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6096, 6335, 7053",
url="https://www.rfc-editor.org/rfc/rfc4960.txt",
  key="RFC 4960",
  abstract={This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]},
  keywords="SCTP, IP, internet, transport, packet, network",
  doi="10.17487/RFC4960",
  }

@misc{rfc4961,
  author="D. Wing",
  title="{Symmetric RTP / RTP Control Protocol (RTCP)}",
  howpublished="RFC 4961 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4961",
  pages="1--6",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4961.txt",
  key="RFC 4961",
  abstract={This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called ``symmetric RTP'' and ``symmetric RTCP''.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="real time transport protocol, symmetric rtcp",
  doi="10.17487/RFC4961",
  }

@misc{rfc4962,
  author="R. Housley and B. Aboba",
  title="{Guidance for Authentication, Authorization, and Accounting (AAA) Key Management}",
  howpublished="RFC 4962 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="4962",
  pages="1--23",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4962.txt",
  key="RFC 4962",
  abstract={This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols.  The guidance is also useful to designers of systems and solutions that include AAA key management protocols.  Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols.  The guidelines in this document apply to documents requesting publication as IETF RFCs.  Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC4962",
  }

@misc{rfc4963,
  author="J. Heffner and M. Mathis and B. Chandler",
  title="{IPv4 Reassembly Errors at High Data Rates}",
  howpublished="RFC 4963 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4963",
  pages="1--10",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4963.txt",
  key="RFC 4963",
  abstract={IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet.  At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers.  This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.  This memo provides information for the Internet community.},
  doi="10.17487/RFC4963",
  }

@misc{rfc4964,
  author="A. Allen and J. Holm and T. Hallin",
  title="{The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular}",
  howpublished="RFC 4964 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4964",
  pages="1--32",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4964.txt",
  key="RFC 4964",
  abstract={This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application.  The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.  This memo provides information for the Internet community.},
  keywords="p-header, oma, open mobile alliance, poc",
  doi="10.17487/RFC4964",
  }

@misc{rfc4965,
  author="J-F. Mule and W. Townsley",
  title="{CableLabs - IETF Standardization Collaboration}",
  howpublished="RFC 4965 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4965",
  pages="1--10",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4965.txt",
  key="RFC 4965",
  abstract={This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs).  This memo provides information for the Internet community.},
  keywords="IETF CableLabs Collaboration, liaison, Cable Television Laboratories, DOCSIS, PacketCable, OpenCable",
  doi="10.17487/RFC4965",
  }

@misc{rfc4966,
  author="C. Aoun and E. Davies",
  title="{Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status}",
  howpublished="RFC 4966 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4966",
  pages="1--25",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4966.txt",
  key="RFC 4966",
  abstract={This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766.  These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status.  This memo provides information for the Internet community.},
  keywords="NAT-PT, v6ops",
  doi="10.17487/RFC4966",
  }

@misc{rfc4967,
  author="B. Rosen",
  title="{Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier}",
  howpublished="RFC 4967 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4967",
  pages="1--6",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4967.txt",
  key="RFC 4967",
  abstract={RFC 3966 explicitly states that 'tel' URIs may not represent a dial string.  That leaves no way specify a dial string in a standardized way.  Great confusion exists with the SIP URI parameter ``user=phone'', and specifically, if it can represent a dial string.  This memo creates a new value for the user parameter ``dialstring'', so that one may specify ``user=dialstring'' to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]},
  keywords="dialstring",
  doi="10.17487/RFC4967",
  }

@misc{rfc4968,
  author="S. Madanapalli",
  title="{Analysis of IPv6 Link Models for 802.16 Based Networks}",
  howpublished="RFC 4968 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4968",
  pages="1--16",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4968.txt",
  key="RFC 4968",
  abstract={This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios.  This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.  This memo provides information for the Internet community.},
  keywords="wimax",
  doi="10.17487/RFC4968",
  }

@misc{rfc4969,
  author="A. Mayrhofer",
  title="{IANA Registration for vCard Enumservice}",
  howpublished="RFC 4969 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4969",
  pages="1--7",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4969.txt",
  key="RFC 4969",
  abstract={This memo registers the Enumservice ``vCard'' using the URI schemes ``http'' and ``https''. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]},
  keywords="enum, e.164",
  doi="10.17487/RFC4969",
  }

@misc{rfc4970,
  author="A. Lindem and N. Shen and JP. Vasseur and R. Aggarwal and S. Shaffer",
  title="{Extensions to OSPF for Advertising Optional Router Capabilities}",
  howpublished="RFC 4970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4970",
  pages="1--13",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7770",
url="https://www.rfc-editor.org/rfc/rfc4970.txt",
  key="RFC 4970",
  abstract={It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose.  In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a new LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]},
  keywords="ospfv2, ospfv3, open shortest path first, ri, router information, lsa, link state advertisement",
  doi="10.17487/RFC4970",
  }

@misc{rfc4971,
  author="JP. Vasseur and N. Shen and R. Aggarwal",
  title="{Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information}",
  howpublished="RFC 4971 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4971",
  pages="1--9",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7981",
url="https://www.rfc-editor.org/rfc/rfc4971.txt",
  key="RFC 4971",
  abstract={This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]},
  keywords="capabilty",
  doi="10.17487/RFC4971",
  }

@misc{rfc4972,
  author="JP. Vasseur and JL. Leroux and S. Yasukawa and S. Previdi and P. Psenak and P. Mabbey",
  title="{Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership}",
  howpublished="RFC 4972 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4972",
  pages="1--15",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4972.txt",
  key="RFC 4972",
  abstract={The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs).  This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]},
  keywords="mpls-te, lsp, label switched path, igp, is-is, ospf",
  doi="10.17487/RFC4972",
  }

@misc{rfc4973,
  author="P. Srisuresh and P. Joseph",
  title="{OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering}",
  howpublished="RFC 4973 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4973",
  pages="1--50",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4973.txt",
  key="RFC 4973",
  abstract={This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF.  OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas.  When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.  OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths.  OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ospf-te, link state advertisement, lsa",
  doi="10.17487/RFC4973",
  }

@misc{rfc4974,
  author="D. Papadimitriou and A. Farrel",
  title="{Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls}",
  howpublished="RFC 4974 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4974",
  pages="1--31",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6001",
url="https://www.rfc-editor.org/rfc/rfc4974.txt",
  key="RFC 4974",
  abstract={In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4974",
  }

@misc{rfc4975,
  author="B. Campbell and R. Mahy and C. Jennings",
  title="{The Message Session Relay Protocol (MSRP)}",
  howpublished="RFC 4975 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4975",
  pages="1--63",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7977",
url="https://www.rfc-editor.org/rfc/rfc4975.txt",
  key="RFC 4975",
  abstract={This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]},
  keywords="instant message",
  doi="10.17487/RFC4975",
  }

@misc{rfc4976,
  author="C. Jennings and R. Mahy and A. B. Roach",
  title="{Relay Extensions for the Message Sessions Relay Protocol (MSRP)}",
  howpublished="RFC 4976 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4976",
  pages="1--36",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7977",
url="https://www.rfc-editor.org/rfc/rfc4976.txt",
  key="RFC 4976",
  abstract={Two separate models for conveying instant messages have been defined.  Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP.  The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.  This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]},
  keywords="instante message, page-mode, session-mode, relay intermediary",
  doi="10.17487/RFC4976",
  }

@misc{rfc4977,
  author="G. Tsirtsis and H. Soliman",
  title="{Problem Statement: Dual Stack Mobility}",
  howpublished="RFC 4977 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4977",
  pages="1--8",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4977.txt",
  key="RFC 4977",
  abstract={This document discusses the issues associated with mobility management for dual stack mobile nodes.  Currently, two mobility management protocols are defined for IPv4 and IPv6.  Deploying both in a dual stack mobile node introduces a number of problems.  Deployment and operational issues motivate the use of a single mobility management protocol.  This document discusses such motivations.  The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.  This memo provides information for the Internet community.},
  keywords="mobility management protocol, mipv4, mipv6, mobile ip",
  doi="10.17487/RFC4977",
  }

@misc{rfc4978,
  author="A. Gulbrandsen",
  title="{The IMAP COMPRESS Extension}",
  howpublished="RFC 4978 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4978",
  pages="1--9",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4978.txt",
  key="RFC 4978",
  abstract={The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC4978",
  }

@misc{rfc4979,
  author="A. Mayrhofer",
  title="{IANA Registration for Enumservice 'XMPP'}",
  howpublished="RFC 4979 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4979",
  pages="1--7",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc4979.txt",
  key="RFC 4979",
  abstract={This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol.  This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]},
  keywords="extensible messaging and presence protocol, e.164",
  doi="10.17487/RFC4979",
  }

@misc{rfc4980,
  author="C. Ng and T. Ernst and E. Paik and M. Bagnulo",
  title="{Analysis of Multihoming in Network Mobility Support}",
  howpublished="RFC 4980 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4980",
  pages="1--39",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4980.txt",
  key="RFC 4980",
  abstract={This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6.  As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations.  The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support).  Recommendations are offered on how to address these issues.  This memo provides information for the Internet community.},
  keywords="nemo, ipv6, mobile networks",
  doi="10.17487/RFC4980",
  }

@misc{rfc4981,
  author="J. Risson and T. Moors",
  title="{Survey of Research towards Robust Peer-to-Peer Networks: Search Methods}",
  howpublished="RFC 4981 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4981",
  pages="1--91",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4981.txt",
  key="RFC 4981",
  abstract={The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs. Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness. P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.},
  keywords="Peer-to-peer network, Distributed hash table, Structured overlay, Unstructured overlay, Key-based routing, Consistent hashing, Scalable distributed data structure, Dependability, Hypercube, Plaxton tree, de Bruijn graph, Skip graph, Torus, Butterfly network, Vector model, Latent semantic indexing",
  doi="10.17487/RFC4981",
  }

@misc{rfc4982,
  author="M. Bagnulo and J. Arkko",
  title="{Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)}",
  howpublished="RFC 4982 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4982",
  pages="1--9",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4982.txt",
  key="RFC 4982",
  abstract={This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4982",
  }

@misc{rfc4983,
  author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai",
  title="{Fibre Channel Registered State Change Notification (RSCN) MIB}",
  howpublished="RFC 4983 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4983",
  pages="1--28",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4983.txt",
  key="RFC 4983",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-RSCN-MIB",
  doi="10.17487/RFC4983",
  }

@misc{rfc4984,
  author="D. Meyer and L. Zhang and K. Fall",
  title="{Report from the IAB Workshop on Routing and Addressing}",
  howpublished="RFC 4984 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4984",
  pages="1--39",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4984.txt",
  key="RFC 4984",
  abstract={This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.},
  keywords="routing and addressing workshop, routing table growth, addressing architecture",
  doi="10.17487/RFC4984",
  }

@misc{rfc4985,
  author="S. Santesson",
  title="{Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name}",
  howpublished="RFC 4985 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4985",
  pages="1--10",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4985.txt",
  key="RFC 4985",
  abstract={This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]},
  keywords="othername",
  doi="10.17487/RFC4985",
  }

@misc{rfc4986,
  author="H. Eland and R. Mundy and S. Crocker and S. Krishnaswamy",
  title="{Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover}",
  howpublished="RFC 4986 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4986",
  pages="1--11",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4986.txt",
  key="RFC 4986",
  abstract={Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones.  For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors.  For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers.  This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.  This memo provides information for the Internet community.},
  keywords="dns signed zone",
  doi="10.17487/RFC4986",
  }

@misc{rfc4987,
  author="W. Eddy",
  title="{TCP SYN Flooding Attacks and Common Mitigations}",
  howpublished="RFC 4987 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4987",
  pages="1--19",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4987.txt",
  key="RFC 4987",
  abstract={This document describes TCP SYN flooding attacks, which have been well-known to the community for several years.  Various countermeasures against these attacks, and the trade-offs of each, are described.  This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.  This memo provides information for the Internet community.},
  keywords="TCP SYN Flood, TCP SYN Cookies, denial-of-service, DoS",
  doi="10.17487/RFC4987",
  }

@misc{rfc4988,
  author="R. Koodli and C. Perkins",
  title="{Mobile IPv4 Fast Handovers}",
  howpublished="RFC 4988 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="4988",
  pages="1--28",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4988.txt",
  key="RFC 4988",
  abstract={This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.  Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover.  For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="mip4, delay, packet loss, movement detection, ip address configuration, loation update latency, care-of address, care of address, coa",
  doi="10.17487/RFC4988",
  }

@misc{rfc4990,
  author="K. Shiomoto and R. Papneja and R. Rabbat",
  title="{Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks}",
  howpublished="RFC 4990 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="4990",
  pages="1--23",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4990.txt",
  key="RFC 4990",
  abstract={This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment. The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.},
  keywords="address field, identifier field",
  doi="10.17487/RFC4990",
  }

@misc{rfc4991,
  author="A. Newton",
  title="{A Common Schema for Internet Registry Information Service Transfer Protocols}",
  howpublished="RFC 4991 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4991",
  pages="1--13",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4991.txt",
  key="RFC 4991",
  abstract={This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics.  It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]},
  keywords="iris, xml",
  doi="10.17487/RFC4991",
  }

@misc{rfc4992,
  author="A. Newton",
  title="{XML Pipelining with Chunks for the Internet Registry Information Service}",
  howpublished="RFC 4992 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4992",
  pages="1--29",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4992.txt",
  key="RFC 4992",
  abstract={This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS).  Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]},
  keywords="tcp, transport control protocol, iris",
  doi="10.17487/RFC4992",
  }

@misc{rfc4993,
  author="A. Newton",
  title="{A Lightweight UDP Transfer Protocol for the Internet Registry Information Service}",
  howpublished="RFC 4993 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4993",
  pages="1--19",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4993.txt",
  key="RFC 4993",
  abstract={This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS).  This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]},
  keywords="iris",
  doi="10.17487/RFC4993",
  }

@misc{rfc4994,
  author="S. Zeng and B. Volz and K. Kinnear and J. Brzozowski",
  title="{DHCPv6 Relay Agent Echo Request Option}",
  howpublished="RFC 4994 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4994",
  pages="1--6",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4994.txt",
  key="RFC 4994",
  abstract={This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol, relay agent option",
  doi="10.17487/RFC4994",
  }

@misc{rfc4995,
  author="L-E. Jonsson and G. Pelletier and K. Sandlund",
  title="{The RObust Header Compression (ROHC) Framework}",
  howpublished="RFC 4995 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4995",
  pages="1--40",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5795",
url="https://www.rfc-editor.org/rfc/rfc4995.txt",
  key="RFC 4995",
  abstract={The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4995",
  }

@misc{rfc4996,
  author="G. Pelletier and K. Sandlund and L-E. Jonsson and M. West",
  title="{RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)}",
  howpublished="RFC 4996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4996",
  pages="1--94",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6846",
url="https://www.rfc-editor.org/rfc/rfc4996.txt",
  key="RFC 4996",
  abstract={This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4996",
  }

@misc{rfc4997,
  author="R. Finking and G. Pelletier",
  title="{Formal Notation for RObust Header Compression (ROHC-FN)}",
  howpublished="RFC 4997 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4997",
  pages="1--62",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4997.txt",
  key="RFC 4997",
  abstract={This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework.  ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]},
  keywords="Robust Header Compression - Formal Notation",
  doi="10.17487/RFC4997",
  }

@misc{rfc4998,
  author="T. Gondrom and R. Brandner and U. Pordesch",
  title="{Evidence Record Syntax (ERS)}",
  howpublished="RFC 4998 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4998",
  pages="1--32",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4998.txt",
  key="RFC 4998",
  abstract={In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time.  This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]},
  keywords="long-term archive, security, timestamp, evidence record, archive timestamp",
  doi="10.17487/RFC4998",
  }

@misc{rfc5000,
  author="RFC Editor",
  title="{Internet Official Protocol Standards}",
  howpublished="RFC 5000 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5000",
  pages="1--75",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7100",
url="https://www.rfc-editor.org/rfc/rfc5000.txt",
  key="RFC 5000",
  abstract={This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred. For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.},
  keywords="",
  doi="10.17487/RFC5000",
  }

@misc{rfc5001,
  author="R. Austein",
  title="{DNS Name Server Identifier (NSID) Option}",
  howpublished="RFC 5001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5001",
  pages="1--11",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5001.txt",
  key="RFC 5001",
  abstract={With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself.  This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]},
  keywords="domain name space, namespace",
  doi="10.17487/RFC5001",
  }

@misc{rfc5002,
  author="G. Camarillo and G. Blanco",
  title="{The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)}",
  howpublished="RFC 5002 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5002",
  pages="1--7",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5002.txt",
  key="RFC 5002",
  abstract={This document specifies the SIP P-Profile-Key P-header.  This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request.  This memo provides information for the Internet community.},
  keywords="3gpp, ims, ip multimedia subsystem",
  doi="10.17487/RFC5002",
  }

@misc{rfc5003,
  author="C. Metz and L. Martini and F. Balus and J. Sugimoto",
  title="{Attachment Individual Identifier (AII) Types for Aggregation}",
  howpublished="RFC 5003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5003",
  pages="1--7",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5003.txt",
  key="RFC 5003",
  abstract={The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs).  This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery.  It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]},
  keywords="tlv, pseudowire",
  doi="10.17487/RFC5003",
  }

@misc{rfc5004,
  author="E. Chen and S. Sangli",
  title="{Avoid BGP Best Path Transitions from One External to Another}",
  howpublished="RFC 5004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5004",
  pages="1--6",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5004.txt",
  key="RFC 5004",
  abstract={In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions.  The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]},
  keywords="border gateway protocol",
  doi="10.17487/RFC5004",
  }

@misc{rfc5005,
  author="M. Nottingham",
  title="{Feed Paging and Archiving}",
  howpublished="RFC 5005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5005",
  pages="1--15",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5005.txt",
  key="RFC 5005",
  abstract={This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents.  This includes ``paged'' feeds for piecemeal access, ``archived'' feeds that allow reconstruction of the feed's contents, and feeds that are explicitly ``complete''. [STANDARDS-TRACK]},
  keywords="atom, rss",
  doi="10.17487/RFC5005",
  }

@misc{rfc5006,
  author="J. Jeong and S. Park and L. Beloeil and S. Madanapalli",
  title="{IPv6 Router Advertisement Option for DNS Configuration}",
  howpublished="RFC 5006 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5006",
  pages="1--12",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6106",
url="https://www.rfc-editor.org/rfc/rfc5006.txt",
  key="RFC 5006",
  abstract={This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="domain namespace",
  doi="10.17487/RFC5006",
  }

@misc{rfc5007,
  author="J. Brzozowski and K. Kinnear and B. Volz and S. Zeng",
  title="{DHCPv6 Leasequery}",
  howpublished="RFC 5007 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5007",
  pages="1--23",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5007.txt",
  key="RFC 5007",
  abstract={This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server.  This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior.  This document extends DHCPv6. [STANDARDS-TRACK]},
  keywords="dhc, dhcp, ipv6",
  doi="10.17487/RFC5007",
  }

@misc{rfc5008,
  author="R. Housley and J. Solinas",
  title="{Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)}",
  howpublished="RFC 5008 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5008",
  pages="1--15",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6318",
url="https://www.rfc-editor.org/rfc/rfc5008.txt",
  key="RFC 5008",
  abstract={This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851.  This memo provides information for the Internet community.},
  keywords="nsa",
  doi="10.17487/RFC5008",
  }

@misc{rfc5009,
  author="R. Ejza",
  title="{Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media}",
  howpublished="RFC 5009 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5009",
  pages="1--15",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5009.txt",
  key="RFC 5009",
  abstract={This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS).  This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state.  This memo provides information for the Internet community.},
  keywords="IMS, NGN, ETSI TISPAN, Gating, Cut-through, Call progress, Charging, PSTN, Interworking, Gateway, Ringback, Trust domain",
  doi="10.17487/RFC5009",
  }

@misc{rfc5010,
  author="K. Kinnear and M. Normoyle and M. Stapp",
  title="{The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption}",
  howpublished="RFC 5010 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5010",
  pages="1--7",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5010.txt",
  key="RFC 5010",
  abstract={This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet.  One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet.  This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]},
  keywords="unicast flag, broadcast flag",
  doi="10.17487/RFC5010",
  }

@misc{rfc5011,
  author="M. StJohns",
  title="{Automated Updates of DNS Security (DNSSEC) Trust Anchors}",
  howpublished="RFC 5011 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5011",
  pages="1--14",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5011.txt",
  key="RFC 5011",
  abstract={This document describes a means for automated, authenticated, and authorized updating of DNSSEC ``trust anchors''. The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]},
  keywords="n-1 key, n keys",
  doi="10.17487/RFC5011",
  }

@misc{rfc5012,
  author="H. Schulzrinne and R. Marshall",
  title="{Requirements for Emergency Context Resolution with Internet Technologies}",
  howpublished="RFC 5012 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5012",
  pages="1--23",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5012.txt",
  key="RFC 5012",
  abstract={This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end.  This memo provides information for the Internet community.},
  keywords="emergency calling, ecrit",
  doi="10.17487/RFC5012",
  }

@misc{rfc5013,
  author="J. Kunze and T. Baker",
  title="{The Dublin Core Metadata Element Set}",
  howpublished="RFC 5013 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5013",
  pages="1--9",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5013.txt",
  key="RFC 5013",
  abstract={This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment.  This memo provides information for the Internet community.},
  keywords="resource description, object descriptors, digital library collections",
  doi="10.17487/RFC5013",
  }

@misc{rfc5014,
  author="E. Nordmark and S. Chakrabarti and J. Laganier",
  title="{IPv6 Socket API for Source Address Selection}",
  howpublished="RFC 5014 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5014",
  pages="1--24",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5014.txt",
  key="RFC 5014",
  abstract={The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API.  However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents.  This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm.  The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication.  It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses.  This memo provides information for the Internet community.},
  keywords="getaddrinfo()cga, cryptographically generated address",
  doi="10.17487/RFC5014",
  }

@misc{rfc5015,
  author="M. Handley and I. Kouvelas and T. Speakman and L. Vicisano",
  title="{Bidirectional Protocol Independent Multicast (BIDIR-PIM)}",
  howpublished="RFC 5015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5015",
  pages="1--43",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5015.txt",
  key="RFC 5015",
  abstract={This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers.  Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology.  With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state.  The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]},
  keywords="pim, sparse-mode, shared trees",
  doi="10.17487/RFC5015",
  }

@misc{rfc5016,
  author="M. Thomas",
  title="{Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol}",
  howpublished="RFC 5016 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5016",
  pages="1--15",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5016.txt",
  key="RFC 5016",
  abstract={DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle.  A related mechanism will allow an administrator to publish various statements about their DKIM signing practices.  This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).  This memo provides information for the Internet community.},
  keywords="cryptographic",
  doi="10.17487/RFC5016",
  }

@misc{rfc5017,
  author="D. McWalter",
  title="{MIB Textual Conventions for Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 5017 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5017",
  pages="1--7",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5017.txt",
  key="RFC 5017",
  abstract={This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs).  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]},
  keywords="management information base, URI-TC-MIB",
  doi="10.17487/RFC5017",
  }

@misc{rfc5018,
  author="G. Camarillo",
  title="{Connection Establishment in the Binary Floor Control Protocol (BFCP)}",
  howpublished="RFC 5018 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5018",
  pages="1--9",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5018.txt",
  key="RFC 5018",
  abstract={This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange.  Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]},
  keywords="floor control server, tls, transport layer security",
  doi="10.17487/RFC5018",
  }

@misc{rfc5019,
  author="A. Deacon and R. Hurst",
  title="{The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments}",
  howpublished="RFC 5019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5019",
  pages="1--22",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5019.txt",
  key="RFC 5019",
  abstract={This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]},
  keywords="OCSP, Online Certificate, Status Protocol, certificate status, http caching, http proxies, efficient, cacheable, pre-produced",
  doi="10.17487/RFC5019",
  }

@misc{rfc5020,
  author="K. Zeilenga",
  title="{The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute}",
  howpublished="RFC 5020 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5020",
  pages="1--5",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5020.txt",
  key="RFC 5020",
  abstract={This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute.  The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]},
  keywords="x.500",
  doi="10.17487/RFC5020",
  }

@misc{rfc5021,
  author="S. Josefsson",
  title="{Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP}",
  howpublished="RFC 5021 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5021",
  pages="1--7",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5021.txt",
  key="RFC 5021",
  abstract={This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports.  The mechanism uses the reserved high-bit in the length field.  It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5021",
  }

@misc{rfc5022,
  author="J. Van Dyke and E. Burger and A. Spitzer",
  title="{Media Server Control Markup Language (MSCML) and Protocol}",
  howpublished="RFC 5022 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5022",
  pages="1--81",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5022.txt",
  key="RFC 5022",
  abstract={Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions.  MSCML presents an application-level control model, as opposed to device-level control models.  One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.  This memo provides information for the Internet community.},
  keywords="sip, ivr, interactive voice response",
  doi="10.17487/RFC5022",
  }

@misc{rfc5023,
  author="J. Gregorio and B. de hOra",
  title="{The Atom Publishing Protocol}",
  howpublished="RFC 5023 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5023",
  pages="1--53",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5023.txt",
  key="RFC 5023",
  abstract={The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources.  The protocol is based on HTTP transfer of Atom-formatted representations.  The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]},
  keywords="atompub, http transfer, atom syndication format",
  doi="10.17487/RFC5023",
  }

@misc{rfc5024,
  author="I. Friend",
  title="{ODETTE File Transfer Protocol 2.0}",
  howpublished="RFC 5024 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5024",
  pages="1--135",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5024.txt",
  key="RFC 5024",
  abstract={This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2. The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files. The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.},
  doi="10.17487/RFC5024",
  }

@misc{rfc5025,
  author="J. Rosenberg",
  title="{Presence Authorization Rules}",
  howpublished="RFC 5025 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5025",
  pages="1--28",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5025.txt",
  key="RFC 5025",
  abstract={Authorization is a key function in presence systems.  Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when.  This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules.  Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]},
  keywords="presence systems, authorization policies, xml, extensible markup language",
  doi="10.17487/RFC5025",
  }

@misc{rfc5026,
  author="G. Giaretta and J. Kempf and V. Devarapalli",
  title="{Mobile IPv6 Bootstrapping in Split Scenario}",
  howpublished="RFC 5026 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5026",
  pages="1--28",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5026.txt",
  key="RFC 5026",
  abstract={A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service.  RFC 3775 requires that some or all of these are statically configured.  This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node.  The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640.  The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access.  The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]},
  keywords="mip6, bootstrapping problem statement",
  doi="10.17487/RFC5026",
  }

@misc{rfc5027,
  author="F. Andreasen and D. Wing",
  title="{Security Preconditions for Session Description Protocol (SDP) Media Streams}",
  howpublished="RFC 5027 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5027",
  pages="1--16",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5027.txt",
  key="RFC 5027",
  abstract={This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032.  A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]},
  keywords="DTLS, DTLS-SRTP, TLS, MIKEY, Security Descriptions, SRTP",
  doi="10.17487/RFC5027",
  }

@misc{rfc5028,
  author="R. Mahy",
  title="{A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services}",
  howpublished="RFC 5028 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5028",
  pages="1--5",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc5028.txt",
  key="RFC 5028",
  abstract={This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM).  Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]},
  keywords="'im:', uri, uniform resource identifier",
  doi="10.17487/RFC5028",
  }

@misc{rfc5029,
  author="JP. Vasseur and S. Previdi",
  title="{Definition of an IS-IS Link Attribute Sub-TLV}",
  howpublished="RFC 5029 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5029",
  pages="1--6",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5029.txt",
  key="RFC 5029",
  abstract={This document defines a sub-TLV called ``Link-attributes'' carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]},
  keywords="link-attributes, tlv 22",
  doi="10.17487/RFC5029",
  }

@misc{rfc5030,
  author="M. Nakhjiri and K. Chowdhury and A. Lior and K. Leung",
  title="{Mobile IPv4 RADIUS Requirements}",
  howpublished="RFC 5030 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5030",
  pages="1--9",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5030.txt",
  key="RFC 5030",
  abstract={This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4.  The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures.  This memo provides information for the Internet community.},
  keywords="remote authentication dial-in user service, mip, mipv4",
  doi="10.17487/RFC5030",
  }

@misc{rfc5031,
  author="H. Schulzrinne",
  title="{A Uniform Resource Name (URN) for Emergency and Other Well-Known Services}",
  howpublished="RFC 5031 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5031",
  pages="1--14",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7163",
url="https://www.rfc-editor.org/rfc/rfc5031.txt",
  key="RFC 5031",
  abstract={The content of many communication services depends on the context, such as the user's location.  We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified.  Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]},
  keywords="urn, ecrit",
  doi="10.17487/RFC5031",
  }

@misc{rfc5032,
  author="E. Burger",
  title="{WITHIN Search Extension to the IMAP Protocol}",
  howpublished="RFC 5032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5032",
  pages="1--5",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5032.txt",
  key="RFC 5032",
  abstract={This document describes the WITHIN extension to IMAP SEARCH.  IMAP SEARCH returns messages whose internal date is within or outside a specified interval.  The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date.  WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]},
  keywords="imap search, older, younger",
  doi="10.17487/RFC5032",
  }

@misc{rfc5033,
  author="S. Floyd and M. Allman",
  title="{Specifying New Congestion Control Algorithms}",
  howpublished="RFC 5033 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5033",
  pages="1--10",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5033.txt",
  key="RFC 5033",
  abstract={The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks).  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC5033",
  }

@misc{rfc5034,
  author="R. Siemborski and A. Menon-Sen",
  title="{The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism}",
  howpublished="RFC 5034 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5034",
  pages="1--12",
  year=2007,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5034.txt",
  key="RFC 5034",
  abstract={This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]},
  keywords="POP3-AUTH, Post, Office, Protocol, Email",
  doi="10.17487/RFC5034",
  }

@misc{rfc5035,
  author="J. Schaad",
  title="{Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility}",
  howpublished="RFC 5035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5035",
  pages="1--17",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5035.txt",
  key="RFC 5035",
  abstract={In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1.  This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]},
  keywords="validation, signature, certificate",
  doi="10.17487/RFC5035",
  }

@misc{rfc5036,
  author="L. Andersson and I. Minei and B. Thomas",
  title="{LDP Specification}",
  howpublished="RFC 5036 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5036",
  pages="1--135",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6720, 6790, 7358, 7552",
url="https://www.rfc-editor.org/rfc/rfc5036.txt",
  key="RFC 5036",
  abstract={The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031.  A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]},
  keywords="label, distribution, protocol",
  doi="10.17487/RFC5036",
  }

@misc{rfc5037,
  author="L. Andersson and I. Minei and B. Thomas",
  title="{Experience with the Label Distribution Protocol (LDP)}",
  howpublished="RFC 5037 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5037",
  pages="1--7",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5037.txt",
  key="RFC 5037",
  abstract={The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol).  Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5037",
  }

@misc{rfc5038,
  author="B. Thomas and L. Andersson",
  title="{The Label Distribution Protocol (LDP) Implementation Survey Results}",
  howpublished="RFC 5038 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5038",
  pages="1--23",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5038.txt",
  key="RFC 5038",
  abstract={Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops.  A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made.  One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths.  This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard.  This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, mpls, lsr, label switched routers",
  doi="10.17487/RFC5038",
  }

@misc{rfc5039,
  author="J. Rosenberg and C. Jennings",
  title="{The Session Initiation Protocol (SIP) and Spam}",
  howpublished="RFC 5039 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5039",
  pages="1--28",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5039.txt",
  key="RFC 5039",
  abstract={Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email.  It can affect any system that enables user-to-user communications.  The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5039",
  }

@misc{rfc5040,
  author="R. Recio and B. Metzler and P. Culley and J. Hilland and D. Garcia",
  title="{A Remote Direct Memory Access Protocol Specification}",
  howpublished="RFC 5040 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5040",
  pages="1--66",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5040.txt",
  key="RFC 5040",
  abstract={This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).  RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies.  It also enables a kernel bypass implementation. [STANDARDS-TRACK]},
  keywords="rdmap, ddp, direct data placement protocol",
  doi="10.17487/RFC5040",
  }

@misc{rfc5041,
  author="H. Shah and J. Pinkerton and R. Recio and P. Culley",
  title="{Direct Data Placement over Reliable Transports}",
  howpublished="RFC 5041 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5041",
  pages="1--38",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5041.txt",
  key="RFC 5041",
  abstract={The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers.  This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]},
  keywords="ddp, cpu",
  doi="10.17487/RFC5041",
  }

@misc{rfc5042,
  author="J. Pinkerton and E. Deleganes",
  title="{Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security}",
  howpublished="RFC 5042 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5042",
  pages="1--52",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5042.txt",
  key="RFC 5042",
  abstract={This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP).  It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP.  The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system.  Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers.  Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]},
  keywords="rdma network interface card, rnic",
  doi="10.17487/RFC5042",
  }

@misc{rfc5043,
  author="C. Bestler and R. Stewart",
  title="{Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation}",
  howpublished="RFC 5043 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5043",
  pages="1--18",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6581, 7146",
url="https://www.rfc-editor.org/rfc/rfc5043.txt",
  key="RFC 5043",
  abstract={This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]},
  keywords="lower layer protocol, llp",
  doi="10.17487/RFC5043",
  }

@misc{rfc5044,
  author="P. Culley and U. Elzur and R. Recio and S. Bailey and J. Carrier",
  title="{Marker PDU Aligned Framing for TCP Specification}",
  howpublished="RFC 5044 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5044",
  pages="1--74",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6581, 7146",
url="https://www.rfc-editor.org/rfc/rfc5044.txt",
  key="RFC 5044",
  abstract={Marker PDU Aligned Framing (MPA) is designed to work as an ``adaptation layer'' between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041.  It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires.  MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations.  MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]},
  keywords="mpa, adaaptation layer, ddp, direct data placement protocol, transmission",
  doi="10.17487/RFC5044",
  }

@misc{rfc5045,
  author="C. Bestler and L. Coene",
  title="{Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)}",
  howpublished="RFC 5045 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5045",
  pages="1--22",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5045.txt",
  key="RFC 5045",
  abstract={This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).  It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality.  This memo provides information for the Internet community.},
  keywords="rdmap",
  doi="10.17487/RFC5045",
  }

@misc{rfc5046,
  author="M. Ko and M. Chadalapaka and J. Hufferd and U. Elzur and H. Shah and P. Thaler",
  title="{Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)}",
  howpublished="RFC 5046 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5046",
  pages="1--85",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7145, updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5046.txt",
  key="RFC 5046",
  abstract={Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite.  An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies.  This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS-TRACK]},
  keywords="rdma data transfer",
  doi="10.17487/RFC5046",
  }

@misc{rfc5047,
  author="M. Chadalapaka and J. Hufferd and J. Satran and H. Shah",
  title="{DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)}",
  howpublished="RFC 5047 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5047",
  pages="1--49",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5047.txt",
  key="RFC 5047",
  abstract={The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP.  Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports.  While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols.  Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself.  This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric.  It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand.  This memo provides information for the Internet community.},
  keywords="scsi transport protocol, tcp/ip",
  doi="10.17487/RFC5047",
  }

@misc{rfc5048,
  author="M. Chadalapaka",
  title="{Internet Small Computer System Interface (iSCSI) Corrections and Clarifications}",
  howpublished="RFC 5048 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5048",
  pages="1--38",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7143, updated by RFC 7146",
url="https://www.rfc-editor.org/rfc/rfc5048.txt",
  key="RFC 5048",
  abstract={The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP.  RFC 3720 defines the iSCSI protocol.  This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers.  This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]},
  keywords="scsi, iscsi protocol",
  doi="10.17487/RFC5048",
  }

@misc{rfc5049,
  author="C. Bormann and Z. Liu and R. Price and G. Camarillo",
  title="{Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5049 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5049",
  pages="1--21",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5049.txt",
  key="RFC 5049",
  abstract={This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP.  Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5049",
  }

@misc{rfc5050,
  author="K. Scott and S. Burleigh",
  title="{Bundle Protocol Specification}",
  howpublished="RFC 5050 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5050",
  pages="1--50",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5050.txt",
  key="RFC 5050",
  abstract={This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.},
  keywords="delay tolerant networking, dtn, dtnrg, exchange of messages",
  doi="10.17487/RFC5050",
  }

@misc{rfc5051,
  author="M. Crispin",
  title="{i;unicode-casemap - Simple Unicode Collation Algorithm}",
  howpublished="RFC 5051 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5051",
  pages="1--7",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5051.txt",
  key="RFC 5051",
  abstract={This document describes ``i;unicode-casemap'', a simple case-insensitive collation for Unicode strings.  It provides equality, substring, and ordering operations. [STANDARDS-TRACK]},
  keywords="unicode strings, i;ascii-casemap",
  doi="10.17487/RFC5051",
  }

@misc{rfc5052,
  author="M. Watson and M. Luby and L. Vicisano",
  title="{Forward Error Correction (FEC) Building Block}",
  howpublished="RFC 5052 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5052",
  pages="1--25",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5052.txt",
  key="RFC 5052",
  abstract={This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast.  This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information.  Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered.  The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.  The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined.  The companion document titled ``The Use of Forward Error Correction (FEC) in Reliable Multicast'' describes some applications of FEC codes for delivering content.  This document obsoletes RFC 3452. [STANDARDS-TRACK]},
  keywords="bulk data transfer",
  doi="10.17487/RFC5052",
  }

@misc{rfc5053,
  author="M. Luby and A. Shokrollahi and M. Watson and T. Stockhammer",
  title="{Raptor Forward Error Correction Scheme for Object Delivery}",
  howpublished="RFC 5053 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5053",
  pages="1--46",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5053.txt",
  key="RFC 5053",
  abstract={This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]},
  keywords="fec, fec encoding, raptor code",
  doi="10.17487/RFC5053",
  }

@misc{rfc5054,
  author="D. Taylor and T. Wu and N. Mavrogiannopoulos and T. Perrin",
  title="{Using the Secure Remote Password (SRP) Protocol for TLS Authentication}",
  howpublished="RFC 5054 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5054",
  pages="1--24",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5054.txt",
  key="RFC 5054",
  abstract={This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol.  This memo provides information for the Internet community.},
  keywords="secure remote password protocol, transport layer security",
  doi="10.17487/RFC5054",
  }

@misc{rfc5055,
  author="T. Freeman and R. Housley and A. Malpani and D. Cooper and W. Polk",
  title="{Server-Based Certificate Validation Protocol (SCVP)}",
  howpublished="RFC 5055 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5055",
  pages="1--88",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5055.txt",
  key="RFC 5055",
  abstract={The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server.  The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors.  It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]},
  keywords="certification path construction, certification path validation",
  doi="10.17487/RFC5055",
  }

@misc{rfc5056,
  author="N. Williams",
  title="{On the Use of Channel Bindings to Secure Channels}",
  howpublished="RFC 5056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5056",
  pages="1--23",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5056.txt",
  key="RFC 5056",
  abstract={The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5056",
  }

@misc{rfc5057,
  author="R. Sparks",
  title="{Multiple Dialog Usages in the Session Initiation Protocol}",
  howpublished="RFC 5057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5057",
  pages="1--26",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5057.txt",
  key="RFC 5057",
  abstract={Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.},
  doi="10.17487/RFC5057",
  }

@misc{rfc5058,
  author="R. Boivie and N. Feldman and Y. Imai and W. Livens and D. Ooms",
  title="{Explicit Multicast (Xcast) Concepts and Options}",
  howpublished="RFC 5058 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5058",
  pages="1--35",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5058.txt",
  key="RFC 5058",
  abstract={While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.},
  keywords="explicit multi-unicast",
  doi="10.17487/RFC5058",
  }

@misc{rfc5059,
  author="N. Bhaskar and A. Gall and J. Lingard and S. Venaas",
  title="{Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)}",
  howpublished="RFC 5059 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5059",
  pages="1--42",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5059.txt",
  key="RFC 5059",
  abstract={This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group.  BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function.  The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]},
  keywords="rendezvous point, rp, multicast router",
  doi="10.17487/RFC5059",
  }

@misc{rfc5060,
  author="R. Sivaramu and J. Lingard and D. McWalter and B. Joshi and A. Kessler",
  title="{Protocol Independent Multicast MIB}",
  howpublished="RFC 5060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5060",
  pages="1--90",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5060.txt",
  key="RFC 5060",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode).  This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap.  This document does not obsolete RFC 2934. [STANDARDS-TRACK]},
  keywords="PIM, PIM-SM, BIDIR-PIM, PIM-DM, Multicast Routing, PIM-STD-MIB, management information base",
  doi="10.17487/RFC5060",
  }

@misc{rfc5061,
  author="R. Stewart and Q. Xie and M. Tuexen and S. Maruyama and M. Kozuka",
  title="{Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration}",
  howpublished="RFC 5061 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5061",
  pages="1--41",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5061.txt",
  key="RFC 5061",
  abstract={A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures.  Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures.  This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5061",
  }

@misc{rfc5062,
  author="R. Stewart and M. Tuexen and G. Camarillo",
  title="{Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures}",
  howpublished="RFC 5062 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5062",
  pages="1--14",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5062.txt",
  key="RFC 5062",
  abstract={This document describes certain security threats to SCTP.  It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460).  These techniques are included in RFC 4960, which obsoletes RFC 2960.  It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5062",
  }

@misc{rfc5063,
  author="A. Satyanarayana and R. Rahman",
  title="{Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart}",
  howpublished="RFC 5063 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5063",
  pages="1--24",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5063.txt",
  key="RFC 5063",
  abstract={This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. These extensions are not used to create or restore data plane state. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]},
  keywords="nodal faults, rsvp hello, state recovery",
  doi="10.17487/RFC5063",
  }

@misc{rfc5064,
  author="M. Duerst",
  title="{The Archived-At Message Header Field}",
  howpublished="RFC 5064 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5064",
  pages="1--10",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5064.txt",
  key="RFC 5064",
  abstract={This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5064",
  }

@misc{rfc5065,
  author="P. Traina and D. McPherson and J. Scudder",
  title="{Autonomous System Confederations for BGP}",
  howpublished="RFC 5065 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5065",
  pages="1--14",
  year=2007,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5065.txt",
  key="RFC 5065",
  abstract={The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the ``full mesh'' requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. This document obsoletes RFC 3065. [STANDARDS-TRACK]},
  keywords="border gateway protocol, tcp/ip, full mesh",
  doi="10.17487/RFC5065",
  }

@misc{rfc5066,
  author="E. Beili",
  title="{Ethernet in the First Mile Copper (EFMCu) Interfaces MIB}",
  howpublished="RFC 5066 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5066",
  pages="1--90",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7124",
url="https://www.rfc-editor.org/rfc/rfc5066.txt",
  key="RFC 5066",
  abstract={This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.  This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005).  In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, MIB, Textual Conventions, 2BASE-TL, 10PASS-TS, 802.3ah, EFM, PAF, PME",
  doi="10.17487/RFC5066",
  }

@misc{rfc5067,
  author="S. Lind and P. Pfautz",
  title="{Infrastructure ENUM Requirements}",
  howpublished="RFC 5067 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5067",
  pages="1--7",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5067.txt",
  key="RFC 5067",
  abstract={This document provides requirements for ``infrastructure'' or ``carrier'' ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.},
  keywords="e.164 number mapping, carrier",
  doi="10.17487/RFC5067",
  }

@misc{rfc5068,
  author="C. Hutzler and D. Crocker and P. Resnick and E. Allman and T. Finch",
  title="{Email Submission Operations: Access and Accountability Requirements}",
  howpublished="RFC 5068 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5068",
  pages="1--12",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5068.txt",
  key="RFC 5068",
  abstract={Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services. Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="spam, email abuse, phishing, email, e-mail, service, mime, rfc2822, rfc 2822, rfc822, rfc 822, rfc2821, rfc 2821, rfc821, rfc 821, architecture, mta, mua, msa, mda, user, delivery, relay, header, gateway agent, sieve, dsn, mdn, tussle, mhs, mail handling service, message transfer agent, message user agent, mail submission agent, mail delivery agent",
  doi="10.17487/RFC5068",
  }

@misc{rfc5069,
  author="T. Taylor and H. Tschofenig and H. Schulzrinne and M. Shanmugam",
  title="{Security Threats and Requirements for Emergency Call Marking and Mapping}",
  howpublished="RFC 5069 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5069",
  pages="1--12",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5069.txt",
  key="RFC 5069",
  abstract={This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.},
  keywords="ecrit, public safety answering points, pasp",
  doi="10.17487/RFC5069",
  }

@misc{rfc5070,
  author="R. Danyliw and J. Meijer and Y. Demchenko",
  title="{The Incident Object Description Exchange Format}",
  howpublished="RFC 5070 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5070",
  pages="1--92",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7970, updated by RFC 6685",
url="https://www.rfc-editor.org/rfc/rfc5070.txt",
  key="RFC 5070",
  abstract={The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents.  This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]},
  keywords="incident data format, compuer security incident, computer security incident response team, csirt, cert, security data sharing, computer network defense service provider, cndsp",
  doi="10.17487/RFC5070",
  }

@misc{rfc5071,
  author="D. Hankins",
  title="{Dynamic Host Configuration Protocol Options Used by PXELINUX}",
  howpublished="RFC 5071 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5071",
  pages="1--14",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5071.txt",
  key="RFC 5071",
  abstract={This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211.  This memo provides information for the Internet community.},
  keywords="dhcp, dhcp option codes",
  doi="10.17487/RFC5071",
  }

@misc{rfc5072,
  author="S. Varada and D. Haskins and E. Allen",
  title="{IP Version 6 over PPP}",
  howpublished="RFC 5072 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5072",
  pages="1--16",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc5072.txt",
  key="RFC 5072",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. This document obsoletes RFC 2472. [STANDARDS-TRACK]},
  keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6",
  doi="10.17487/RFC5072",
  }

@misc{rfc5073,
  author="J.P. Vasseur and J.L. Le Roux",
  title="{IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities}",
  howpublished="RFC 5073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5073",
  pages="1--13",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5073.txt",
  key="RFC 5073",
  abstract={It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP.  This requires advertising these capabilities within the Interior Gateway Protocol (IGP).  For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]},
  keywords="interior gateway protocol",
  doi="10.17487/RFC5073",
  }

@misc{rfc5074,
  author="S. Weiler",
  title="{DNSSEC Lookaside Validation (DLV)}",
  howpublished="RFC 5074 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5074",
  pages="1--11",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5074.txt",
  key="RFC 5074",
  abstract={DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain.  It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children.  This memo provides information for the Internet community.},
  keywords="dns security, trust anchors",
  doi="10.17487/RFC5074",
  }

@misc{rfc5075,
  author="B. Haberman and R. Hinden",
  title="{IPv6 Router Advertisement Flags Option}",
  howpublished="RFC 5075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5075",
  pages="1--7",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5175",
url="https://www.rfc-editor.org/rfc/rfc5075.txt",
  key="RFC 5075",
  abstract={The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags.  Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field.  This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]},
  keywords="neighbor discovery protocol, ndp, expanded flags option, efo, ndp  router advertisement message",
  doi="10.17487/RFC5075",
  }

@misc{rfc5076,
  author="B. Hoeneisen",
  title="{ENUM Validation Information Mapping for the Extensible Provisioning Protocol}",
  howpublished="RFC 5076 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5076",
  pages="1--24",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5076.txt",
  key="RFC 5076",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on.  Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]},
  keywords="epp, validation process, e.164, enum, enum domain name",
  doi="10.17487/RFC5076",
  }

@misc{rfc5077,
  author="J. Salowey and H. Zhou and P. Eronen and H. Tschofenig",
  title="{Transport Layer Security (TLS) Session Resumption without Server-Side State}",
  howpublished="RFC 5077 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5077",
  pages="1--20",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5077.txt",
  key="RFC 5077",
  abstract={This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained ticket.  This document obsoletes RFC 4507. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5077",
  }

@misc{rfc5078,
  author="S. Dawkins",
  title="{IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline}",
  howpublished="RFC 5078 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5078",
  pages="1--9",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7437",
url="https://www.rfc-editor.org/rfc/rfc5078.txt",
  key="RFC 5078",
  abstract={RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process.  Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier.  This document restructures the sample timeline, but makes no normative process changes.  This memo provides information for the Internet community.},
  keywords="Internet Architecture Board, Engineering Steering Group, nomcom",
  doi="10.17487/RFC5078",
  }

@misc{rfc5079,
  author="J. Rosenberg",
  title="{Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5079 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5079",
  pages="1--8",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5079.txt",
  key="RFC 5079",
  abstract={The Session Initiation Protocol (SIP) allows for users to make anonymous calls.  However, users receiving such calls have the right to reject them because they are anonymous.  SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous.  Such an indication is useful to allow the call to be retried without anonymity.  This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]},
  keywords="anonymous calls",
  doi="10.17487/RFC5079",
  }

@misc{rfc5080,
  author="D. Nelson and A. DeKok",
  title="{Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes}",
  howpublished="RFC 5080 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5080",
  pages="1--28",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5080.txt",
  key="RFC 5080",
  abstract={This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes.  Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5080",
  }

@misc{rfc5081,
  author="N. Mavrogiannopoulos",
  title="{Using OpenPGP Keys for Transport Layer Security (TLS) Authentication}",
  howpublished="RFC 5081 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5081",
  pages="1--8",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6091",
url="https://www.rfc-editor.org/rfc/rfc5081.txt",
  key="RFC 5081",
  abstract={This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format.  The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="tls handshake protocol, handshake",
  doi="10.17487/RFC5081",
  }

@misc{rfc5082,
  author="V. Gill and J. Heasley and D. Meyer and P. Savola and C. Pignataro",
  title="{The Generalized TTL Security Mechanism (GTSM)}",
  howpublished="RFC 5082 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5082",
  pages="1--16",
  year=2007,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5082.txt",
  key="RFC 5082",
  abstract={The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols.  This document generalizes this technique.  This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]},
  keywords="time to live, packet hop limit",
  doi="10.17487/RFC5082",
  }

@misc{rfc5083,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type}",
  howpublished="RFC 5083 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5083",
  pages="1--10",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5083.txt",
  key="RFC 5083",
  abstract={This document describes an additional content type for the Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data content type is intended for use with authenticated encryption modes.  All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]},
  keywords="encryption mode",
  doi="10.17487/RFC5083",
  }

@misc{rfc5084,
  author="R. Housley",
  title="{Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5084 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5084",
  pages="1--11",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5084.txt",
  key="RFC 5084",
  abstract={This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]},
  keywords="authenticated encryption algorithm",
  doi="10.17487/RFC5084",
  }

@misc{rfc5085,
  author="T. Nadeau and C. Pignataro",
  title="{Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires}",
  howpublished="RFC 5085 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5085",
  pages="1--30",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5586",
url="https://www.rfc-editor.org/rfc/rfc5085.txt",
  key="RFC 5085",
  abstract={This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel.  VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]},
  keywords="pw",
  doi="10.17487/RFC5085",
  }

@misc{rfc5086,
  author="A. Vainshtein and I. Sasson and E. Metz and T. Frost and P. Pate",
  title="{Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)}",
  howpublished="RFC 5086 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5086",
  pages="1--38",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5086.txt",
  key="RFC 5086",
  abstract={This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs).  In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553).  This memo provides information for the Internet community.},
  keywords="nxds0, psn",
  doi="10.17487/RFC5086",
  }

@misc{rfc5087,
  author="Y(J). Stein and R. Shashoua and R. Insler and M. Anavi",
  title="{Time Division Multiplexing over IP (TDMoIP)}",
  howpublished="RFC 5087 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5087",
  pages="1--50",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5087.txt",
  key="RFC 5087",
  abstract={Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs).  Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport.  Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation.  Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.  This memo provides information for the Internet community.},
  keywords="TDM, pseudowire, PWE3, TDMoIP, structure-aware TDM emulation",
  doi="10.17487/RFC5087",
  }

@misc{rfc5088,
  author="JL. Le Roux and JP. Vasseur and Y. Ikejiri and R. Zhang",
  title="{OSPF Protocol Extensions for Path Computation Element (PCE) Discovery}",
  howpublished="RFC 5088 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5088",
  pages="1--20",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5088.txt",
  key="RFC 5088",
  abstract={There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.  When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding.  For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]},
  keywords="pcc, path computation client, open shortest path first",
  doi="10.17487/RFC5088",
  }

@misc{rfc5089,
  author="JL. Le Roux and JP. Vasseur and Y. Ikejiri and R. Zhang",
  title="{IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery}",
  howpublished="RFC 5089 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5089",
  pages="1--17",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5089.txt",
  key="RFC 5089",
  abstract={There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.  When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding.  For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]},
  keywords="path computation client, pcc, intermediate system to intermediate system",
  doi="10.17487/RFC5089",
  }

@misc{rfc5090,
  author="B. Sterman and D. Sadolevsky and D. Schwartz and D. Williams and W. Beck",
  title="{RADIUS Extension for Digest Authentication}",
  howpublished="RFC 5090 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5090",
  pages="1--33",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5090.txt",
  key="RFC 5090",
  abstract={This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]},
  keywords="remote authentication dial-in user service, sip, http",
  doi="10.17487/RFC5090",
  }

@misc{rfc5091,
  author="X. Boyen and L. Martin",
  title="{Identity-Based Cryptography Standard (IBCS) \#1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems}",
  howpublished="RFC 5091 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5091",
  pages="1--63",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5091.txt",
  key="RFC 5091",
  abstract={This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption.  This document is in part based on IBCS \#1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document.  This memo provides information for the Internet community.},
  keywords="Encryption, Cryptography, Security, Elliptic Curves, Elliptic Curve Cryptography, Pairing-based Cryptography, Identity-based Cryptography, Identity-based Encryption, Boneh-Franklin Encryption Scheme, Boneh-Boyen Encryption Scheme",
  doi="10.17487/RFC5091",
  }

@misc{rfc5092,
  author="A. Melnikov and C. Newman",
  title="{IMAP URL Scheme}",
  howpublished="RFC 5092 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5092",
  pages="1--32",
  year=2007,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5593",
url="https://www.rfc-editor.org/rfc/rfc5092.txt",
  key="RFC 5092",
  abstract={IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]},
  keywords="IMAP-URL, remote access store, Internet, Message, Access, Protocol, Uniform, Resource, Identifiers",
  doi="10.17487/RFC5092",
  }

@misc{rfc5093,
  author="G. Hunt",
  title="{BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)}",
  howpublished="RFC 5093 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5093",
  pages="1--8",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5093.txt",
  key="RFC 5093",
  abstract={This document describes an RTCP XR report block, which reports packet transport parameters.  The report block was developed by BT for pre-standards use in BT's next-generation network.  This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611.  This specification does not standardise the new report block for use outside BT's network.  This memo provides information for the Internet community.},
  keywords="next-generation network, rtcp xr, real time control protocol, extended reports, transport, metrics",
  doi="10.17487/RFC5093",
  }

@misc{rfc5094,
  author="V. Devarapalli and A. Patel and K. Leung",
  title="{Mobile IPv6 Vendor Specific Option}",
  howpublished="RFC 5094 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5094",
  pages="1--7",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5094.txt",
  key="RFC 5094",
  abstract={There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes.  This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]},
  keywords="mobility header, mip6, mipv6",
  doi="10.17487/RFC5094",
  }

@misc{rfc5095,
  author="J. Abley and P. Savola and G. Neville-Neil",
  title="{Deprecation of Type 0 Routing Headers in IPv6}",
  howpublished="RFC 5095 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5095",
  pages="1--7",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5095.txt",
  key="RFC 5095",
  abstract={The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic.  This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]},
  keywords="ipv6 type 0 routing header, traffic amplification",
  doi="10.17487/RFC5095",
  }

@misc{rfc5096,
  author="V. Devarapalli",
  title="{Mobile IPv6 Experimental Messages}",
  howpublished="RFC 5096 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5096",
  pages="1--7",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5096.txt",
  key="RFC 5096",
  abstract={This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]},
  keywords="mip6, mobility header, mobility option, mipv6",
  doi="10.17487/RFC5096",
  }

@misc{rfc5097,
  author="G. Renker and G. Fairhurst",
  title="{MIB for the UDP-Lite protocol}",
  howpublished="RFC 5097 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5097",
  pages="1--23",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5097.txt",
  key="RFC 5097",
  abstract={This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite).  It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite.  UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option.  This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]},
  keywords="SMIv2, UDPLITE-MIB, management information base, lightweight user datagram protocol",
  doi="10.17487/RFC5097",
  }

@misc{rfc5098,
  author="G. Beacham and S. Kumar and S. Channabasappa",
  title="{Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)}",
  howpublished="RFC 5098 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5098",
  pages="1--79",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5098.txt",
  key="RFC 5098",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]},
  keywords="PKTC-IETF-SIG-MIB, snmp, simple network management protocol, packetcable-compliant, ipcablecom-compliant",
  doi="10.17487/RFC5098",
  }

@misc{rfc5101,
  author="B. Claise",
  title="{Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information}",
  howpublished="RFC 5101 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5101",
  pages="1--63",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7011",
url="https://www.rfc-editor.org/rfc/rfc5101.txt",
  key="RFC 5101",
  abstract={This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network.  In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]},
  keywords="exporting process, collecting process, template records",
  doi="10.17487/RFC5101",
  }

@misc{rfc5102,
  author="J. Quittek and S. Bryant and B. Claise and P. Aitken and J. Meyer",
  title="{Information Model for IP Flow Information Export}",
  howpublished="RFC 5102 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5102",
  pages="1--171",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7012, updated by RFC 6313",
url="https://www.rfc-editor.org/rfc/rfc5102.txt",
  key="RFC 5102",
  abstract={This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]},
  keywords="ipfix, ip flow information export protocol, measured traffic, observation point, metering process, exporting process",
  doi="10.17487/RFC5102",
  }

@misc{rfc5103,
  author="B. Trammell and E. Boschi",
  title="{Bidirectional Flow Export Using IP Flow Information Export (IPFIX)}",
  howpublished="RFC 5103 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5103",
  pages="1--24",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5103.txt",
  key="RFC 5103",
  abstract={This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]},
  keywords="flow record, biflow",
  doi="10.17487/RFC5103",
  }

@misc{rfc5104,
  author="S. Wenger and U. Chandra and M. Westerlund and B. Burman",
  title="{Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)}",
  howpublished="RFC 5104 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5104",
  pages="1--64",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7728, 8082",
url="https://www.rfc-editor.org/rfc/rfc5104.txt",
  key="RFC 5104",
  abstract={This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]},
  keywords="real time protocol, real-time protocol, , itu-t rec. h271, video back channel, full intra request, temporary maximum media stream bit rate, temporal-spatial trade-off",
  doi="10.17487/RFC5104",
  }

@misc{rfc5105,
  author="O. Lendl",
  title="{ENUM Validation Token Format Definition}",
  howpublished="RFC 5105 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5105",
  pages="1--17",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5105.txt",
  key="RFC 5105",
  abstract={An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ``validation''.  This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]},
  keywords="telephone number mapping, e.164",
  doi="10.17487/RFC5105",
  }

@misc{rfc5106,
  author="H. Tschofenig and D. Kroeselberg and A. Pashalidis and Y. Ohba and F. Bersani",
  title="{The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method}",
  howpublished="RFC 5106 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5106",
  pages="1--33",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5106.txt",
  key="RFC 5106",
  abstract={This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol.  EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server.  It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates.  EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional ``fast reconnect'' mode.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="cryptographic ciphersuite negotiation, hash function agility, identity confidentiality, fragmentation, fast reconnect mode",
  doi="10.17487/RFC5106",
  }

@misc{rfc5107,
  author="R. Johnson and J. Kumarasamy and K. Kinnear and M. Stapp",
  title="{DHCP Server Identifier Override Suboption}",
  howpublished="RFC 5107 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5107",
  pages="1--7",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5107.txt",
  key="RFC 5107",
  abstract={This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server.  This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly.  This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]},
  keywords="xml, extensible markup langauge, dynamic host configuration protocol, RENEW DHCPREQUEST, DHCP RENEW",
  doi="10.17487/RFC5107",
  }

@misc{rfc5109,
  author="A. Li",
  title="{RTP Payload Format for Generic Forward Error Correction}",
  howpublished="RFC 5109 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5109",
  pages="1--44",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5109.txt",
  key="RFC 5109",
  abstract={This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP.  It is based on the exclusive-or (parity) operation.  The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics.  It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation.  This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data.  This specification obsoletes RFC 2733 and RFC 3009.  The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]},
  keywords="fec, realtime transport protocol",
  doi="10.17487/RFC5109",
  }

@misc{rfc5110,
  author="P. Savola",
  title="{Overview of the Internet Multicast Routing Architecture}",
  howpublished="RFC 5110 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5110",
  pages="1--25",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5110.txt",
  key="RFC 5110",
  abstract={This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications. This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.},
  keywords="RFC 3913, RFC 2189, RFC 2201, RFC 1584",
  doi="10.17487/RFC5110",
  }

@misc{rfc5111,
  author="B. Aboba and L. Dondeti",
  title="{Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)}",
  howpublished="RFC 5111 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5111",
  pages="1--8",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5111.txt",
  key="RFC 5111",
  abstract={This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group.  Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation.  Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="working group formation, bof, birds of a feather",
  doi="10.17487/RFC5111",
  }

@misc{rfc5112,
  author="M. Garcia-Martin",
  title="{The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)}",
  howpublished="RFC 5112 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5112",
  pages="1--25",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5112.txt",
  key="RFC 5112",
  abstract={The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions.  The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events.  One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents.  SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates.  However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents.  This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency.  The dictionary is compression-algorithm independent. [STANDARDS-TRACK]},
  keywords="communication session, event notification, presence",
  doi="10.17487/RFC5112",
  }

@misc{rfc5113,
  author="J. Arkko and B. Aboba and J. Korhonen and F. Bari",
  title="{Network Discovery and Selection Problem}",
  howpublished="RFC 5113 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5113",
  pages="1--39",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5113.txt",
  key="RFC 5113",
  abstract={When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network.  This document defines the network discovery and selection problem, dividing it into multiple sub- problems.  Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5113",
  }

@misc{rfc5114,
  author="M. Lepinski and S. Kent",
  title="{Additional Diffie-Hellman Groups for Use with IETF Standards}",
  howpublished="RFC 5114 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5114",
  pages="1--23",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5114.txt",
  key="RFC 5114",
  abstract={This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE). All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography. These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.},
  keywords="elliptic curve, ike, tls, ssh, smime, x.509",
  doi="10.17487/RFC5114",
  }

@misc{rfc5115,
  author="K. Carlberg and P. O'Hanlon",
  title="{Telephony Routing over IP (TRIP) Attribute for Resource Priority}",
  howpublished="RFC 5115 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5115",
  pages="1--8",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5115.txt",
  key="RFC 5115",
  abstract={This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol.  The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway.  Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S.  and Government Telephone Preference Scheme (GTPS) in the U.K.  The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]},
  keywords="ip telephony, ResourcePriority",
  doi="10.17487/RFC5115",
  }

@misc{rfc5116,
  author="D. McGrew",
  title="{An Interface and Algorithms for Authenticated Encryption}",
  howpublished="RFC 5116 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5116",
  pages="1--22",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5116.txt",
  key="RFC 5116",
  abstract={This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]},
  keywords="Encryption, Authentication, AEAD, authenticated encryption with associated data",
  doi="10.17487/RFC5116",
  }

@misc{rfc5117,
  author="M. Westerlund and S. Wenger",
  title="{RTP Topologies}",
  howpublished="RFC 5117 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5117",
  pages="1--21",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7667",
url="https://www.rfc-editor.org/rfc/rfc5117.txt",
  key="RFC 5117",
  abstract={This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments.  In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.  This memo provides information for the Internet community.},
  keywords="multi-endpoint topologies, real-time transport protocol",
  doi="10.17487/RFC5117",
  }

@misc{rfc5118,
  author="V. Gurbani and C. Boulton and R. Sparks",
  title="{Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)}",
  howpublished="RFC 5118 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5118",
  pages="1--18",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5118.txt",
  key="RFC 5118",
  abstract={This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and ``torture'' the code of an IPv6-enabled SIP implementation.  This memo provides information for the Internet community.},
  keywords="Torture test, IPv6, SIP",
  doi="10.17487/RFC5118",
  }

@misc{rfc5119,
  author="T. Edwards",
  title="{A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)}",
  howpublished="RFC 5119 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5119",
  pages="1--9",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5119.txt",
  key="RFC 5119",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages.  A subnamespace for Universal Labels is specifically described.  This memo provides information for the Internet community.},
  keywords="persistent resources, universal labels,",
  doi="10.17487/RFC5119",
  }

@misc{rfc5120,
  author="T. Przygienda and N. Shen and N. Sheth",
  title="{M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)}",
  howpublished="RFC 5120 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5120",
  pages="1--14",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5120.txt",
  key="RFC 5120",
  abstract={This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds.  This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs).  This MT extension can be used for a variety of purposes, such as an in-band management network ``on top'' of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]},
  keywords="is-is",
  doi="10.17487/RFC5120",
  }

@misc{rfc5121,
  author="B. Patil and F. Xia and B. Sarikaya and JH. Choi and S. Madanapalli",
  title="{Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks}",
  howpublished="RFC 5121 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5121",
  pages="1--22",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8064",
url="https://www.rfc-editor.org/rfc/rfc5121.txt",
  key="RFC 5121",
  abstract={IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems.  Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control).  The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet).  IPv6 packets can be sent and received via the IP-specific part of the Packet CS.  This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface.  It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]},
  keywords="Neighbor Discovery, Per-MS Perfix",
  doi="10.17487/RFC5121",
  }

@misc{rfc5122,
  author="P. Saint-Andre",
  title="{Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 5122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5122",
  pages="1--26",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5122.txt",
  key="RFC 5122",
  abstract={This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]},
  keywords="Extensible Messaging and Presence Protocol, Internationalized Resource Identifier, Uniform Resource Identifier, Jabber, xmpp, iri, uri",
  doi="10.17487/RFC5122",
  }

@misc{rfc5123,
  author="R. White and B. Akyol",
  title="{Considerations in Validating the Path in BGP}",
  howpublished="RFC 5123 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5123",
  pages="1--16",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5123.txt",
  key="RFC 5123",
  abstract={This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path.  This memo provides information for the Internet community.},
  keywords="bgp autonomous system path, bgp as path",
  doi="10.17487/RFC5123",
  }

@misc{rfc5124,
  author="J. Ott and E. Carrara",
  title="{Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)}",
  howpublished="RFC 5124 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5124",
  pages="1--18",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5124.txt",
  key="RFC 5124",
  abstract={An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively.  This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]},
  keywords="avpf, rtp communication",
  doi="10.17487/RFC5124",
  }

@misc{rfc5125,
  author="T. Taylor",
  title="{Reclassification of RFC 3525 to Historic}",
  howpublished="RFC 5125 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5125",
  pages="1--4",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5125.txt",
  key="RFC 5125",
  abstract={This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status.  This memo also obsoletes RFC 3525.  This memo provides information for the Internet community.},
  keywords="MEGACO, H.248, media, gateway, control",
  doi="10.17487/RFC5125",
  }

@misc{rfc5126,
  author="D. Pinkas and N. Pope and J. Ross",
  title="{CMS Advanced Electronic Signatures (CAdES)}",
  howpublished="RFC 5126 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5126",
  pages="1--141",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5126.txt",
  key="RFC 5126",
  abstract={This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature. The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined. The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it. The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.},
  keywords="verifying party, signer, purchase, contract, invoice, application, smart cards, data",
  doi="10.17487/RFC5126",
  }

@misc{rfc5127,
  author="K. Chan and J. Babiarz and F. Baker",
  title="{Aggregation of Diffserv Service Classes}",
  howpublished="RFC 5127 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5127",
  pages="1--19",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5127.txt",
  key="RFC 5127",
  abstract={In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network.  Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications.  However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes.  In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment.  This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments.  This memo provides information for the Internet community.},
  keywords="Treatment Aggregate, forwarding treatment",
  doi="10.17487/RFC5127",
  }

@misc{rfc5128,
  author="P. Srisuresh and B. Ford and D. Kegel",
  title="{State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)}",
  howpublished="RFC 5128 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5128",
  pages="1--32",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5128.txt",
  key="RFC 5128",
  abstract={This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time.  Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described.  This memo covers NAT traversal approaches used by both TCP- and UDP-based applications.  This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5128",
  }

@misc{rfc5129,
  author="B. Davie and B. Briscoe and J. Tay",
  title="{Explicit Congestion Marking in MPLS}",
  howpublished="RFC 5129 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5129",
  pages="1--21",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5462",
url="https://www.rfc-editor.org/rfc/rfc5129.txt",
  key="RFC 5129",
  abstract={RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header.  DSCPs may be encoded in the EXP field, while other uses of that field are not precluded.  RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header.  This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]},
  keywords="Diffserv, Differentiated Services, QOS, ECN tunnel",
  doi="10.17487/RFC5129",
  }

@misc{rfc5130,
  author="S. Previdi and M. Shand and C. Martin",
  title="{A Policy Control Mechanism in IS-IS Using Administrative Tags}",
  howpublished="RFC 5130 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5130",
  pages="1--8",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5130.txt",
  key="RFC 5130",
  abstract={This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain.  This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use.  This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]},
  keywords="intermediate systetm to intermediate system, ip prefix distribution, lsp, link state protocol",
  doi="10.17487/RFC5130",
  }

@misc{rfc5131,
  author="D. McWalter",
  title="{A MIB Textual Convention for Language Tags}",
  howpublished="RFC 5131 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5131",
  pages="1--6",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5131.txt",
  key="RFC 5131",
  abstract={This MIB module defines a textual convention to represent BCP 47 language tags.  The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]},
  keywords="LANGTAG-TC-MIB",
  doi="10.17487/RFC5131",
  }

@misc{rfc5132,
  author="D. McWalter and D. Thaler and A. Kessler",
  title="{IP Multicast MIB}",
  howpublished="RFC 5132 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5132",
  pages="1--59",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5132.txt",
  key="RFC 5132",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use.  This document obsoletes RFC 2932. [STANDARDS-TRACK]},
  keywords="managament information base, IPMCAST-MIB,",
  doi="10.17487/RFC5132",
  }

@misc{rfc5133,
  author="M. Tuexen and K. Morneault",
  title="{Terminal Endpoint Identifier (TEI) Query Request Number Change}",
  howpublished="RFC 5133 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5133",
  pages="1--4",
  year=2007,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5133.txt",
  key="RFC 5133",
  abstract={The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5.  However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.  This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]},
  keywords="isdn q.921-user adaptation layer, iua",
  doi="10.17487/RFC5133",
  }

@misc{rfc5134,
  author="M. Mealling",
  title="{A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards}",
  howpublished="RFC 5134 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5134",
  pages="1--10",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5134.txt",
  key="RFC 5134",
  abstract={This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications.  This memo provides information for the Internet community.},
  keywords="uniform resource name, Auto-ID, RFID, EPCglobal, EPC, UPC, supply chain management, bar code",
  doi="10.17487/RFC5134",
  }

@misc{rfc5135,
  author="D. Wing and T. Eckert",
  title="{IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)}",
  howpublished="RFC 5135 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5135",
  pages="1--16",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5135.txt",
  key="RFC 5135",
  abstract={This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast.  An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="multicast application, multicast nat",
  doi="10.17487/RFC5135",
  }

@misc{rfc5136,
  author="P. Chimento and J. Ishac",
  title="{Defining Network Capacity}",
  howpublished="RFC 5136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5136",
  pages="1--14",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5136.txt",
  key="RFC 5136",
  abstract={Measuring capacity is a task that sounds simple, but in reality can be quite complex.  In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs.  This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network.  By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques.  This memo provides information for the Internet community.},
  keywords="bandwidth, bandwidth estimation, capacity estimation, link capacity, available capacity, narrow link, tight link",
  doi="10.17487/RFC5136",
  }

@misc{rfc5137,
  author="J. Klensin",
  title="{ASCII Escaping of Unicode Characters}",
  howpublished="RFC 5137 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5137",
  pages="1--13",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5137.txt",
  key="RFC 5137",
  abstract={There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly.  With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways.  The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes.  This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Text, internationalization, ascii, unicode, utf-8, encoding",
  doi="10.17487/RFC5137",
  }

@misc{rfc5138,
  author="S. Cox",
  title="{A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI)}",
  howpublished="RFC 5138 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5138",
  pages="1--8",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5138.txt",
  key="RFC 5138",
  abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI.  The formal Namespace Identifier (NID) is ``cgi''.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5138",
  }

@misc{rfc5139,
  author="M. Thomson and J. Winterbottom",
  title="{Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)}",
  howpublished="RFC 5139 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5139",
  pages="1--14",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5139.txt",
  key="RFC 5139",
  abstract={This document defines an XML format for the representation of civic location.  This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119.  The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes.  The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]},
  keywords="location, civic location, pidf-lo, civic address",
  doi="10.17487/RFC5139",
  }

@misc{rfc5140,
  author="M. Bangalore and R. Kumar and J. Rosenberg and H. Salama and D.N. Shah",
  title="{A Telephony Gateway REgistration Protocol (TGREP)}",
  howpublished="RFC 5140 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5140",
  pages="1--28",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5140.txt",
  key="RFC 5140",
  abstract={This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches.  The registration mechanism can also be used to export resource information.  The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs).  TGREP shares a lot of similarities with the TRIP protocol.  It has similar procedures and finite state machine for session establishment.  It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]},
  keywords="telephony prefix, soft switches, telephony routing over ip, trip, internet telephony administrative domains, itad",
  doi="10.17487/RFC5140",
  }

@misc{rfc5141,
  author="J. Goodwin and H. Apel",
  title="{A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)}",
  howpublished="RFC 5141 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5141",
  pages="1--28",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5141.txt",
  key="RFC 5141",
  abstract={This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO).  This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources).  This memo provides information for the Internet community.},
  keywords="urn nid, uniform resource name namespace identification, NSS",
  doi="10.17487/RFC5141",
  }

@misc{rfc5142,
  author="B. Haley and V. Devarapalli and H. Deng and J. Kempf",
  title="{Mobility Header Home Agent Switch Message}",
  howpublished="RFC 5142 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5142",
  pages="1--13",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5142.txt",
  key="RFC 5142",
  abstract={This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5142",
  }

@misc{rfc5143,
  author="A. Malis and J. Brayley and J. Shirron and L. Martini and S. Vogelsang",
  title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation}",
  howpublished="RFC 5143 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5143",
  pages="1--24",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 4842",
url="https://www.rfc-editor.org/rfc/rfc5143.txt",
  key="RFC 5143",
  abstract={This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs).  The PSNs explicitly supported by this document include MPLS and IP.  Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired.  This memo defines a Historic Document for the Internet community.},
  keywords="psn, packet switched network, RFC4842",
  doi="10.17487/RFC5143",
  }

@misc{rfc5144,
  author="A. Newton and M. Sanz",
  title="{A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)}",
  howpublished="RFC 5144 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5144",
  pages="1--17",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5144.txt",
  key="RFC 5144",
  abstract={This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]},
  keywords="dreg, iris domain registry",
  doi="10.17487/RFC5144",
  }

@misc{rfc5145,
  author="K. Shiomoto",
  title="{Framework for MPLS-TE to GMPLS Migration}",
  howpublished="RFC 5145 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5145",
  pages="1--19",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5145.txt",
  key="RFC 5145",
  abstract={The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy. This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.},
  keywords="multiprotocol label switching traffic engineering, control plane",
  doi="10.17487/RFC5145",
  }

@misc{rfc5146,
  author="K. Kumaki",
  title="{Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks}",
  howpublished="RFC 5146 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5146",
  pages="1--15",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5146.txt",
  key="RFC 5146",
  abstract={Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer). The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP. This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.},
  keywords="multiprotocol label switching traffic engineering, service provider requirements",
  doi="10.17487/RFC5146",
  }

@misc{rfc5147,
  author="E. Wilde and M. Duerst",
  title="{URI Fragment Identifiers for the text/plain Media Type}",
  howpublished="RFC 5147 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5147",
  pages="1--17",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5147.txt",
  key="RFC 5147",
  abstract={This memo defines URI fragment identifiers for text/plain MIME entities.  These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range.  Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]},
  keywords="uniform resource identifier, mime entity",
  doi="10.17487/RFC5147",
  }

@misc{rfc5148,
  author="T. Clausen and C. Dearlove and B. Adamson",
  title="{Jitter Considerations in Mobile Ad Hoc Networks (MANETs)}",
  howpublished="RFC 5148 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5148",
  pages="1--12",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5148.txt",
  key="RFC 5148",
  abstract={This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions.  This memo provides information for the Internet community.},
  keywords="randomly modifying timing, control traffic transmission, tranmission collision",
  doi="10.17487/RFC5148",
  }

@misc{rfc5149,
  author="J. Korhonen and U. Nilsson and V. Devarapalli",
  title="{Service Selection for Mobile IPv6}",
  howpublished="RFC 5149 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5149",
  pages="1--9",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5149.txt",
  key="RFC 5149",
  abstract={In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription.  A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription.  This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure.  This memo provides information for the Internet community.},
  keywords="mipv6, service selection mobility option, proxy mobile ipv6, mobilty service subscription, binding registration procedure",
  doi="10.17487/RFC5149",
  }

@misc{rfc5150,
  author="A. Ayyangar and K. Kompella and JP. Vasseur and A. Farrel",
  title="{Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)}",
  howpublished="RFC 5150 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5150",
  pages="1--19",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5150.txt",
  key="RFC 5150",
  abstract={In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as ``LSP stitching'', the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as ``LSP segments'' (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]},
  keywords="lsp, label switched paths, e2e lsp, lsp stitching, lsp segments, s-lsp",
  doi="10.17487/RFC5150",
  }

@misc{rfc5151,
  author="A. Farrel and A. Ayyangar and JP. Vasseur",
  title="{Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions}",
  howpublished="RFC 5151 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5151",
  pages="1--25",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5151.txt",
  key="RFC 5151",
  abstract={This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, mpls-te",
  doi="10.17487/RFC5151",
  }

@misc{rfc5152,
  author="JP. Vasseur and A. Ayyangar and R. Zhang",
  title="{A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)}",
  howpublished="RFC 5152 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5152",
  pages="1--21",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5152.txt",
  key="RFC 5152",
  abstract={This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]},
  keywords="mpls, gmpls",
  doi="10.17487/RFC5152",
  }

@misc{rfc5153,
  author="E. Boschi and L. Mark and J. Quittek and M. Stiemerling and P. Aitken",
  title="{IP Flow Information Export (IPFIX) Implementation Guidelines}",
  howpublished="RFC 5153 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5153",
  pages="1--35",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5153.txt",
  key="RFC 5153",
  abstract={The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices.  This document provides guidelines for the implementation and use of the IPFIX protocol.  Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).  This memo provides information for the Internet community.},
  keywords="template mangaement, exporting processes, collecting processes, ipfix middleboxes",
  doi="10.17487/RFC5153",
  }

@misc{rfc5154,
  author="J. Jee and S. Madanapalli and J. Mandin",
  title="{IP over IEEE 802.16 Problem Statement and Goals}",
  howpublished="RFC 5154 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5154",
  pages="1--14",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5154.txt",
  key="RFC 5154",
  abstract={This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support.  This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers.  Common terminology used for the base guideline while defining the solution framework is also presented.  This memo provides information for the Internet community.},
  keywords="WiMAX, Mobile WiMAX, WiBro",
  doi="10.17487/RFC5154",
  }

@misc{rfc5155,
  author="B. Laurie and G. Sisson and R. Arends and D. Blacka",
  title="{DNS Security (DNSSEC) Hashed Authenticated Denial of Existence}",
  howpublished="RFC 5155 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5155",
  pages="1--52",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6840, 6944",
url="https://www.rfc-editor.org/rfc/rfc5155.txt",
  key="RFC 5155",
  abstract={The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence.  This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]},
  keywords="domain name system, nsec, resource record, nsec3",
  doi="10.17487/RFC5155",
  }

@misc{rfc5156,
  author="M. Blanchet",
  title="{Special-Use IPv6 Addresses}",
  howpublished="RFC 5156 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5156",
  pages="1--7",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6890",
url="https://www.rfc-editor.org/rfc/rfc5156.txt",
  key="RFC 5156",
  abstract={This document is a compilation of special IPv6 addresses defined in other RFCs.  It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.  It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries.  This memo provides information for the Internet community.},
  keywords="invalid routing prefix",
  doi="10.17487/RFC5156",
  }

@misc{rfc5157,
  author="T. Chown",
  title="{IPv6 Implications for Network Scanning}",
  howpublished="RFC 5157 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5157",
  pages="1--13",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7707",
url="https://www.rfc-editor.org/rfc/rfc5157.txt",
  key="RFC 5157",
  abstract={The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective.  While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them.  This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security.  This memo provides information for the Internet community.},
  keywords="subnet address space",
  doi="10.17487/RFC5157",
  }

@misc{rfc5158,
  author="G. Huston",
  title="{6to4 Reverse DNS Delegation Specification}",
  howpublished="RFC 5158 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5158",
  pages="1--12",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5158.txt",
  key="RFC 5158",
  abstract={This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file.  The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain.  In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.  This memo provides information for the Internet community.},
  keywords="dns, domain name system",
  doi="10.17487/RFC5158",
  }

@misc{rfc5159,
  author="L. Dondeti and A. Jerichow",
  title="{Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection}",
  howpublished="RFC 5159 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5159",
  pages="1--8",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5159.txt",
  key="RFC 5159",
  abstract={This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification.  This memo provides information for the Internet community.},
  keywords="SDP, IANA registration, OMA BCAST",
  doi="10.17487/RFC5159",
  }

@misc{rfc5160,
  author="P. Levis and M. Boucadair",
  title="{Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)}",
  howpublished="RFC 5160 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5160",
  pages="1--19",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5160.txt",
  key="RFC 5160",
  abstract={This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet.  It defines terminology relevant to inter-domain QoS models.  It proposes a new concept denoted by Meta-QoS-Class (MQC).  This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers.  It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet.  This memo provides information for the Internet community.},
  keywords="sls, bgp, peering, diffserv, parallel internet",
  doi="10.17487/RFC5160",
  }

@misc{rfc5161,
  author="A. Gulbrandsen and A. Melnikov",
  title="{The IMAP ENABLE Extension}",
  howpublished="RFC 5161 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5161",
  pages="1--7",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5161.txt",
  key="RFC 5161",
  abstract={Most IMAP extensions are used by the client when it wants to and the server supports it.  However, a few extensions require the server to know whether a client supports that extension.  The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC5161",
  }

@misc{rfc5162,
  author="A. Melnikov and D. Cridland and C. Wilson",
  title="{IMAP4 Extensions for Quick Mailbox Resynchronization}",
  howpublished="RFC 5162 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5162",
  pages="1--23",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7162",
url="https://www.rfc-editor.org/rfc/rfc5162.txt",
  key="RFC 5162",
  abstract={This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips.  This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC5162",
  }

@misc{rfc5163,
  author="G. Fairhurst and B. Collini-Nocker",
  title="{Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)}",
  howpublished="RFC 5163 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5163",
  pages="1--18",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5163.txt",
  key="RFC 5163",
  abstract={This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]},
  keywords="digital video broadcasting, dvb, mpeg-2 ts-concat, pdu-concat, timestamp",
  doi="10.17487/RFC5163",
  }

@misc{rfc5164,
  author="T. Melia",
  title="{Mobility Services Transport: Problem Statement}",
  howpublished="RFC 5164 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5164",
  pages="1--16",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5164.txt",
  key="RFC 5164",
  abstract={There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21.  Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa.  The protocol requirements for this signalling have both transport and security issues that must be considered.  The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF.  This document presents a problem statement for this core problem.  This memo provides information for the Internet community.},
  keywords="intelligent access selection, ip handover mechanism",
  doi="10.17487/RFC5164",
  }

@misc{rfc5165,
  author="C. Reed",
  title="{A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC)}",
  howpublished="RFC 5165 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5165",
  pages="1--7",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5165.txt",
  key="RFC 5165",
  abstract={This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC.  The formal Namespace IDentifier (NID) is ``ogc''.  This memo provides information for the Internet community.},
  keywords="location, geospatial, namespace, OGC, URN, Open Geospatial Consortium",
  doi="10.17487/RFC5165",
  }

@misc{rfc5166,
  author="S. Floyd",
  title="{Metrics for the Evaluation of Congestion Control Mechanisms}",
  howpublished="RFC 5166 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5166",
  pages="1--23",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5166.txt",
  key="RFC 5166",
  abstract={This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.},
  keywords="transport protocol, transport modeling research group, tmrg",
  doi="10.17487/RFC5166",
  }

@misc{rfc5167,
  author="M. Dolly and R. Even",
  title="{Media Server Control Protocol Requirements}",
  howpublished="RFC 5167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5167",
  pages="1--9",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5167.txt",
  key="RFC 5167",
  abstract={This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities. This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.},
  keywords="logical entities, mcp, interactive voice response, conferencing media services",
  doi="10.17487/RFC5167",
  }

@misc{rfc5168,
  author="O. Levin and R. Even and P. Hagendorf",
  title="{XML Schema for Media Control}",
  howpublished="RFC 5168 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5168",
  pages="1--10",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5168.txt",
  key="RFC 5168",
  abstract={This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors.  This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner.  New implementations are discouraged from using the method described except for backward compatibility purposes.  New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.  This memo provides information for the Internet community.},
  keywords="extensible markup language, video fast update",
  doi="10.17487/RFC5168",
  }

@misc{rfc5169,
  author="T. Clancy and M. Nakhjiri and V. Narayanan and L. Dondeti",
  title="{Handover Key Management and Re-Authentication Problem Statement}",
  howpublished="RFC 5169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5169",
  pages="1--15",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5169.txt",
  key="RFC 5169",
  abstract={This document describes the Handover Keying (HOKEY) re-authentication problem statement.  The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method.  This often causes unacceptable latency in various mobile wireless environments.  This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover.  This memo provides information for the Internet community.},
  keywords="hokey, handover key management, fast re-authentication, mobility",
  doi="10.17487/RFC5169",
  }

@misc{rfc5170,
  author="V. Roca and C. Neumann and D. Furodet",
  title="{Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes}",
  howpublished="RFC 5170 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5170",
  pages="1--33",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5170.txt",
  key="RFC 5170",
  abstract={This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission).  These systematic FEC codes belong to the well- known class of ``Low Density Parity Check'' codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]},
  keywords="LDPC, FEC",
  doi="10.17487/RFC5170",
  }

@misc{rfc5171,
  author="M. Foschiano",
  title="{Cisco Systems UniDirectional Link Detection (UDLD) Protocol}",
  howpublished="RFC 5171 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5171",
  pages="1--13",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5171.txt",
  key="RFC 5171",
  abstract={This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.},
  keywords="Ethernet, switches, LAN, IEEE, 802, spanning tree, STP, FEFI, autonegotiation",
  doi="10.17487/RFC5171",
  }

@misc{rfc5172,
  author="S. Varada",
  title="{Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol}",
  howpublished="RFC 5172 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5172",
  pages="1--7",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5172.txt",
  key="RFC 5172",
  abstract={The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP. This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]},
  keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6",
  doi="10.17487/RFC5172",
  }

@misc{rfc5173,
  author="J. Degener and P. Guenther",
  title="{Sieve Email Filtering: Body Extension}",
  howpublished="RFC 5173 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5173",
  pages="1--10",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5173.txt",
  key="RFC 5173",
  abstract={This document defines a new command for the ``Sieve'' email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]},
  keywords="search, full text, email",
  doi="10.17487/RFC5173",
  }

@misc{rfc5174,
  author="J-P. Evain",
  title="{A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU)}",
  howpublished="RFC 5174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5174",
  pages="1--8",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5174.txt",
  key="RFC 5174",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources.  Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU.  This memo provides information for the Internet community.},
  keywords="EBU, namespace, urn, broadcast, metadata, classification, schema",
  doi="10.17487/RFC5174",
  }

@misc{rfc5175,
  author="B. Haberman and R. Hinden",
  title="{IPv6 Router Advertisement Flags Option}",
  howpublished="RFC 5175 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5175",
  pages="1--7",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5175.txt",
  key="RFC 5175",
  abstract={The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags.  Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field.  This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]},
  keywords="neighbor discovery protocol, ndp, expanded flags option, efo, ndp  router advertisement message",
  doi="10.17487/RFC5175",
  }

@misc{rfc5176,
  author="M. Chiba and G. Dommety and M. Eklund and D. Mitton and B. Aboba",
  title="{Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)}",
  howpublished="RFC 5176 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5176",
  pages="1--34",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5176.txt",
  key="RFC 5176",
  abstract={This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products.  This includes support for disconnecting users and changing authorizations applicable to a user session.  This memo provides information for the Internet community.},
  keywords="user session",
  doi="10.17487/RFC5176",
  }

@misc{rfc5177,
  author="K. Leung and G. Dommety and V. Narayanan and A. Petrescu",
  title="{Network Mobility (NEMO) Extensions for Mobile IPv4}",
  howpublished="RFC 5177 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5177",
  pages="1--26",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6626",
url="https://www.rfc-editor.org/rfc/rfc5177.txt",
  key="RFC 5177",
  abstract={This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]},
  keywords="NEMOv4, Mobile Networks, Moving Networks, Mobile Router, Local Fixed Node, Prefix Table, Mobile Network Prefix, Nested Mobile Networks, Nested Network Mobility",
  doi="10.17487/RFC5177",
  }

@misc{rfc5178,
  author="N. Williams and A. Melnikov",
  title="{Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type}",
  howpublished="RFC 5178 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5178",
  pages="1--9",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5178.txt",
  key="RFC 5178",
  abstract={This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered. Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the ``domain'' which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]},
  keywords="domain-based-name, gss-domain-based-services, GSS\_C\_NT\_DOMAINBASED\_SERVICE",
  doi="10.17487/RFC5178",
  }

@misc{rfc5179,
  author="N. Williams",
  title="{Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism}",
  howpublished="RFC 5179 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5179",
  pages="1--5",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5179.txt",
  key="RFC 5179",
  abstract={This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]},
  keywords="domain-name-based, GSS\_C\_NT\_DOMAINBASED\_SERVICE",
  doi="10.17487/RFC5179",
  }

@misc{rfc5180,
  author="C. Popoviciu and A. Hamza and G. Van de Velde and D. Dugatkin",
  title="{IPv6 Benchmarking Methodology for Network Interconnect Devices}",
  howpublished="RFC 5180 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5180",
  pages="1--20",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5180.txt",
  key="RFC 5180",
  abstract={The benchmarking methodologies defined in RFC 2544 are IP version independent.  However, RFC 2544 does not address some of the specificities of IPv6.  This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices.  IPv6 transition mechanisms are outside the scope of this document.  This memo provides information for the Internet community.},
  keywords="rfc2544, ipv6, benchmarking guidelines",
  doi="10.17487/RFC5180",
  }

@misc{rfc5181,
  author="M-K. Shin and Y-H. Han and S-E. Kim and D. Premec",
  title="{IPv6 Deployment Scenarios in 802.16 Networks}",
  howpublished="RFC 5181 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5181",
  pages="1--16",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5181.txt",
  key="RFC 5181",
  abstract={This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services.  In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies.  This memo provides information for the Internet community.},
  keywords="Ethernet CS (Convergence Sublayer), IPv6 CS (Convergence Sublayer)",
  doi="10.17487/RFC5181",
  }

@misc{rfc5182,
  author="A. Melnikov",
  title="{IMAP Extension for Referencing the Last SEARCH Result}",
  howpublished="RFC 5182 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5182",
  pages="1--13",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5182.txt",
  key="RFC 5182",
  abstract={Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations. This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]},
  keywords="uid, unique identifier, searchres, internet message access protocol",
  doi="10.17487/RFC5182",
  }

@misc{rfc5183,
  author="N. Freed",
  title="{Sieve Email Filtering: Environment Extension}",
  howpublished="RFC 5183 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5183",
  pages="1--10",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5183.txt",
  key="RFC 5183",
  abstract={This document describes the ``environment'' extension to the Sieve email filtering language.  The ``environment'' extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]},
  keywords="vnd",
  doi="10.17487/RFC5183",
  }

@misc{rfc5184,
  author="F. Teraoka and K. Gogo and K. Mitsuya and R. Shibui and K. Mitani",
  title="{Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover}",
  howpublished="RFC 5184 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5184",
  pages="1--29",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5184.txt",
  key="RFC 5184",
  abstract={This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers.  For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers.  However, each protocol layer is basically designed independently.  Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.  This document defines nine kinds of L2 abstractions in the form of ``primitives'' to achieve fast handovers in the network layer as a means of solving the problem.  This mechanism is called ``L3-driven fast handovers'' because the network layer initiates L2 and L3 handovers by using the primitives.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="l2 triggers, primitives, l3-driven fast handover, ip mobility optimizations, mobopts",
  doi="10.17487/RFC5184",
  }

@misc{rfc5185,
  author="S. Mirtorabi and P. Psenak and A. Lindem and A. Oswal",
  title="{OSPF Multi-Area Adjacency}",
  howpublished="RFC 5185 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5185",
  pages="1--11",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5185.txt",
  key="RFC 5185",
  abstract={This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas.  This is necessary to allow the link to be considered an intra-area link in multiple areas.  This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]},
  keywords="open shortest path first, inter-area, intra-area path",
  doi="10.17487/RFC5185",
  }

@misc{rfc5186,
  author="B. Haberman and J. Martin",
  title="{Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction}",
  howpublished="RFC 5186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5186",
  pages="1--6",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5186.txt",
  key="RFC 5186",
  abstract={The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols.  The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information.  This document describes how multicast routing protocols will interact with these source-filtering group management protocols.  This memo provides information for the Internet community.},
  keywords="source information, source-filtering group management",
  doi="10.17487/RFC5186",
  }

@misc{rfc5187,
  author="P. Pillay-Esnault and A. Lindem",
  title="{OSPFv3 Graceful Restart}",
  howpublished="RFC 5187 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5187",
  pages="1--7",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5187.txt",
  key="RFC 5187",
  abstract={This document describes the OSPFv3 graceful restart.  The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document.  These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]},
  keywords="open shortest path first",
  doi="10.17487/RFC5187",
  }

@misc{rfc5188,
  author="H. Desineni and Q. Xie",
  title="{RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec}",
  howpublished="RFC 5188 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5188",
  pages="1--25",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5188.txt",
  key="RFC 5188",
  abstract={This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec.  Several media type registrations are included for EVRC-WB RTP payload formats.  In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]},
  doi="10.17487/RFC5188",
  }

@misc{rfc5189,
  author="M. Stiemerling and J. Quittek and T. Taylor",
  title="{Middlebox Communication (MIDCOM) Protocol Semantics}",
  howpublished="RFC 5189 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5189",
  pages="1--70",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5189.txt",
  key="RFC 5189",
  abstract={This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs).  The semantics discussion does not include any specification of a concrete syntax or a transport protocol.  However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it.  The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions.  This document obsoletes RFC 3989. [STANDARDS-TRACK]},
  keywords="nat, network address translator, firewall",
  doi="10.17487/RFC5189",
  }

@misc{rfc5190,
  author="J. Quittek and M. Stiemerling and P. Srisuresh",
  title="{Definitions of Managed Objects for Middlebox Communication}",
  howpublished="RFC 5190 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5190",
  pages="1--92",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5190.txt",
  key="RFC 5190",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices.  The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]},
  keywords="management information base, mib, midcom, MIDCOM-MIB",
  doi="10.17487/RFC5190",
  }

@misc{rfc5191,
  author="D. Forsberg and Y. Ohba and B. Patil and H. Tschofenig and A. Yegin",
  title="{Protocol for Carrying Authentication for Network Access (PANA)}",
  howpublished="RFC 5191 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5191",
  pages="1--46",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5872",
url="https://www.rfc-editor.org/rfc/rfc5191.txt",
  key="RFC 5191",
  abstract={This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks.  In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]},
  keywords="eap, exensible authentication protocol",
  doi="10.17487/RFC5191",
  }

@misc{rfc5192,
  author="L. Morand and A. Yegin and S. Kumar and S. Madanapalli",
  title="{DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents}",
  howpublished="RFC 5192 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5192",
  pages="1--8",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5192.txt",
  key="RFC 5192",
  abstract={This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs).  This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol, pac, pana client",
  doi="10.17487/RFC5192",
  }

@misc{rfc5193,
  author="P. Jayaraman and R. Lopez and Y. Ohba and M. Parthasarathy and A. Yegin",
  title="{Protocol for Carrying Authentication for Network Access (PANA) Framework}",
  howpublished="RFC 5193 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5193",
  pages="1--11",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5193.txt",
  key="RFC 5193",
  abstract={This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments.  This memo provides information for the Internet community.},
  keywords="",
  doi="10.17487/RFC5193",
  }

@misc{rfc5194,
  author="A. van Wijk and G. Gybels",
  title="{Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5194 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5194",
  pages="1--31",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5194.txt",
  key="RFC 5194",
  abstract={This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP).  This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks.  This memo provides information for the Internet community.},
  keywords="text telephone, textphone, deaf, hard-of-hearing, speech-impaired, interactive text, transcoding, speech-to-text, user alerting, emergency services, gateway, analog terminal adapters, PSTN interworking, text presentation, user alerting, instant messaging, conversation, conversational text, interactivity, total conversation, user requirements, text gateway, relay, relay service, text relay, TTY, text transport, text interworking, combination gateway",
  doi="10.17487/RFC5194",
  }

@misc{rfc5195,
  author="H. Ould-Brahim and D. Fedyk and Y. Rekhter",
  title="{BGP-Based Auto-Discovery for Layer-1 VPNs}",
  howpublished="RFC 5195 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5195",
  pages="1--10",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5195.txt",
  key="RFC 5195",
  abstract={The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs).  The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN.  That information is necessary for completing the signaling phase of L1VPN connections.  One main objective of a L1VPN auto-discovery mechanism is to support the ``single-end provisioning'' model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]},
  keywords="import route target, l1vpn, single-end provisioning",
  doi="10.17487/RFC5195",
  }

@misc{rfc5196,
  author="M. Lonnfors and K. Kiss",
  title="{Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)}",
  howpublished="RFC 5196 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5196",
  pages="1--30",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5196.txt",
  key="RFC 5196",
  abstract={Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols.  This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]},
  keywords="common presence data format, cpp, common profile for presence",
  doi="10.17487/RFC5196",
  }

@misc{rfc5197,
  author="S. Fries and D. Ignjatic",
  title="{On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions}",
  howpublished="RFC 5197 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5197",
  pages="1--31",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5197.txt",
  key="RFC 5197",
  abstract={Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \\%real-time applications. In particular, it has been defined focusing on the support of the Secure \\%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements. This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.},
  keywords="key management, media stream security, end-to-end, SRTP",
  doi="10.17487/RFC5197",
  }

@misc{rfc5198,
  author="J. Klensin and M. Padlipsky",
  title="{Unicode Format for Network Interchange}",
  howpublished="RFC 5198 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5198",
  pages="1--19",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5198.txt",
  key="RFC 5198",
  abstract={The Internet today is in need of a standardized form for the transmission of internationalized ``text'' information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET.  This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]},
  keywords="internationalized, utf-8",
  doi="10.17487/RFC5198",
  }

@misc{rfc5201,
  author="R. Moskowitz and P. Nikander and P. Jokela and T. Henderson",
  title="{Host Identity Protocol}",
  howpublished="RFC 5201 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5201",
  pages="1--104",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7401, updated by RFC 6253",
url="https://www.rfc-editor.org/rfc/rfc5201.txt",
  key="RFC 5201",
  abstract={This memo specifies the details of the Host Identity Protocol (HIP).  HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes.  HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication.  The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks.  When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hip, ip-layer state, integrity protection, optional encryption",
  doi="10.17487/RFC5201",
  }

@misc{rfc5202,
  author="P. Jokela and R. Moskowitz and P. Nikander",
  title="{Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)}",
  howpublished="RFC 5202 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5202",
  pages="1--30",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7402",
url="https://www.rfc-editor.org/rfc/rfc5202.txt",
  key="RFC 5202",
  abstract={This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="user data packets",
  doi="10.17487/RFC5202",
  }

@misc{rfc5203,
  author="J. Laganier and T. Koponen and L. Eggert",
  title="{Host Identity Protocol (HIP) Registration Extension}",
  howpublished="RFC 5203 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5203",
  pages="1--13",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8003",
url="https://www.rfc-editor.org/rfc/rfc5203.txt",
  key="RFC 5203",
  abstract={This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="register",
  doi="10.17487/RFC5203",
  }

@misc{rfc5204,
  author="J. Laganier and L. Eggert",
  title="{Host Identity Protocol (HIP) Rendezvous Extension}",
  howpublished="RFC 5204 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5204",
  pages="1--15",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8004",
url="https://www.rfc-editor.org/rfc/rfc5204.txt",
  key="RFC 5204",
  abstract={This document defines a rendezvous extension for the Host Identity Protocol (HIP).  The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers.  Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hip registration extension, hip nodes, hip redezvous server",
  doi="10.17487/RFC5204",
  }

@misc{rfc5205,
  author="P. Nikander and J. Laganier",
  title="{Host Identity Protocol (HIP) Domain Name System (DNS) Extensions}",
  howpublished="RFC 5205 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5205",
  pages="1--17",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8005",
url="https://www.rfc-editor.org/rfc/rfc5205.txt",
  key="RFC 5205",
  abstract={This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP).  This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hip, host identity protocol, host identity payload, dns, domain name system",
  doi="10.17487/RFC5205",
  }

@misc{rfc5206,
  author="P. Nikander and T. Henderson and C. Vogt and J. Arkko",
  title="{End-Host Mobility and Multihoming with the Host Identity Protocol}",
  howpublished="RFC 5206 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5206",
  pages="1--40",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8046",
url="https://www.rfc-editor.org/rfc/rfc5206.txt",
  key="RFC 5206",
  abstract={This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP).  Specifically, this document defines a general ``LOCATOR'' parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached.  This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets.  While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="hip, multihoming extensions, mobility extentions, locator",
  doi="10.17487/RFC5206",
  }

@misc{rfc5207,
  author="M. Stiemerling and J. Quittek and L. Eggert",
  title="{NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication}",
  howpublished="RFC 5207 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5207",
  pages="1--13",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5207.txt",
  key="RFC 5207",
  abstract={The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate.  One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers.  In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet.  These ``middleboxes'' are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts.  Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible.  This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls.  It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes.  This document is a product of the IRTF HIP Research Group.  This memo provides information for the Internet community.},
  keywords="HIP, host identity protocol, host identity payload, NAT traversal, middlebox traversal, firewall traversal, ID locator split, problem statement",
  doi="10.17487/RFC5207",
  }

@misc{rfc5208,
  author="B. Kaliski",
  title="{Public-Key Cryptography Standards (PKCS) \#8: Private-Key Information Syntax Specification Version 1.2}",
  howpublished="RFC 5208 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5208",
  pages="1--8",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5958",
url="https://www.rfc-editor.org/rfc/rfc5208.txt",
  key="RFC 5208",
  abstract={This document represents a republication of PKCS \#8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS \#8 v1.2 specification. This document describes a syntax for private-key information. This memo provides information for the Internet community.},
  keywords="rsa laboratories, private-key syntax, change control",
  doi="10.17487/RFC5208",
  }

@misc{rfc5209,
  author="P. Sangster and H. Khosravi and M. Mani and K. Narayan and J. Tardo",
  title="{Network Endpoint Assessment (NEA): Overview and Requirements}",
  howpublished="RFC 5209 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5209",
  pages="1--53",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5209.txt",
  key="RFC 5209",
  abstract={This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model.  NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system.  This may take place during the request for network access and/or subsequently at any time while connected to the network.  The learned posture information can then be applied to a variety of compliance-oriented decisions.  The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software.  In order to provide context for the requirements, a reference model and terminology are introduced.  This memo provides information for the Internet community.},
  keywords="Posture, Remediation, reassessment, Validator, Collector, Broker, compliance, privacy, disclosure, replay, trust, policy",
  doi="10.17487/RFC5209",
  }

@misc{rfc5210,
  author="J. Wu and J. Bi and X. Li and G. Ren and K. Xu and M. Williams",
  title="{A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience}",
  howpublished="RFC 5210 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5210",
  pages="1--25",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5210.txt",
  key="RFC 5210",
  abstract={Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses.  In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network.  This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="Source Address Validation, Source Addressing Spoofing, Network Security, Testbed, IPv6",
  doi="10.17487/RFC5210",
  }

@misc{rfc5211,
  author="J. Curran",
  title="{An Internet Transition Plan}",
  howpublished="RFC 5211 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5211",
  pages="1--8",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5211.txt",
  key="RFC 5211",
  abstract={This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5211",
  }

@misc{rfc5212,
  author="K. Shiomoto and D. Papadimitriou and JL. Le Roux and M. Vigoureux and D. Brungard",
  title="{Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)}",
  howpublished="RFC 5212 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5212",
  pages="1--28",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5212.txt",
  key="RFC 5212",
  abstract={Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.},
  keywords="generalized mpls, switching technology",
  doi="10.17487/RFC5212",
  }

@misc{rfc5213,
  author="S. Gundavelli and K. Leung and V. Devarapalli and K. Chowdhury and B. Patil",
  title="{Proxy Mobile IPv6}",
  howpublished="RFC 5213 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5213",
  pages="1--92",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6543, 7864",
url="https://www.rfc-editor.org/rfc/rfc5213.txt",
  key="RFC 5213",
  abstract={Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling.  The network is responsible for managing IP mobility on behalf of the host.  The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf.  This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]},
  keywords="mobility management",
  doi="10.17487/RFC5213",
  }

@misc{rfc5214,
  author="F. Templin and T. Gleeson and D. Thaler",
  title="{Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}",
  howpublished="RFC 5214 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5214",
  pages="1--15",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5214.txt",
  key="RFC 5214",
  abstract={The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks.  ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.  This memo provides information for the Internet community.},
  keywords="ipv6, ipv4, non-broadcast multiple access, nbma, dual-stack",
  doi="10.17487/RFC5214",
  }

@misc{rfc5215,
  author="L. Barbato",
  title="{RTP Payload Format for Vorbis Encoded Audio}",
  howpublished="RFC 5215 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5215",
  pages="1--26",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5215.txt",
  key="RFC 5215",
  abstract={This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information. Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]},
  keywords="realtime transport protocol, codebook",
  doi="10.17487/RFC5215",
  }

@misc{rfc5216,
  author="D. Simon and B. Aboba and R. Hurst",
  title="{The EAP-TLS Authentication Protocol}",
  howpublished="RFC 5216 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5216",
  pages="1--34",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5216.txt",
  key="RFC 5216",
  abstract={The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]},
  keywords="extensible authentication protocol, point-to-point, link control compression, extensible, transport level security",
  doi="10.17487/RFC5216",
  }

@misc{rfc5217,
  author="M. Shimaoka and N. Hastings and R. Nielsen",
  title="{Memorandum for Multi-Domain Public Key Infrastructure Interoperability}",
  howpublished="RFC 5217 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5217",
  pages="1--29",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5217.txt",
  key="RFC 5217",
  abstract={The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy.  This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI.  This memo provides information for the Internet community.},
  keywords="pki, multi-domain pki, pki domain",
  doi="10.17487/RFC5217",
  }

@misc{rfc5218,
  author="D. Thaler and B. Aboba",
  title="{What Makes for a Successful Protocol?}",
  howpublished="RFC 5218 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5218",
  pages="1--28",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5218.txt",
  key="RFC 5218",
  abstract={The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success.  Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success.  It is hoped that these observations can serve as guidance for future protocol work.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5218",
  }

@misc{rfc5219,
  author="R. Finlayson",
  title="{A More Loss-Tolerant RTP Payload Format for MP3 Audio}",
  howpublished="RFC 5219 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5219",
  pages="1--22",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5219.txt",
  key="RFC 5219",
  abstract={This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as ``MP3'').  This format is an alternative to that described in RFC 2250, and performs better if there is packet loss.  This document obsoletes RFC 3119, correcting typographical errors in the ``SDP usage'' section and pseudo-code appendices. [STANDARDS-TRACK]},
  keywords="real time protocol, real-time protocol, mpeg, moving picture experts group,",
  doi="10.17487/RFC5219",
  }

@misc{rfc5220,
  author="A. Matsumoto and T. Fujisaki and R. Hiromi and K. Kanayama",
  title="{Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules}",
  howpublished="RFC 5220 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5220",
  pages="1--17",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5220.txt",
  key="RFC 5220",
  abstract={A single physical link can have multiple prefixes assigned to it.  In that environment, end hosts might have multiple IP addresses and be required to use them selectively.  RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs.  But, it has been too difficult to use operationally for several reasons.  In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication.  This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.  This memo provides information for the Internet community.},
  keywords="multiple prefixes",
  doi="10.17487/RFC5220",
  }

@misc{rfc5221,
  author="A. Matsumoto and T. Fujisaki and R. Hiromi and K. Kanayama",
  title="{Requirements for Address Selection Mechanisms}",
  howpublished="RFC 5221 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5221",
  pages="1--7",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5221.txt",
  key="RFC 5221",
  abstract={There are some problematic cases when using the default address selection mechanism that RFC 3484 defines.  This document describes additional requirements that operate with RFC 3484 to solve the problems.  This memo provides information for the Internet community.},
  keywords="default address selection",
  doi="10.17487/RFC5221",
  }

@misc{rfc5222,
  author="T. Hardie and A. Newton and H. Schulzrinne and H. Tschofenig",
  title="{LoST: A Location-to-Service Translation Protocol}",
  howpublished="RFC 5222 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5222",
  pages="1--69",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6848",
url="https://www.rfc-editor.org/rfc/rfc5222.txt",
  key="RFC 5222",
  abstract={This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs.  In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]},
  keywords="emergency services, emergency call routing",
  doi="10.17487/RFC5222",
  }

@misc{rfc5223,
  author="H. Schulzrinne and J. Polk and H. Tschofenig",
  title="{Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)}",
  howpublished="RFC 5223 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5223",
  pages="1--8",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5223.txt",
  key="RFC 5223",
  abstract={The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]},
  keywords="mapping service, emergency service, emergency communication",
  doi="10.17487/RFC5223",
  }

@misc{rfc5224,
  author="M. Brenner",
  title="{Diameter Policy Processing Application}",
  howpublished="RFC 5224 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5224",
  pages="1--5",
  year=2008,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5224.txt",
  key="RFC 5224",
  abstract={This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement).  This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing.  This memo provides information for the Internet community.},
  keywords="policy evaluation, or evaluation and enforcement, pem-1, peem, oma, open mobile alliance",
  doi="10.17487/RFC5224",
  }

@misc{rfc5225,
  author="G. Pelletier and K. Sandlund",
  title="{RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite}",
  howpublished="RFC 5225 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5225",
  pages="1--124",
  year=2008,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5225.txt",
  key="RFC 5225",
  abstract={This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them. The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]},
  keywords="rohc, 3095, 3843, 4019",
  doi="10.17487/RFC5225",
  }

@misc{rfc5226,
  author="T. Narten and H. Alvestrand",
  title="{Guidelines for Writing an IANA Considerations Section in RFCs}",
  howpublished="RFC 5226 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5226",
  pages="1--27",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5226.txt",
  key="RFC 5226",
  abstract={Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet assigned numbers authority, values, implementations, code point, protocol constant, protocol parameter",
  doi="10.17487/RFC5226",
  }

@misc{rfc5227,
  author="S. Cheshire",
  title="{IPv4 Address Conflict Detection}",
  howpublished="RFC 5227 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5227",
  pages="1--21",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5227.txt",
  key="RFC 5227",
  abstract={When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts.  This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]},
  keywords="internet protocol version 4",
  doi="10.17487/RFC5227",
  }

@misc{rfc5228,
  author="P. Guenther and T. Showalter",
  title="{Sieve: An Email Filtering Language}",
  howpublished="RFC 5228 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5228",
  pages="1--42",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5229, 5429, 6785",
url="https://www.rfc-editor.org/rfc/rfc5228.txt",
  key="RFC 5228",
  abstract={This document describes a language for filtering email messages at time of final delivery.  It is designed to be implementable on either a mail client or mail server.  It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system.  It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5228",
  }

@misc{rfc5229,
  author="K. Homme",
  title="{Sieve Email Filtering: Variables Extension}",
  howpublished="RFC 5229 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5229",
  pages="1--11",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5173",
url="https://www.rfc-editor.org/rfc/rfc5229.txt",
  key="RFC 5229",
  abstract={In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules.  This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.  The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5229",
  }

@misc{rfc5230,
  author="T. Showalter and N. Freed",
  title="{Sieve Email Filtering: Vacation Extension}",
  howpublished="RFC 5230 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5230",
  pages="1--16",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5230.txt",
  key="RFC 5230",
  abstract={This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix ``vacation'' command for replying to messages.  Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]},
  keywords="autoresponder",
  doi="10.17487/RFC5230",
  }

@misc{rfc5231,
  author="W. Segmuller and B. Leiba",
  title="{Sieve Email Filtering: Relational Extension}",
  howpublished="RFC 5231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5231",
  pages="1--9",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5231.txt",
  key="RFC 5231",
  abstract={This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. This document obsoletes RFC 3431. [STANDARDS-TRACK]},
  keywords="relational operators",
  doi="10.17487/RFC5231",
  }

@misc{rfc5232,
  author="A. Melnikov",
  title="{Sieve Email Filtering: Imap4flags Extension}",
  howpublished="RFC 5232 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5232",
  pages="1--12",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5232.txt",
  key="RFC 5232",
  abstract={Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]},
  keywords="imap, internet message access control protocol, imap flags, imap system flags, imap keywords",
  doi="10.17487/RFC5232",
  }

@misc{rfc5233,
  author="K. Murchison",
  title="{Sieve Email Filtering: Subaddress Extension}",
  howpublished="RFC 5233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5233",
  pages="1--7",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5233.txt",
  key="RFC 5233",
  abstract={On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., ``ken+sieve@example.org''), it is sometimes desirable to make comparisons against these sub-parts of addresses.  This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]},
  keywords="subaddressing, detailed addressing, :user, :detail",
  doi="10.17487/RFC5233",
  }

@misc{rfc5234,
  author="D. Crocker and P. Overell",
  title="{Augmented BNF for Syntax Specifications: ABNF}",
  howpublished="RFC 5234 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5234",
  pages="1--16",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7405",
url="https://www.rfc-editor.org/rfc/rfc5234.txt",
  key="RFC 5234",
  abstract={Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]},
  keywords="ABNF, backus-naur form, augmented backus-naur form, rule definitions, encoding, core lexical analyzer",
  doi="10.17487/RFC5234",
  }

@misc{rfc5235,
  author="C. Daboo",
  title="{Sieve Email Filtering: Spamtest and Virustest Extensions}",
  howpublished="RFC 5235 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5235",
  pages="1--13",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5235.txt",
  key="RFC 5235",
  abstract={The Sieve email filtering language ``spamtest'', ``spamtestplus'', and ``virustest'' extensions permit users to use simple, portable commands for spam and virus tests on email messages.  Each extension provides a new test using matches against numeric ``scores''.  It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. [STANDARDS-TRACK]},
  keywords="spamtest, spamtestplus, virustest, scores",
  doi="10.17487/RFC5235",
  }

@misc{rfc5236,
  author="A. Jayasumana and N. Piratla and T. Banka and A. Bare and R. Whitner",
  title="{Improved Packet Reordering Metrics}",
  howpublished="RFC 5236 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5236",
  pages="1--26",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5236.txt",
  key="RFC 5236",
  abstract={This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.},
  keywords="reorder density, rd, reorder buffer-occupancy density, rbd",
  doi="10.17487/RFC5236",
  }

@misc{rfc5237,
  author="J. Arkko and S. Bradner",
  title="{IANA Allocation Guidelines for the Protocol Field}",
  howpublished="RFC 5237 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5237",
  pages="1--5",
  year=2008,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5237.txt",
  key="RFC 5237",
  abstract={This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header.  It modifies the rules specified in RFC 2780 by removing the Expert Review option.  The change will also affect the allocation of Next Header field values in IPv6.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ipv4 header, next header field, internet, assigned, numbers, authority, IP",
  doi="10.17487/RFC5237",
  }

@misc{rfc5238,
  author="T. Phelan",
  title="{Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 5238 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5238",
  pages="1--10",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5238.txt",
  key="RFC 5238",
  abstract={This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.  DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]},
  keywords="tls, transport protocol",
  doi="10.17487/RFC5238",
  }

@misc{rfc5239,
  author="M. Barnes and C. Boulton and O. Levin",
  title="{A Framework for Centralized Conferencing}",
  howpublished="RFC 5239 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5239",
  pages="1--57",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5239.txt",
  key="RFC 5239",
  abstract={This document defines the framework for Centralized Conferencing.  The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference.  The Centralized Conferencing Framework defines logical entities and naming conventions.  The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications.  The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]},
  keywords="call signaling, call signalling",
  doi="10.17487/RFC5239",
  }

@misc{rfc5240,
  author="B. Joshi and R. Bijlani",
  title="{Protocol Independent Multicast (PIM) Bootstrap Router MIB}",
  howpublished="RFC 5240 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5240",
  pages="1--23",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5240.txt",
  key="RFC 5240",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]},
  keywords="management information base, bootstrap router, bsr, PIM-BSR-MIB",
  doi="10.17487/RFC5240",
  }

@misc{rfc5241,
  author="A. Falk and S. Bradner",
  title="{Naming Rights in IETF Protocols}",
  howpublished="RFC 5241 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5241",
  pages="1--12",
  year=2008,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5241.txt",
  key="RFC 5241",
  abstract={This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields.  This memo describes a process for assignment of rights and explores some of the issues associated with the process.  Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.  This memo provides information for the Internet community.},
  keywords="april fools, field naming rights",
  doi="10.17487/RFC5241",
  }

@misc{rfc5242,
  author="J. Klensin and H. Alvestrand",
  title="{A Generalized Unified Character Code: Western European and CJK Sections}",
  howpublished="RFC 5242 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5242",
  pages="1--14",
  year=2008,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5242.txt",
  key="RFC 5242",
  abstract={Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes.  This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters.  It is not a complete specification of that character set.  This memo provides information for the Internet community.},
  keywords="idn, latin, greek, cyrilllic, chinese, internationalized domain names",
  doi="10.17487/RFC5242",
  }

@misc{rfc5243,
  author="R. Ogier",
  title="{OSPF Database Exchange Summary List Optimization}",
  howpublished="RFC 5243 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5243",
  pages="1--5",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5243.txt",
  key="RFC 5243",
  abstract={This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3.  In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor.  This optimization reduces Database Description overhead by about 50\% in large networks.  This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5243",
  }

@misc{rfc5244,
  author="H. Schulzrinne and T. Taylor",
  title="{Definition of Events for Channel-Oriented Telephony Signalling}",
  howpublished="RFC 5244 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5244",
  pages="1--23",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5244.txt",
  key="RFC 5244",
  abstract={This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload.  It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833.  As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant.  In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling.  This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]},
  keywords="event code, telephony event rtp payload",
  doi="10.17487/RFC5244",
  }

@misc{rfc5245,
  author="J. Rosenberg",
  title="{Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols}",
  howpublished="RFC 5245 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5245",
  pages="1--117",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6336",
url="https://www.rfc-editor.org/rfc/rfc5245.txt",
  key="RFC 5245",
  abstract={This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5245",
  }

@misc{rfc5246,
  author="T. Dierks and E. Rescorla",
  title="{The Transport Layer Security (TLS) Protocol Version 1.2}",
  howpublished="RFC 5246 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5246",
  pages="1--104",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685, 7905, 7919",
url="https://www.rfc-editor.org/rfc/rfc5246.txt",
  key="RFC 5246",
  abstract={This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]},
  keywords="idea, international data algorithm, symmetric, transport protocol layer, authentication, privacy",
  doi="10.17487/RFC5246",
  }

@misc{rfc5247,
  author="B. Aboba and D. Simon and P. Eronen",
  title="{Extensible Authentication Protocol (EAP) Key Management Framework}",
  howpublished="RFC 5247 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5247",
  pages="1--79",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5247.txt",
  key="RFC 5247",
  abstract={The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication.  This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as ``methods''.  It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]},
  keywords="extensible network access authentication, key hierarchy, methods",
  doi="10.17487/RFC5247",
  }

@misc{rfc5248,
  author="T. Hansen and J. Klensin",
  title="{A Registry for SMTP Enhanced Mail System Status Codes}",
  howpublished="RFC 5248 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5248",
  pages="1--11",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5248.txt",
  key="RFC 5248",
  abstract={The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes.  While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes.  This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="simple mail transfer protocol",
  doi="10.17487/RFC5248",
  }

@misc{rfc5249,
  author="D. Harrington",
  title="{Templates for Internet-Drafts Containing MIB Modules}",
  howpublished="RFC 5249 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5249",
  pages="1--4",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5249.txt",
  key="RFC 5249",
  abstract={This memo references three annotated templates for IETF documents that contain the definition of MIB modules.  It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="network management, management information base, mib, smiv2, template",
  doi="10.17487/RFC5249",
  }

@misc{rfc5250,
  author="L. Berger and I. Bryskin and A. Zinin and R. Coltun",
  title="{The OSPF Opaque LSA Option}",
  howpublished="RFC 5250 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5250",
  pages="1--17",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5250.txt",
  key="RFC 5250",
  abstract={This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]},
  keywords="OSPF-LSA], open shortest path first, link state advertisement, opaque lsas",
  doi="10.17487/RFC5250",
  }

@misc{rfc5251,
  author="D. Fedyk and Y. Rekhter and D. Papadimitriou and R. Rabbat and L. Berger",
  title="{Layer 1 VPN Basic Mode}",
  howpublished="RFC 5251 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5251",
  pages="1--24",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5251.txt",
  key="RFC 5251",
  abstract={This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).  L1VPN Basic Mode (L1VPN BM) is a port-based VPN.  In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology.  This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]},
  keywords="virtual private network, l1vpn, l1vpn bm",
  doi="10.17487/RFC5251",
  }

@misc{rfc5252,
  author="I. Bryskin and L. Berger",
  title="{OSPF-Based Layer 1 VPN Auto-Discovery}",
  howpublished="RFC 5252 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5252",
  pages="1--11",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5252.txt",
  key="RFC 5252",
  abstract={This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism.  This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs.  This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]},
  keywords="open shortest path first, l1vpn, layer 1 virtual private network",
  doi="10.17487/RFC5252",
  }

@misc{rfc5253,
  author="T. Takeda",
  title="{Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode}",
  howpublished="RFC 5253 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5253",
  pages="1--19",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5253.txt",
  key="RFC 5253",
  abstract={This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.},
  keywords="gmpls, generalized multiprotocol label switching, l1vpn bm",
  doi="10.17487/RFC5253",
  }

@misc{rfc5254,
  author="N. Bitar and M. Bocci and L. Martini",
  title="{Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)}",
  howpublished="RFC 5254 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5254",
  pages="1--27",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5254.txt",
  key="RFC 5254",
  abstract={This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains.  These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains.  This memo provides information for the Internet community.},
  keywords="Pseudowire, PWE3, multi-segment, MS-PW, SS-PW, S-PE, T-PE",
  doi="10.17487/RFC5254",
  }

@misc{rfc5255,
  author="C. Newman and A. Gulbrandsen and A. Melnikov",
  title="{Internet Message Access Protocol Internationalization}",
  howpublished="RFC 5255 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5255",
  pages="1--20",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5255.txt",
  key="RFC 5255",
  abstract={Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings.  It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).  This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]},
  keywords="imap, imapv4, imap4",
  doi="10.17487/RFC5255",
  }

@misc{rfc5256,
  author="M. Crispin and K. Murchison",
  title="{Internet Message Access Protocol - SORT and THREAD Extensions}",
  howpublished="RFC 5256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5256",
  pages="1--19",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5957",
url="https://www.rfc-editor.org/rfc/rfc5256.txt",
  key="RFC 5256",
  abstract={This document describes the base-level server-based sorting and threading extensions to the IMAP protocol.  These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]},
  keywords="ordered subject references, imap capability",
  doi="10.17487/RFC5256",
  }

@misc{rfc5257,
  author="C. Daboo and R. Gellens",
  title="{Internet Message Access Protocol - ANNOTATE Extension}",
  howpublished="RFC 5257 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5257",
  pages="1--31",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5257.txt",
  key="RFC 5257",
  abstract={The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain ``meta data'' for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added. Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress. Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.},
  keywords="imap",
  doi="10.17487/RFC5257",
  }

@misc{rfc5258,
  author="B. Leiba and A. Melnikov",
  title="{Internet Message Access Protocol version 4 - LIST Command Extensions}",
  howpublished="RFC 5258 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5258",
  pages="1--31",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5258.txt",
  key="RFC 5258",
  abstract={IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible.  If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension.  This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]},
  keywords="imap4 ,list, lsub, extended list, email",
  doi="10.17487/RFC5258",
  }

@misc{rfc5259,
  author="A. Melnikov and P. Coates",
  title="{Internet Message Access Protocol - CONVERT Extension}",
  howpublished="RFC 5259 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5259",
  pages="1--30",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5259.txt",
  key="RFC 5259",
  abstract={CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments.  Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]},
  keywords="IMAP, Lemonade, CONVERT, conversion, transcoding",
  doi="10.17487/RFC5259",
  }

@misc{rfc5260,
  author="N. Freed",
  title="{Sieve Email Filtering: Date and Index Extensions}",
  howpublished="RFC 5260 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5260",
  pages="1--13",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5260.txt",
  key="RFC 5260",
  abstract={This document describes the ``date'' and ``index'' extensions to the Sieve email filtering language.  The ``date'' extension gives Sieve the ability to test date and time values in various ways.  The ``index'' extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]},
  keywords="smtp, esmtp, date, index",
  doi="10.17487/RFC5260",
  }

@misc{rfc5261,
  author="J. Urpalainen",
  title="{An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors}",
  howpublished="RFC 5261 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5261",
  pages="1--40",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5261.txt",
  key="RFC 5261",
  abstract={Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems.  In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed.  This document describes an XML patch framework utilizing XML Path language (XPath) selectors.  These selector values and updated new data content constitute the basis of patch operations described in this document.  In addition to them, with basic \&lt;add\&gt;, \&lt;replace\&gt;, and \&lt;remove\&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5261",
  }

@misc{rfc5262,
  author="M. Lonnfors and E. Leppanen and H. Khartabil and J. Urpalainen",
  title="{Presence Information Data Format (PIDF) Extension for Partial Presence}",
  howpublished="RFC 5262 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5262",
  pages="1--16",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5262.txt",
  key="RFC 5262",
  abstract={The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information.  One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity.  In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network.  This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5262",
  }

@misc{rfc5263,
  author="M. Lonnfors and J. Costa-Requena and E. Leppanen and H. Khartabil",
  title="{Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information}",
  howpublished="RFC 5263 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5263",
  pages="1--16",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5263.txt",
  key="RFC 5263",
  abstract={By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF).  A PIDF document contains a set of elements, each representing a different aspect of the presence being reported.  When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered.  This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]},
  keywords="pidf, presence information data format",
  doi="10.17487/RFC5263",
  }

@misc{rfc5264,
  author="A. Niemi and M. Lonnfors and E. Leppanen",
  title="{Publication of Partial Presence Information}",
  howpublished="RFC 5264 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5264",
  pages="1--15",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5264.txt",
  key="RFC 5264",
  abstract={The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent.  Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update.  As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient.  Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system.  This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5264",
  }

@misc{rfc5265,
  author="S. Vaarala and E. Klovning",
  title="{Mobile IPv4 Traversal across IPsec-Based VPN Gateways}",
  howpublished="RFC 5265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5265",
  pages="1--39",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5265.txt",
  key="RFC 5265",
  abstract={This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users.  The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]},
  keywords="mobile ip, mobile ipv4, ipsec, mipv4",
  doi="10.17487/RFC5265",
  }

@misc{rfc5266,
  author="V. Devarapalli and P. Eronen",
  title="{Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)}",
  howpublished="RFC 5266 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5266",
  pages="1--15",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5266.txt",
  key="RFC 5266",
  abstract={Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise.  Secure connectivity is required when the user connects to the enterprise from an untrusted network.  Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address.  This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC5266",
  }

@misc{rfc5267,
  author="D. Cridland and C. King",
  title="{Contexts for IMAP4}",
  howpublished="RFC 5267 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5267",
  pages="1--18",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5465",
url="https://www.rfc-editor.org/rfc/rfc5267.txt",
  key="RFC 5267",
  abstract={The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled.  This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]},
  keywords="imap4rev1, esort, context",
  doi="10.17487/RFC5267",
  }

@misc{rfc5268,
  author="R. Koodli",
  title="{Mobile IPv6 Fast Handovers}",
  howpublished="RFC 5268 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5268",
  pages="1--48",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5568",
url="https://www.rfc-editor.org/rfc/rfc5268.txt",
  key="RFC 5268",
  abstract={Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover.  During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations.  This ``handover latency'' resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP).  Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well.  This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures.  This document does not address improving the link switching latency. [STANDARDS-TRACK]},
  keywords="mipv6, handover latency",
  doi="10.17487/RFC5268",
  }

@misc{rfc5269,
  author="J. Kempf and R. Koodli",
  title="{Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)}",
  howpublished="RFC 5269 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5269",
  pages="1--14",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5269.txt",
  key="RFC 5269",
  abstract={Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks.  In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling.  The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971).  The Mobile Node sends the public key to the Access Router.  The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node.  The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update.  The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange.  The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node.  This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]},
  keywords="fast binding update",
  doi="10.17487/RFC5269",
  }

@misc{rfc5270,
  author="H. Jang and J. Jee and Y. Han and S. Park and J. Cha",
  title="{Mobile IPv6 Fast Handovers over IEEE 802.16e Networks}",
  howpublished="RFC 5270 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5270",
  pages="1--18",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5270.txt",
  key="RFC 5270",
  abstract={This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications.  The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently.  This memo provides information for the Internet community.},
  keywords="Mobile IPv6,  Handover optimization, Cross-layer design",
  doi="10.17487/RFC5270",
  }

@misc{rfc5271,
  author="H. Yokota and G. Dommety",
  title="{Mobile IPv6 Fast Handovers for 3G CDMA Networks}",
  howpublished="RFC 5271 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5271",
  pages="1--22",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5271.txt",
  key="RFC 5271",
  abstract={Mobile IPv6 is designed to maintain its connectivity while moving from one network to another.  It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers.  However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network.  During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony.  This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover.  This memo provides information for the Internet community.},
  keywords="FMIP, handoff, 3GPP2",
  doi="10.17487/RFC5271",
  }

@misc{rfc5272,
  author="J. Schaad and M. Myers",
  title="{Certificate Management over CMS (CMC)}",
  howpublished="RFC 5272 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5272",
  pages="1--83",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6402",
url="https://www.rfc-editor.org/rfc/rfc5272.txt",
  key="RFC 5272",
  abstract={This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS \#10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]},
  keywords="certificate management protocol, cryptographic message syntax, pki, public key infrastructure",
  doi="10.17487/RFC5272",
  }

@misc{rfc5273,
  author="J. Schaad and M. Myers",
  title="{Certificate Management over CMS (CMC): Transport Protocols}",
  howpublished="RFC 5273 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5273",
  pages="1--7",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6402",
url="https://www.rfc-editor.org/rfc/rfc5273.txt",
  key="RFC 5273",
  abstract={This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages.  The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]},
  keywords="cryptographic message syntax, http, file, mail, tcp",
  doi="10.17487/RFC5273",
  }

@misc{rfc5274,
  author="J. Schaad and M. Myers",
  title="{Certificate Management Messages over CMS (CMC): Compliance Requirements}",
  howpublished="RFC 5274 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5274",
  pages="1--13",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6402",
url="https://www.rfc-editor.org/rfc/rfc5274.txt",
  key="RFC 5274",
  abstract={This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol.  The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents.  This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]},
  keywords="cryptographic message syntax, cmc enrollment protocol",
  doi="10.17487/RFC5274",
  }

@misc{rfc5275,
  author="S. Turner",
  title="{CMS Symmetric Key Management and Distribution}",
  howpublished="RFC 5275 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5275",
  pages="1--89",
  year=2008,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5275.txt",
  key="RFC 5275",
  abstract={This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms.  Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms.  The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys.  Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key.  This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]},
  keywords="cryptographic message syntax, symmetric cryptographic algorithms, certificate management over cms, cmc",
  doi="10.17487/RFC5275",
  }

@misc{rfc5276,
  author="C. Wallace",
  title="{Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records}",
  howpublished="RFC 5276 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5276",
  pages="1--13",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5276.txt",
  key="RFC 5276",
  abstract={The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server.  It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past.  The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data.  Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure.  This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]},
  keywords="ERS, Evidence Record, SCVP, Server-based Certificate Validation Protocol, PKI artifact preservation",
  doi="10.17487/RFC5276",
  }

@misc{rfc5277,
  author="S. Chisholm and H. Trevino",
  title="{NETCONF Event Notifications}",
  howpublished="RFC 5277 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5277",
  pages="1--35",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5277.txt",
  key="RFC 5277",
  abstract={This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF).  This is an optional capability built on top of the base NETCONF definition.  This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]},
  keywords="XML, Extensible Markup Language, NETCONF, Event, Asynchronous Message, Notification",
  doi="10.17487/RFC5277",
  }

@misc{rfc5278,
  author="J. Livingood and D. Troshynski",
  title="{IANA Registration of Enumservices for Voice and Video Messaging}",
  howpublished="RFC 5278 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5278",
  pages="1--22",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc5278.txt",
  key="RFC 5278",
  abstract={This document registers the Enumservice named ``vmsg'', which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system.  This vmsg Enumservice registers three Enumservice types: ``voicemsg'', ``videomsg'', and ``unifmsg''.  Each type also registers the subtypes ``sip'', ``sips'', ``http'', and ``https'', as well as the subtype ``tel'' for the ``voicemsg'' type. [STANDARDS-TRACK]},
  keywords="vmsg, voicemsg, videomsg, unifmsg, sip, sips, http, https, tel",
  doi="10.17487/RFC5278",
  }

@misc{rfc5279,
  author="A. Monrad and S. Loreto",
  title="{A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)}",
  howpublished="RFC 5279 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5279",
  pages="1--7",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5279.txt",
  key="RFC 5279",
  abstract={This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP).  3GPP defines and manages resources that utilize this URN name model.  Management activities for these and other resource types are provided by the 3GPP Support Team.  This memo provides information for the Internet community.},
  keywords="nid, namespace identifier, 3gpp",
  doi="10.17487/RFC5279",
  }

@misc{rfc5280,
  author="D. Cooper and S. Santesson and S. Farrell and S. Boeyen and R. Housley and W. Polk",
  title="{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 5280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5280",
  pages="1--151",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6818",
url="https://www.rfc-editor.org/rfc/rfc5280.txt",
  key="RFC 5280",
  abstract={This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]},
  keywords="X.509 v3, X.509 v2, certificate extensions",
  doi="10.17487/RFC5280",
  }

@misc{rfc5281,
  author="P. Funk and S. Blake-Wilson",
  title="{Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)}",
  howpublished="RFC 5281 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5281",
  pages="1--51",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5281.txt",
  key="RFC 5281",
  abstract={EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase.  During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase.  During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel.  The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2.  Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.  The data phase may also be used for additional, arbitrary data exchange.  This memo provides information for the Internet community.},
  keywords="EAP, AAA, Authentication, TLS",
  doi="10.17487/RFC5281",
  }

@misc{rfc5282,
  author="D. Black and D. McGrew",
  title="{Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol}",
  howpublished="RFC 5282 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5282",
  pages="1--19",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5282.txt",
  key="RFC 5282",
  abstract={An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]},
  keywords="encryption cipher, combined mode algorithms, aes gcm, advanced encryption standard in galois/counter mode, aes ccm, aes in couner with cbc-mac mode",
  doi="10.17487/RFC5282",
  }

@misc{rfc5283,
  author="B. Decraene and JL. Le Roux and I. Minei",
  title="{LDP Extension for Inter-Area Label Switched Paths (LSPs)}",
  howpublished="RFC 5283 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5283",
  pages="1--12",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5283.txt",
  key="RFC 5283",
  abstract={To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]},
  keywords="LDP label mapping procedures, longest-match, prefix aggregation",
  doi="10.17487/RFC5283",
  }

@misc{rfc5284,
  author="G. Swallow and A. Farrel",
  title="{User-Defined Errors for RSVP}",
  howpublished="RFC 5284 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5284",
  pages="1--9",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5284.txt",
  key="RFC 5284",
  abstract={The Resource ReserVation Protocol (RSVP) defines an ERROR\_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER\_ERROR\_SPEC to be used in addition to the ERROR\_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]},
  keywords="resource reservation protocol, user\_error\_spec, error\_spec",
  doi="10.17487/RFC5284",
  }

@misc{rfc5285,
  author="D. Singer and H. Desineni",
  title="{A General Mechanism for RTP Header Extensions}",
  howpublished="RFC 5285 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5285",
  pages="1--17",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5285.txt",
  key="RFC 5285",
  abstract={This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized.  The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, extmap",
  doi="10.17487/RFC5285",
  }

@misc{rfc5286,
  author="A. Atlas and A. Zinin",
  title="{Basic Specification for IP Fast Reroute: Loop-Free Alternates}",
  howpublished="RFC 5286 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5286",
  pages="1--31",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5286.txt",
  key="RFC 5286",
  abstract={This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG).  The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure.  Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.  This simple approach does not require any support from other routers.  The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]},
  keywords="FRR, LFA, recovery, failure, routing",
  doi="10.17487/RFC5286",
  }

@misc{rfc5287,
  author="A. Vainshtein and Y(J). Stein",
  title="{Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks}",
  howpublished="RFC 5287 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5287",
  pages="1--16",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5287.txt",
  key="RFC 5287",
  abstract={This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]},
  keywords="pwe3, pseudowire emulation edge-to-edge, tdmoip, tdm options",
  doi="10.17487/RFC5287",
  }

@misc{rfc5288,
  author="J. Salowey and A. Choudhury and D. McGrew",
  title="{AES Galois Counter Mode (GCM) Cipher Suites for TLS}",
  howpublished="RFC 5288 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5288",
  pages="1--8",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5288.txt",
  key="RFC 5288",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation.  GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.  This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]},
  keywords="advanced encryption standard, transport layer security, data origin, confidentiality",
  doi="10.17487/RFC5288",
  }

@misc{rfc5289,
  author="E. Rescorla",
  title="{TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)}",
  howpublished="RFC 5289 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5289",
  pages="1--6",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5289.txt",
  key="RFC 5289",
  abstract={RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS).  However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm.  This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms.  Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM).  This memo provides information for the Internet community.},
  keywords="transport layer security, mac algorithm",
  doi="10.17487/RFC5289",
  }

@misc{rfc5290,
  author="S. Floyd and M. Allman",
  title="{Comments on the Usefulness of Simple Best-Effort Traffic}",
  howpublished="RFC 5290 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5290",
  pages="1--20",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5290.txt",
  key="RFC 5290",
  abstract={This document presents some observations on ``simple best-effort traffic'', defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like.  One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping.  While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic.  A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where ``flow-rate fairness'' is defined by the goal of equal flow rates for different flows over the same path.  This memo provides information for the Internet community.},
  keywords="flow-rate fairness",
  doi="10.17487/RFC5290",
  }

@misc{rfc5291,
  author="E. Chen and Y. Rekhter",
  title="{Outbound Route Filtering Capability for BGP-4}",
  howpublished="RFC 5291 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5291",
  pages="1--12",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5291.txt",
  key="RFC 5291",
  abstract={This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]},
  keywords="border gatway protocol, orf",
  doi="10.17487/RFC5291",
  }

@misc{rfc5292,
  author="E. Chen and S. Sangli",
  title="{Address-Prefix-Based Outbound Route Filter for BGP-4}",
  howpublished="RFC 5292 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5292",
  pages="1--6",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5292.txt",
  key="RFC 5292",
  abstract={This document defines a new Outbound Router Filter (ORF) type for BGP, termed ``Address Prefix Outbound Route Filter'', that can be used to perform address-prefix-based route filtering.  This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]},
  keywords="orf, border gateway protocol, Address Prefix Outbound Route Filter",
  doi="10.17487/RFC5292",
  }

@misc{rfc5293,
  author="J. Degener and P. Guenther",
  title="{Sieve Email Filtering: Editheader Extension}",
  howpublished="RFC 5293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5293",
  pages="1--9",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5293.txt",
  key="RFC 5293",
  abstract={This document defines two new actions for the ``Sieve'' email filtering language that add and delete email header fields. [STANDARDS-TRACK]},
  keywords="addheadaer, deleteheader",
  doi="10.17487/RFC5293",
  }

@misc{rfc5294,
  author="P. Savola and J. Lingard",
  title="{Host Threats to Protocol Independent Multicast (PIM)}",
  howpublished="RFC 5294 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5294",
  pages="1--12",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5294.txt",
  key="RFC 5294",
  abstract={This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts.  This memo provides information for the Internet community.},
  keywords="security threat analysis",
  doi="10.17487/RFC5294",
  }

@misc{rfc5295,
  author="J. Salowey and L. Dondeti and V. Narayanan and M. Nakhjiri",
  title="{Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)}",
  howpublished="RFC 5295 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5295",
  pages="1--21",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5295.txt",
  key="RFC 5295",
  abstract={The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses.  This memo reserves the EMSK for the sole purpose of deriving root keys.  Root keys are master keys that can be used for multiple purposes, identified by usage definitions.  This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation.  Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]},
  keywords="EAP keying, EMSK, DSRK, DSUSRK, Domain-Specific Key Derivation, Usage-Specific Key Derivation",
  doi="10.17487/RFC5295",
  }

@misc{rfc5296,
  author="V. Narayanan and L. Dondeti",
  title="{EAP Extensions for EAP Re-authentication Protocol (ERP)}",
  howpublished="RFC 5296 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5296",
  pages="1--43",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6696",
url="https://www.rfc-editor.org/rfc/rfc5296.txt",
  key="RFC 5296",
  abstract={The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.  In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator.  This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.  The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]},
  keywords="extensible authentication protocol, authentication modes",
  doi="10.17487/RFC5296",
  }

@misc{rfc5297,
  author="D. Harkins",
  title="{Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)}",
  howpublished="RFC 5297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5297",
  pages="1--26",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5297.txt",
  key="RFC 5297",
  abstract={This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation.  SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted.  It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector.  Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption.  This memo provides information for the Internet community.},
  keywords="authenticated encryption, key wrapping, key derivation, block cipher, pseudo-random function",
  doi="10.17487/RFC5297",
  }

@misc{rfc5298,
  author="T. Takeda and A. Farrel and Y. Ikejiri and JP. Vasseur",
  title="{Analysis of Inter-Domain Label Switched Path (LSP) Recovery}",
  howpublished="RFC 5298 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5298",
  pages="1--26",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5298.txt",
  key="RFC 5298",
  abstract={Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: ``A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering''. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.},
  keywords="mpls, gmpls, multi-domain environment, end-to-end diverse Traffic Engineering LSPs",
  doi="10.17487/RFC5298",
  }

@misc{rfc5301,
  author="D. McPherson and N. Shen",
  title="{Dynamic Hostname Exchange Mechanism for IS-IS}",
  howpublished="RFC 5301 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5301",
  pages="1--6",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6232",
url="https://www.rfc-editor.org/rfc/rfc5301.txt",
  key="RFC 5301",
  abstract={RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network. This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, routers, tlv, name-to-systemID",
  doi="10.17487/RFC5301",
  }

@misc{rfc5302,
  author="T. Li and H. Smit and T. Przygienda",
  title="{Domain-Wide Prefix Distribution with Two-Level IS-IS}",
  howpublished="RFC 5302 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5302",
  pages="1--16",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5302.txt",
  key="RFC 5302",
  abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, routers, loops, IP, internet protocol",
  doi="10.17487/RFC5302",
  }

@misc{rfc5303,
  author="D. Katz and R. Saluja and D. {Eastlake 3rd}",
  title="{Three-Way Handshake for IS-IS Point-to-Point Adjacencies}",
  howpublished="RFC 5303 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5303",
  pages="1--11",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5303.txt",
  key="RFC 5303",
  abstract={The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system",
  doi="10.17487/RFC5303",
  }

@misc{rfc5304,
  author="T. Li and R. Atkinson",
  title="{IS-IS Cryptographic Authentication}",
  howpublished="RFC 5304 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5304",
  pages="1--11",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6233, 6232",
url="https://www.rfc-editor.org/rfc/rfc5304.txt",
  key="RFC 5304",
  abstract={This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, IS-IS authentication, MD5, HMAC-MD5, security, routing, iso, international standards organization",
  doi="10.17487/RFC5304",
  }

@misc{rfc5305,
  author="T. Li and H. Smit",
  title="{IS-IS Extensions for Traffic Engineering}",
  howpublished="RFC 5305 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5305",
  pages="1--17",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5307",
url="https://www.rfc-editor.org/rfc/rfc5305.txt",
  key="RFC 5305",
  abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).  This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP).  This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, te, router, lsp  data units, link state protocol data units",
  doi="10.17487/RFC5305",
  }

@misc{rfc5306,
  author="M. Shand and L. Ginsberg",
  title="{Restart Signaling for IS-IS}",
  howpublished="RFC 5306 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5306",
  pages="1--22",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5306.txt",
  key="RFC 5306",
  abstract={This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, LSP database synchronization, Link State, Routing",
  doi="10.17487/RFC5306",
  }

@misc{rfc5307,
  author="K. Kompella and Y. Rekhter",
  title="{IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 5307 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5307",
  pages="1--12",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6001, 6002, 7074",
url="https://www.rfc-editor.org/rfc/rfc5307.txt",
  key="RFC 5307",
  abstract={This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system",
  doi="10.17487/RFC5307",
  }

@misc{rfc5308,
  author="C. Hopps",
  title="{Routing IPv6 with IS-IS}",
  howpublished="RFC 5308 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5308",
  pages="1--7",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7775",
url="https://www.rfc-editor.org/rfc/rfc5308.txt",
  key="RFC 5308",
  abstract={This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol.  The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain.  Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]},
  keywords="intermediate system to intermediate system, tlv, osi",
  doi="10.17487/RFC5308",
  }

@misc{rfc5309,
  author="N. Shen and A. Zinin",
  title="{Point-to-Point Operation over LAN in Link State Routing Protocols}",
  howpublished="RFC 5309 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5309",
  pages="1--10",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5309.txt",
  key="RFC 5309",
  abstract={The two predominant circuit types used by link state routing protocols are point-to-point and broadcast.  It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically.  This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing.  This memo provides information for the Internet community.},
  keywords="broadcast",
  doi="10.17487/RFC5309",
  }

@misc{rfc5310,
  author="M. Bhatia and V. Manral and T. Li and R. Atkinson and R. White and M. Fanto",
  title="{IS-IS Generic Cryptographic Authentication}",
  howpublished="RFC 5310 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5310",
  pages="1--12",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6233, 6232",
url="https://www.rfc-editor.org/rfc/rfc5310.txt",
  key="RFC 5310",
  abstract={This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]},
  keywords="IS-IS, Security, HMAC-SHA, Cryptographic Authentication",
  doi="10.17487/RFC5310",
  }

@misc{rfc5311,
  author="D. McPherson and L. Ginsberg and S. Previdi and M. Shand",
  title="{Simplified Extension of Link State PDU (LSP) Space for IS-IS}",
  howpublished="RFC 5311 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5311",
  pages="1--12",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5311.txt",
  key="RFC 5311",
  abstract={This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit.  This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5311",
  }

@misc{rfc5316,
  author="M. Chen and R. Zhang and X. Duan",
  title="{ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering}",
  howpublished="RFC 5316 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5316",
  pages="1--19",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5316.txt",
  key="RFC 5316",
  abstract={This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, generalized mpls, gmpls-te, mpls-te, isis-te, flooding",
  doi="10.17487/RFC5316",
  }

@misc{rfc5317,
  author="S. Bryant and L. Andersson",
  title="{Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile}",
  howpublished="RFC 5317 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5317",
  pages="1--10",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5317.txt",
  key="RFC 5317",
  abstract={This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks.  The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process.  This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides).  This memo provides information for the Internet community.},
  keywords="ITU-T, MPLS-TP, JWT, GMPLS, agreement, PWE3, OAM, transport network",
  doi="10.17487/RFC5317",
  }

@misc{rfc5318,
  author="J. Hautakorpi and G. Camarillo",
  title="{The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)}",
  howpublished="RFC 5318 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5318",
  pages="1--12",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5318.txt",
  key="RFC 5318",
  abstract={This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header).  This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system.  It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists.  This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list.  This memo provides information for the Internet community.},
  keywords="oma, open mobile alliance, push to talk over cellular, poc",
  doi="10.17487/RFC5318",
  }

@misc{rfc5320,
  author="F. Templin",
  title="{The Subnetwork Encapsulation and Adaptation Layer (SEAL)}",
  howpublished="RFC 5320 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5320",
  pages="1--29",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5320.txt",
  key="RFC 5320",
  abstract={For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes.  These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs).  This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.  This document defines an Experimental Protocol for the Internet community.},
  keywords="virtual topologies, mtu, maximum transmission units",
  doi="10.17487/RFC5320",
  }

@misc{rfc5321,
  author="J. Klensin",
  title="{Simple Mail Transfer Protocol}",
  howpublished="RFC 5321 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5321",
  pages="1--95",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7504",
url="https://www.rfc-editor.org/rfc/rfc5321.txt",
  key="RFC 5321",
  abstract={This document is a specification of the basic protocol for Internet electronic mail transport.  It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete.  It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions.  Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a ``mail submission'' protocol for ``split-UA'' (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]},
  keywords="SMTP]",
  doi="10.17487/RFC5321",
  }

@misc{rfc5322,
  author="P. Resnick",
  title="{Internet Message Format}",
  howpublished="RFC 5322 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5322",
  pages="1--57",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6854",
url="https://www.rfc-editor.org/rfc/rfc5322.txt",
  key="RFC 5322",
  abstract={This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of ``electronic mail'' messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, ``Standard for the Format of ARPA Internet Text Messages'', updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]},
  keywords="MAIL], e-mail, email, electronic mail, header, address, mailbox, reply, forward, resend, resent, folding, Date, From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Subject, Comments, Keywords, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Bcc, Resent-Reply-To, Resent-Message-ID, Return-Path, Received",
  doi="10.17487/RFC5322",
  }

@misc{rfc5323,
  author="J. Reschke and S. Reddy and J. Davis and A. Babich",
  title="{Web Distributed Authoring and Versioning (WebDAV) SEARCH}",
  howpublished="RFC 5323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5323",
  pages="1--49",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5323.txt",
  key="RFC 5323",
  abstract={This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]},
  keywords="HTTP, Query, Properties",
  doi="10.17487/RFC5323",
  }

@misc{rfc5324,
  author="C. DeSanti and F. Maino and K. McCloghrie",
  title="{MIB for Fibre-Channel Security Protocols (FC-SP)}",
  howpublished="RFC 5324 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5324",
  pages="1--216",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5324.txt",
  key="RFC 5324",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]},
  keywords="management information base, T11-FC-SP-TC-MIB, T11-FC-SP-AUTHENTICATION-MIB, T11-FC-SP-ZONING-MIB, T11-FC-SP-POLICY-MIB, T11-FC-SP-SA-MIB",
  doi="10.17487/RFC5324",
  }

@misc{rfc5325,
  author="S. Burleigh and M. Ramadas and S. Farrell",
  title="{Licklider Transmission Protocol - Motivation}",
  howpublished="RFC 5325 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5325",
  pages="1--23",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5325.txt",
  key="RFC 5325",
  abstract={This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting ``long-haul'' reliable transmission in interplanetary space, but it has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.},
  keywords="ltp, round-trip times, long-haul",
  doi="10.17487/RFC5325",
  }

@misc{rfc5326,
  author="M. Ramadas and S. Burleigh and S. Farrell",
  title="{Licklider Transmission Protocol - Specification}",
  howpublished="RFC 5326 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5326",
  pages="1--54",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5326.txt",
  key="RFC 5326",
  abstract={This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting ``long-haul'' reliable transmission in interplanetary space, but it has applications in other environments as well. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.},
  keywords="ltp, round-trip times, rtt, long-haul",
  doi="10.17487/RFC5326",
  }

@misc{rfc5327,
  author="S. Farrell and M. Ramadas and S. Burleigh",
  title="{Licklider Transmission Protocol - Security Extensions}",
  howpublished="RFC 5327 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5327",
  pages="1--11",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5327.txt",
  key="RFC 5327",
  abstract={The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.},
  keywords="ltp, radio frequency, automatic repeat request, arq",
  doi="10.17487/RFC5327",
  }

@misc{rfc5328,
  author="A. Adolf and P. MacAvock",
  title="{A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)}",
  howpublished="RFC 5328 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5328",
  pages="1--12",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7354",
url="https://www.rfc-editor.org/rfc/rfc5328.txt",
  key="RFC 5328",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards.  Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB.  This memo provides information for the Internet community.},
  keywords="tv, television, digital television, mpeg-2, iptv, multimedia, content guide, program guide, metadata",
  doi="10.17487/RFC5328",
  }

@misc{rfc5329,
  author="K. Ishiguro and V. Manral and A. Davey and A. Lindem",
  title="{Traffic Engineering Extensions to OSPF Version 3}",
  howpublished="RFC 5329 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5329",
  pages="1--12",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5329.txt",
  key="RFC 5329",
  abstract={This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE).  This document extends OSPFv2 TE to handle IPv6 networks.  A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]},
  keywords="open shortest path first, ospfv3, te",
  doi="10.17487/RFC5329",
  }

@misc{rfc5330,
  author="JP. Vasseur and M. Meyer and K. Kumaki and A. Bonda",
  title="{A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link}",
  howpublished="RFC 5330 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5330",
  pages="1--8",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5330.txt",
  key="RFC 5330",
  abstract={Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on.  By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as ``unconstrained TE LSP'' in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths.  This requires knowledge of the number of unconstrained TE LSPs signalled across a link.  This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]},
  keywords="te, lsp",
  doi="10.17487/RFC5330",
  }

@misc{rfc5331,
  author="R. Aggarwal and Y. Rekhter and E. Rosen",
  title="{MPLS Upstream Label Assignment and Context-Specific Label Space}",
  howpublished="RFC 5331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5331",
  pages="1--13",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc5331.txt",
  key="RFC 5331",
  abstract={RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels.  This document introduces the notion of upstream-assigned MPLS labels.  It describes the procedures for upstream MPLS label assignment and introduces the concept of a ``Context-Specific Label Space''. [STANDARDS-TRACK]},
  keywords="upstream-assigned mpls labels",
  doi="10.17487/RFC5331",
  }

@misc{rfc5332,
  author="T. Eckert and E. Rosen and R. Aggarwal and Y. Rekhter",
  title="{MPLS Multicast Encapsulations}",
  howpublished="RFC 5332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5332",
  pages="1--11",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5332.txt",
  key="RFC 5332",
  abstract={RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the ``multicast codepoint'') is now to be used only on multiaccess media, and it is to mean ``the top label of the following label stack is an upstream-assigned label''. RFC 3032 does not specify the destination address to be placed in the ``MAC DA'' (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]},
  keywords="data link layer codepoint, multiaccess media, upstream-assigned label, mac da, medium access layer destination address",
  doi="10.17487/RFC5332",
  }

@misc{rfc5333,
  author="R. Mahy and B. Hoeneisen",
  title="{IANA Registration of Enumservices for Internet Calendaring}",
  howpublished="RFC 5333 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5333",
  pages="1--8",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6118",
url="https://www.rfc-editor.org/rfc/rfc5333.txt",
  key="RFC 5333",
  abstract={This document registers Enumservices for Internet calendaring.  Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]},
  keywords="ENUM, iCal, iMIP, i TIP, CalDAV",
  doi="10.17487/RFC5333",
  }

@misc{rfc5334,
  author="I. Goncalves and S. Pfeiffer and C. Montgomery",
  title="{Ogg Media Types}",
  howpublished="RFC 5334 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5334",
  pages="1--14",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7845",
url="https://www.rfc-editor.org/rfc/rfc5334.txt",
  key="RFC 5334",
  abstract={This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types.  This document obsoletes RFC 3534. [STANDARDS-TRACK]},
  keywords="Ogg, MIME, Video, Audio, Codecs",
  doi="10.17487/RFC5334",
  }

@misc{rfc5335,
  author="A. Yang",
  title="{Internationalized Email Headers}",
  howpublished="RFC 5335 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5335",
  pages="1--14",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6532",
url="https://www.rfc-editor.org/rfc/rfc5335.txt",
  key="RFC 5335",
  abstract={Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses.  It also requires being able to express those addresses and the information based on them in mail header fields.  This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.  This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification.  This specification Updates section 6.4 of RFC 2045 to conform with the requirements.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="unicode, utf-8",
  doi="10.17487/RFC5335",
  }

@misc{rfc5336,
  author="J. Yao and W. Mao",
  title="{SMTP Extension for Internationalized Email Addresses}",
  howpublished="RFC 5336 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5336",
  pages="1--22",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6531",
url="https://www.rfc-editor.org/rfc/rfc5336.txt",
  key="RFC 5336",
  abstract={This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information.  Communication with systems that do not implement this specification is specified in another document.  This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.},
  keywords="EAI, UTF8SMTP, MAIL, TRANSFER",
  doi="10.17487/RFC5336",
  }

@misc{rfc5337,
  author="C. Newman and A. Melnikov",
  title="{Internationalized Delivery Status and Disposition Notifications}",
  howpublished="RFC 5337 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5337",
  pages="1--18",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6533",
url="https://www.rfc-editor.org/rfc/rfc5337.txt",
  key="RFC 5337",
  abstract={Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.},
  keywords="EAI, DSN, SMTP",
  doi="10.17487/RFC5337",
  }

@misc{rfc5338,
  author="T. Henderson and P. Nikander and M. Komu",
  title="{Using the Host Identity Protocol with Legacy Applications}",
  howpublished="RFC 5338 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5338",
  pages="1--14",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5338.txt",
  key="RFC 5338",
  abstract={This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP).  HIP proposes to add a cryptographic name space for network stack names.  From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded.  This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.  This memo provides information for the Internet community.},
  keywords="hip, cryptographic name space, network stack names, api, application programming interface",
  doi="10.17487/RFC5338",
  }

@misc{rfc5339,
  author="JL. Le Roux and D. Papadimitriou",
  title="{Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)}",
  howpublished="RFC 5339 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5339",
  pages="1--25",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5339.txt",
  key="RFC 5339",
  abstract={This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs).  In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions.  This memo provides information for the Internet community.},
  keywords="general multiprotocol label switching",
  doi="10.17487/RFC5339",
  }

@misc{rfc5340,
  author="R. Coltun and D. Ferguson and J. Moy and A. Lindem",
  title="{OSPF for IPv6}",
  howpublished="RFC 5340 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5340",
  pages="1--94",
  year=2008,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6845, 6860, 7503",
url="https://www.rfc-editor.org/rfc/rfc5340.txt",
  key="RFC 5340",
  abstract={This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]},
  keywords="open shortest path first, ospfv3",
  doi="10.17487/RFC5340",
  }

@misc{rfc5341,
  author="C. Jennings and V. Gurbani",
  title="{The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry}",
  howpublished="RFC 5341 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5341",
  pages="1--7",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5341.txt",
  key="RFC 5341",
  abstract={This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values.  It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]},
  keywords="uniform resource locator, schemes",
  doi="10.17487/RFC5341",
  }

@misc{rfc5342,
  author="D. {Eastlake 3rd}",
  title="{IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters}",
  howpublished="RFC 5342 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5342",
  pages="1--21",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7042",
url="https://www.rfc-editor.org/rfc/rfc5342.txt",
  key="RFC 5342",
  abstract={Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Ethernet, Ethertype, 802, OUI, EUI, LSAP",
  doi="10.17487/RFC5342",
  }

@misc{rfc5343,
  author="J. Schoenwaelder",
  title="{Simple Network Management Protocol (SNMP) Context EngineID Discovery}",
  howpublished="RFC 5343 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5343",
  pages="1--9",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5343.txt",
  key="RFC 5343",
  abstract={The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. This document updates RFC 3411. [STANDARDS-TRACK]},
  keywords="snmpv3, snmpengineid, localengineid",
  doi="10.17487/RFC5343",
  }

@misc{rfc5344,
  author="A. Houri and E. Aoki and S. Parameswar",
  title="{Presence and Instant Messaging Peering Use Cases}",
  howpublished="RFC 5344 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5344",
  pages="1--9",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5344.txt",
  key="RFC 5344",
  abstract={This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers.  These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network.  The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM).  This memo provides information for the Internet community.},
  keywords="non-voip, collaboration service, instant messaging, im",
  doi="10.17487/RFC5344",
  }

@misc{rfc5345,
  author="J. Schoenwaelder",
  title="{Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats}",
  howpublished="RFC 5345 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5345",
  pages="1--23",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5345.txt",
  key="RFC 5345",
  abstract={The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.},
  keywords="large-scale snmp, irtf, nmrg, network management research group",
  doi="10.17487/RFC5345",
  }

@misc{rfc5346,
  author="J. Lim and W. Kim and C. Park and L. Conroy",
  title="{Operational Requirements for ENUM-Based Softswitch Use}",
  howpublished="RFC 5346 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5346",
  pages="1--14",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5346.txt",
  key="RFC 5346",
  abstract={This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.},
  keywords="Applications, ENUM, DNS, E.164, NAPTR, Softswitch, Field Trial",
  doi="10.17487/RFC5346",
  }

@misc{rfc5347,
  author="F. Andreasen and D. Hancock",
  title="{Media Gateway Control Protocol Fax Package}",
  howpublished="RFC 5347 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5347",
  pages="1--46",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5347.txt",
  key="RFC 5347",
  abstract={This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls.  The package allows for fax calls to be supported in two different ways.  The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent.  The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.  This memo provides information for the Internet community.},
  keywords="mgcp, fax calls, fax relay, fax transmission",
  doi="10.17487/RFC5347",
  }

@misc{rfc5348,
  author="S. Floyd and M. Handley and J. Padhye and J. Widmer",
  title="{TCP Friendly Rate Control (TFRC): Protocol Specification}",
  howpublished="RFC 5348 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5348",
  pages="1--58",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5348.txt",
  key="RFC 5348",
  abstract={This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]},
  keywords="tcp-friendly rate control, congestion control",
  doi="10.17487/RFC5348",
  }

@misc{rfc5349,
  author="L. Zhu and K. Jaganathan and K. Lauter",
  title="{Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}",
  howpublished="RFC 5349 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5349",
  pages="1--10",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5349.txt",
  key="RFC 5349",
  abstract={This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography.  This memo provides information for the Internet community.},
  keywords="ecdh, elliptic curve diffie-hellman",
  doi="10.17487/RFC5349",
  }

@misc{rfc5350,
  author="J. Manner and A. McDonald",
  title="{IANA Considerations for the IPv4 and IPv6 Router Alert Options}",
  howpublished="RFC 5350 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5350",
  pages="1--8",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5350.txt",
  key="RFC 5350",
  abstract={This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5350",
  }

@misc{rfc5351,
  author="P. Lei and L. Ong and M. Tuexen and T. Dreibholz",
  title="{An Overview of Reliable Server Pooling Protocols}",
  howpublished="RFC 5351 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5351",
  pages="1--15",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5351.txt",
  key="RFC 5351",
  abstract={The Reliable Server Pooling effort (abbreviated ``RSerPool'') provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications.  This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite.  This memo provides information for the Internet community.},
  keywords="rserpool",
  doi="10.17487/RFC5351",
  }

@misc{rfc5352,
  author="R. Stewart and Q. Xie and M. Stillman and M. Tuexen",
  title="{Aggregate Server Access Protocol (ASAP)}",
  howpublished="RFC 5352 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5352",
  pages="1--53",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5352.txt",
  key="RFC 5352",
  abstract={Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol. The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.},
  keywords="rserpool, enrp, endpoint handlespace redundancy protocol",
  doi="10.17487/RFC5352",
  }

@misc{rfc5353,
  author="Q. Xie and R. Stewart and M. Stillman and M. Tuexen and A. Silverton",
  title="{Endpoint Handlespace Redundancy Protocol (ENRP)}",
  howpublished="RFC 5353 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5353",
  pages="1--39",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5353.txt",
  key="RFC 5353",
  abstract={The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture.  Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="rserpool, asap, aggregate server access protocol, fault-tolerant registry",
  doi="10.17487/RFC5353",
  }

@misc{rfc5354,
  author="R. Stewart and Q. Xie and M. Stillman and M. Tuexen",
  title="{Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters}",
  howpublished="RFC 5354 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5354",
  pages="1--23",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5354.txt",
  key="RFC 5354",
  abstract={This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="rserpool",
  doi="10.17487/RFC5354",
  }

@misc{rfc5355,
  author="M. Stillman and R. Gopal and E. Guttman and S. Sengodan and M. Holdrege",
  title="{Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats}",
  howpublished="RFC 5355 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5355",
  pages="1--19",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5355.txt",
  key="RFC 5355",
  abstract={Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool.  This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5355",
  }

@misc{rfc5356,
  author="T. Dreibholz and M. Tuexen",
  title="{Reliable Server Pooling Policies}",
  howpublished="RFC 5356 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5356",
  pages="1--16",
  year=2008,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5356.txt",
  key="RFC 5356",
  abstract={This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="rserpool, enrp, endpoint handlespace redundancy protocol",
  doi="10.17487/RFC5356",
  }

@misc{rfc5357,
  author="K. Hedayat and R. Krzanowski and A. Morton and K. Yum and J. Babiarz",
  title="{A Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 5357 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5357",
  pages="1--26",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5618, 5938, 6038, 7717, 7750",
url="https://www.rfc-editor.org/rfc/rfc5357.txt",
  key="RFC 5357",
  abstract={The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices.  OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements.  However, it does not accommodate round-trip or two-way measurements.  This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities.  The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]},
  keywords="two-way measaurement, round-trip measurement",
  doi="10.17487/RFC5357",
  }

@misc{rfc5358,
  author="J. Damas and F. Neves",
  title="{Preventing Use of Recursive Nameservers in Reflector Attacks}",
  howpublished="RFC 5358 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5358",
  pages="1--7",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5358.txt",
  key="RFC 5358",
  abstract={This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks.  It provides recommended configuration as measures to mitigate the attack.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="denial of service, dos",
  doi="10.17487/RFC5358",
  }

@misc{rfc5359,
  author="A. Johnston and R. Sparks and C. Cunningham and S. Donovan and K. Summers",
  title="{Session Initiation Protocol Service Examples}",
  howpublished="RFC 5359 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5359",
  pages="1--170",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5359.txt",
  key="RFC 5359",
  abstract={This document gives examples of Session Initiation Protocol (SIP) services.  This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features.  Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy.  Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields.  These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="sip, pbx, centrex, features, hold, transfer, forwarding, screening, park, pickup, redial, click, call flows",
  doi="10.17487/RFC5359",
  }

@misc{rfc5360,
  author="J. Rosenberg and G. Camarillo and D. Willis",
  title="{A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5360 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5360",
  pages="1--31",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5360.txt",
  key="RFC 5360",
  abstract={SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence.  In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient.  Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks.  This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5360",
  }

@misc{rfc5361,
  author="G. Camarillo",
  title="{A Document Format for Requesting Consent}",
  howpublished="RFC 5361 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5361",
  pages="1--14",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5361.txt",
  key="RFC 5361",
  abstract={This document defines an Extensible Markup Language (XML) format for a permission document used to request consent.  A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]},
  keywords="xml, extensible markup language, premission document",
  doi="10.17487/RFC5361",
  }

@misc{rfc5362,
  author="G. Camarillo",
  title="{The Session Initiation Protocol (SIP) Pending Additions Event Package}",
  howpublished="RFC 5362 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5362",
  pages="1--16",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5362.txt",
  key="RFC 5362",
  abstract={This document defines the SIP Pending Additions event package.  This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]},
  keywords="consent-related, resource list",
  doi="10.17487/RFC5362",
  }

@misc{rfc5363,
  author="G. Camarillo and A.B. Roach",
  title="{Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services}",
  howpublished="RFC 5363 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5363",
  pages="1--10",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5363.txt",
  key="RFC 5363",
  abstract={This document describes the need for SIP URI-list services and provides requirements for their invocation.  Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5363",
  }

@misc{rfc5364,
  author="M. Garcia-Martin and G. Camarillo",
  title="{Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists}",
  howpublished="RFC 5364 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5364",
  pages="1--17",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5364.txt",
  key="RFC 5364",
  abstract={In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs).  The sender sends a single SIP request to a server which further distributes the request to the group.  This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request.  This URI list is expressed as a resource list XML document.  This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]},
  keywords="XML, copy, control, resource, list",
  doi="10.17487/RFC5364",
  }

@misc{rfc5365,
  author="M. Garcia-Martin and G. Camarillo",
  title="{Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5365 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5365",
  pages="1--18",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5365.txt",
  key="RFC 5365",
  abstract={This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service.  The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]},
  keywords="user agent client, uac, sip message request, uniform resource identifier list, message uri list",
  doi="10.17487/RFC5365",
  }

@misc{rfc5366,
  author="G. Camarillo and A. Johnston",
  title="{Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5366 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5366",
  pages="1--13",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5366.txt",
  key="RFC 5366",
  abstract={This document describes how to create a conference using SIP URI-list services.  In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]},
  keywords="sip uri list, invite-contatined uri",
  doi="10.17487/RFC5366",
  }

@misc{rfc5367,
  author="G. Camarillo and A.B. Roach and O. Levin",
  title="{Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5367 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5367",
  pages="1--9",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5367.txt",
  key="RFC 5367",
  abstract={This document specifies a way to create subscription to a list of resources in SIP.  This is achieved by including the list of resources in the body of a SUBSCRIBE request.  Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]},
  keywords="subscribe request, resrouce list",
  doi="10.17487/RFC5367",
  }

@misc{rfc5368,
  author="G. Camarillo and A. Niemi and M. Isomaki and M. Garcia-Martin and H. Khartabil",
  title="{Referring to Multiple Resources in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5368",
  pages="1--13",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5368.txt",
  key="RFC 5368",
  abstract={This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request.  These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the ``multiple-refer'' SIP option-tag. [STANDARDS-TRACK]},
  keywords="sip refer, refer-to, multipler-refer",
  doi="10.17487/RFC5368",
  }

@misc{rfc5369,
  author="G. Camarillo",
  title="{Framework for Transcoding with the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5369 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5369",
  pages="1--10",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5369.txt",
  key="RFC 5369",
  abstract={This document defines a framework for transcoding with SIP.  This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services.  Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model.  Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.  This memo provides information for the Internet community.},
  keywords="transcoding services, conference bridge model, third-party call control model, deaf, hard of hearing, speech-impaired",
  doi="10.17487/RFC5369",
  }

@misc{rfc5370,
  author="G. Camarillo",
  title="{The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model}",
  howpublished="RFC 5370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5370",
  pages="1--11",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5370.txt",
  key="RFC 5370",
  abstract={This document describes how to invoke transcoding services using the conference bridge model.  This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]},
  keywords="transcoding service, deaf, hard of hearing, speech-impaired",
  doi="10.17487/RFC5370",
  }

@misc{rfc5371,
  author="S. Futemma and E. Itakura and A. Leung",
  title="{RTP Payload Format for JPEG 2000 Video Streams}",
  howpublished="RFC 5371 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5371",
  pages="1--31",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5371.txt",
  key="RFC 5371",
  abstract={This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec.  T.800, better known as JPEG 2000.  JPEG 2000 features are considered in the design of this payload format.  JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways.  The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]},
  keywords="JPEG 2000 video, RTP, Real-time Transport Protocol, main header, tile number, Sony Corporation",
  doi="10.17487/RFC5371",
  }

@misc{rfc5372,
  author="A. Leung and S. Futemma and E. Itakura",
  title="{Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery}",
  howpublished="RFC 5372 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5372",
  pages="1--26",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5372.txt",
  key="RFC 5372",
  abstract={This memo describes extended uses for the payload header in ``RTP Payload Format for JPEG 2000 Video Streams'' as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery. This memo must be accompanied with a complete implementation of ``RTP Payload Format for JPEG 2000 Video Streams''. That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]},
  keywords="Real-time Transport Protocol, main header compensation, priority field, priority mapping table, packet-number-based ordering, progression-based ordering, layer-based ordering, resolution-based ordering, component-based ordering, Sony Corporation",
  doi="10.17487/RFC5372",
  }

@misc{rfc5373,
  author="D. Willis and A. Allen",
  title="{Requesting Answering Modes for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5373 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5373",
  pages="1--24",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5373.txt",
  key="RFC 5373",
  abstract={This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request.  The first header, ``Answer-Mode'', expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input.  The second header, ``Priv-Answer-Mode'', is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements.  These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back.  Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]},
  keywords="PoC, PTT, auto, automatic, manual, answer, loopback, diagnostic, answer-mode, priv-answer-mode",
  doi="10.17487/RFC5373",
  }

@misc{rfc5374,
  author="B. Weis and G. Gross and D. Ignjatic",
  title="{Multicast Extensions to the Security Architecture for the Internet Protocol}",
  howpublished="RFC 5374 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5374",
  pages="1--38",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5374.txt",
  key="RFC 5374",
  abstract={The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer.  That architecture primarily defines services for Internet Protocol (IP) unicast packets.  This document describes how the IPsec security services are applied to IP multicast packets.  These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]},
  keywords="ip, ipsec, ip multicast packets",
  doi="10.17487/RFC5374",
  }

@misc{rfc5375,
  author="G. Van de Velde and C. Popoviciu and T. Chown and O. Bonness and C. Hahn",
  title="{IPv6 Unicast Address Assignment Considerations}",
  howpublished="RFC 5375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5375",
  pages="1--35",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5375.txt",
  key="RFC 5375",
  abstract={One fundamental aspect of any IP communications infrastructure is its addressing plan.  With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing.  Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6.  This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments.  The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.  This memo provides information for the Internet community.},
  keywords="internet protocol version 6, address architecture",
  doi="10.17487/RFC5375",
  }

@misc{rfc5376,
  author="N. Bitar and R. Zhang and K. Kumaki",
  title="{Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)}",
  howpublished="RFC 5376 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5376",
  pages="1--14",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5376.txt",
  key="RFC 5376",
  abstract={Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in ``Path Computation Element (PCE) Communication Protocol Generic Requirements'', RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.},
  keywords="PCE, PCECP, inter-AS PCE, inter-provider PCE, inter-AS MPLS-TE, inter-provider MPLS-TE, inter-AS PCECP, inter-provider PCECP, GMPLS path computation, MPLS-TE path computation, path computation element, path computation communication protocol, path computing element, Interas, Interas TE",
  doi="10.17487/RFC5376",
  }

@misc{rfc5377,
  author="J. Halpern",
  title="{Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents}",
  howpublished="RFC 5377 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5377",
  pages="1--8",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5377.txt",
  key="RFC 5377",
  abstract={Contributors grant intellectual property rights to the IETF.  The IETF Trust holds and manages those rights on behalf of the IETF.  The Trustees of the IETF Trust are responsible for that management.  This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs.  The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted.  This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions.  This memo provides information for the Internet community.},
  keywords="contributors, ietf contributions, outbound rights",
  doi="10.17487/RFC5377",
  }

@misc{rfc5378,
  author="S. Bradner and J. Contreras",
  title="{Rights Contributors Provide to the IETF Trust}",
  howpublished="RFC 5378 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5378",
  pages="1--16",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5378.txt",
  key="RFC 5378",
  abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible.  This memo details the IETF policies on rights in Contributions to the IETF.  It also describes the objectives that the policies are designed to meet.  This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="intellectual property rights, copyright, ipr",
  doi="10.17487/RFC5378",
  }

@misc{rfc5379,
  author="M. Munakata and S. Schubert and T. Ohba",
  title="{Guidelines for Using the Privacy Mechanism for SIP}",
  howpublished="RFC 5379 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5379",
  pages="1--23",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5379.txt",
  key="RFC 5379",
  abstract={This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244.  It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SIP, Privacy, priv-value, guideline",
  doi="10.17487/RFC5379",
  }

@misc{rfc5380,
  author="H. Soliman and C. Castelluccia and K. ElMalki and L. Bellier",
  title="{Hierarchical Mobile IPv6 (HMIPv6) Mobility Management}",
  howpublished="RFC 5380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5380",
  pages="1--26",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5380.txt",
  key="RFC 5380",
  abstract={This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling.  Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent.  The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]},
  keywords="mobile ipv6, ipv6 neighbor discovery, map, mobility anchor point",
  doi="10.17487/RFC5380",
  }

@misc{rfc5381,
  author="T. Iijima and Y. Atarashi and H. Kimura and M. Kitani and H. Okita",
  title="{Experience of Implementing NETCONF over SOAP}",
  howpublished="RFC 5381 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5381",
  pages="1--22",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5381.txt",
  key="RFC 5381",
  abstract={This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server.  It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP.  When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available.  By making full use of these tools, developers can significantly reduce their workload.  The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP.  This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server.  This memo provides information for the Internet community.},
  keywords="simple object access protocol, network configuration protocol, mns, network management system",
  doi="10.17487/RFC5381",
  }

@misc{rfc5382,
  author="S. Guha and K. Biswas and B. Ford and S. Sivakumar and P. Srisuresh",
  title="{NAT Behavioral Requirements for TCP}",
  howpublished="RFC 5382 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5382",
  pages="1--31",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7857",
url="https://www.rfc-editor.org/rfc/rfc5382.txt",
  key="RFC 5382",
  abstract={This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently.  Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="network address translation",
  doi="10.17487/RFC5382",
  }

@misc{rfc5383,
  author="R. Gellens",
  title="{Deployment Considerations for Lemonade-Compliant Mobile Email}",
  howpublished="RFC 5383 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5383",
  pages="1--12",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5383.txt",
  key="RFC 5383",
  abstract={This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC5383",
  }

@misc{rfc5384,
  author="A. Boers and I. Wijnands and E. Rosen",
  title="{The Protocol Independent Multicast (PIM) Join Attribute Format}",
  howpublished="RFC 5384 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5384",
  pages="1--10",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7887",
url="https://www.rfc-editor.org/rfc/rfc5384.txt",
  key="RFC 5384",
  abstract={A ``Protocol Independent Multicast - Sparse Mode'' Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join.  Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a ``wild card'').  Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree.  However, there has been no way to do so until now.  This document describes a modification of the Join message that allows a node to associate attributes with a particular tree.  The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]},
  keywords="pim-sm, multicast distribution tree, pim join attribute, attr\_type",
  doi="10.17487/RFC5384",
  }

@misc{rfc5385,
  author="J. Touch",
  title="{Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs}",
  howpublished="RFC 5385 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5385",
  pages="1--20",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5385.txt",
  key="RFC 5385",
  abstract={This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="writing I-Ds, writing RFCs, authoring,  tools, document preparation",
  doi="10.17487/RFC5385",
  }

@misc{rfc5386,
  author="N. Williams and M. Richardson",
  title="{Better-Than-Nothing Security: An Unauthenticated Mode of IPsec}",
  howpublished="RFC 5386 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5386",
  pages="1--11",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5386.txt",
  key="RFC 5386",
  abstract={This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup ``unauthenticated'' security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH).  No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified.  Unauthenticated IPsec is herein referred to by its popular acronym, ``BTNS'' (Better-Than-Nothing Security). [STANDARDS-TRACK]},
  keywords="internet protocol security, ikev1, ikev2, sas, esp, ah, pad, spd, btns, unauthenticated ipsec",
  doi="10.17487/RFC5386",
  }

@misc{rfc5387,
  author="J. Touch and D. Black and Y. Wang",
  title="{Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)}",
  howpublished="RFC 5387 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5387",
  pages="1--28",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5387.txt",
  key="RFC 5387",
  abstract={The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing ``better-than-nothing security'' (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.},
  keywords="ipsec, stand-alone btns, sab, channel-bound btns, cbb",
  doi="10.17487/RFC5387",
  }

@misc{rfc5388,
  author="S. Niccolini and S. Tartarelli and J. Quittek and T. Dietz and M. Swany",
  title="{Information Model and XML Data Model for Traceroute Measurements}",
  howpublished="RFC 5388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5388",
  pages="1--75",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5388.txt",
  key="RFC 5388",
  abstract={This document describes a standard way to store the configuration and the results of traceroute measurements.  This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements).  Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier.  On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]},
  keywords="extensible markup language, DISMAN-TRACEROUTE-MIB",
  doi="10.17487/RFC5388",
  }

@misc{rfc5389,
  author="J. Rosenberg and R. Mahy and P. Matthews and D. Wing",
  title="{Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 5389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5389",
  pages="1--51",
  year=2008,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7350",
url="https://www.rfc-editor.org/rfc/rfc5389.txt",
  key="RFC 5389",
  abstract={Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. [STANDARDS-TRACK]},
  keywords="SIPs, NAT, STUN, Traversal, ICE, firewall, TURN, VOIP",
  doi="10.17487/RFC5389",
  }

@misc{rfc5390,
  author="J. Rosenberg",
  title="{Requirements for Management of Overload in the Session Initiation Protocol}",
  howpublished="RFC 5390 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5390",
  pages="1--14",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5390.txt",
  key="RFC 5390",
  abstract={Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request.  SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded.  However, numerous problems have been identified with this mechanism.  This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.  This memo provides information for the Internet community.},
  keywords="sip, overload handling, 503 response",
  doi="10.17487/RFC5390",
  }

@misc{rfc5391,
  author="A. Sollaud",
  title="{RTP Payload Format for ITU-T Recommendation G.711.1}",
  howpublished="RFC 5391 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5391",
  pages="1--14",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5391.txt",
  key="RFC 5391",
  abstract={This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec.  Two media type registrations are also included. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, itu telecommunication standardization sector, audio coded, pcmu-wb, pcma-wb",
  doi="10.17487/RFC5391",
  }

@misc{rfc5392,
  author="M. Chen and R. Zhang and X. Duan",
  title="{OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering}",
  howpublished="RFC 5392 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5392",
  pages="1--17",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5392.txt",
  key="RFC 5392",
  abstract={This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, generalized mpls, gmpls-te, mpls-te, isis-te, open shortest path first, ospf-te",
  doi="10.17487/RFC5392",
  }

@misc{rfc5393,
  author="R. Sparks and S. Lawrence and A. Hawrylyshen and B. Campen",
  title="{Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies}",
  howpublished="RFC 5393 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5393",
  pages="1--20",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5393.txt",
  key="RFC 5393",
  abstract={This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]},
  keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast",
  doi="10.17487/RFC5393",
  }

@misc{rfc5394,
  author="I. Bryskin and D. Papadimitriou and L. Berger and J. Ash",
  title="{Policy-Enabled Path Computation Framework}",
  howpublished="RFC 5394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5394",
  pages="1--36",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5394.txt",
  key="RFC 5394",
  abstract={The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation.  This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy.  This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy.  This document also provides representative scenarios for the support of PCE Policy.  This memo provides information for the Internet community.},
  keywords="PCE, pce policy",
  doi="10.17487/RFC5394",
  }

@misc{rfc5395,
  author="D. {Eastlake 3rd}",
  title="{Domain Name System (DNS) IANA Considerations}",
  howpublished="RFC 5395 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5395",
  pages="1--17",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6195",
url="https://www.rfc-editor.org/rfc/rfc5395.txt",
  key="RFC 5395",
  abstract={Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="RRTYPE, RCODE, AFSDB",
  doi="10.17487/RFC5395",
  }

@misc{rfc5396,
  author="G. Huston and G. Michaelson",
  title="{Textual Representation of Autonomous System (AS) Numbers}",
  howpublished="RFC 5396 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5396",
  pages="1--3",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5396.txt",
  key="RFC 5396",
  abstract={A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number.  This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]},
  keywords="decimal value",
  doi="10.17487/RFC5396",
  }

@misc{rfc5397,
  author="W. Sanchez and C. Daboo",
  title="{WebDAV Current Principal Extension}",
  howpublished="RFC 5397 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5397",
  pages="1--5",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5397.txt",
  key="RFC 5397",
  abstract={This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]},
  keywords="http, webdav, access control, acl, authentication",
  doi="10.17487/RFC5397",
  }

@misc{rfc5398,
  author="G. Huston",
  title="{Autonomous System (AS) Number Reservation for Documentation Use}",
  howpublished="RFC 5398 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5398",
  pages="1--4",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5398.txt",
  key="RFC 5398",
  abstract={To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like.  This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation.  This memo provides information for the Internet community.},
  keywords="autonomous system numbers, asn",
  doi="10.17487/RFC5398",
  }

@misc{rfc5401,
  author="B. Adamson and C. Bormann and M. Handley and J. Macker",
  title="{Multicast Negative-Acknowledgment (NACK) Building Blocks}",
  howpublished="RFC 5401 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5401",
  pages="1--42",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5401.txt",
  key="RFC 5401",
  abstract={This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback.  The rationale for protocol design goals and assumptions are presented.  Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified.  These goals and challenges are resolved into a set of functional ``building blocks'' that address different aspects of reliable multicast protocol operation.  It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.  This document obsoletes RFC 3941. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5401",
  }

@misc{rfc5402,
  author="T. Harding",
  title="{Compressed Data within an Internet Electronic Data Interchange (EDI) Message}",
  howpublished="RFC 5402 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5402",
  pages="1--7",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5402.txt",
  key="RFC 5402",
  abstract={This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="internet edi",
  doi="10.17487/RFC5402",
  }

@misc{rfc5403,
  author="M. Eisler",
  title="{RPCSEC\_GSS Version 2}",
  howpublished="RFC 5403 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5403",
  pages="1--14",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7861",
url="https://www.rfc-editor.org/rfc/rfc5403.txt",
  key="RFC 5403",
  abstract={This document describes version 2 of the RPCSEC\_GSS protocol.  Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added.  RPCSEC\_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]},
  keywords="Kerberos, ONC, RPC, security, authentication, integrity, GSS, GSS-API, privacy, confidentiality, encryption, MIC, NFS, credential, verifier, mechanism, context",
  doi="10.17487/RFC5403",
  }

@misc{rfc5404,
  author="M. Westerlund and I. Johansson",
  title="{RTP Payload Format for G.719}",
  howpublished="RFC 5404 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5404",
  pages="1--27",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5404.txt",
  key="RFC 5404",
  abstract={This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]},
  keywords="ITU-T, g.719 full-band codec",
  doi="10.17487/RFC5404",
  }

@misc{rfc5405,
  author="L. Eggert and G. Fairhurst",
  title="{Unicast UDP Usage Guidelines for Application Designers}",
  howpublished="RFC 5405 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5405",
  pages="1--27",
  year=2008,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8085",
url="https://www.rfc-editor.org/rfc/rfc5405.txt",
  key="RFC 5405",
  abstract={The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.  Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic.  This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="user datagram protocol, congestion control",
  doi="10.17487/RFC5405",
  }

@misc{rfc5406,
  author="S. Bellovin",
  title="{Guidelines for Specifying the Use of IPsec Version 2}",
  howpublished="RFC 5406 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5406",
  pages="1--13",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5406.txt",
  key="RFC 5406",
  abstract={The Security Considerations sections of many Internet Drafts say, in effect, ``just use IPsec''.  While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms.  This memo offers some guidance on when IPsec Version 2 should and should not be specified.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="internet security, security considerations",
  doi="10.17487/RFC5406",
  }

@misc{rfc5407,
  author="M. Hasebe and J. Koshiko and Y. Suzuki and T. Yoshikawa and P. Kyzivat",
  title="{Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5407 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5407",
  pages="1--60",
  year=2008,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5407.txt",
  key="RFC 5407",
  abstract={This document gives example call flows of race conditions in the Session Initiation Protocol (SIP).  Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them.  The elements in these call flows include SIP User Agents and SIP Proxy Servers.  Call flow diagrams and message details are given.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="sip user agents, sip ua, sip proxy servers",
  doi="10.17487/RFC5407",
  }

@misc{rfc5408,
  author="G. Appenzeller and L. Martin and M. Schertler",
  title="{Identity-Based Encryption Architecture and Supporting Data Structures}",
  howpublished="RFC 5408 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5408",
  pages="1--30",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5408.txt",
  key="RFC 5408",
  abstract={This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key.  It also defines data structures that can be used to implement the technology.  This memo provides information for the Internet community.},
  keywords="public key, public-key encryption technology",
  doi="10.17487/RFC5408",
  }

@misc{rfc5409,
  author="L. Martin and M. Schertler",
  title="{Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5409 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5409",
  pages="1--13",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5409.txt",
  key="RFC 5409",
  abstract={This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys.  Object identifiers and the convention for encoding a recipient's identity are also defined.  This memo provides information for the Internet community.},
  keywords="bf, bbq, content-encryption keys",
  doi="10.17487/RFC5409",
  }

@misc{rfc5410,
  author="A. Jerichow and L. Piron",
  title="{Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0}",
  howpublished="RFC 5410 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5410",
  pages="1--7",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6309",
url="https://www.rfc-editor.org/rfc/rfc5410.txt",
  key="RFC 5410",
  keywords="MIKEY Extension, IANA registration, OMA BCAST",
  doi="10.17487/RFC5410",
  }

@misc{rfc5411,
  author="J. Rosenberg",
  title="{A Hitchhiker's Guide to the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5411 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5411",
  pages="1--39",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5411.txt",
  key="RFC 5411",
  abstract={The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF.  It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP.  This specification serves as a guide to the SIP RFC series.  It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories.  This memo provides information for the Internet community.},
  keywords="42, don't panic, sip overview,",
  doi="10.17487/RFC5411",
  }

@misc{rfc5412,
  author="P. Calhoun and R. Suri and N. Cam-Winget and M. Williams and S. Hares and B. O'Hara and S. Kelly",
  title="{Lightweight Access Point Protocol}",
  howpublished="RFC 5412 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5412",
  pages="1--125",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5412.txt",
  key="RFC 5412",
  abstract={In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller. The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.},
  keywords="lwapp, capwap",
  doi="10.17487/RFC5412",
  }

@misc{rfc5413,
  author="P. Narasimhan and D. Harkins and S. Ponnuswamy",
  title="{SLAPP: Secure Light Access Point Protocol}",
  howpublished="RFC 5413 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5413",
  pages="1--75",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5413.txt",
  key="RFC 5413",
  abstract={The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another. In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document. Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.},
  keywords="capwap",
  doi="10.17487/RFC5413",
  }

@misc{rfc5414,
  author="S. Iino and S. Govindan and M. Sugiura and H. Cheng",
  title="{Wireless LAN Control Protocol (WiCoP)}",
  howpublished="RFC 5414 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5414",
  pages="1--54",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 5415",
url="https://www.rfc-editor.org/rfc/rfc5414.txt",
  key="RFC 5414",
  abstract={The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.},
  keywords="wlan, wireless local area network, twp, wireless termination points, capwap, control and provisioning of wireless access points",
  doi="10.17487/RFC5414",
  }

@misc{rfc5415,
  author="P. Calhoun and M. Montemurro and D. Stanley",
  title="{Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification}",
  howpublished="RFC 5415 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5415",
  pages="1--155",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5415.txt",
  key="RFC 5415",
  abstract={This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564.  The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies.  This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]},
  keywords="LWAPP, CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point",
  doi="10.17487/RFC5415",
  }

@misc{rfc5416,
  author="P. Calhoun and M. Montemurro and D. Stanley",
  title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11}",
  howpublished="RFC 5416 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5416",
  pages="1--76",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5416.txt",
  key="RFC 5416",
  abstract={Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]},
  keywords="Operations and Management, LWAPP, CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point",
  doi="10.17487/RFC5416",
  }

@misc{rfc5417,
  author="P. Calhoun",
  title="{Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option}",
  howpublished="RFC 5417 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5417",
  pages="1--6",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5417.txt",
  key="RFC 5417",
  abstract={The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect.  This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]},
  keywords="CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point",
  doi="10.17487/RFC5417",
  }

@misc{rfc5418,
  author="S. Kelly and T. Clancy",
  title="{Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments}",
  howpublished="RFC 5418 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5418",
  pages="1--34",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5418.txt",
  key="RFC 5418",
  abstract={Early Wireless Local Area Network (WLAN) deployments feature a ``fat'' Access Point (AP), which serves as a \\%stand-alone interface between the wired and wireless network segments.  However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues.  CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops.  This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments.  This memo provides information for the Internet community.},
  keywords="WLAN, security",
  doi="10.17487/RFC5418",
  }

@misc{rfc5419,
  author="B. Patil and G. Dommety",
  title="{Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)}",
  howpublished="RFC 5419 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5419",
  pages="1--19",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5419.txt",
  key="RFC 5419",
  abstract={Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA).  These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA.  The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding.  This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments.  This memo provides information for the Internet community.},
  keywords="authentication signaling message, mn, ha",
  doi="10.17487/RFC5419",
  }

@misc{rfc5420,
  author="A. Farrel and D. Papadimitriou and JP. Vasseur and A. Ayyangarps",
  title="{Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)}",
  howpublished="RFC 5420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5420",
  pages="1--22",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6510",
url="https://www.rfc-editor.org/rfc/rfc5420.txt",
  key="RFC 5420",
  abstract={Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION\_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, label switched paths, SESSION\_ATTRIBUTE",
  doi="10.17487/RFC5420",
  }

@misc{rfc5421,
  author="N. Cam-Winget and H. Zhou",
  title="{Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)}",
  howpublished="RFC 5421 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5421",
  pages="1--10",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5421.txt",
  key="RFC 5421",
  abstract={The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer.  This memo provides information for the Internet community.},
  keywords="generic token card, eap-gtc",
  doi="10.17487/RFC5421",
  }

@misc{rfc5422,
  author="N. Cam-Winget and D. McGrew and J. Salowey and H. Zhou",
  title="{Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)}",
  howpublished="RFC 5422 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5422",
  pages="1--39",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5422.txt",
  key="RFC 5422",
  abstract={The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  EAP- FAST also enables the provisioning credentials or other information through this protected tunnel.  This document describes the use of EAP-FAST for dynamic provisioning.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5422",
  }

@misc{rfc5423,
  author="R. Gellens and C. Newman",
  title="{Internet Message Store Events}",
  howpublished="RFC 5423 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5423",
  pages="1--17",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5423.txt",
  key="RFC 5423",
  abstract={One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system. This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]},
  keywords="imap",
  doi="10.17487/RFC5423",
  }

@misc{rfc5424,
  author="R. Gerhards",
  title="{The Syslog Protocol}",
  howpublished="RFC 5424 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5424",
  pages="1--38",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5424.txt",
  key="RFC 5424",
  abstract={This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]},
  keywords="event notification message, syslog message, berkeley, software, distribution, transmission, messages",
  doi="10.17487/RFC5424",
  }

@misc{rfc5425,
  author="F. Miao and Y. Ma and J. Salowey",
  title="{Transport Layer Security (TLS) Transport Mapping for Syslog}",
  howpublished="RFC 5425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5425",
  pages="1--13",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5425.txt",
  key="RFC 5425",
  abstract={This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.  This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS-TRACK]},
  keywords="syslog message, syslog security",
  doi="10.17487/RFC5425",
  }

@misc{rfc5426,
  author="A. Okmianski",
  title="{Transmission of Syslog Messages over UDP}",
  howpublished="RFC 5426 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5426",
  pages="1--9",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5426.txt",
  key="RFC 5426",
  abstract={This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6.  The syslog protocol layered architecture provides for support of any number of transport mappings.  However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]},
  keywords="udp, User Datagram Protocol",
  doi="10.17487/RFC5426",
  }

@misc{rfc5427,
  author="G. Keeni",
  title="{Textual Conventions for Syslog Management}",
  howpublished="RFC 5427 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5427",
  pages="1--8",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5427.txt",
  key="RFC 5427",
  abstract={This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages.  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="syslog facility, syslog severity, MIB, textual-convention",
  doi="10.17487/RFC5427",
  }

@misc{rfc5428,
  author="S. Channabasappa and W. De Ketelaere and E. Nechamkin",
  title="{Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices}",
  howpublished="RFC 5428 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5428",
  pages="1--37",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5428.txt",
  key="RFC 5428",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]},
  keywords="snmp, simple network management protocol, multimedia terminal adapter, PKTC-IETF-EVENT-MIB",
  doi="10.17487/RFC5428",
  }

@misc{rfc5429,
  author="A. Stone",
  title="{Sieve Email Filtering: Reject and Extended Reject Extensions}",
  howpublished="RFC 5429 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5429",
  pages="1--14",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5429.txt",
  key="RFC 5429",
  abstract={This memo updates the definition of the Sieve mail filtering language ``reject'' extension, originally defined in RFC 3028. A ``Joe-job'' is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve ``reject'' action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the ``reject'' action to allow messages to be refused during the SMTP transaction, and defines the ``ereject'' action to require messages to be refused during the SMTP transaction, if possible. The ``ereject'' action is intended to replace the ``reject'' action wherever possible. The ``ereject'' action is similar to ``reject'', but will always favor protocol-level message rejection. [STANDARDS-TRACK]},
  keywords="sieve, refuse, reject, ereject, joe-job, smtp, lmtp, spam",
  doi="10.17487/RFC5429",
  }

@misc{rfc5430,
  author="M. Salter and E. Rescorla and R. Housley",
  title="{Suite B Profile for Transport Layer Security (TLS)}",
  howpublished="RFC 5430 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5430",
  pages="1--12",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6460",
url="https://www.rfc-editor.org/rfc/rfc5430.txt",
  key="RFC 5430",
  abstract={The United States government has published guidelines for ``NSA Suite B Cryptography'', which defines cryptographic algorithm policy for national security applications.  This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B.  This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible.  This memo provides information for the Internet community.},
  keywords="nsa suite b cryptography",
  doi="10.17487/RFC5430",
  }

@misc{rfc5431,
  author="D. Sun",
  title="{Diameter ITU-T Rw Policy Enforcement Interface Application}",
  howpublished="RFC 5431 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5431",
  pages="1--5",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5431.txt",
  key="RFC 5431",
  abstract={This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec.  Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T).  This memo provides information for the Internet community.},
  keywords="diameter command code, itu-t, ITU-T Rw, Policy-Install-Request, pir, Policy-Install-Answer, pia",
  doi="10.17487/RFC5431",
  }

@misc{rfc5432,
  author="J. Polk and S. Dhesikan and G. Camarillo",
  title="{Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)}",
  howpublished="RFC 5432 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5432",
  pages="1--9",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5432.txt",
  key="RFC 5432",
  abstract={The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish.  Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use.  However, on the Internet, there is more than one QoS service available.  Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream.  This document defines such a mechanism. [STANDARDS-TRACK]},
  keywords="offer/answer, media stream",
  doi="10.17487/RFC5432",
  }

@misc{rfc5433,
  author="T. Clancy and H. Tschofenig",
  title="{Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method}",
  howpublished="RFC 5433 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5433",
  pages="1--38",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5433.txt",
  key="RFC 5433",
  abstract={This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]},
  keywords="EAP, EAP-GPSK, pre-shared key",
  doi="10.17487/RFC5433",
  }

@misc{rfc5434,
  author="T. Narten",
  title="{Considerations for Having a Successful Birds-of-a-Feather (BOF) Session}",
  howpublished="RFC 5434 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5434",
  pages="1--13",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5434.txt",
  key="RFC 5434",
  abstract={This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group.  It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]},
  keywords="ietf bof, working group",
  doi="10.17487/RFC5434",
  }

@misc{rfc5435,
  author="A. Melnikov and B. Leiba and W. Segmuller and T. Martin",
  title="{Sieve Email Filtering: Extension for Notifications}",
  howpublished="RFC 5435 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5435",
  pages="1--17",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5435.txt",
  key="RFC 5435",
  abstract={Users go to great lengths to be notified as quickly as possible that they have received new mail.  Most of these methods involve polling to check for new messages periodically.  A push method handled by the final delivery agent gives users quicker notifications and saves server resources.  This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular.  This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5435",
  }

@misc{rfc5436,
  author="B. Leiba and M. Haardt",
  title="{Sieve Notification Mechanism: mailto}",
  howpublished="RFC 5436 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5436",
  pages="1--12",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5436.txt",
  key="RFC 5436",
  abstract={This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]},
  keywords="eletctronic mail notification",
  doi="10.17487/RFC5436",
  }

@misc{rfc5437,
  author="P. Saint-Andre and A. Melnikov",
  title="{Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 5437 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5437",
  pages="1--14",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5437.txt",
  key="RFC 5437",
  abstract={This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]},
  keywords="jabber",
  doi="10.17487/RFC5437",
  }

@misc{rfc5438,
  author="E. Burger and H. Khartabil",
  title="{Instant Message Disposition Notification (IMDN)}",
  howpublished="RFC 5438 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5438",
  pages="1--38",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5438.txt",
  key="RFC 5438",
  abstract={Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages. The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]},
  keywords="im, instant messaging, cpim, common presence and instant messaging",
  doi="10.17487/RFC5438",
  }

@misc{rfc5439,
  author="S. Yasukawa and A. Farrel and O. Komolafe",
  title="{An Analysis of Scaling Issues in MPLS-TE Core Networks}",
  howpublished="RFC 5439 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5439",
  pages="1--45",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5439.txt",
  key="RFC 5439",
  abstract={Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, traffic engineered, scaling concerns, lsp, label switch path,  point-to-point mpls-te lsps",
  doi="10.17487/RFC5439",
  }

@misc{rfc5440,
  author="JP. Vasseur and JL. Le Roux",
  title="{Path Computation Element (PCE) Communication Protocol (PCEP)}",
  howpublished="RFC 5440 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5440",
  pages="1--87",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7896",
url="https://www.rfc-editor.org/rfc/rfc5440.txt",
  key="RFC 5440",
  abstract={This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs.  Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering.  PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]},
  keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path",
  doi="10.17487/RFC5440",
  }

@misc{rfc5441,
  author="JP. Vasseur and R. Zhang and N. Bitar and JL. Le Roux",
  title="{A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths}",
  howpublished="RFC 5441 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5441",
  pages="1--18",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5441.txt",
  key="RFC 5441",
  abstract={The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement.  In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems.  This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique.  This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]},
  keywords="te lsp, path computation element",
  doi="10.17487/RFC5441",
  }

@misc{rfc5442,
  author="E. Burger and G. Parsons",
  title="{LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail}",
  howpublished="RFC 5442 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5442",
  pages="1--15",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5442.txt",
  key="RFC 5442",
  abstract={This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols.  This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF.  This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service.  This memo provides information for the Internet community.},
  keywords="enhancements to internet email to supportt diverse service environments, Phone",
  doi="10.17487/RFC5442",
  }

@misc{rfc5443,
  author="M. Jork and A. Atlas and L. Fang",
  title="{LDP IGP Synchronization}",
  howpublished="RFC 5443 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5443",
  pages="1--7",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6138",
url="https://www.rfc-editor.org/rfc/rfc5443.txt",
  key="RFC 5443",
  abstract={In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications.  For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately.  Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not.  While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores.  This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.  This memo provides information for the Internet community.},
  keywords="label distribution protocol, interior gateway protocol",
  doi="10.17487/RFC5443",
  }

@misc{rfc5444,
  author="T. Clausen and C. Dearlove and J. Dean and C. Adjih",
  title="{Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format}",
  howpublished="RFC 5444 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5444",
  pages="1--60",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7631",
url="https://www.rfc-editor.org/rfc/rfc5444.txt",
  key="RFC 5444",
  abstract={This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]},
  keywords="routing, TLV, address",
  doi="10.17487/RFC5444",
  }

@misc{rfc5445,
  author="M. Watson",
  title="{Basic Forward Error Correction (FEC) Schemes}",
  howpublished="RFC 5445 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5445",
  pages="1--19",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5445.txt",
  key="RFC 5445",
  abstract={This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme.  This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]},
  keywords="content, stream, delivery, multicast, internet protocol",
  doi="10.17487/RFC5445",
  }

@misc{rfc5446,
  author="J. Korhonen and U. Nilsson",
  title="{Service Selection for Mobile IPv4}",
  howpublished="RFC 5446 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5446",
  pages="1--9",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5446.txt",
  key="RFC 5446",
  abstract={In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node.  The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription.  This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure.  This memo provides information for the Internet community.},
  keywords="internet protocol version 4, host name agent, mobility service subscription",
  doi="10.17487/RFC5446",
  }

@misc{rfc5447,
  author="J. Korhonen and J. Bournelle and H. Tschofenig and C. Perkins and K. Chowdhury",
  title="{Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction}",
  howpublished="RFC 5447 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5447",
  pages="1--17",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5447.txt",
  key="RFC 5447",
  abstract={A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6.  RFC 3775 requires that some or all of these parameters be statically configured.  Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node.  An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures.  This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]},
  keywords="Diameter, Mobile IPv6, Integrated Scenario",
  doi="10.17487/RFC5447",
  }

@misc{rfc5448,
  author="J. Arkko and V. Lehtovirta and P. Eronen",
  title="{Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')}",
  howpublished="RFC 5448 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5448",
  pages="1--29",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5448.txt",
  key="RFC 5448",
  abstract={This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.},
  keywords="EAP, AKA, AKA', 3GPP",
  doi="10.17487/RFC5448",
  }

@misc{rfc5449,
  author="E. Baccelli and P. Jacquet and D. Nguyen and T. Clausen",
  title="{OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks}",
  howpublished="RFC 5449 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5449",
  pages="1--31",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5449.txt",
  key="RFC 5449",
  abstract={This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks.  This interface type is derived from the broadcast interface type, and is denoted the ``OSPFv3 MANET interface type''.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="open shortest path first, interface type, mobile ad hoc",
  doi="10.17487/RFC5449",
  }

@misc{rfc5450,
  author="D. Singer and H. Desineni",
  title="{Transmission Time Offsets in RTP Streams}",
  howpublished="RFC 5450 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5450",
  pages="1--8",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5450.txt",
  key="RFC 5450",
  abstract={This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time.  It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]},
  keywords="real-time transport, IJ, inter-arrival jitter",
  doi="10.17487/RFC5450",
  }

@misc{rfc5451,
  author="M. Kucherawy",
  title="{Message Header Field for Indicating Message Authentication Status}",
  howpublished="RFC 5451 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5451",
  pages="1--43",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7001, updated by RFC 6577",
url="https://www.rfc-editor.org/rfc/rfc5451.txt",
  key="RFC 5451",
  abstract={This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]},
  keywords="authentication-results, email authentication result",
  doi="10.17487/RFC5451",
  }

@misc{rfc5452,
  author="A. Hubert and R. van Mook",
  title="{Measures for Making DNS More Resilient against Forged Answers}",
  howpublished="RFC 5452 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5452",
  pages="1--18",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5452.txt",
  key="RFC 5452",
  abstract={The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]},
  keywords="spoofing, source port, hardening",
  doi="10.17487/RFC5452",
  }

@misc{rfc5453,
  author="S. Krishnan",
  title="{Reserved IPv6 Interface Identifiers}",
  howpublished="RFC 5453 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5453",
  pages="1--6",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5453.txt",
  key="RFC 5453",
  abstract={Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link.  They are required to be unique within a subnet.  Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them.  An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences.  Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]},
  keywords="unicast address",
  doi="10.17487/RFC5453",
  }

@misc{rfc5454,
  author="G. Tsirtsis and V. Park and H. Soliman",
  title="{Dual-Stack Mobile IPv4}",
  howpublished="RFC 5454 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5454",
  pages="1--18",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5454.txt",
  key="RFC 5454",
  abstract={This specification provides IPv6 extensions to the Mobile IPv4 protocol.  The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]},
  keywords="ipv6, mipv4",
  doi="10.17487/RFC5454",
  }

@misc{rfc5455,
  author="S. Sivabalan and J. Parker and S. Boutros and K. Kumaki",
  title="{Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol}",
  howpublished="RFC 5455 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5455",
  pages="1--9",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5455.txt",
  key="RFC 5455",
  abstract={This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]},
  keywords="classtype, ds-te, diffserv-aware traffic engineering, pce",
  doi="10.17487/RFC5455",
  }

@misc{rfc5456,
  author="M. Spencer and B. Capouch and E. Guy and F. Miller and K. Shumard",
  title="{IAX: Inter-Asterisk eXchange Version 2}",
  howpublished="RFC 5456 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5456",
  pages="1--101",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5456.txt",
  key="RFC 5456",
  abstract={This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an ``all in one'' protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="asterisk private branch exchange, pbx, voip, voice over internet protocol",
  doi="10.17487/RFC5456",
  }

@misc{rfc5457,
  author="E. Guy",
  title="{IANA Considerations for IAX: Inter-Asterisk eXchange Version 2}",
  howpublished="RFC 5457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5457",
  pages="1--21",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5457.txt",
  key="RFC 5457",
  abstract={This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks.  IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="asterisk private branch exchange, pbx, voip, voice over internet protocol",
  doi="10.17487/RFC5457",
  }

@misc{rfc5458,
  author="H. Cruickshank and P. Pillai and M. Noisternig and S. Iyengar",
  title="{Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol}",
  howpublished="RFC 5458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5458",
  pages="1--26",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5458.txt",
  key="RFC 5458",
  abstract={The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.},
  keywords="iso 13818-1, transport stream, ts, ule stream, gse, generic stream encapsulation",
  doi="10.17487/RFC5458",
  }

@misc{rfc5459,
  author="A. Sollaud",
  title="{G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support}",
  howpublished="RFC 5459 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5459",
  pages="1--7",
  year=2009,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5459.txt",
  key="RFC 5459",
  abstract={This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec.  It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way.  An updated media type registration is included for this payload format. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, rtp, itu-t, international telecommunication union, g.729.1, audio codec",
  doi="10.17487/RFC5459",
  }

@misc{rfc5460,
  author="M. Stapp",
  title="{DHCPv6 Bulk Leasequery}",
  howpublished="RFC 5460 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5460",
  pages="1--18",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7653",
url="https://www.rfc-editor.org/rfc/rfc5460.txt",
  key="RFC 5460",
  abstract={The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings.  That mechanism is limited to queries for individual bindings.  In some situations individual binding queries may not be efficient, or even possible.  This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]},
  keywords="dynamic hos configuration protocol, ipv6, dhcpv6 bindings",
  doi="10.17487/RFC5460",
  }

@misc{rfc5461,
  author="F. Gont",
  title="{TCP's Reaction to Soft Errors}",
  howpublished="RFC 5461 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5461",
  pages="1--13",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5461.txt",
  key="RFC 5461",
  abstract={This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received.  This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments.  This memo provides information for the Internet community.},
  keywords="icmp, Internet Control Message Protocol",
  doi="10.17487/RFC5461",
  }

@misc{rfc5462,
  author="L. Andersson and R. Asati",
  title="{Multiprotocol Label Switching (MPLS) Label Stack Entry: ``EXP'' Field Renamed to ``Traffic Class'' Field}",
  howpublished="RFC 5462 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5462",
  pages="1--9",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5462.txt",
  key="RFC 5462",
  abstract={The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the ``EXP field''. The exact use of this field was not defined by these documents, except to state that it was to be ``reserved for experimental use''. Although the intended use of the EXP field was as a ``Class of Service'' (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the ``Traffic Class field'' (``TC field''). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]},
  keywords="exp, class of service, cos, tc field",
  doi="10.17487/RFC5462",
  }

@misc{rfc5463,
  author="N. Freed",
  title="{Sieve Email Filtering:  Ihave Extension}",
  howpublished="RFC 5463 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5463",
  pages="1--6",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5463.txt",
  key="RFC 5463",
  abstract={This document describes the ``ihave'' extension to the Sieve email filtering language.  The ``ihave'' extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available.  The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]},
  keywords="SMTP, ESMTP",
  doi="10.17487/RFC5463",
  }

@misc{rfc5464,
  author="C. Daboo",
  title="{The IMAP METADATA Extension}",
  howpublished="RFC 5464 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5464",
  pages="1--20",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5464.txt",
  key="RFC 5464",
  abstract={The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain ``annotations'' or ``metadata'' on IMAP servers.  It is possible to have annotations on a per-mailbox basis or on the server as a whole.  For example, this would allow comments about the purpose of a particular mailbox to be ``attached'' to that mailbox, or a ``message of the day'' containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]},
  keywords="internet message access protocol, annotation, metadata",
  doi="10.17487/RFC5464",
  }

@misc{rfc5465,
  author="A. Gulbrandsen and C. King and A. Melnikov",
  title="{The IMAP NOTIFY Extension}",
  howpublished="RFC 5465 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5465",
  pages="1--22",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5465.txt",
  key="RFC 5465",
  abstract={This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC5465",
  }

@misc{rfc5466,
  author="A. Melnikov and C. King",
  title="{IMAP4 Extension for Named Searches (Filters)}",
  howpublished="RFC 5466 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5466",
  pages="1--9",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5466.txt",
  key="RFC 5466",
  abstract={The document defines a way to persistently store named IMAP (RFC 3501) searches on the server.  Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC5466",
  }

@misc{rfc5467,
  author="L. Berger and A. Takacs and D. Caviglia and D. Fedyk and J. Meuric",
  title="{GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)}",
  howpublished="RFC 5467 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5467",
  pages="1--14",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6387",
url="https://www.rfc-editor.org/rfc/rfc5467.txt",
  key="RFC 5467",
  abstract={This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs).  The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters.  The procedures described in this document are experimental.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="RSVP-TE, TSPEC, ADSPEC",
  doi="10.17487/RFC5467",
  }

@misc{rfc5468,
  author="S. Dasgupta and J. de Oliveira and JP. Vasseur",
  title="{Performance Analysis of Inter-Domain Path Computation Methodologies}",
  howpublished="RFC 5468 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5468",
  pages="1--10",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5468.txt",
  key="RFC 5468",
  abstract={This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure.  Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios.  A performance analysis for each of the path computation methods is then undertaken.  This memo provides information for the Internet community.},
  keywords="pce, path computation element, brpc, backward recursive path computation",
  doi="10.17487/RFC5468",
  }

@misc{rfc5469,
  author="P. Eronen",
  title="{DES and IDEA Cipher Suites for Transport Layer Security (TLS)}",
  howpublished="RFC 5469 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5469",
  pages="1--4",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5469.txt",
  key="RFC 5469",
  abstract={Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms.  DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246).  This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended.  This memo provides information for the Internet community.},
  keywords="ciphersuite, data encryption standard, international data encryption algorithm",
  doi="10.17487/RFC5469",
  }

@misc{rfc5470,
  author="G. Sadasivan and N. Brownlee and B. Claise and J. Quittek",
  title="{Architecture for IP Flow Information Export}",
  howpublished="RFC 5470 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5470",
  pages="1--31",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6183",
url="https://www.rfc-editor.org/rfc/rfc5470.txt",
  key="RFC 5470",
  abstract={This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.  This memo provides information for the Internet community.},
  keywords="ipfix, ipfix device, ipfix collector",
  doi="10.17487/RFC5470",
  }

@misc{rfc5471,
  author="C. Schmoll and P. Aitken and B. Claise",
  title="{Guidelines for IP Flow Information Export (IPFIX) Testing}",
  howpublished="RFC 5471 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5471",
  pages="1--32",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5471.txt",
  key="RFC 5471",
  abstract={This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes.  This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations.  These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation.  Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.  This memo provides information for the Internet community.},
  keywords="exporting process, collecting process",
  doi="10.17487/RFC5471",
  }

@misc{rfc5472,
  author="T. Zseby and E. Boschi and N. Brownlee and B. Claise",
  title="{IP Flow Information Export (IPFIX) Applicability}",
  howpublished="RFC 5472 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5472",
  pages="1--31",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5472.txt",
  key="RFC 5472",
  abstract={In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications.  We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol.  Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.  This memo provides information for the Internet community.},
  keywords="ie, information element, PSAMP, measurement, QoS monitoring, attack detection, AAA, ipfix framework",
  doi="10.17487/RFC5472",
  }

@misc{rfc5473,
  author="E. Boschi and L. Mark and B. Claise",
  title="{Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports}",
  howpublished="RFC 5473 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5473",
  pages="1--27",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5473.txt",
  key="RFC 5473",
  abstract={This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.},
  doi="10.17487/RFC5473",
  }

@misc{rfc5474,
  author="N. Duffield and D. Chiou and B. Claise and A. Greenberg and M. Grossglauser and J. Rexford",
  title="{A Framework for Packet Selection and Reporting}",
  howpublished="RFC 5474 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5474",
  pages="1--38",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5474.txt",
  key="RFC 5474",
  abstract={This document specifies a framework for the PSAMP (Packet SAMPling) protocol.  The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector.  This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications.  Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions.  This memo provides information for the Internet community.},
  keywords="psamp, selector, collector",
  doi="10.17487/RFC5474",
  }

@misc{rfc5475,
  author="T. Zseby and M. Molina and N. Duffield and S. Niccolini and F. Raspall",
  title="{Sampling and Filtering Techniques for IP Packet Selection}",
  howpublished="RFC 5475 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5475",
  pages="1--46",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5475.txt",
  key="RFC 5475",
  abstract={This document describes Sampling and Filtering techniques for IP packet selection.  It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes.  Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors.  The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]},
  keywords="psamp, metering process",
  doi="10.17487/RFC5475",
  }

@misc{rfc5476,
  author="B. Claise and A. Johnson and J. Quittek",
  title="{Packet Sampling (PSAMP) Protocol Specifications}",
  howpublished="RFC 5476 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5476",
  pages="1--45",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5476.txt",
  key="RFC 5476",
  abstract={This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process.  For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient.  The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]},
  keywords="exporting process, collecting process, ipfix, ip flow information export",
  doi="10.17487/RFC5476",
  }

@misc{rfc5477,
  author="T. Dietz and B. Claise and P. Aitken and F. Dressler and G. Carle",
  title="{Information Model for Packet Sampling Exports}",
  howpublished="RFC 5477 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5477",
  pages="1--46",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5477.txt",
  key="RFC 5477",
  abstract={This memo defines an information model for the Packet SAMPling (PSAMP) protocol.  It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.  As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]},
  keywords="psamp, ipfix, ip flow information export",
  doi="10.17487/RFC5477",
  }

@misc{rfc5478,
  author="J. Polk",
  title="{IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces}",
  howpublished="RFC 5478 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5478",
  pages="1--6",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5478.txt",
  key="RFC 5478",
  abstract={This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]},
  keywords="us defense information systems agency",
  doi="10.17487/RFC5478",
  }

@misc{rfc5479,
  author="D. Wing and S. Fries and H. Tschofenig and F. Audet",
  title="{Requirements and Analysis of Media Security Management Protocols}",
  howpublished="RFC 5479 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5479",
  pages="1--45",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5479.txt",
  key="RFC 5479",
  abstract={This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media.  In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways.  A number of proposals have been published and a summary of these proposals is in the appendix of this document.  This memo provides information for the Internet community.},
  keywords="keying, Secure RTP, SRTP",
  doi="10.17487/RFC5479",
  }

@misc{rfc5480,
  author="S. Turner and D. Brown and K. Yiu and R. Housley and T. Polk",
  title="{Elliptic Curve Cryptography Subject Public Key Information}",
  howpublished="RFC 5480 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5480",
  pages="1--20",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5480.txt",
  key="RFC 5480",
  abstract={This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of ``Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile'', RFC 3279. [STANDARDS-TRACK]},
  keywords="x.509, asn.1, subjectPubicKeyInfo",
  doi="10.17487/RFC5480",
  }

@misc{rfc5481,
  author="A. Morton and B. Claise",
  title="{Packet Delay Variation Applicability Statement}",
  howpublished="RFC 5481 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5481",
  pages="1--39",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5481.txt",
  key="RFC 5481",
  abstract={Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions. Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.},
  keywords="active measurement, ipdv, pdv, inter-packet delay variation",
  doi="10.17487/RFC5481",
  }

@misc{rfc5482,
  author="L. Eggert and F. Gont",
  title="{TCP User Timeout Option}",
  howpublished="RFC 5482 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5482",
  pages="1--14",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5482.txt",
  key="RFC 5482",
  abstract={The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed.  It is a local, per-connection parameter.  This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value.  This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly.  Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity.  Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]},
  keywords="Transmission Control Protocol",
  doi="10.17487/RFC5482",
  }

@misc{rfc5483,
  author="L. Conroy and K. Fujiwara",
  title="{ENUM Implementation Issues and Experiences}",
  howpublished="RFC 5483 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5483",
  pages="1--30",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5483.txt",
  key="RFC 5483",
  abstract={This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others.  As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards.  Its aim is to help others by reporting both what is ``out there'' and potential pitfalls in interpreting the set of documents that specify the ENUM protocol.  It does not revise the standards but is intended to provide technical input to future revisions of those documents.  This memo provides information for the Internet community.},
  keywords="DNS, E.164, NAPTR, dynamic delegation discovery system",
  doi="10.17487/RFC5483",
  }

@misc{rfc5484,
  author="D. Singer",
  title="{Associating Time-Codes with RTP Streams}",
  howpublished="RFC 5484 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5484",
  pages="1--13",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5484.txt",
  key="RFC 5484",
  abstract={This document describes a mechanism for associating \\%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]},
  keywords="smpte, society of motion picture and television engineers, media stream",
  doi="10.17487/RFC5484",
  }

@misc{rfc5485,
  author="R. Housley",
  title="{Digital Signatures on Internet-Draft Documents}",
  howpublished="RFC 5485 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5485",
  pages="1--14",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5485.txt",
  key="RFC 5485",
  abstract={This document specifies the conventions for digital signatures on Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.  This memo provides information for the Internet community.},
  keywords="cms, cryptographic message syntax, detached signature",
  doi="10.17487/RFC5485",
  }

@misc{rfc5486,
  author="D. Malas and D. Meyer",
  title="{Session Peering for Multimedia Interconnect (SPEERMINT) Terminology}",
  howpublished="RFC 5486 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5486",
  pages="1--10",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5486.txt",
  key="RFC 5486",
  abstract={This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).  This memo provides information for the Internet community.},
  doi="10.17487/RFC5486",
  }

@misc{rfc5487,
  author="M. Badra",
  title="{Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode}",
  howpublished="RFC 5487 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5487",
  pages="1--7",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5487.txt",
  key="RFC 5487",
  abstract={RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS).  However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm.  This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]},
  keywords="PSK, Diffie-Hellman, Key Exchange, advanced encryption standard, gcm, digest algorithm, ciphersuite",
  doi="10.17487/RFC5487",
  }

@misc{rfc5488,
  author="S. Gundavelli and G. Keeni and K. Koide and K. Nagami",
  title="{Network Mobility (NEMO) Management Information Base}",
  howpublished="RFC 5488 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5488",
  pages="1--44",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5488.txt",
  key="RFC 5488",
  abstract={This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community.  In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]},
  keywords="mib, NEMO-MIB",
  doi="10.17487/RFC5488",
  }

@misc{rfc5489,
  author="M. Badra and I. Hajjeh",
  title="{ECDHE\_PSK Cipher Suites for Transport Layer Security (TLS)}",
  howpublished="RFC 5489 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5489",
  pages="1--7",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5489.txt",
  key="RFC 5489",
  abstract={This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE).  These cipher suites provide Perfect Forward Secrecy (PFS).  This memo provides information for the Internet community.},
  keywords="pre-shared key,  Diffie-Hellman, Key Exchange, Elliptic Curve Cryptography",
  doi="10.17487/RFC5489",
  }

@misc{rfc5490,
  author="A. Melnikov",
  title="{The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata}",
  howpublished="RFC 5490 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5490",
  pages="1--8",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5490.txt",
  key="RFC 5490",
  abstract={This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on ``fileinto'' action. [STANDARDS-TRACK]},
  keywords="mail filtering, fileinto",
  doi="10.17487/RFC5490",
  }

@misc{rfc5491,
  author="J. Winterbottom and M. Thomson and H. Tschofenig",
  title="{GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations}",
  howpublished="RFC 5491 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5491",
  pages="1--28",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7459",
url="https://www.rfc-editor.org/rfc/rfc5491.txt",
  key="RFC 5491",
  abstract={The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information.  There are, however, circumstances that arise when information needs to be constrained in how it is represented.  In these circumstances, the range of options that need to be implemented are reduced.  There is growing interest in being able to use location information contained in a PIDF-LO for routing applications.  To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO).  This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO.  It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]},
  keywords="PIDF-LO, civic, geodetic, location, well-formed, GeoShape",
  doi="10.17487/RFC5491",
  }

@misc{rfc5492,
  author="J. Scudder and R. Chandra",
  title="{Capabilities Advertisement with BGP-4}",
  howpublished="RFC 5492 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5492",
  pages="1--7",
  year=2009,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5492.txt",
  key="RFC 5492",
  abstract={This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. [STANDARDS-TRACK]},
  keywords="bgp, idr, border gateway protocol, capabilities",
  doi="10.17487/RFC5492",
  }

@misc{rfc5493,
  author="D. Caviglia and D. Bramanti and D. Li and D. McDysan",
  title="{Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network}",
  howpublished="RFC 5493 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5493",
  pages="1--11",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5493.txt",
  key="RFC 5493",
  abstract={From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.},
  keywords="pc, spc, soft permanent connection, data plane traffic",
  doi="10.17487/RFC5493",
  }

@misc{rfc5494,
  author="J. Arkko and C. Pignataro",
  title="{IANA Allocation Guidelines for the Address Resolution Protocol (ARP)}",
  howpublished="RFC 5494 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5494",
  pages="1--7",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5494.txt",
  key="RFC 5494",
  abstract={This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP).  This document also reserves some numbers for experimentation purposes.  The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]},
  keywords="IANA rules, Address Resolution Protocol, ARP",
  doi="10.17487/RFC5494",
  }

@misc{rfc5495,
  author="D. Li and J. Gao and A. Satyanarayana and S. Bardalai",
  title="{Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures}",
  howpublished="RFC 5495 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5495",
  pages="1--18",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5495.txt",
  key="RFC 5495",
  abstract={The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults. The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP). Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different. This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.},
  keywords="Hello message, gmpls",
  doi="10.17487/RFC5495",
  }

@misc{rfc5496,
  author="IJ. Wijnands and A. Boers and E. Rosen",
  title="{The Reverse Path Forwarding (RPF) Vector TLV}",
  howpublished="RFC 5496 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5496",
  pages="1--8",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5496.txt",
  key="RFC 5496",
  abstract={This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]},
  keywords="pim, protocol independent multicast join attribute",
  doi="10.17487/RFC5496",
  }

@misc{rfc5497,
  author="T. Clausen and C. Dearlove",
  title="{Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)}",
  howpublished="RFC 5497 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5497",
  pages="1--14",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5497.txt",
  key="RFC 5497",
  abstract={This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format.  It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]},
  keywords="Routing Protocol, TLV, Fisheye, FSR, Fuzzy-Sighted, extension, packetbb, RFC5444",
  doi="10.17487/RFC5497",
  }

@misc{rfc5498,
  author="I. Chakeres",
  title="{IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols}",
  howpublished="RFC 5498 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5498",
  pages="1--5",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5498.txt",
  key="RFC 5498",
  abstract={This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols.  The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]},
  keywords="manet protocols",
  doi="10.17487/RFC5498",
  }

@misc{rfc5501,
  author="Y. Kamite and Y. Wada and Y. Serbest and T. Morin and L. Fang",
  title="{Requirements for Multicast Support in Virtual Private LAN Services}",
  howpublished="RFC 5501 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5501",
  pages="1--31",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5501.txt",
  key="RFC 5501",
  abstract={This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS).  It specifies requirements both from the end user and service provider standpoints.  It is intended that potential solutions will use these requirements as guidelines.  This memo provides information for the Internet community.},
  keywords="L2, VPN, VPLS, Ethernet, P2MP, IGMP, MLD, PIM",
  doi="10.17487/RFC5501",
  }

@misc{rfc5502,
  author="J. van Elburg",
  title="{The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem}",
  howpublished="RFC 5502 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5502",
  pages="1--14",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5502.txt",
  key="RFC 5502",
  abstract={This document specifies the SIP P-Served-User P-header.  This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface.  This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation.  This memo provides information for the Internet community.},
  keywords="SIP, S-CSCF, AS, ISC",
  doi="10.17487/RFC5502",
  }

@misc{rfc5503,
  author="F. Andreasen and B. McKibben and B. Marshall",
  title="{Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture}",
  howpublished="RFC 5503 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5503",
  pages="1--34",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5503.txt",
  key="RFC 5503",
  abstract={In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call.  This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture.  These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues.  The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.  This memo provides information for the Internet community.},
  keywords="P-DCS-TRACE-PARTY-ID, P-DCS-OSPS, P-DCS-BILLING-INFO, P-DCS-LAES, P-DCS-Redirect, P-DCS-INFO",
  doi="10.17487/RFC5503",
  }

@misc{rfc5504,
  author="K. Fujiwara and Y. Yoneya",
  title="{Downgrading Mechanism for Email Address Internationalization}",
  howpublished="RFC 5504 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5504",
  pages="1--24",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6530",
url="https://www.rfc-editor.org/rfc/rfc5504.txt",
  key="RFC 5504",
  abstract={Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields.  The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields.  To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required.  This document describes a downgrading mechanism for Email Address Internationalization.  Note that this is a way to downgrade, not tunnel.  There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="EAI, Email Address Internationalization, Downgrade, MAIL",
  doi="10.17487/RFC5504",
  }

@misc{rfc5505,
  author="B. Aboba and D. Thaler and L. Andersson and S. Cheshire",
  title="{Principles of Internet Host Configuration}",
  howpublished="RFC 5505 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5505",
  pages="1--25",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5505.txt",
  key="RFC 5505",
  abstract={This document describes principles of Internet host configuration.  It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.  This memo provides information for the Internet community.},
  keywords="internet-layer parameter, higher-layer configuration",
  doi="10.17487/RFC5505",
  }

@misc{rfc5506,
  author="I. Johansson and M. Westerlund",
  title="{Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences}",
  howpublished="RFC 5506 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5506",
  pages="1--17",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5506.txt",
  key="RFC 5506",
  abstract={This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size.  The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed.  Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585).  This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]},
  keywords="AVPF, non-compound, non compound, compound",
  doi="10.17487/RFC5506",
  }

@misc{rfc5507,
  author="IAB and P. Faltstrom and R. Austein and P. Koch",
  title="{Design Choices When Expanding the DNS}",
  howpublished="RFC 5507 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5507",
  pages="1--18",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5507.txt",
  key="RFC 5507",
  abstract={This note discusses how to extend the DNS with new data for a new application.  DNS extension discussions too often focus on reuse of the TXT Resource Record Type.  This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution.  This memo provides information for the Internet community.},
  keywords="domain name system, resource record type",
  doi="10.17487/RFC5507",
  }

@misc{rfc5508,
  author="P. Srisuresh and B. Ford and S. Sivakumar and S. Guha",
  title="{NAT Behavioral Requirements for ICMP}",
  howpublished="RFC 5508 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5508",
  pages="1--29",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7857",
url="https://www.rfc-editor.org/rfc/rfc5508.txt",
  key="RFC 5508",
  abstract={This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP).  The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices.  Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="ICMP Error payload translation, hairpin translation, ICMP Query, ICMP Error, Ping, Traceroute",
  doi="10.17487/RFC5508",
  }

@misc{rfc5509,
  author="S. Loreto",
  title="{Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5509 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5509",
  pages="1--5",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5509.txt",
  key="RFC 5509",
  abstract={This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]},
  keywords="\_sip",
  doi="10.17487/RFC5509",
  }

@misc{rfc5510,
  author="J. Lacan and V. Roca and J. Peltotalo and S. Peltotalo",
  title="{Reed-Solomon Forward Error Correction (FEC) Schemes}",
  howpublished="RFC 5510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5510",
  pages="1--28",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5510.txt",
  key="RFC 5510",
  abstract={This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8). Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]},
  keywords="maximum distance separable, MDS",
  doi="10.17487/RFC5510",
  }

@misc{rfc5511,
  author="A. Farrel",
  title="{Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications}",
  howpublished="RFC 5511 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5511",
  pages="1--14",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5511.txt",
  key="RFC 5511",
  abstract={Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]},
  keywords="routing bnf",
  doi="10.17487/RFC5511",
  }

@misc{rfc5512,
  author="P. Mohapatra and E. Rosen",
  title="{The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute}",
  howpublished="RFC 5512 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5512",
  pages="1--13",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5512.txt",
  key="RFC 5512",
  abstract={In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the ``encapsulation information'', i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]},
  keywords="BGP, Encapsulation, Encap SAFI, Tunnel, Softwire, 4over6, 6over4",
  doi="10.17487/RFC5512",
  }

@misc{rfc5513,
  author="A. Farrel",
  title="{IANA Considerations for Three Letter Acronyms}",
  howpublished="RFC 5513 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5513",
  pages="1--7",
  year=2009,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5513.txt",
  key="RFC 5513",
  abstract={Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors. Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.},
  keywords="tla, abbreviation",
  doi="10.17487/RFC5513",
  }

@misc{rfc5514,
  author="E. Vyncke",
  title="{IPv6 over Social Networks}",
  howpublished="RFC 5514 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5514",
  pages="1--6",
  year=2009,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5514.txt",
  key="RFC 5514",
  abstract={There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low.  This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.  This will immediately add millions of IPv6 hosts to the existing IPv6 Internet.  This document includes sections on addressing and transport of IPv6 over a Social Network.  A working prototype has been developed.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="facebook",
  doi="10.17487/RFC5514",
  }

@misc{rfc5515,
  author="V. Mammoliti and C. Pignataro and P. Arberg and J. Gibbons and P. Howard",
  title="{Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions}",
  howpublished="RFC 5515 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5515",
  pages="1--28",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5515.txt",
  key="RFC 5515",
  abstract={This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality.  It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment.  The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products.  The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3.  This memo provides information for the Internet community.},
  keywords="L2TP, Acces Line Information, DSLAM",
  doi="10.17487/RFC5515",
  }

@misc{rfc5516,
  author="M. Jones and L. Morand",
  title="{Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)}",
  howpublished="RFC 5516 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5516",
  pages="1--5",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5516.txt",
  key="RFC 5516",
  abstract={This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS).  These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS).  This memo provides information for the Internet community.},
  keywords="3GPP, Release 8, Diameter, command codes, EPS",
  doi="10.17487/RFC5516",
  }

@misc{rfc5517,
  author="S. HomChaudhuri and M. Foschiano",
  title="{Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment}",
  howpublished="RFC 5517 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5517",
  pages="1--12",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5517.txt",
  key="RFC 5517",
  abstract={This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5517",
  }

@misc{rfc5518,
  author="P. Hoffman and J. Levine and A. Hathcock",
  title="{Vouch By Reference}",
  howpublished="RFC 5518 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5518",
  pages="1--12",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5518.txt",
  key="RFC 5518",
  abstract={This document describes the Vouch By Reference (VBR) protocol.  VBR is a protocol for adding third-party certification to email.  It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]},
  keywords="VBR, DKIM, SenderID, DK, reputation",
  doi="10.17487/RFC5518",
  }

@misc{rfc5519,
  author="J. Chesterfield and B. Haberman",
  title="{Multicast Group Membership Discovery MIB}",
  howpublished="RFC 5519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5519",
  pages="1--41",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5519.txt",
  key="RFC 5519",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]},
  keywords="management information base, mgmd, mld, multicast listener discovery, MGMD-STD-MIB",
  doi="10.17487/RFC5519",
  }

@misc{rfc5520,
  author="R. Bradford and JP. Vasseur and A. Farrel",
  title="{Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism}",
  howpublished="RFC 5520 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5520",
  pages="1--19",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5520.txt",
  key="RFC 5520",
  abstract={Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]},
  keywords="confidential path segment, cps, pcep",
  doi="10.17487/RFC5520",
  }

@misc{rfc5521,
  author="E. Oki and T. Takeda and A. Farrel",
  title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions}",
  howpublished="RFC 5521 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5521",
  pages="1--16",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5521.txt",
  key="RFC 5521",
  abstract={The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed ``route exclusions''. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]},
  keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path",
  doi="10.17487/RFC5521",
  }

@misc{rfc5522,
  author="W. Eddy and W. Ivancic and T. Davis",
  title="{Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks}",
  howpublished="RFC 5522 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5522",
  pages="1--31",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5522.txt",
  key="RFC 5522",
  abstract={This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration. Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.},
  keywords="NEMO, aeronautics, space exploration, route optimization, mobility",
  doi="10.17487/RFC5522",
  }

@misc{rfc5523,
  author="L. Berger",
  title="{OSPFv3-Based Layer 1 VPN Auto-Discovery}",
  howpublished="RFC 5523 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5523",
  pages="1--12",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5523.txt",
  key="RFC 5523",
  abstract={This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism.  This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism.  The notable functional difference is the support of IPv6.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="open shortest path first, layer 1 virtual private network",
  doi="10.17487/RFC5523",
  }

@misc{rfc5524,
  author="D. Cridland",
  title="{Extended URLFETCH for Binary and Converted Parts}",
  howpublished="RFC 5524 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5524",
  pages="1--9",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5524.txt",
  key="RFC 5524",
  abstract={The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications.  This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]},
  keywords="IMAP, Lemonade",
  doi="10.17487/RFC5524",
  }

@misc{rfc5525,
  author="T. Dreibholz and J. Mulik",
  title="{Reliable Server Pooling MIB Module Definition}",
  howpublished="RFC 5525 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5525",
  pages="1--46",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5525.txt",
  key="RFC 5525",
  abstract={Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling.  The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol).  This document defines an \\%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="RSerPool, Management Information Base, asap, aggregate server access protocol, enrp, endpoint handlespace redundancy protocol, RSERPOOL-MIB",
  doi="10.17487/RFC5525",
  }

@misc{rfc5526,
  author="J. Livingood and P. Pfautz and R. Stastny",
  title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM}",
  howpublished="RFC 5526 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5526",
  pages="1--5",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5526.txt",
  key="RFC 5526",
  abstract={This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to ``e164.arpa'', as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees).  This memo provides information for the Internet community.},
  keywords="e164.arpa",
  doi="10.17487/RFC5526",
  }

@misc{rfc5527,
  author="M. Haberler and O. Lendl and R. Stastny",
  title="{Combined User and Infrastructure ENUM in the e164.arpa Tree}",
  howpublished="RFC 5527 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5527",
  pages="1--10",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5527.txt",
  key="RFC 5527",
  abstract={This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice.  This interim solution will be deprecated after implementation of the long-term solution.  This memo provides information for the Internet community.},
  keywords="e164.arpa",
  doi="10.17487/RFC5527",
  }

@misc{rfc5528,
  author="A. Kato and M. Kanda and S. Kanno",
  title="{Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms}",
  howpublished="RFC 5528 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5528",
  pages="1--22",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5528.txt",
  key="RFC 5528",
  abstract={This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM).  The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community.  This memo provides information for the Internet community.},
  keywords="Camellia, Block Cipher, Mode of operation",
  doi="10.17487/RFC5528",
  }

@misc{rfc5529,
  author="A. Kato and M. Kanda and S. Kanno",
  title="{Modes of Operation for Camellia for Use with IPsec}",
  howpublished="RFC 5529 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5529",
  pages="1--7",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5529.txt",
  key="RFC 5529",
  abstract={This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]},
  keywords="IPsec, Camellia, Block Cipher, Mode of operation",
  doi="10.17487/RFC5529",
  }

@misc{rfc5530,
  author="A. Gulbrandsen",
  title="{IMAP Response Codes}",
  howpublished="RFC 5530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5530",
  pages="1--9",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5530.txt",
  key="RFC 5530",
  abstract={IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]},
  keywords="machine-readable response codes",
  doi="10.17487/RFC5530",
  }

@misc{rfc5531,
  author="R. Thurlow",
  title="{RPC: Remote Procedure Call Protocol Specification Version 2}",
  howpublished="RFC 5531 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5531",
  pages="1--63",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5531.txt",
  key="RFC 5531",
  abstract={This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted.  This document obsoletes RFC 1831. [STANDARDS-TRACK]},
  keywords="RPC, ONC, Open Network Computing",
  doi="10.17487/RFC5531",
  }

@misc{rfc5532,
  author="T. Talpey and C. Juszczak",
  title="{Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement}",
  howpublished="RFC 5532 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5532",
  pages="1--15",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5532.txt",
  key="RFC 5532",
  abstract={This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols.  NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead.  This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general.  This memo provides information for the Internet community.},
  keywords="RPC, XDR, ONC, RDDP, NFSv4",
  doi="10.17487/RFC5532",
  }

@misc{rfc5533,
  author="E. Nordmark and M. Bagnulo",
  title="{Shim6: Level 3 Multihoming Shim Protocol for IPv6}",
  howpublished="RFC 5533 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5533",
  pages="1--124",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5533.txt",
  key="RFC 5533",
  abstract={This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table.  The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]},
  keywords="locator pair",
  doi="10.17487/RFC5533",
  }

@misc{rfc5534,
  author="J. Arkko and I. van Beijnum",
  title="{Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming}",
  howpublished="RFC 5534 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5534",
  pages="1--36",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5534.txt",
  key="RFC 5534",
  abstract={This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes.  It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]},
  keywords="Shim6, reachability protocol, REAP",
  doi="10.17487/RFC5534",
  }

@misc{rfc5535,
  author="M. Bagnulo",
  title="{Hash-Based Addresses (HBA)}",
  howpublished="RFC 5535 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5535",
  pages="1--25",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5535.txt",
  key="RFC 5535",
  abstract={This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site.  This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses.  The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves.  This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number.  Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers.  The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]},
  keywords="Shim6, multi-homing, cryptographically generated addresses (cgas),",
  doi="10.17487/RFC5535",
  }

@misc{rfc5536,
  author="K. Murchison and C. Lindsey and D. Kohn",
  title="{Netnews Article Format}",
  howpublished="RFC 5536 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5536",
  pages="1--36",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5536.txt",
  key="RFC 5536",
  abstract={This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045).  This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]},
  keywords="Usenet, Usefor",
  doi="10.17487/RFC5536",
  }

@misc{rfc5537,
  author="R. Allbery and C. Lindsey",
  title="{Netnews Architecture and Protocols}",
  howpublished="RFC 5537 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5537",
  pages="1--48",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5537.txt",
  key="RFC 5537",
  abstract={This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them.  It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]},
  keywords="usefor, Usenet, netnews",
  doi="10.17487/RFC5537",
  }

@misc{rfc5538,
  author="F. Ellermann",
  title="{The 'news' and 'nntp' URI Schemes}",
  howpublished="RFC 5538 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5538",
  pages="1--14",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5538.txt",
  key="RFC 5538",
  abstract={This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]},
  doi="10.17487/RFC5538",
  }

@misc{rfc5539,
  author="M. Badra",
  title="{NETCONF over Transport Layer Security (TLS)}",
  howpublished="RFC 5539 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5539",
  pages="1--7",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7589",
url="https://www.rfc-editor.org/rfc/rfc5539.txt",
  key="RFC 5539",
  abstract={The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.  This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS-TRACK]},
  keywords="Authentication, TLS, RPC",
  doi="10.17487/RFC5539",
  }

@misc{rfc5540,
  author="RFC Editor",
  title="{40 Years of RFCs}",
  howpublished="RFC 5540 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5540",
  pages="1--3",
  year=2009,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5540.txt",
  key="RFC 5540",
  abstract={This RFC marks the 40th anniversary of the RFC document series.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5540",
  }

@misc{rfc5541,
  author="JL. Le Roux and JP. Vasseur and Y. Lee",
  title="{Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)}",
  howpublished="RFC 5541 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5541",
  pages="1--23",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5541.txt",
  key="RFC 5541",
  abstract={The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation. This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]},
  keywords="pcc, path computation client",
  doi="10.17487/RFC5541",
  }

@misc{rfc5542,
  author="T. Nadeau and D. Zelig and O. Nicklass",
  title="{Definitions of Textual Conventions for Pseudowire (PW) Management}",
  howpublished="RFC 5542 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5542",
  pages="1--11",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5542.txt",
  key="RFC 5542",
  abstract={This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information.  The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]},
  keywords="Pseudowire, PWE3, MIB, PWE3-TC, PW-TC",
  doi="10.17487/RFC5542",
  }

@misc{rfc5543,
  author="H. Ould-Brahim and D. Fedyk and Y. Rekhter",
  title="{BGP Traffic Engineering Attribute}",
  howpublished="RFC 5543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5543",
  pages="1--6",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7606",
url="https://www.rfc-editor.org/rfc/rfc5543.txt",
  key="RFC 5543",
  abstract={This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information. The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]},
  keywords="BGP-TE, BGP-TE Attribute, Traffic Engineering with BGP, Inter-domain Traffic Engineering, L1VPN BGP-TE, BGP-TE-VPN, VPN BGP Traffic Engineering Attribute",
  doi="10.17487/RFC5543",
  }

@misc{rfc5544,
  author="A. Santoni",
  title="{Syntax for Binding Documents with Time-Stamps}",
  howpublished="RFC 5544 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5544",
  pages="1--13",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 5955",
url="https://www.rfc-editor.org/rfc/rfc5544.txt",
  key="RFC 5544",
  abstract={This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where ``time-stamp token'' has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed. The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="time-stamp token,",
  doi="10.17487/RFC5544",
  }

@misc{rfc5545,
  author="B. Desruisseaux",
  title="{Internet Calendaring and Scheduling Core Object Specification (iCalendar)}",
  howpublished="RFC 5545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5545",
  pages="1--168",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5546, 6868, 7529, 7953, 7986",
url="https://www.rfc-editor.org/rfc/rfc5545.txt",
  key="RFC 5545",
  abstract={This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]},
  keywords="calsify, calsched, calsch, caldav, calendar, calendaring, meeting, event, task, to-do, journal, appointment, agenda, schedule, scheduling, ical, icalendar, itip, imip, text/calendar, ischedule, xCalendar",
  doi="10.17487/RFC5545",
  }

@misc{rfc5546,
  author="C. Daboo",
  title="{iCalendar Transport-Independent Interoperability Protocol (iTIP)}",
  howpublished="RFC 5546 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5546",
  pages="1--133",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6638",
url="https://www.rfc-editor.org/rfc/rfc5546.txt",
  key="RFC 5546",
  abstract={This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems. The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]},
  keywords="calendar, scheduling",
  doi="10.17487/RFC5546",
  }

@misc{rfc5547,
  author="M. Garcia-Martin and M. Isomaki and G. Camarillo and S. Loreto and P. Kyzivat",
  title="{A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer}",
  howpublished="RFC 5547 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5547",
  pages="1--50",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5547.txt",
  key="RFC 5547",
  abstract={This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264.  SDP is extended to describe the attributes of the files to be transferred.  The offerer can describe either the files it wants to send or the files it would like to receive.  The answerer can either accept or reject the offer separately for each individual file.  The transfer of one or more files is initiated after a successful negotiation.  The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints.  The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]},
  keywords="msrp, message session relay protocol",
  doi="10.17487/RFC5547",
  }

@misc{rfc5548,
  author="M. Dohler and T. Watteyne and T. Winter and D. Barthel",
  title="{Routing Requirements for Urban Low-Power and Lossy Networks}",
  howpublished="RFC 5548 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5548",
  pages="1--21",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5548.txt",
  key="RFC 5548",
  abstract={The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document.  In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws.  These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions).  The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols.  The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios.  As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous.  This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.  This memo provides information for the Internet community.},
  keywords="u-lln, roll, routing over low-power and loss",
  doi="10.17487/RFC5548",
  }

@misc{rfc5549,
  author="F. Le Faucheur and E. Rosen",
  title="{Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop}",
  howpublished="RFC 5549 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5549",
  pages="1--10",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5549.txt",
  key="RFC 5549",
  abstract={Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).  The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol.  This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]},
  keywords="BGP, IPv6, IPv4",
  doi="10.17487/RFC5549",
  }

@misc{rfc5550,
  author="D. Cridland and A. Melnikov and S. Maes",
  title="{The Internet Email to Support Diverse Service Environments (Lemonade) Profile}",
  howpublished="RFC 5550 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5550",
  pages="1--41",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5550.txt",
  key="RFC 5550",
  abstract={This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]},
  keywords="IMAP, Sieve, SMTP, Lemonade, mobile email, low-bandwidth efficient",
  doi="10.17487/RFC5550",
  }

@misc{rfc5551,
  author="R. Gellens",
  title="{Lemonade Notifications Architecture}",
  howpublished="RFC 5551 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5551",
  pages="1--12",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5551.txt",
  key="RFC 5551",
  abstract={Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for ``interesting''. This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group. This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.},
  keywords="notification, filtering",
  doi="10.17487/RFC5551",
  }

@misc{rfc5552,
  author="D. Burke and M. Scott",
  title="{SIP Interface to VoiceXML Media Services}",
  howpublished="RFC 5552 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5552",
  pages="1--36",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5552.txt",
  key="RFC 5552",
  abstract={This document describes a SIP interface to VoiceXML media services.  Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities.  This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]},
  keywords="VoiceXML, SIP, MRF, IVR, IMS",
  doi="10.17487/RFC5552",
  }

@misc{rfc5553,
  author="A. Farrel and R. Bradford and JP. Vasseur",
  title="{Resource Reservation Protocol (RSVP) Extensions for Path Key Support}",
  howpublished="RFC 5553 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5553",
  pages="1--14",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5553.txt",
  key="RFC 5553",
  abstract={The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]},
  keywords="pks, path key subobject, ero, explicit route object, rro, record route object",
  doi="10.17487/RFC5553",
  }

@misc{rfc5554,
  author="N. Williams",
  title="{Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings}",
  howpublished="RFC 5554 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5554",
  pages="1--4",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5554.txt",
  key="RFC 5554",
  abstract={This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) ``channel bindings'' facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]},
  keywords="GSS, GSS-API, channel binding, and C-bindings",
  doi="10.17487/RFC5554",
  }

@misc{rfc5555,
  author="H. Soliman",
  title="{Mobile IPv6 Support for Dual Stack Hosts and Routers}",
  howpublished="RFC 5555 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5555",
  pages="1--41",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5555.txt",
  key="RFC 5555",
  abstract={The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only.  This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent.  This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]},
  keywords="nemo, mipv6, ipv4",
  doi="10.17487/RFC5555",
  }

@misc{rfc5556,
  author="J. Touch and R. Perlman",
  title="{Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement}",
  howpublished="RFC 5556 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5556",
  pages="1--17",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5556.txt",
  key="RFC 5556",
  abstract={Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges.  These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support.  Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees).  This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer.  This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities.  This memo provides information for the Internet community.},
  keywords="spanning tree protocol, ieee 802.1",
  doi="10.17487/RFC5556",
  }

@misc{rfc5557,
  author="Y. Lee and JL. Le Roux and D. King and E. Oki",
  title="{Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization}",
  howpublished="RFC 5557 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5557",
  pages="1--26",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5557.txt",
  key="RFC 5557",
  abstract={The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]},
  keywords="pcc, path communication client, pce, gco, global concurrent optimization, nms, network management system",
  doi="10.17487/RFC5557",
  }

@misc{rfc5558,
  author="F. Templin",
  title="{Virtual Enterprise Traversal (VET)}",
  howpublished="RFC 5558 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5558",
  pages="1--36",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5558.txt",
  key="RFC 5558",
  abstract={Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet.  Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself.  This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Enterprise, MANET, Encapsulation, Tunneling, Autoconfiguration, Subnetwork, Provider-Independent, Provider-Aggregated",
  doi="10.17487/RFC5558",
  }

@misc{rfc5559,
  author="P. Eardley",
  title="{Pre-Congestion Notification (PCN) Architecture}",
  howpublished="RFC 5559 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5559",
  pages="1--54",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5559.txt",
  key="RFC 5559",
  abstract={This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.  This memo provides information for the Internet community.},
  keywords="Quality of Service, QoS, Congestion Control, Differentiated Services, Admission Control, Termination",
  doi="10.17487/RFC5559",
  }

@misc{rfc5560,
  author="H. Uijterwaal",
  title="{A One-Way Packet Duplication Metric}",
  howpublished="RFC 5560 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5560",
  pages="1--14",
  year=2009,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6248",
url="https://www.rfc-editor.org/rfc/rfc5560.txt",
  key="RFC 5560",
  abstract={When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive. In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]},
  keywords="performance metrics, packet duplication, unidirectional",
  doi="10.17487/RFC5560",
  }

@misc{rfc5561,
  author="B. Thomas and K. Raza and S. Aggarwal and R. Aggarwal and JL. Le Roux",
  title="{LDP Capabilities}",
  howpublished="RFC 5561 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5561",
  pages="1--12",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5561.txt",
  key="RFC 5561",
  abstract={A number of enhancements to the Label Distribution Protocol (LDP) have been proposed.  Some have been implemented, and some are advancing toward standardization.  It is likely that additional enhancements will be proposed in the future.  This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]},
  keywords="MPLS, LDP, Capabilities",
  doi="10.17487/RFC5561",
  }

@misc{rfc5562,
  author="A. Kuzmanovic and A. Mondal and S. Floyd and K. Ramakrishnan",
  title="{Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets}",
  howpublished="RFC 5562 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5562",
  pages="1--33",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5562.txt",
  key="RFC 5562",
  abstract={The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets. This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.},
  keywords="ecn-capable",
  doi="10.17487/RFC5562",
  }

@misc{rfc5563,
  author="K. Leung and G. Dommety and P. Yegani and K. Chowdhury",
  title="{WiMAX Forum / 3GPP2 Proxy Mobile IPv4}",
  howpublished="RFC 5563 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5563",
  pages="1--41",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5563.txt",
  key="RFC 5563",
  abstract={Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address.  The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent.  However, there are many IPv4 devices without such capability due to various reasons.  This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device.  This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mipv4, pmipv4",
  doi="10.17487/RFC5563",
  }

@misc{rfc5564,
  author="A. El-Sherbiny and M. Farah and I. Oueichek and A. Al-Zoman",
  title="{Linguistic Guidelines for the Use of the Arabic Language in Internet Domains}",
  howpublished="RFC 5564 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5564",
  pages="1--11",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5564.txt",
  key="RFC 5564",
  abstract={This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names.  It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="arabic domain names",
  doi="10.17487/RFC5564",
  }

@misc{rfc5565,
  author="J. Wu and Y. Cui and C. Metz and E. Rosen",
  title="{Softwire Mesh Framework}",
  howpublished="RFC 5565 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5565",
  pages="1--31",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5565.txt",
  key="RFC 5565",
  abstract={The Internet needs to be able to handle both IPv4 and IPv6 packets.  However, it is expected that some constituent networks of the Internet will be ``single-protocol'' networks.  One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information.  It is nevertheless required that either kind of single-protocol network be able to provide transit service for the ``other'' protocol.  This is done by passing the ``other kind'' of routing information from one edge of the single-protocol network to the other, and by tunneling the ``other kind'' of data packet from one edge to the other.  The tunnels are known as ``softwires''.  This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol.  The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5565",
  }

@misc{rfc5566,
  author="L. Berger and R. White and E. Rosen",
  title="{BGP IPsec Tunnel Encapsulation Attribute}",
  howpublished="RFC 5566 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5566",
  pages="1--8",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5566.txt",
  key="RFC 5566",
  abstract={The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops.  Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined.  This document defines support for IPsec tunnel types. [STANDARDS-TRACK]},
  keywords="border gateway protocol, safi, subsequent address family identifier",
  doi="10.17487/RFC5566",
  }

@misc{rfc5567,
  author="T. Melanchuk",
  title="{An Architectural Framework for Media Server Control}",
  howpublished="RFC 5567 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5567",
  pages="1--25",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5567.txt",
  key="RFC 5567",
  abstract={This document describes an architectural framework for Media Server control.  The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5567",
  }

@misc{rfc5568,
  author="R. Koodli",
  title="{Mobile IPv6 Fast Handovers}",
  howpublished="RFC 5568 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5568",
  pages="1--51",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7411",
url="https://www.rfc-editor.org/rfc/rfc5568.txt",
  key="RFC 5568",
  abstract={Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This ``handover latency'' resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency. This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]},
  keywords="mpiv6, handover latency",
  doi="10.17487/RFC5568",
  }

@misc{rfc5569,
  author="R. Despres",
  title="{IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)}",
  howpublished="RFC 5569 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5569",
  pages="1--10",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5569.txt",
  key="RFC 5569",
  abstract={IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment.  Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.  Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix.  A service provider has used this mechanism for its own IPv6 ``rapid deployment'': five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6, IPv4, migration, transition, 6to4, 6rd",
  doi="10.17487/RFC5569",
  }

@misc{rfc5570,
  author="M. StJohns and R. Atkinson and G. Thomas",
  title="{Common Architecture Label IPv6 Security Option (CALIPSO)}",
  howpublished="RFC 5570 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5570",
  pages="1--52",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5570.txt",
  key="RFC 5570",
  abstract={This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets.  It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.  This memo provides information for the Internet community.},
  keywords="sensitivity labels, mls, multi-level secure",
  doi="10.17487/RFC5570",
  }

@misc{rfc5571,
  author="B. Storer and C. Pignataro and M. Dos Santos and B. Stevant and L. Toutain and J. Tremblay",
  title="{Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)}",
  howpublished="RFC 5571 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5571",
  pages="1--41",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5571.txt",
  key="RFC 5571",
  abstract={This document describes the framework of the Softwire ``Hub and Spoke'' solution with the Layer Two Tunneling Protocol version 2 (L2TPv2).  The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]},
  keywords="Softwire, L2TP, Softwire Hub and Spoke, Softwire HnS, 4over6, 6over4, L2TP softwires, L2TPv2 softwires",
  doi="10.17487/RFC5571",
  }

@misc{rfc5572,
  author="M. Blanchet and F. Parent",
  title="{IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)}",
  howpublished="RFC 5572 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5572",
  pages="1--32",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5572.txt",
  key="RFC 5572",
  abstract={A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal.  The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker.  A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only.  A tunnel broker may terminate the tunnels on remote tunnel servers or on itself.  This document describes the TSP within the model of the tunnel broker model.  This document defines an Experimental Protocol for the Internet community.},
  keywords="IPv6, Tunnel, Transition, TSP",
  doi="10.17487/RFC5572",
  }

@misc{rfc5573,
  author="M. Thomson",
  title="{Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)}",
  howpublished="RFC 5573 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5573",
  pages="1--8",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5573.txt",
  key="RFC 5573",
  abstract={The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols.  This document describes a BEEP feature that enables asynchrony for individual channels.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="asynchronous beep channels",
  doi="10.17487/RFC5573",
  }

@misc{rfc5574,
  author="G. Herlein and J. Valin and A. Heggestad and A. Moizard",
  title="{RTP Payload Format for the Speex Codec}",
  howpublished="RFC 5574 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5574",
  pages="1--14",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5574.txt",
  key="RFC 5574",
  abstract={Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications.  This document describes the payload format for Speex-generated bit streams within an RTP packet.  Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]},
  keywords="Voip, SDP, audio, CELLP, Xiph.Org",
  doi="10.17487/RFC5574",
  }

@misc{rfc5575,
  author="P. Marques and N. Sheth and R. Raszuk and B. Greene and J. Mauch and D. McPherson",
  title="{Dissemination of Flow Specification Rules}",
  howpublished="RFC 5575 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5575",
  pages="1--22",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7674",
url="https://www.rfc-editor.org/rfc/rfc5575.txt",
  key="RFC 5575",
  abstract={This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]},
  keywords="IDR, Inter-domain routing, BGP, DDOS, Denial of Service, ACL, Firewall, Filter",
  doi="10.17487/RFC5575",
  }

@misc{rfc5576,
  author="J. Lennox and J. Ott and T. Schierl",
  title="{Source-Specific Media Attributes in the Session Description Protocol (SDP)}",
  howpublished="RFC 5576 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5576",
  pages="1--18",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5576.txt",
  key="RFC 5576",
  abstract={The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream.  This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources.  It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, rtp, synchronization source, ssrc, fid, flow identification, fec, forward error correction",
  doi="10.17487/RFC5576",
  }

@misc{rfc5577,
  author="P. Luthi and R. Even",
  title="{RTP Payload Format for ITU-T Recommendation G.722.1}",
  howpublished="RFC 5577 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5577",
  pages="1--11",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5577.txt",
  key="RFC 5577",
  abstract={International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec.  This document describes the payload format for including G.722.1-generated bit streams within an RTP packet.  The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]},
  keywords="international telecommunication union, wide-band audio coded",
  doi="10.17487/RFC5577",
  }

@misc{rfc5578,
  author="B. Berry and S. Ratliff and E. Paradise and T. Kaiser and M. Adams",
  title="{PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics}",
  howpublished="RFC 5578 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5578",
  pages="1--24",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5578.txt",
  key="RFC 5578",
  abstract={This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report.  These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="point-to-point protocol over ethernet, link quality metric",
  doi="10.17487/RFC5578",
  }

@misc{rfc5579,
  author="F. Templin",
  title="{Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces}",
  howpublished="RFC 5579 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5579",
  pages="1--9",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5579.txt",
  key="RFC 5579",
  abstract={The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation.  The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however.  This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ISATAP, Tunnel, Encapsulation, Map-and-Encaps, IPv4, IPv6",
  doi="10.17487/RFC5579",
  }

@misc{rfc5580,
  author="H. Tschofenig and F. Adrangi and M. Jones and A. Lior and B. Aboba",
  title="{Carrying Location Objects in RADIUS and Diameter}",
  howpublished="RFC 5580 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5580",
  pages="1--53",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5580.txt",
  key="RFC 5580",
  abstract={This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter. The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]},
  keywords="remote authentication dial-in user service, location information",
  doi="10.17487/RFC5580",
  }

@misc{rfc5581,
  author="D. Shaw",
  title="{The Camellia Cipher in OpenPGP}",
  howpublished="RFC 5581 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5581",
  pages="1--3",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5581.txt",
  key="RFC 5581",
  abstract={This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol.  This memo provides information for the Internet community.},
  keywords="PGP, GPG, GnuPG, Encryption, Symmetric",
  doi="10.17487/RFC5581",
  }

@misc{rfc5582,
  author="H. Schulzrinne",
  title="{Location-to-URL Mapping Architecture and Framework}",
  howpublished="RFC 5582 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5582",
  pages="1--17",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5582.txt",
  key="RFC 5582",
  abstract={This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol.  The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS.  This memo provides information for the Internet community.},
  keywords="ECRIT, Mapping, LoST, Emergency calling",
  doi="10.17487/RFC5582",
  }

@misc{rfc5583,
  author="T. Schierl and S. Wenger",
  title="{Signaling Media Decoding Dependency in the Session Description Protocol (SDP)}",
  howpublished="RFC 5583 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5583",
  pages="1--18",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5583.txt",
  key="RFC 5583",
  abstract={This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type ``DDP'' -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled ``Grouping of Media Lines in the Session Description Protocol''. In addition, an attribute is specified describing the relationship of the media streams in a ``DDP'' group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]},
  keywords="media coding, ddp, decoding dependency",
  doi="10.17487/RFC5583",
  }

@misc{rfc5584,
  author="M. Hatanaka and J. Matsumoto",
  title="{RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family}",
  howpublished="RFC 5584 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5584",
  pages="1--30",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5584.txt",
  key="RFC 5584",
  abstract={This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs.  Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels.  The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]},
  keywords="RTP, audio, fragmentation, layered coding, multiplexed, multi-session, multi-channel, redundancy, scalable, ATRAC, ATRAC3, ATRAC-X, ATRAC Advanced Lossless, AAL, Sony Corporation",
  doi="10.17487/RFC5584",
  }

@misc{rfc5585,
  author="T. Hansen and D. Crocker and P. Hallam-Baker",
  title="{DomainKeys Identified Mail (DKIM) Service Overview}",
  howpublished="RFC 5585 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5585",
  pages="1--24",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5585.txt",
  key="RFC 5585",
  abstract={This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service.  It also describes how DKIM relates to other IETF message signature technologies.  It is intended for those who are adopting, developing, or deploying DKIM.  DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient.  The organization can be the author's, the originating sending site, an intermediary, or one of their agents.  A message can contain multiple signatures from the same or different organizations involved with the message.  DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871).  This permits verification of a responsible organization, as well as the integrity of the message contents.  DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.  DKIM's authentication of email identity can assist in the global control of ``spam'' and ``phishing''.  This memo provides information for the Internet community.},
  keywords="Email, Electroni Mail, Internet Mail, Message Verification",
  doi="10.17487/RFC5585",
  }

@misc{rfc5586,
  author="M. Bocci and M. Vigoureux and S. Bryant",
  title="{MPLS Generic Associated Channel}",
  howpublished="RFC 5586 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5586",
  pages="1--19",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6423, 7026, 7214, 7274",
url="https://www.rfc-editor.org/rfc/rfc5586.txt",
  key="RFC 5586",
  abstract={This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires.  In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.},
  keywords="mpls-tp, oam, g-ach, ach, associated channel header, gal, generic associated label",
  doi="10.17487/RFC5586",
  }

@misc{rfc5587,
  author="N. Williams",
  title="{Extended Generic Security Service Mechanism Inquiry APIs}",
  howpublished="RFC 5587 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5587",
  pages="1--16",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5587.txt",
  key="RFC 5587",
  abstract={This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]},
  keywords="GSS-API, mechanism, inquiry, extension",
  doi="10.17487/RFC5587",
  }

@misc{rfc5588,
  author="N. Williams",
  title="{Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials}",
  howpublished="RFC 5588 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5588",
  pages="1--7",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5588.txt",
  key="RFC 5588",
  abstract={This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store.  This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]},
  keywords="GSS-API, credential, gss\_store\_cred",
  doi="10.17487/RFC5588",
  }

@misc{rfc5589,
  author="R. Sparks and A. Johnston and D. Petrie",
  title="{Session Initiation Protocol (SIP) Call Control - Transfer}",
  howpublished="RFC 5589 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5589",
  pages="1--58",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5589.txt",
  key="RFC 5589",
  abstract={This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP).  SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer.  This work is part of the SIP multiparty call control framework.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="REFER, GRUU, Attended Transfer, Target-Dialog, Out of Dialog REFER, SIP, SIP Services, blind transfer, SIP Features, Replaces, Referred-By",
  doi="10.17487/RFC5589",
  }

@misc{rfc5590,
  author="D. Harrington and J. Schoenwaelder",
  title="{Transport Subsystem for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 5590 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5590",
  pages="1--34",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5590.txt",
  key="RFC 5590",
  abstract={This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411.  This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture.  As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models.  This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, SNMP-TRANSPORT-MIB",
  doi="10.17487/RFC5590",
  }

@misc{rfc5591,
  author="D. Harrington and W. Hardaker",
  title="{Transport Security Model for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 5591 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5591",
  pages="1--28",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5591.txt",
  key="RFC 5591",
  abstract={This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP). This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Transport Security Model, Security Model",
  doi="10.17487/RFC5591",
  }

@misc{rfc5592,
  author="D. Harrington and J. Salowey and W. Hardaker",
  title="{Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 5592 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5592",
  pages="1--36",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5592.txt",
  key="RFC 5592",
  abstract={This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Secure Shell, SSH",
  doi="10.17487/RFC5592",
  }

@misc{rfc5593,
  author="N. Cook",
  title="{Internet Message Access Protocol (IMAP) - URL Access Identifier Extension}",
  howpublished="RFC 5593 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5593",
  pages="1--10",
  year=2009,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5593.txt",
  key="RFC 5593",
  abstract={The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications. This document updates RFC 5092. [STANDARDS-TRACK]},
  keywords="urlauth, imap url",
  doi="10.17487/RFC5593",
  }

@misc{rfc5594,
  author="J. Peterson and A. Cooper",
  title="{Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008}",
  howpublished="RFC 5594 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5594",
  pages="1--28",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5594.txt",
  key="RFC 5594",
  abstract={This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes.  The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA.  The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems.  Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal.  The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community.  This memo provides information for the Internet community.},
  keywords="P2PI",
  doi="10.17487/RFC5594",
  }

@misc{rfc5595,
  author="G. Fairhurst",
  title="{The Datagram Congestion Control Protocol (DCCP) Service Codes}",
  howpublished="RFC 5595 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5595",
  pages="1--19",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6335",
url="https://www.rfc-editor.org/rfc/rfc5595.txt",
  key="RFC 5595",
  abstract={This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340.  It motivates the setting of a Service Code by applications.  Service Codes provide a method to identify the intended service/application to process a DCCP connection request.  This provides improved flexibility in the use and assignment of port numbers for connection multiplexing.  The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls).  This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]},
  keywords="DCCP-Request Ports",
  doi="10.17487/RFC5595",
  }

@misc{rfc5596,
  author="G. Fairhurst",
  title="{Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal}",
  howpublished="RFC 5596 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5596",
  pages="1--25",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5596.txt",
  key="RFC 5596",
  abstract={This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol.  The update adds support for the DCCP-Listen packet.  This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]},
  keywords="DCCP, NAT traversal, Middlebox Issues",
  doi="10.17487/RFC5596",
  }

@misc{rfc5597,
  author="R. Denis-Courmont",
  title="{Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol}",
  howpublished="RFC 5597 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5597",
  pages="1--9",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5597.txt",
  key="RFC 5597",
  abstract={This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP).  These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF.  Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="dccp",
  doi="10.17487/RFC5597",
  }

@misc{rfc5598,
  author="D. Crocker",
  title="{Internet Mail Architecture}",
  howpublished="RFC 5598 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5598",
  pages="1--54",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5598.txt",
  key="RFC 5598",
  abstract={Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service.  These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness.  To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them.  But the many differences in perspective currently make it difficult to know exactly what another participant means.  To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.  This memo provides information for the Internet community.},
  keywords="email, e-mail, service, mime, architecture, mta, mua, msa, mda, admd, user, originator, recipient, transfer, message transfer, deliver, delivery, relay, header, gateway agent, gateway actor, gateway, sieve, dsn, mdn, tussle, mhs, Message handling service, message transfer agent, message user agent, mail submission agent, mail delivery agent, administrative management domain",
  doi="10.17487/RFC5598",
  }

@misc{rfc5601,
  author="T. Nadeau and D. Zelig",
  title="{Pseudowire (PW) Management Information Base (MIB)}",
  howpublished="RFC 5601 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5601",
  pages="1--67",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5601.txt",
  key="RFC 5601",
  abstract={This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]},
  keywords="pseudowire edge-to-edge services, IANA-PWE3-MIB, PW-STD-MIB",
  doi="10.17487/RFC5601",
  }

@misc{rfc5602,
  author="D. Zelig and T. Nadeau",
  title="{Pseudowire (PW) over MPLS PSN Management Information Base (MIB)}",
  howpublished="RFC 5602 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5602",
  pages="1--31",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5602.txt",
  key="RFC 5602",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]},
  keywords="pw operation, PW-MPLS-STD-MIB",
  doi="10.17487/RFC5602",
  }

@misc{rfc5603,
  author="D. Zelig and T. Nadeau",
  title="{Ethernet Pseudowire (PW) Management Information Base (MIB)}",
  howpublished="RFC 5603 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5603",
  pages="1--23",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5603.txt",
  key="RFC 5603",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]},
  keywords="ethernet pw, PW-ENET-STD-MIB",
  doi="10.17487/RFC5603",
  }

@misc{rfc5604,
  author="O. Nicklass",
  title="{Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)}",
  howpublished="RFC 5604 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5604",
  pages="1--41",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5604.txt",
  key="RFC 5604",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]},
  keywords="mib, management information base, pseudowire encapsulation, t1, e1, t3, e3",
  doi="10.17487/RFC5604",
  }

@misc{rfc5605,
  author="O. Nicklass and T. Nadeau",
  title="{Managed Objects for ATM over Packet Switched Networks (PSNs)}",
  howpublished="RFC 5605 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5605",
  pages="1--36",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5605.txt",
  key="RFC 5605",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]},
  keywords="mib, management information base, atm pseudowire",
  doi="10.17487/RFC5605",
  }

@misc{rfc5606,
  author="J. Peterson and T. Hardie and J. Morris",
  title="{Implications of 'retransmission-allowed' for SIP Location Conveyance}",
  howpublished="RFC 5606 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5606",
  pages="1--11",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5606.txt",
  key="RFC 5606",
  abstract={This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity. Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.},
  keywords="pidf-lo,  presence information data format for location objects",
  doi="10.17487/RFC5606",
  }

@misc{rfc5607,
  author="D. Nelson and G. Weber",
  title="{Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management}",
  howpublished="RFC 5607 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5607",
  pages="1--25",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5607.txt",
  key="RFC 5607",
  abstract={This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS).  Both local and remote management are supported, with granular access rights and management privileges.  Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]},
  keywords="Network Management, Device Management, Simple Network Management Protocol, SNMP, Network Configuration Protocol, NETCONF, Access Control",
  doi="10.17487/RFC5607",
  }

@misc{rfc5608,
  author="K. Narayan and D. Nelson",
  title="{Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models}",
  howpublished="RFC 5608 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5608",
  pages="1--14",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5608.txt",
  key="RFC 5608",
  abstract={This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions.  While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]},
  keywords="authorization service, ssh transport model, secure shell transport model",
  doi="10.17487/RFC5608",
  }

@misc{rfc5609,
  author="V. Fajardo and Y. Ohba and R. Marin-Lopez",
  title="{State Machines for the Protocol for Carrying Authentication for Network Access (PANA)}",
  howpublished="RFC 5609 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5609",
  pages="1--30",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5609.txt",
  key="RFC 5609",
  abstract={This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA).  The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine.  The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines.  The state machines and associated models are informative only.  Implementations may achieve the same results using different methods.  This memo provides information for the Internet community.},
  keywords="PANA, State Machine, EAP",
  doi="10.17487/RFC5609",
  }

@misc{rfc5610,
  author="E. Boschi and B. Trammell and L. Mark and T. Zseby",
  title="{Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements}",
  howpublished="RFC 5610 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5610",
  pages="1--20",
  year=2009,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5610.txt",
  key="RFC 5610",
  abstract={This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream.  This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]},
  keywords="enterprise-specific Information Element, IPFIX Template, type record, type options template",
  doi="10.17487/RFC5610",
  }

@misc{rfc5611,
  author="A. Vainshtein and S. Galtzur",
  title="{Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires}",
  howpublished="RFC 5611 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5611",
  pages="1--11",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5611.txt",
  key="RFC 5611",
  abstract={This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.  Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]},
  keywords="l2tpv3, layer tow tunneling protocol version 3, structure-agnostic, structure-aware, cesopsn, tdmoip",
  doi="10.17487/RFC5611",
  }

@misc{rfc5612,
  author="P. Eronen and D. Harrington",
  title="{Enterprise Number for Documentation Use}",
  howpublished="RFC 5612 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5612",
  pages="1--4",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5612.txt",
  key="RFC 5612",
  abstract={This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation.  This memo provides information for the Internet community.},
  keywords="smi network management private enterprise code",
  doi="10.17487/RFC5612",
  }

@misc{rfc5613,
  author="A. Zinin and A. Roy and L. Nguyen and B. Friedman and D. Yeung",
  title="{OSPF Link-Local Signaling}",
  howpublished="RFC 5613 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5613",
  pages="1--12",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5613.txt",
  key="RFC 5613",
  abstract={OSPF is a link-state intra-domain routing protocol.  OSPF routers exchange information on a link using packets that follow a well-defined fixed format.  The format is not flexible enough to enable new features that need to exchange arbitrary data.  This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.  This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.},
  keywords="open shortest path first, intra-domain routing",
  doi="10.17487/RFC5613",
  }

@misc{rfc5614,
  author="R. Ogier and P. Spagnolo",
  title="{Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding}",
  howpublished="RFC 5614 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5614",
  pages="1--71",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7038",
url="https://www.rfc-editor.org/rfc/rfc5614.txt",
  key="RFC 5614",
  abstract={This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs).  The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs.  OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs.  The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness.  This CDS is exploited in two ways.  First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.  Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks.  The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension.  The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states.  Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="MANET routing, link-state routing, CDS flooding, mesh network, MANET Designated Router, MDR",
  doi="10.17487/RFC5614",
  }

@misc{rfc5615,
  author="C. Groves and Y. Lin",
  title="{H.248/MEGACO Registration Procedures}",
  howpublished="RFC 5615 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5615",
  pages="1--14",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5615.txt",
  key="RFC 5615",
  abstract={This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Package, Error Code, ServiceChange Reason, Profile",
  doi="10.17487/RFC5615",
  }

@misc{rfc5616,
  author="N. Cook",
  title="{Streaming Internet Messaging Attachments}",
  howpublished="RFC 5616 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5616",
  pages="1--28",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5616.txt",
  key="RFC 5616",
  abstract={This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content. The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.},
  keywords="IMAP, SIP, streaming, stream, email, multimedia, lemonade, attachments, video, audio",
  doi="10.17487/RFC5616",
  }

@misc{rfc5617,
  author="E. Allman and J. Fenton and M. Delany and J. Levine",
  title="{DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)}",
  howpublished="RFC 5617 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5617",
  pages="1--21",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5617.txt",
  key="RFC 5617",
  abstract={DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages.  This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address.  It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]},
  keywords="email, e-mail, rfc 5322, rfc 5322, rfc 822, rfc 822, rfc 5321, rfc 5321, rfc 821, rfc 821, rfc 4871, rfc 4871, DKIM, domain keys, domainkeys, ADSP, ADSP, SSP, architecture, mta, user, delivery, smtp, submission,  email, e-mail, smtp, Internet, mailfrom, mail from, author, return address, sender signing, signing practices",
  doi="10.17487/RFC5617",
  }

@misc{rfc5618,
  author="A. Morton and K. Hedayat",
  title="{Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 5618 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5618",
  pages="1--8",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5618.txt",
  key="RFC 5618",
  abstract={This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol).  The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously.  The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]},
  keywords="twamp-control protocol, twamp-test protocol, twamp modes",
  doi="10.17487/RFC5618",
  }

@misc{rfc5619,
  author="S. Yamamoto and C. Williams and H. Yokota and F. Parent",
  title="{Softwire Security Analysis and Requirements}",
  howpublished="RFC 5619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5619",
  pages="1--28",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5619.txt",
  key="RFC 5619",
  abstract={This document describes security guidelines for the softwire ``Hubs and Spokes'' and ``Mesh'' solutions.  Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]},
  keywords="IPv6, Tunnel, Softwire, Transition",
  doi="10.17487/RFC5619",
  }

@misc{rfc5620,
  author="O. Kolkman and IAB",
  title="{RFC Editor Model (Version 1)}",
  howpublished="RFC 5620 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5620",
  pages="1--19",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFCs 6548, 6635",
url="https://www.rfc-editor.org/rfc/rfc5620.txt",
  key="RFC 5620",
  abstract={The RFC Editor performs a number of functions that may be carried out by various persons or entities.  The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher.  It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board.  The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency.  This memo provides information for the Internet community.},
  keywords="RFC Series Editor, Independent Stream Editor",
  doi="10.17487/RFC5620",
  }

@misc{rfc5621,
  author="G. Camarillo",
  title="{Message Body Handling in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5621 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5621",
  pages="1--19",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5621.txt",
  key="RFC 5621",
  abstract={This document specifies how message bodies are handled in SIP.  Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]},
  keywords="Message body, MIME, SIP",
  doi="10.17487/RFC5621",
  }

@misc{rfc5622,
  author="S. Floyd and E. Kohler",
  title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)}",
  howpublished="RFC 5622 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5622",
  pages="1--19",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6323",
url="https://www.rfc-editor.org/rfc/rfc5622.txt",
  key="RFC 5622",
  abstract={This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets.  CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time.  The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion.  CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ccid 4, congestion control identifier 4",
  doi="10.17487/RFC5622",
  }

@misc{rfc5623,
  author="E. Oki and T. Takeda and JL. Le Roux and A. Farrel",
  title="{Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering}",
  howpublished="RFC 5623 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5623",
  pages="1--34",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5623.txt",
  key="RFC 5623",
  abstract={A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.},
  keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path, Virtual Network Topology",
  doi="10.17487/RFC5623",
  }

@misc{rfc5624,
  author="J. Korhonen and H. Tschofenig and E. Davies",
  title="{Quality of Service Parameters for Usage with Diameter}",
  howpublished="RFC 5624 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5624",
  pages="1--12",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5624.txt",
  key="RFC 5624",
  abstract={This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter. The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]},
  keywords="Diameter, QoS Parameters",
  doi="10.17487/RFC5624",
  }

@misc{rfc5625,
  author="R. Bellis",
  title="{DNS Proxy Implementation Guidelines}",
  howpublished="RFC 5625 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5625",
  pages="1--12",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5625.txt",
  key="RFC 5625",
  abstract={This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="DNS, Proxy",
  doi="10.17487/RFC5625",
  }

@misc{rfc5626,
  author="C. Jennings and R. Mahy and F. Audet",
  title="{Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5626 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5626",
  pages="1--50",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5626.txt",
  key="RFC 5626",
  abstract={The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests.  However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way.  This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent.  It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5626",
  }

@misc{rfc5627,
  author="J. Rosenberg",
  title="{Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5627 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5627",
  pages="1--40",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5627.txt",
  key="RFC 5627",
  abstract={Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance.  A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU).  This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]},
  keywords="SIP, NAT, outbound, gruu, registration, traversal",
  doi="10.17487/RFC5627",
  }

@misc{rfc5628,
  author="P. Kyzivat",
  title="{Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)}",
  howpublished="RFC 5628 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5628",
  pages="1--14",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5628.txt",
  key="RFC 5628",
  abstract={RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact. However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]},
  keywords="registration",
  doi="10.17487/RFC5628",
  }

@misc{rfc5629,
  author="J. Rosenberg",
  title="{A Framework for Application Interaction in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5629 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5629",
  pages="1--38",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5629.txt",
  key="RFC 5629",
  abstract={This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications.  By interacting with applications, users can guide the way in which they operate.  The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application.  Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams.  Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input.  In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]},
  keywords="sip, dtmf",
  doi="10.17487/RFC5629",
  }

@misc{rfc5630,
  author="F. Audet",
  title="{The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5630",
  pages="1--56",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5630.txt",
  key="RFC 5630",
  abstract={This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).  It also makes normative changes to SIP. [STANDARDS-TRACK]},
  keywords="SIPS, SIP, TLS",
  doi="10.17487/RFC5630",
  }

@misc{rfc5631,
  author="R. Shacham and H. Schulzrinne and S. Thakolsri and W. Kellerer",
  title="{Session Initiation Protocol (SIP) Session Mobility}",
  howpublished="RFC 5631 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5631",
  pages="1--35",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5631.txt",
  key="RFC 5631",
  abstract={Session mobility is the transfer of media of an ongoing communication session from one device to another.  This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP).  Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example.  This document is an informational document.  This memo provides information for the Internet community.},
  keywords="third party call control (3pcc), transfer, voice over ip (voip)",
  doi="10.17487/RFC5631",
  }

@misc{rfc5632,
  author="C. Griffiths and J. Livingood and L. Popkin and R. Woundy and Y. Yang",
  title="{Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial}",
  howpublished="RFC 5632 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5632",
  pages="1--12",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5632.txt",
  key="RFC 5632",
  abstract={This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008.  This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group.  This memo provides information for the Internet community.},
  keywords="ISP, Internet Service Provider, P2P, Peer-to-Peer, P4P, Proactive Network Provider Partication for P2P, DCIA, Distributed Computing Industry Association",
  doi="10.17487/RFC5632",
  }

@misc{rfc5633,
  author="S. Dawkins",
  title="{Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers}",
  howpublished="RFC 5633 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5633",
  pages="1--5",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7437",
url="https://www.rfc-editor.org/rfc/rfc5633.txt",
  key="RFC 5633",
  abstract={This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="Internet Architecture Board, Engineering Steering Group",
  doi="10.17487/RFC5633",
  }

@misc{rfc5634,
  author="G. Fairhurst and A. Sathiaseelan",
  title="{Quick-Start for the Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 5634 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5634",
  pages="1--22",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5634.txt",
  key="RFC 5634",
  abstract={This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP).  DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams.  DCCP is intended for applications such as streaming media, Internet telephony, and online games.  In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID).  This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4.  Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period).  The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="ccid, congestion control identifier, ccid 2, ccid 3, ccid 4",
  doi="10.17487/RFC5634",
  }

@misc{rfc5635,
  author="W. Kumari and D. McPherson",
  title="{Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)}",
  howpublished="RFC 5635 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5635",
  pages="1--15",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5635.txt",
  key="RFC 5635",
  abstract={Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.  This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.  This memo provides information for the Internet community.},
  keywords="rtbh",
  doi="10.17487/RFC5635",
  }

@misc{rfc5636,
  author="S. Park and H. Park and Y. Won and J. Lee and S. Kent",
  title="{Traceable Anonymous Certificate}",
  howpublished="RFC 5636 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5636",
  pages="1--31",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5636.txt",
  key="RFC 5636",
  abstract={This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it.  The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272).  The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer).  The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs).  This memo defines an Experimental Protocol for the Internet community.},
  keywords="x.509 certificate, blind issuer, anonymity issuer, tacs, end entity, ee",
  doi="10.17487/RFC5636",
  }

@misc{rfc5637,
  author="G. Giaretta and I. Guardini and E. Demaria and J. Bournelle and R. Lopez",
  title="{Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6}",
  howpublished="RFC 5637 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5637",
  pages="1--11",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5637.txt",
  key="RFC 5637",
  abstract={In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP).  In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure.  Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping.  This document describes various scenarios where a AAA interface for Mobile IPv6 is required.  Additionally, it lists design goals and requirements for such an interface.  This memo provides information for the Internet community.},
  keywords="AAA, MIPv6, Mobile IP",
  doi="10.17487/RFC5637",
  }

@misc{rfc5638,
  author="H. Sinnreich and A. Johnston and E. Shim and K. Singh",
  title="{Simple SIP Usage Scenario for Applications in the Endpoints}",
  howpublished="RFC 5638 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5638",
  pages="1--19",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5638.txt",
  key="RFC 5638",
  abstract={For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints. This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11. References for NAT traversal and for security are also provided. This memo provides information for the Internet community.},
  keywords="session initiation protocol, rich internet application, ria",
  doi="10.17487/RFC5638",
  }

@misc{rfc5639,
  author="M. Lochter and J. Merkle",
  title="{Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation}",
  howpublished="RFC 5639 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5639",
  pages="1--27",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5639.txt",
  key="RFC 5639",
  abstract={This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications.  The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5639",
  }

@misc{rfc5640,
  author="C. Filsfils and P. Mohapatra and C. Pignataro",
  title="{Load-Balancing for Mesh Softwires}",
  howpublished="RFC 5640 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5640",
  pages="1--6",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5640.txt",
  key="RFC 5640",
  abstract={Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows.  It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network.  Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers.  Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion.  This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]},
  keywords="bgp encapsulation subsequent address family identifier, safi",
  doi="10.17487/RFC5640",
  }

@misc{rfc5641,
  author="N. McGill and C. Pignataro",
  title="{Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values}",
  howpublished="RFC 5641 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5641",
  pages="1--11",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5641.txt",
  key="RFC 5641",
  abstract={This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the ``Circuit Status'' Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs).  It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]},
  keywords="attachment circuits, acs, pseudowires, pw, active bit, new bit, circuit status avp",
  doi="10.17487/RFC5641",
  }

@misc{rfc5642,
  author="S. Venkata and S. Harwani and C. Pignataro and D. McPherson",
  title="{Dynamic Hostname Exchange Mechanism for OSPF}",
  howpublished="RFC 5642 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5642",
  pages="1--8",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5642.txt",
  key="RFC 5642",
  abstract={This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS.  This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]},
  keywords="open shortest path first, router information, ri, ospf dynamic hostname",
  doi="10.17487/RFC5642",
  }

@misc{rfc5643,
  author="D. Joyal and V. Manral",
  title="{Management Information Base for OSPFv3}",
  howpublished="RFC 5643 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5643",
  pages="1--95",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5643.txt",
  key="RFC 5643",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.  In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]},
  keywords="mib, ipv6, open shortest path first, routing protocol, OSPFV3-MIB",
  doi="10.17487/RFC5643",
  }

@misc{rfc5644,
  author="E. Stephan and L. Liang and A. Morton",
  title="{IP Performance Metrics (IPPM): Spatial and Multicast}",
  howpublished="RFC 5644 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5644",
  pages="1--57",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6248",
url="https://www.rfc-editor.org/rfc/rfc5644.txt",
  key="RFC 5644",
  abstract={The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points.  This memo defines two new categories of metrics that extend the coverage to multiple measurement points.  It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]},
  keywords="Multiple point measurement, relative performance, group performance statistic, per hop measurement, segment performance",
  doi="10.17487/RFC5644",
  }

@misc{rfc5645,
  author="D. Ewell",
  title="{Update to the Language Subtag Registry}",
  howpublished="RFC 5645 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5645",
  pages="1--13",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5645.txt",
  key="RFC 5645",
  abstract={This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages.  This memo provides information for the Internet community.},
  keywords="language tags, language tagging, ltru, registry",
  doi="10.17487/RFC5645",
  }

@misc{rfc5646,
  author="A. Phillips and M. Davis",
  title="{Tags for Identifying Languages}",
  howpublished="RFC 5646 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5646",
  pages="1--84",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5646.txt",
  key="RFC 5646",
  abstract={This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="language tags, private interchange",
  doi="10.17487/RFC5646",
  }

@misc{rfc5647,
  author="K. Igoe and J. Solinas",
  title="{AES Galois Counter Mode for the Secure Shell Transport Layer Protocol}",
  howpublished="RFC 5647 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5647",
  pages="1--10",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5647.txt",
  key="RFC 5647",
  abstract={Secure shell (SSH) is a secure remote-login protocol.  SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services.  The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol.  This memo provides information for the Internet community.},
  keywords="ssh, remote-login",
  doi="10.17487/RFC5647",
  }

@misc{rfc5648,
  author="R. Wakikawa and V. Devarapalli and G. Tsirtsis and T. Ernst and K. Nagami",
  title="{Multiple Care-of Addresses Registration}",
  howpublished="RFC 5648 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5648",
  pages="1--36",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6089",
url="https://www.rfc-editor.org/rfc/rfc5648.txt",
  key="RFC 5648",
  abstract={According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes.  However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses.  This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses.  The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5648",
  }

@misc{rfc5649,
  author="R. Housley and M. Dworkin",
  title="{Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm}",
  howpublished="RFC 5649 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5649",
  pages="1--13",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5649.txt",
  key="RFC 5649",
  abstract={This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394.  This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped.  This memo provides information for the Internet community.},
  doi="10.17487/RFC5649",
  }

@misc{rfc5650,
  author="M. Morgenstern and S. Baillie and U. Bonollo",
  title="{Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)}",
  howpublished="RFC 5650 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5650",
  pages="1--218",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5650.txt",
  key="RFC 5650",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it describes objects used for managing parameters of the ``Very High Speed Digital Subscriber Line 2 (VDSL2)'' interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]},
  keywords="mib, management information base, adsl, asymmetric digital subscriber line, VDSL2-LINE-TC-MIB, VDSL2-LINE-MIB",
  doi="10.17487/RFC5650",
  }

@misc{rfc5651,
  author="M. Luby and M. Watson and L. Vicisano",
  title="{Layered Coding Transport (LCT) Building Block}",
  howpublished="RFC 5651 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5651",
  pages="1--34",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5651.txt",
  key="RFC 5651",
  abstract={The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols.  LCT is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast.  LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.  This document obsoletes RFC 3451. [STANDARDS-TRACK]},
  keywords="FEC, reliable multicast",
  doi="10.17487/RFC5651",
  }

@misc{rfc5652,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5652 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5652",
  pages="1--56",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5652.txt",
  key="RFC 5652",
  abstract={This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]},
  keywords="digital signature, message content",
  doi="10.17487/RFC5652",
  }

@misc{rfc5653,
  author="M. Upadhyay and S. Malkani",
  title="{Generic Security Service API Version 2: Java Bindings Update}",
  howpublished="RFC 5653 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5653",
  pages="1--99",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5653.txt",
  key="RFC 5653",
  abstract={The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in ``Generic Security Service API Version 2 : Java Bindings'' (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The GSS-API is described at a language-independent conceptual level in ``Generic Security Service Application Program Interface Version 2, Update 1'' (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are ``The Simple Public-Key GSS-API Mechanism'' (RFC 2025) and ``The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2'' (RFC 4121). [STANDARDS-TRACK]},
  keywords="gssapi, application program interface, gss-api, GSI",
  doi="10.17487/RFC5653",
  }

@misc{rfc5654,
  author="B. Niven-Jenkins and D. Brungard and M. Betts and N. Sprecher and S. Ueno",
  title="{Requirements of an MPLS Transport Profile}",
  howpublished="RFC 5654 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5654",
  pages="1--31",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5654.txt",
  key="RFC 5654",
  abstract={This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T. The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]},
  keywords="MPLS-TP, ITU, ITU-T",
  doi="10.17487/RFC5654",
  }

@misc{rfc5655,
  author="B. Trammell and E. Boschi and L. Mark and T. Zseby and A. Wagner",
  title="{Specification of the IP Flow Information Export (IPFIX) File Format}",
  howpublished="RFC 5655 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5655",
  pages="1--64",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5655.txt",
  key="RFC 5655",
  abstract={This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol.  It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages.  This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]},
  keywords="flow file, flow storage, ipfix storage, netflow storage",
  doi="10.17487/RFC5655",
  }

@misc{rfc5656,
  author="D. Stebila and J. Green",
  title="{Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer}",
  howpublished="RFC 5656 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5656",
  pages="1--20",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5656.txt",
  key="RFC 5656",
  abstract={This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol.  In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]},
  keywords="Key Agreement, Cryptography",
  doi="10.17487/RFC5656",
  }

@misc{rfc5657,
  author="L. Dusseault and R. Sparks",
  title="{Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard}",
  howpublished="RFC 5657 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5657",
  pages="1--12",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5657.txt",
  key="RFC 5657",
  abstract={Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol.  Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers.  This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="rfc2026, 2026, guidance, interoperation, implementation, reports, advancement, draft standard",
  doi="10.17487/RFC5657",
  }

@misc{rfc5658,
  author="T. Froment and C. Lebel and B. Bonnaerens",
  title="{Addressing Record-Route Issues in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5658 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5658",
  pages="1--18",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5658.txt",
  key="RFC 5658",
  abstract={A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it.  This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy.  These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like ``comp=sigcomp''.  When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s).  It is not possible to make one header have the characteristics of both interfaces at the same time.  This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]},
  keywords="multi-homed, user agent, proxy, interoperability, double record-routing",
  doi="10.17487/RFC5658",
  }

@misc{rfc5659,
  author="M. Bocci and S. Bryant",
  title="{An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge}",
  howpublished="RFC 5659 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5659",
  pages="1--24",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5659.txt",
  key="RFC 5659",
  abstract={This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments.  Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN.  It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions.  This memo provides information for the Internet community.},
  keywords="psn, packet switched network",
  doi="10.17487/RFC5659",
  }

@misc{rfc5660,
  author="N. Williams",
  title="{IPsec Channels: Connection Latching}",
  howpublished="RFC 5660 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5660",
  pages="1--31",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5660.txt",
  key="RFC 5660",
  abstract={This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create ``channels'' by latching ``connections'' (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]},
  keywords="IPsec, connection latching, channel",
  doi="10.17487/RFC5660",
  }

@misc{rfc5661,
  author="S. Shepler and M. Eisler and D. Noveck",
  title="{Network File System (NFS) Version 4 Minor Version 1 Protocol}",
  howpublished="RFC 5661 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5661",
  pages="1--617",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5661.txt",
  key="RFC 5661",
  abstract={This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently.  Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS).  NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol.  Thus, this document neither updates nor obsoletes RFC 3530.  NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0.  Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]},
  keywords="Access Control List, ACL, Communications Sessions, Exactly Once Semantics, File Access Protocol, Global Namespace, Network Authentication, Network File Access, Network File System, Network Security, NFS, Parallel Storage, pNFS, Storage Cluster",
  doi="10.17487/RFC5661",
  }

@misc{rfc5662,
  author="S. Shepler and M. Eisler and D. Noveck",
  title="{Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description}",
  howpublished="RFC 5662 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5662",
  pages="1--73",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5662.txt",
  key="RFC 5662",
  abstract={This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]},
  keywords="xdr, nfsv4",
  doi="10.17487/RFC5662",
  }

@misc{rfc5663,
  author="D. Black and S. Fridella and J. Glasgow",
  title="{Parallel NFS (pNFS) Block/Volume Layout}",
  howpublished="RFC 5663 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5663",
  pages="1--28",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6688",
url="https://www.rfc-editor.org/rfc/rfc5663.txt",
  key="RFC 5663",
  abstract={Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server.  This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used.  The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]},
  keywords="nfsv4, network file sharing version 4",
  doi="10.17487/RFC5663",
  }

@misc{rfc5664,
  author="B. Halevy and B. Welch and J. Zelenka",
  title="{Object-Based Parallel NFS (pNFS) Operations}",
  howpublished="RFC 5664 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5664",
  pages="1--35",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5664.txt",
  key="RFC 5664",
  abstract={Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server.  This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a.  the Layout Type.  The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification.  This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS-TRACK]},
  keywords="OSD, storage device",
  doi="10.17487/RFC5664",
  }

@misc{rfc5665,
  author="M. Eisler",
  title="{IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats}",
  howpublished="RFC 5665 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5665",
  pages="1--14",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5665.txt",
  key="RFC 5665",
  abstract={This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs).  This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]},
  keywords="rpcbind, portmap, transport independent remote procedure call, TI-RPC, transport identifier, protocol identifier",
  doi="10.17487/RFC5665",
  }

@misc{rfc5666,
  author="T. Talpey and B. Callaghan",
  title="{Remote Direct Memory Access Transport for Remote Procedure Call}",
  howpublished="RFC 5666 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5666",
  pages="1--34",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5666.txt",
  key="RFC 5666",
  abstract={This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC).  The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]},
  keywords="Network File System, NFS, ONC RPC, RDMA, RDDP, iWARP, InfiniBand",
  doi="10.17487/RFC5666",
  }

@misc{rfc5667,
  author="T. Talpey and B. Callaghan",
  title="{Network File System (NFS) Direct Data Placement}",
  howpublished="RFC 5667 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5667",
  pages="1--10",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5667.txt",
  key="RFC 5667",
  abstract={This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol.  It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]},
  keywords="Network File System, NFS, ONC RPC, RDMA, RDDP, iWARP, InfiniBand",
  doi="10.17487/RFC5667",
  }

@misc{rfc5668,
  author="Y. Rekhter and S. Sangli and D. Tappan",
  title="{4-Octet AS Specific BGP Extended Community}",
  howpublished="RFC 5668 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5668",
  pages="1--5",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5668.txt",
  key="RFC 5668",
  abstract={This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]},
  keywords="border gateway protocol, autonomous system",
  doi="10.17487/RFC5668",
  }

@misc{rfc5669,
  author="S. Yoon and J. Kim and H. Park and H. Jeong and Y. Won",
  title="{The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)}",
  howpublished="RFC 5669 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5669",
  pages="1--13",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5669.txt",
  key="RFC 5669",
  abstract={This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5669",
  }

@misc{rfc5670,
  author="P. Eardley",
  title="{Metering and Marking Behaviour of PCN-Nodes}",
  howpublished="RFC 5670 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5670",
  pages="1--20",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5670.txt",
  key="RFC 5670",
  abstract={The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion.  This document defines the two metering and marking behaviours of PCN-nodes.  Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate (``PCN-threshold-rate'').  Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate (``PCN-excess-rate'').  The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]},
  keywords="pre-congestion notification, threshold metering, threshold marking, pcn-threshold-rate, pcn-excess-rate",
  doi="10.17487/RFC5670",
  }

@misc{rfc5671,
  author="S. Yasukawa and A. Farrel",
  title="{Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)}",
  howpublished="RFC 5671 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5671",
  pages="1--15",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5671.txt",
  key="RFC 5671",
  abstract={The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, generalized mpls",
  doi="10.17487/RFC5671",
  }

@misc{rfc5672,
  author="D. Crocker",
  title="{RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update}",
  howpublished="RFC 5672 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5672",
  pages="1--14",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6376",
url="https://www.rfc-editor.org/rfc/rfc5672.txt",
  key="RFC 5672",
  abstract={This document updates RFC 4871, ``DomainKeys Identified Mail (DKIM) Signatures''.  Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.  The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]},
  keywords="DKIM, email, authentication, security, spam, abuse, errata, trust, Signing Domain Identifier, SDID, AUID, Agent or User Identifier",
  doi="10.17487/RFC5672",
  }

@misc{rfc5673,
  author="K. Pister and P. Thubert and S. Dwars and T. Phinney",
  title="{Industrial Routing Requirements in Low-Power and Lossy Networks}",
  howpublished="RFC 5673 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5673",
  pages="1--27",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5673.txt",
  key="RFC 5673",
  abstract={The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations.  The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices.  This memo provides information for the Internet community.},
  keywords="lln",
  doi="10.17487/RFC5673",
  }

@misc{rfc5674,
  author="S. Chisholm and R. Gerhards",
  title="{Alarms in Syslog}",
  howpublished="RFC 5674 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5674",
  pages="1--7",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5674.txt",
  key="RFC 5674",
  abstract={This document describes how to send alarm information in syslog.  It includes the mapping of ITU perceived severities onto syslog message fields.  It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]},
  keywords="SYSLOG, alarm",
  doi="10.17487/RFC5674",
  }

@misc{rfc5675,
  author="V. Marinov and J. Schoenwaelder",
  title="{Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages}",
  howpublished="RFC 5675 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5675",
  pages="1--15",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5675.txt",
  key="RFC 5675",
  abstract={This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Notifications, Syslog",
  doi="10.17487/RFC5675",
  }

@misc{rfc5676,
  author="J. Schoenwaelder and A. Clemm and A. Karmakar",
  title="{Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications}",
  howpublished="RFC 5676 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5676",
  pages="1--22",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5676.txt",
  key="RFC 5676",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Notifications, Syslog",
  doi="10.17487/RFC5676",
  }

@misc{rfc5677,
  author="T. Melia and G. Bajko and S. Das and N. Golmie and JC. Zuniga",
  title="{IEEE 802.21 Mobility Services Framework Design (MSFD)}",
  howpublished="RFC 5677 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5677",
  pages="1--25",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5677.txt",
  key="RFC 5677",
  abstract={This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages.  The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages.  This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server.  Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]},
  keywords="media independent handover, mih, mobility services, mos",
  doi="10.17487/RFC5677",
  }

@misc{rfc5678,
  author="G. Bajko and S. Das",
  title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery}",
  howpublished="RFC 5678 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5678",
  pages="1--14",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5678.txt",
  key="RFC 5678",
  abstract={This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677).  These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection).  The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]},
  keywords="handover preparation handover decision, media independent handover services",
  doi="10.17487/RFC5678",
  }

@misc{rfc5679,
  author="G. Bajko",
  title="{Locating IEEE 802.21 Mobility Services Using DNS}",
  howpublished="RFC 5679 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5679",
  pages="1--9",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5679.txt",
  key="RFC 5679",
  abstract={This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services.  Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection).  The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]},
  keywords="domain name server, handover preparation, handover decision, media independent handover services",
  doi="10.17487/RFC5679",
  }

@misc{rfc5680,
  author="S. Dawkins",
  title="{The Nominating Committee Process: Open Disclosure of Willing Nominees}",
  howpublished="RFC 5680 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5680",
  pages="1--7",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7437",
url="https://www.rfc-editor.org/rfc/rfc5680.txt",
  key="RFC 5680",
  abstract={This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
  keywords="",
  doi="10.17487/RFC5680",
  }

@misc{rfc5681,
  author="M. Allman and V. Paxson and E. Blanton",
  title="{TCP Congestion Control}",
  howpublished="RFC 5681 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5681",
  pages="1--18",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5681.txt",
  key="RFC 5681",
  abstract={This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.  This document obsoletes RFC 2581. [STANDARDS-TRACK]},
  keywords="slow start, congestion avoidance, fast retransmit, fast recovery",
  doi="10.17487/RFC5681",
  }

@misc{rfc5682,
  author="P. Sarolahti and M. Kojo and K. Yamamoto and M. Hata",
  title="{Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP}",
  howpublished="RFC 5682 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5682",
  pages="1--19",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5682.txt",
  key="RFC 5682",
  abstract={The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138. Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]},
  keywords="SACK, transmission control protocol, loss recovery",
  doi="10.17487/RFC5682",
  }

@misc{rfc5683,
  author="A. Brusilovsky and I. Faynberg and Z. Zeltsan and S. Patel",
  title="{Password-Authenticated Key (PAK) Diffie-Hellman Exchange}",
  howpublished="RFC 5683 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5683",
  pages="1--10",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5683.txt",
  key="RFC 5683",
  abstract={This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5683",
  }

@misc{rfc5684,
  author="P. Srisuresh and B. Ford",
  title="{Unintended Consequences of NAT Deployments with Overlapping Address Space}",
  howpublished="RFC 5684 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5684",
  pages="1--26",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5684.txt",
  key="RFC 5684",
  abstract={This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices.  First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.  Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks.  This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="network address translator",
  doi="10.17487/RFC5684",
  }

@misc{rfc5685,
  author="V. Devarapalli and K. Weniger",
  title="{Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 5685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5685",
  pages="1--15",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5685.txt",
  key="RFC 5685",
  abstract={The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway.  This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway.  The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]},
  keywords="IKEv2 Redirect, REDIRECT, REDIRECTED\_FROM, anycast redirect, home agent redirect, VPN gateway direct",
  doi="10.17487/RFC5685",
  }

@misc{rfc5686,
  author="Y. Hiwasaki and H. Ohmuro",
  title="{RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec}",
  howpublished="RFC 5686 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5686",
  pages="1--21",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5686.txt",
  key="RFC 5686",
  abstract={This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711.  The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]},
  keywords="RTP Payload type, MIME, UEMCLIP, PCMU, Speech Coding",
  doi="10.17487/RFC5686",
  }

@misc{rfc5687,
  author="H. Tschofenig and H. Schulzrinne",
  title="{GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements}",
  howpublished="RFC 5687 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5687",
  pages="1--21",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5687.txt",
  key="RFC 5687",
  abstract={This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP).  This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network.  The obtained location information can then be used for a variety of different protocols and purposes.  For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Location Information, Location Information Server, Location by Value, Location by Reference",
  doi="10.17487/RFC5687",
  }

@misc{rfc5688,
  author="J. Rosenberg",
  title="{A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes}",
  howpublished="RFC 5688 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5688",
  pages="1--7",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5688.txt",
  key="RFC 5688",
  abstract={The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities.  Similarly, a specification exists to allow a UA to indicate its capabilities in a registration.  Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types.  The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability.  This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]},
  keywords="SIP, IMS",
  doi="10.17487/RFC5688",
  }

@misc{rfc5689,
  author="C. Daboo",
  title="{Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 5689 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5689",
  pages="1--12",
  year=2009,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5689.txt",
  key="RFC 5689",
  abstract={This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]},
  keywords="webdav, HTTP",
  doi="10.17487/RFC5689",
  }

@misc{rfc5690,
  author="S. Floyd and A. Arcia and D. Ros and J. Iyengar",
  title="{Adding Acknowledgement Congestion Control to TCP}",
  howpublished="RFC 5690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5690",
  pages="1--33",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5690.txt",
  key="RFC 5690",
  abstract={This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP.  The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver.  The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender.  The TCP data receiver sends roughly one ACK packet for every R data packets received.  This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2.  This acknowledgement congestion control mechanism is being specified for further evaluation by the network community.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ackcc",
  doi="10.17487/RFC5690",
  }

@misc{rfc5691,
  author="F. de Bont and S. Doehla and M. Schmidt and R. Sperschneider",
  title="{RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio}",
  howpublished="RFC 5691 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5691",
  pages="1--12",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5691.txt",
  key="RFC 5691",
  abstract={This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio.  Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream.  In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]},
  keywords="MPEG Surround, RFC 3640, RTP, MPEG-4, AAC",
  doi="10.17487/RFC5691",
  }

@misc{rfc5692,
  author="H. Jeon and S. Jeong and M. Riegel",
  title="{Transmission of IP over Ethernet over IEEE 802.16 Networks}",
  howpublished="RFC 5692 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5692",
  pages="1--21",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5692.txt",
  key="RFC 5692",
  abstract={This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology.  The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations.  Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]},
  keywords="Bridge, WiMAX, Ethernet-CS, Cellular",
  doi="10.17487/RFC5692",
  }

@misc{rfc5693,
  author="J. Seedorf and E. Burger",
  title="{Application-Layer Traffic Optimization (ALTO) Problem Statement}",
  howpublished="RFC 5693 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5693",
  pages="1--14",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5693.txt",
  key="RFC 5693",
  abstract={Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices. This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.},
  keywords="peer-to-peer, p2p",
  doi="10.17487/RFC5693",
  }

@misc{rfc5694,
  author="G. Camarillo and IAB",
  title="{Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability}",
  howpublished="RFC 5694 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5694",
  pages="1--26",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5694.txt",
  key="RFC 5694",
  abstract={In this document, we provide a survey of P2P (Peer-to-Peer) systems.  The survey includes a definition and several taxonomies of P2P systems.  This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet.  Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application.  This memo provides information for the Internet community.},
  keywords="P2P, decentralized, architecture",
  doi="10.17487/RFC5694",
  }

@misc{rfc5695,
  author="A. Akhter and R. Asati and C. Pignataro",
  title="{MPLS Forwarding Benchmarking Methodology for IP Flows}",
  howpublished="RFC 5695 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5695",
  pages="1--27",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5695.txt",
  key="RFC 5695",
  abstract={This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows.  It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts.  This document seeks to extend these efforts to the MPLS paradigm.  This memo provides information for the Internet community.},
  keywords="multiprotocol label switching, mpmls forwarding devices",
  doi="10.17487/RFC5695",
  }

@misc{rfc5696,
  author="T. Moncaster and B. Briscoe and M. Menth",
  title="{Baseline Encoding and Transport of Pre-Congestion Information}",
  howpublished="RFC 5696 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5696",
  pages="1--15",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6660",
url="https://www.rfc-editor.org/rfc/rfc5696.txt",
  key="RFC 5696",
  abstract={The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.  It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain.  These marks can then be evaluated to determine how close the domain is to being congested.  This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains.  The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked.  Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]},
  keywords="Quality of Service, QoS, Differentiated Services, Admission Control, Codepoint, Protocol",
  doi="10.17487/RFC5696",
  }

@misc{rfc5697,
  author="S. Farrell",
  title="{Other Certificates Extension}",
  howpublished="RFC 5697 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5697",
  pages="1--8",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5697.txt",
  key="RFC 5697",
  abstract={Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information.  This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="template",
  doi="10.17487/RFC5697",
  }

@misc{rfc5698,
  author="T. Kunz and S. Okunick and U. Pordesch",
  title="{Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)}",
  howpublished="RFC 5698 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5698",
  pages="1--40",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5698.txt",
  key="RFC 5698",
  abstract={Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability.  When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered.  This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]},
  keywords="long term archive, security, policy, hash algorithm, public key algorithm",
  doi="10.17487/RFC5698",
  }

@misc{rfc5701,
  author="Y. Rekhter",
  title="{IPv6 Address Specific BGP Extended Community Attribute}",
  howpublished="RFC 5701 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5701",
  pages="1--5",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7153, 7606",
url="https://www.rfc-editor.org/rfc/rfc5701.txt",
  key="RFC 5701",
  abstract={Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community.  The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment.  This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem.  The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]},
  keywords="border gateway protocol",
  doi="10.17487/RFC5701",
  }

@misc{rfc5702,
  author="J. Jansen",
  title="{Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC}",
  howpublished="RFC 5702 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5702",
  pages="1--10",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc5702.txt",
  key="RFC 5702",
  abstract={This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]},
  keywords="DNSSEC, RSA, SHA-256, SHA-512",
  doi="10.17487/RFC5702",
  }

@misc{rfc5703,
  author="T. Hansen and C. Daboo",
  title="{Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure}",
  howpublished="RFC 5703 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5703",
  pages="1--18",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5703.txt",
  key="RFC 5703",
  abstract={This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]},
  keywords="Email, Electronic Mail, Internet Mail, Message Filtering",
  doi="10.17487/RFC5703",
  }

@misc{rfc5704,
  author="S. Bryant and M. Morrow and IAB",
  title="{Uncoordinated Protocol Development Considered Harmful}",
  howpublished="RFC 5704 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5704",
  pages="1--15",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5704.txt",
  key="RFC 5704",
  abstract={This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol. This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the ``Joint working team on MPLS-TP''. In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs. Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.},
  keywords="ITU-T, MPLS-TP, T-MPLS, Joint working team, JWT",
  doi="10.17487/RFC5704",
  }

@misc{rfc5705,
  author="E. Rescorla",
  title="{Keying Material Exporters for Transport Layer Security (TLS)}",
  howpublished="RFC 5705 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5705",
  pages="1--7",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5705.txt",
  key="RFC 5705",
  abstract={A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that. [STANDARDS-TRACK]},
  keywords="key establishment",
  doi="10.17487/RFC5705",
  }

@misc{rfc5706,
  author="D. Harrington",
  title="{Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions}",
  howpublished="RFC 5706 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5706",
  pages="1--35",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5706.txt",
  key="RFC 5706",
  abstract={New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols.  Retrofitting operations and management is sub-optimal.  The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.  This memo provides information for the Internet community.},
  keywords="management, operations",
  doi="10.17487/RFC5706",
  }

@misc{rfc5707,
  author="A. Saleem and Y. Xin and G. Sharratt",
  title="{Media Server Markup Language (MSML)}",
  howpublished="RFC 5707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5707",
  pages="1--184",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5707.txt",
  key="RFC 5707",
  abstract={The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers.  The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry.  Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users.  MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams.  As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences.  Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML.  MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5707",
  }

@misc{rfc5708,
  author="A. Keromytis",
  title="{X.509 Key and Signature Encoding for the KeyNote Trust Management System}",
  howpublished="RFC 5708 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5708",
  pages="1--6",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5708.txt",
  key="RFC 5708",
  abstract={This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5708",
  }

@misc{rfc5709,
  author="M. Bhatia and V. Manral and M. Fanto and R. White and M. Barnes and T. Li and R. Atkinson",
  title="{OSPFv2 HMAC-SHA Cryptographic Authentication}",
  howpublished="RFC 5709 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5709",
  pages="1--14",
  year=2009,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7474",
url="https://www.rfc-editor.org/rfc/rfc5709.txt",
  key="RFC 5709",
  abstract={This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism.  This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]},
  keywords="open shortest path first, nist, secure  hash standard, hashed message authentication code",
  doi="10.17487/RFC5709",
  }

@misc{rfc5710,
  author="L. Berger and D. Papadimitriou and JP. Vasseur",
  title="{PathErr Message Triggered MPLS and GMPLS LSP Reroutes}",
  howpublished="RFC 5710 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5710",
  pages="1--12",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5710.txt",
  key="RFC 5710",
  abstract={This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources.  Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown.  This document describes the usage of existing Standards Track mechanisms to support LSP rerouting.  In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed.  While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]},
  keywords="resource reservation protocol, rsvp, multiprotocol label switching, generalized mpls, rsvp-te",
  doi="10.17487/RFC5710",
  }

@misc{rfc5711,
  author="JP. Vasseur and G. Swallow and I. Minei",
  title="{Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages}",
  howpublished="RFC 5711 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5711",
  pages="1--7",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5711.txt",
  key="RFC 5711",
  abstract={The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]},
  keywords="rsvp-te",
  doi="10.17487/RFC5711",
  }

@misc{rfc5712,
  author="M. Meyer and JP. Vasseur",
  title="{MPLS Traffic Engineering Soft Preemption}",
  howpublished="RFC 5712 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5712",
  pages="1--13",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5712.txt",
  key="RFC 5712",
  abstract={This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs).  Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption.  The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP.  For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted.  For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]},
  keywords="multiprotocol label switching, mpls-te, te lsp",
  doi="10.17487/RFC5712",
  }

@misc{rfc5713,
  author="H. Moustafa and H. Tschofenig and S. De Cnodder",
  title="{Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)}",
  howpublished="RFC 5713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5713",
  pages="1--18",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5713.txt",
  key="RFC 5713",
  abstract={The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS. This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ANCP security, ANCP threats, ANCP attacks",
  doi="10.17487/RFC5713",
  }

@misc{rfc5714,
  author="M. Shand and S. Bryant",
  title="{IP Fast Reroute Framework}",
  howpublished="RFC 5714 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5714",
  pages="1--15",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5714.txt",
  key="RFC 5714",
  abstract={This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths.  Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IP Fast Reroute, MPLS Fast Reroute, Routing Convergence, Network  Topology, loop-free-convergence",
  doi="10.17487/RFC5714",
  }

@misc{rfc5715,
  author="M. Shand and S. Bryant",
  title="{A Framework for Loop-Free Convergence}",
  howpublished="RFC 5715 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5715",
  pages="1--22",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5715.txt",
  key="RFC 5715",
  abstract={A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IP Fast Reroute, MPLS Fast Reroute, Routing Convergence, Network Topology, PLSN, not-via, Incremental Cost, Packet Marking, ordered fib, ofib",
  doi="10.17487/RFC5715",
  }

@misc{rfc5716,
  author="J. Lentini and C. Everhart and D. Ellard and R. Tewari and M. Naik",
  title="{Requirements for Federated File Systems}",
  howpublished="RFC 5716 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5716",
  pages="1--26",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5716.txt",
  key="RFC 5716",
  abstract={This document describes and lists the functional requirements of a federated file system and defines related terms.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Federated File Systems, Federated FA, FedFS, Fed-FS, Federation",
  doi="10.17487/RFC5716",
  }

@misc{rfc5717,
  author="B. Lengyel and M. Bjorklund",
  title="{Partial Lock Remote Procedure Call (RPC) for NETCONF}",
  howpublished="RFC 5717 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5717",
  pages="1--23",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5717.txt",
  key="RFC 5717",
  abstract={The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores.  In some situations, a way to lock only parts of a configuration datastore is required.  This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]},
  keywords="YANG, Network Management",
  doi="10.17487/RFC5717",
  }

@misc{rfc5718,
  author="D. Beller and A. Farrel",
  title="{An In-Band Data Communication Network For the MPLS Transport Profile}",
  howpublished="RFC 5718 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5718",
  pages="1--8",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5718.txt",
  key="RFC 5718",
  abstract={The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]},
  keywords="MPLS-TP, DCN, SCN, MCN, G-Ach, GAL",
  doi="10.17487/RFC5718",
  }

@misc{rfc5719,
  author="D. Romascanu and H. Tschofenig",
  title="{Updated IANA Considerations for Diameter Command Code Allocations}",
  howpublished="RFC 5719 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5719",
  pages="1--5",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6733",
url="https://www.rfc-editor.org/rfc/rfc5719.txt",
  key="RFC 5719",
  abstract={The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]},
  keywords="diameter application, diameter commands",
  doi="10.17487/RFC5719",
  }

@misc{rfc5720,
  author="F. Templin",
  title="{Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)}",
  howpublished="RFC 5720 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5720",
  pages="1--26",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5720.txt",
  key="RFC 5720",
  abstract={RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion.  The term ``enterprise network'' within this context extends to a wide variety of use cases and deployment scenarios, where an ``enterprise'' can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself.  Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security.  These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches.  The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="enterprise network",
  doi="10.17487/RFC5720",
  }

@misc{rfc5721,
  author="R. Gellens and C. Newman",
  title="{POP3 Support for UTF-8}",
  howpublished="RFC 5721 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5721",
  pages="1--13",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6856",
url="https://www.rfc-editor.org/rfc/rfc5721.txt",
  key="RFC 5721",
  abstract={This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings.  This document defines an Experimental Protocol for the Internet community.},
  keywords="POP, UTF8, mail, email, internationalization, charset",
  doi="10.17487/RFC5721",
  }

@misc{rfc5722,
  author="S. Krishnan",
  title="{Handling of Overlapping IPv6 Fragments}",
  howpublished="RFC 5722 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5722",
  pages="1--6",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6946",
url="https://www.rfc-editor.org/rfc/rfc5722.txt",
  key="RFC 5722",
  abstract={The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap.  This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]},
  keywords="fragmentation, overlapping fragments",
  doi="10.17487/RFC5722",
  }

@misc{rfc5723,
  author="Y. Sheffer and H. Tschofenig",
  title="{Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption}",
  howpublished="RFC 5723 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5723",
  pages="1--26",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5723.txt",
  key="RFC 5723",
  abstract={The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]},
  keywords="IKE, Internet Key Exchange, session resumption, failover, high availability, cryptographic ticket, cryptographic token, stateful resumption, stateless resumption",
  doi="10.17487/RFC5723",
  }

@misc{rfc5724,
  author="E. Wilde and A. Vaha-Sipila",
  title="{URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)}",
  howpublished="RFC 5724 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5724",
  pages="1--18",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5724.txt",
  key="RFC 5724",
  abstract={This memo specifies the Uniform Resource Identifier (URI) scheme ``sms'' for specifying one or more recipients for an SMS message.  SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]},
  keywords="GSM, SMS, URI scheme",
  doi="10.17487/RFC5724",
  }

@misc{rfc5725,
  author="A. Begen and D. Hsu and M. Lague",
  title="{Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)}",
  howpublished="RFC 5725 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5725",
  pages="1--9",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5725.txt",
  key="RFC 5725",
  abstract={This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs).  One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block.  This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report.  The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied.  By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion.  This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]},
  keywords="Loss repair, retransmission, FEC",
  doi="10.17487/RFC5725",
  }

@misc{rfc5726,
  author="Y. Qiu and F. Zhao and R. Koodli",
  title="{Mobile IPv6 Location Privacy Solutions}",
  howpublished="RFC 5726 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5726",
  pages="1--48",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5726.txt",
  key="RFC 5726",
  abstract={Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet.  However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets.  In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This document defines an Experimental Protocol for the Internet community.},
  keywords="mobopts",
  doi="10.17487/RFC5726",
  }

@misc{rfc5727,
  author="J. Peterson and C. Jennings and R. Sparks",
  title="{Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area}",
  howpublished="RFC 5727 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5727",
  pages="1--14",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7957",
url="https://www.rfc-editor.org/rfc/rfc5727.txt",
  key="RFC 5727",
  abstract={This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area.  As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP.  This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space.  This document obsoletes RFC 3427.  This memo documents an Internet Best Current Practice.},
  keywords="RAI, sipping",
  doi="10.17487/RFC5727",
  }

@misc{rfc5728,
  author="S. Combes and P. Amundsen and M. Lambert and H-P. Lexow",
  title="{The SatLabs Group DVB-RCS MIB}",
  howpublished="RFC 5728 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5728",
  pages="1--95",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5728.txt",
  key="RFC 5728",
  abstract={This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group.  It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="management information base, digital video broadcasting return channel, DVB-RCS-MIB",
  doi="10.17487/RFC5728",
  }

@misc{rfc5729,
  author="J. Korhonen and M. Jones and L. Morand and T. Tsou",
  title="{Clarifications on the Routing of Diameter Requests Based on the Username and the Realm}",
  howpublished="RFC 5729 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5729",
  pages="1--11",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5729.txt",
  key="RFC 5729",
  abstract={This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms.  These multi-realm, or ``Decorated'', Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]},
  keywords="nai, network access identifier, decorated, multi-realm",
  doi="10.17487/RFC5729",
  }

@misc{rfc5730,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 5730 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5730",
  pages="1--67",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5730.txt",
  key="RFC 5730",
  abstract={This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document includes a protocol specification, an object mapping template, and an XML media type registration.  This document obsoletes RFC 4930. [STANDARDS-TRACK]},
  keywords="shared framework mapping",
  doi="10.17487/RFC5730",
  }

@misc{rfc5731,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}",
  howpublished="RFC 5731 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5731",
  pages="1--44",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5731.txt",
  key="RFC 5731",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.  This document obsoletes RFC 4931. [STANDARDS-TRACK]},
  keywords="EPP, Extensible Provisioning Protocol, XML, domain, domain name",
  doi="10.17487/RFC5731",
  }

@misc{rfc5732,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Host Mapping}",
  howpublished="RFC 5732 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5732",
  pages="1--29",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5732.txt",
  key="RFC 5732",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository.  Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.  This document obsoletes RFC 4932. [STANDARDS-TRACK]},
  keywords="EPP, Extensible Provisioning Protocol, XML, host",
  doi="10.17487/RFC5732",
  }

@misc{rfc5733,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Contact Mapping}",
  howpublished="RFC 5733 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5733",
  pages="1--41",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5733.txt",
  key="RFC 5733",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository.  Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.  This document obsoletes RFC 4933. [STANDARDS-TRACK]},
  keywords="EPP, Extensible Provisioning Protocol, XML, contact, registrant",
  doi="10.17487/RFC5733",
  }

@misc{rfc5734,
  author="S. Hollenbeck",
  title="{Extensible Provisioning Protocol (EPP) Transport over TCP}",
  howpublished="RFC 5734 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5734",
  pages="1--13",
  year=2009,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5734.txt",
  key="RFC 5734",
  abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.  This document obsoletes RFC 4934. [STANDARDS-TRACK]},
  keywords="EPP, Extensible Provisioning Protocol, XML, TCP, TLS",
  doi="10.17487/RFC5734",
  }

@misc{rfc5735,
  author="M. Cotton and L. Vegoda",
  title="{Special Use IPv4 Addresses}",
  howpublished="RFC 5735 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5735",
  pages="1--10",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6890, updated by RFC 6598",
url="https://www.rfc-editor.org/rfc/rfc5735.txt",
  key="RFC 5735",
  abstract={This document obsoletes RFC 3330.  It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA).  It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries.  It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers.  This memo documents an Internet Best Current Practice.},
  keywords="internet protocol, space assignments",
  doi="10.17487/RFC5735",
  }

@misc{rfc5736,
  author="G. Huston and M. Cotton and L. Vegoda",
  title="{IANA IPv4 Special Purpose Address Registry}",
  howpublished="RFC 5736 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5736",
  pages="1--6",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6890",
url="https://www.rfc-editor.org/rfc/rfc5736.txt",
  key="RFC 5736",
  abstract={This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5736",
  }

@misc{rfc5737,
  author="J. Arkko and M. Cotton and L. Vegoda",
  title="{IPv4 Address Blocks Reserved for Documentation}",
  howpublished="RFC 5737 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5737",
  pages="1--4",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5737.txt",
  key="RFC 5737",
  abstract={Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents.  This document describes the use of these blocks.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="example addresses, IPv4",
  doi="10.17487/RFC5737",
  }

@misc{rfc5738,
  author="P. Resnick and C. Newman",
  title="{IMAP Support for UTF-8}",
  howpublished="RFC 5738 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5738",
  pages="1--15",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6855",
url="https://www.rfc-editor.org/rfc/rfc5738.txt",
  key="RFC 5738",
  abstract={This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.  This document defines an Experimental Protocol for the Internet community.},
  keywords="internet message access protocol, imap4rev1",
  doi="10.17487/RFC5738",
  }

@misc{rfc5739,
  author="P. Eronen and J. Laganier and C. Madson",
  title="{IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 5739 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5739",
  pages="1--32",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5739.txt",
  key="RFC 5739",
  abstract={When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads.  The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6.  This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway ``virtual link''.  This document defines an Experimental Protocol for the Internet community.},
  keywords="remote vpn access, vpn gateway, virtual link",
  doi="10.17487/RFC5739",
  }

@misc{rfc5740,
  author="B. Adamson and C. Bormann and M. Handley and J. Macker",
  title="{NACK-Oriented Reliable Multicast (NORM) Transport Protocol}",
  howpublished="RFC 5740 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5740",
  pages="1--96",
  year=2009,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5740.txt",
  key="RFC 5740",
  abstract={This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.  This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services.  NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers.  A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP).  It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers.  The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways.  The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design.  This document obsoletes RFC 3940. [STANDARDS-TRACK]},
  keywords="multicast, reliable multicast, transport, negative-acknowledgment, forward error correction, packet erasure coding, group communication",
  doi="10.17487/RFC5740",
  }

@misc{rfc5741,
  author="L. Daigle and O. Kolkman and IAB",
  title="{RFC Streams, Headers, and Boilerplates}",
  howpublished="RFC 5741 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5741",
  pages="1--16",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7841",
url="https://www.rfc-editor.org/rfc/rfc5741.txt",
  key="RFC 5741",
  abstract={RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.  This document describes them and introduces some updates to reflect current usage and requirements of RFC publication.  In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5741",
  }

@misc{rfc5742,
  author="H. Alvestrand and R. Housley",
  title="{IESG Procedures for Handling of Independent and IRTF Stream Submissions}",
  howpublished="RFC 5742 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5742",
  pages="1--9",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5742.txt",
  key="RFC 5742",
  abstract={This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC5742",
  }

@misc{rfc5743,
  author="A. Falk",
  title="{Definition of an Internet Research Task Force (IRTF) Document Stream}",
  howpublished="RFC 5743 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5743",
  pages="1--9",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5743.txt",
  key="RFC 5743",
  abstract={This memo defines the publication stream for RFCs from the Internet Research Task Force.  Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="irtf stream",
  doi="10.17487/RFC5743",
  }

@misc{rfc5744,
  author="R. Braden and J. Halpern",
  title="{Procedures for Rights Handling in the RFC Independent Submission Stream}",
  howpublished="RFC 5744 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5744",
  pages="1--6",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5744.txt",
  key="RFC 5744",
  abstract={This document specifies the procedures by which authors of RFC Independent Submission documents grant the community ``incoming'' rights for copying and using the text.  It also specifies the ``outgoing'' rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet community.},
  keywords="incoming rights, outgoing rights, ietf trust",
  doi="10.17487/RFC5744",
  }

@misc{rfc5745,
  author="A. Malis and IAB",
  title="{Procedures for Rights Handling in the RFC IAB Stream}",
  howpublished="RFC 5745 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5745",
  pages="1--6",
  year=2009,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5745.txt",
  key="RFC 5745",
  abstract={This document specifies the procedures by which authors of RFC IAB stream documents grant the community ``incoming'' rights for copying and using the text.  It also specifies the ``outgoing'' rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet community.},
  keywords="incoming rights, outgoing rights, ietf trust",
  doi="10.17487/RFC5745",
  }

@misc{rfc5746,
  author="E. Rescorla and M. Ray and S. Dispensa and N. Oskov",
  title="{Transport Layer Security (TLS) Renegotiation Indication Extension}",
  howpublished="RFC 5746 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5746",
  pages="1--15",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5746.txt",
  key="RFC 5746",
  abstract={Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client.  The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.  This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]},
  keywords="ssl, secure socket layer",
  doi="10.17487/RFC5746",
  }

@misc{rfc5747,
  author="J. Wu and Y. Cui and X. Li and M. Xu and C. Metz",
  title="{4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions}",
  howpublished="RFC 5747 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5747",
  pages="1--15",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5747.txt",
  key="RFC 5747",
  abstract={The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired.  This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP.  It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels.  The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China.  This document defines an Experimental Protocol for the Internet community.},
  keywords="IPv4/IPv6, coexistence, CNGI, CERNET2, Softwire mesh",
  doi="10.17487/RFC5747",
  }

@misc{rfc5748,
  author="S. Yoon and J. Jeong and H. Kim and H. Jeong and Y. Won",
  title="{IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 5748 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5748",
  pages="1--5",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5748.txt",
  key="RFC 5748",
  abstract={This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5748",
  }

@misc{rfc5749,
  author="K. Hoeper and M. Nakhjiri and Y. Ohba",
  title="{Distribution of EAP-Based Keys for Handover and Re-Authentication}",
  howpublished="RFC 5749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5749",
  pages="1--12",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5749.txt",
  key="RFC 5749",
  abstract={This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer.  The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer.  This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements.  The described protocol template does not specify message formats, data encoding, or other implementation details.  It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]},
  keywords="security, authentication, mobility, EAP, key management, key distribution",
  doi="10.17487/RFC5749",
  }

@misc{rfc5750,
  author="B. Ramsdell and S. Turner",
  title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling}",
  howpublished="RFC 5750 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5750",
  pages="1--21",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5750.txt",
  key="RFC 5750",
  abstract={This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.  S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.  S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile.  S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280.  This document obsoletes RFC 3850. [STANDARDS-TRACK]},
  keywords="encryption, certificate, multipurpose, internet, mail , extensions, secure",
  doi="10.17487/RFC5750",
  }

@misc{rfc5751,
  author="B. Ramsdell and S. Turner",
  title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification}",
  howpublished="RFC 5751 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5751",
  pages="1--45",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5751.txt",
  key="RFC 5751",
  abstract={This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.  Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 3851. [STANDARDS-TRACK]},
  keywords="secure, multipurpose, internet, mail, extensions, encryption",
  doi="10.17487/RFC5751",
  }

@misc{rfc5752,
  author="S. Turner and J. Schaad",
  title="{Multiple Signatures in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5752 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5752",
  pages="1--17",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5752.txt",
  key="RFC 5752",
  abstract={Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information.  SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures.  If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s).  This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks.  Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]},
  keywords="signeddata, signerinfo, downgrade attacks, algorithm migration",
  doi="10.17487/RFC5752",
  }

@misc{rfc5753,
  author="S. Turner and D. Brown",
  title="{Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5753 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5753",
  pages="1--61",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5753.txt",
  key="RFC 5753",
  abstract={This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS).  The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content.  The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards.  This document obsoletes RFC 3278.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="public key, digital signatures, authentication",
  doi="10.17487/RFC5753",
  }

@misc{rfc5754,
  author="S. Turner",
  title="{Using SHA2 Algorithms with Cryptographic Message Syntax}",
  howpublished="RFC 5754 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5754",
  pages="1--10",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5754.txt",
  key="RFC 5754",
  abstract={This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS).  It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms.  Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]},
  keywords="secure hash algorithm, message digest algorithm, sha-224, sha-256, sha-384, sha-512, cms, dsa, digital signature algorithm, rsa, rivest sharmi adleman, ecdsa, elliptic curve dsa, smimecapabilities",
  doi="10.17487/RFC5754",
  }

@misc{rfc5755,
  author="S. Farrell and R. Housley and S. Turner",
  title="{An Internet Attribute Certificate Profile for Authorization}",
  howpublished="RFC 5755 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5755",
  pages="1--50",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5755.txt",
  key="RFC 5755",
  abstract={This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols.  Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements.  The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements.  The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications.  This document obsoletes RFC 3281. [STANDARDS-TRACK]},
  keywords="electronic mail, email, ipsec, www security",
  doi="10.17487/RFC5755",
  }

@misc{rfc5756,
  author="S. Turner and D. Brown and K. Yiu and R. Housley and T. Polk",
  title="{Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters}",
  howpublished="RFC 5756 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5756",
  pages="1--6",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5756.txt",
  key="RFC 5756",
  abstract={This document updates RFC 4055.  It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]},
  keywords="rsa encryption scheme, optical asymmetric encryption padding, subjectpublickeyinfo",
  doi="10.17487/RFC5756",
  }

@misc{rfc5757,
  author="T. Schmidt and M. Waehlisch and G. Fairhurst",
  title="{Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey}",
  howpublished="RFC 5757 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5757",
  pages="1--37",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5757.txt",
  key="RFC 5757",
  abstract={This document discusses current mobility extensions to IP-layer multicast.  It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast.  Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized.  Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain.  It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space.  This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="PMIPv6, FMIPv6, HMIPv6, SSM, ASM, MLD, Mobile Multicast Routing, Hybrid Multicast, Wireless, Multipoint",
  doi="10.17487/RFC5757",
  }

@misc{rfc5758,
  author="Q. Dang and S. Santesson and K. Moriarty and D. Brown and T. Polk",
  title="{Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA}",
  howpublished="RFC 5758 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5758",
  pages="1--8",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5758.txt",
  key="RFC 5758",
  abstract={This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm.  This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs).  This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]},
  keywords="digital signature algorithm, elliptic curve digital signature algorithm, pki",
  doi="10.17487/RFC5758",
  }

@misc{rfc5759,
  author="J. Solinas and L. Zieglar",
  title="{Suite B Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 5759 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5759",
  pages="1--11",
  year=2010,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5759.txt",
  key="RFC 5759",
  abstract={This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography.  The reader is assumed to have familiarity with RFC 5280, ``Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile''.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="x.509 v3 certificates, x.509 v2 certificate revocation lists, crl",
  doi="10.17487/RFC5759",
  }

@misc{rfc5760,
  author="J. Ott and J. Chesterfield and E. Schooler",
  title="{RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback}",
  howpublished="RFC 5760 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5760",
  pages="1--66",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6128",
url="https://www.rfc-editor.org/rfc/rfc5760.txt",
  key="RFC 5760",
  abstract={This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender.  The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired.  In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]},
  keywords="real-time transport protocol, ssm",
  doi="10.17487/RFC5760",
  }

@misc{rfc5761,
  author="C. Perkins and M. Westerlund",
  title="{Multiplexing RTP Data and Control Packets on a Single Port}",
  howpublished="RFC 5761 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5761",
  pages="1--13",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8035",
url="https://www.rfc-editor.org/rfc/rfc5761.txt",
  key="RFC 5761",
  abstract={This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.  It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5761",
  }

@misc{rfc5762,
  author="C. Perkins",
  title="{RTP and the Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 5762 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5762",
  pages="1--16",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6773",
url="https://www.rfc-editor.org/rfc/rfc5762.txt",
  key="RFC 5762",
  abstract={The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks.  The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications.  This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]},
  keywords="real-time transport protocol",
  doi="10.17487/RFC5762",
  }

@misc{rfc5763,
  author="J. Fischl and H. Tschofenig and E. Rescorla",
  title="{Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 5763 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5763",
  pages="1--37",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5763.txt",
  key="RFC 5763",
  abstract={This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]},
  keywords="stip, session initiation protocol, fingerprint attribute, dtls handshake",
  doi="10.17487/RFC5763",
  }

@misc{rfc5764,
  author="D. McGrew and E. Rescorla",
  title="{Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 5764 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5764",
  pages="1--26",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7983",
url="https://www.rfc-editor.org/rfc/rfc5764.txt",
  key="RFC 5764",
  abstract={This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]},
  keywords="secure rtp control protocol, srtcp",
  doi="10.17487/RFC5764",
  }

@misc{rfc5765,
  author="H. Schulzrinne and E. Marocco and E. Ivov",
  title="{Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications}",
  howpublished="RFC 5765 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5765",
  pages="1--28",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5765.txt",
  key="RFC 5765",
  abstract={Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues.  It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P.  Such a migration needs to address a new set of P2P-specific security problems.  This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication.  This document is a product of the P2P Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="p2p, overlay, rtc, voip",
  doi="10.17487/RFC5765",
  }

@misc{rfc5766,
  author="R. Mahy and P. Matthews and J. Rosenberg",
  title="{Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 5766 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5766",
  pages="1--67",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8155",
url="https://www.rfc-editor.org/rfc/rfc5766.txt",
  key="RFC 5766",
  abstract={If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers).  In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay.  This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.  TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]},
  keywords="NAT, TURN, STUN, ICE",
  doi="10.17487/RFC5766",
  }

@misc{rfc5767,
  author="M. Munakata and S. Schubert and T. Ohba",
  title="{User-Agent-Driven Privacy Mechanism for SIP}",
  howpublished="RFC 5767 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5767",
  pages="1--11",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5767.txt",
  key="RFC 5767",
  abstract={This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SIP, IMS, privacy, guidelines",
  doi="10.17487/RFC5767",
  }

@misc{rfc5768,
  author="J. Rosenberg",
  title="{Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5768 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5768",
  pages="1--6",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5768.txt",
  key="RFC 5768",
  abstract={This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP).  The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE.  The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]},
  keywords="SIP, NAT",
  doi="10.17487/RFC5768",
  }

@misc{rfc5769,
  author="R. Denis-Courmont",
  title="{Test Vectors for Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 5769 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5769",
  pages="1--11",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5769.txt",
  key="RFC 5769",
  abstract={The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes.  The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor).  This document provides test vectors for those attributes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="STUN, test, vectors, fingerprint",
  doi="10.17487/RFC5769",
  }

@misc{rfc5770,
  author="M. Komu and T. Henderson and H. Tschofenig and J. Melen and A. Keranen",
  title="{Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators}",
  howpublished="RFC 5770 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5770",
  pages="1--34",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5770.txt",
  key="RFC 5770",
  abstract={This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal.  The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP).  This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.  With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications.  This document defines an Experimental Protocol for the Internet community.},
  keywords="ICE, HIP relay",
  doi="10.17487/RFC5770",
  }

@misc{rfc5771,
  author="M. Cotton and L. Vegoda and D. Meyer",
  title="{IANA Guidelines for IPv4 Multicast Address Assignments}",
  howpublished="RFC 5771 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5771",
  pages="1--11",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5771.txt",
  key="RFC 5771",
  abstract={This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.  It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780.  This memo documents an Internet Best Current Practice.},
  keywords="internet, assigned, numbers, authority, protocol, parameters",
  doi="10.17487/RFC5771",
  }

@misc{rfc5772,
  author="A. Doria and E. Davies and F. Kastenholz",
  title="{A Set of Possible Requirements for a Future Routing Architecture}",
  howpublished="RFC 5772 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5772",
  pages="1--68",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5772.txt",
  key="RFC 5772",
  abstract={The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.},
  keywords="Routing Research Group, RRG, IDR, FDR",
  doi="10.17487/RFC5772",
  }

@misc{rfc5773,
  author="E. Davies and A. Doria",
  title="{Analysis of Inter-Domain Routing Requirements and History}",
  howpublished="RFC 5773 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5773",
  pages="1--51",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5773.txt",
  key="RFC 5773",
  abstract={This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing.  The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006.  It is the companion document to ``A Set of Possible Requirements for a Future Routing Architecture'' (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols.  This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties.  The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.  This document defines a Historic Document for the Internet community.},
  keywords="History, IRTF, Routing Research Group, RRG, Routing Requirements, IDR, FDR",
  doi="10.17487/RFC5773",
  }

@misc{rfc5774,
  author="K. Wolf and A. Mayrhofer",
  title="{Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition}",
  howpublished="RFC 5774 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5774",
  pages="1--33",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5774.txt",
  key="RFC 5774",
  abstract={This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776.  Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC5774",
  }

@misc{rfc5775,
  author="M. Luby and M. Watson and L. Vicisano",
  title="{Asynchronous Layered Coding (ALC) Protocol Instantiation}",
  howpublished="RFC 5775 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5775",
  pages="1--24",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5775.txt",
  key="RFC 5775",
  abstract={This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.  Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender.  This document obsoletes RFC 3450. [STANDARDS-TRACK]},
  keywords="Forward Error Correction, FEC, Layered Coding Transport, LCT, Building Block, WEBRC, reliable +object delivery, reliable file delivery, broadcast, multicast",
  doi="10.17487/RFC5775",
  }

@misc{rfc5776,
  author="V. Roca and A. Francillon and S. Faurite",
  title="{Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}",
  howpublished="RFC 5776 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5776",
  pages="1--58",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5776.txt",
  key="RFC 5776",
  abstract={This document details the Timed Efficient Stream \\%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols.  This document only considers the authentication/integrity verification of the packets generated by the session's sender.  The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.  This document defines an Experimental Protocol for the Internet community.},
  keywords="TESLA, FLUTE, ALC, NORM",
  doi="10.17487/RFC5776",
  }

@misc{rfc5777,
  author="J. Korhonen and H. Tschofenig and M. Arumaithurai and M. Jones and A. Lior",
  title="{Traffic Classification and Quality of Service (QoS) Attributes for Diameter}",
  howpublished="RFC 5777 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5777",
  pages="1--43",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5777.txt",
  key="RFC 5777",
  abstract={This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment.  These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]},
  keywords="Diameter, Qos Attributes, Traffic classification, Filtering, Firewalling",
  doi="10.17487/RFC5777",
  }

@misc{rfc5778,
  author="J. Korhonen and H. Tschofenig and J. Bournelle and G. Giaretta and M. Nakhjiri",
  title="{Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction}",
  howpublished="RFC 5778 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5778",
  pages="1--34",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5778.txt",
  key="RFC 5778",
  abstract={Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server. This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5778",
  }

@misc{rfc5779,
  author="J. Korhonen and J. Bournelle and K. Chowdhury and A. Muhanna and U. Meyer",
  title="{Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server}",
  howpublished="RFC 5779 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5779",
  pages="1--20",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5779.txt",
  key="RFC 5779",
  abstract={This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain.  These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]},
  keywords="aaa, authentication, authorization, and accounting",
  doi="10.17487/RFC5779",
  }

@misc{rfc5780,
  author="D. MacDonald and B. Lowekamp",
  title="{NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 5780 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5780",
  pages="1--27",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5780.txt",
  key="RFC 5780",
  abstract={This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.  This document defines an Experimental Protocol for the Internet community.},
  keywords="NAT type diagnostics",
  doi="10.17487/RFC5780",
  }

@misc{rfc5781,
  author="S. Weiler and D. Ward and R. Housley",
  title="{The rsync URI Scheme}",
  howpublished="RFC 5781 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5781",
  pages="1--4",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5781.txt",
  key="RFC 5781",
  abstract={This document specifies the rsync Uniform Resource Identifier (URI) scheme.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="rsyncuri",
  doi="10.17487/RFC5781",
  }

@misc{rfc5782,
  author="J. Levine",
  title="{DNS Blacklists and Whitelists}",
  howpublished="RFC 5782 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5782",
  pages="1--11",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5782.txt",
  key="RFC 5782",
  abstract={The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains.  The DNS has become the de-facto standard method of distributing these blacklists and whitelists.  This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mail, electronic mail, DNS, spam, blacklist, whitelist",
  doi="10.17487/RFC5782",
  }

@misc{rfc5783,
  author="M. Welzl and W. Eddy",
  title="{Congestion Control in the RFC Series}",
  howpublished="RFC 5783 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5783",
  pages="1--28",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5783.txt",
  key="RFC 5783",
  abstract={This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008.  It provides a survey of congestion control topics described by documents in the RFC series.  This does not modify or update the specifications or status of the RFC documents that are discussed.  It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5783",
  }

@misc{rfc5784,
  author="N. Freed and S. Vedam",
  title="{Sieve Email Filtering:  Sieves and Display Directives in XML}",
  howpublished="RFC 5784 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5784",
  pages="1--32",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5784.txt",
  key="RFC 5784",
  abstract={This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]},
  keywords="SMTP, ESMTP, Sieve",
  doi="10.17487/RFC5784",
  }

@misc{rfc5785,
  author="M. Nottingham and E. Hammer-Lahav",
  title="{Defining Well-Known Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 5785 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5785",
  pages="1--8",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5785.txt",
  key="RFC 5785",
  abstract={This memo defines a path prefix for ``well-known locations'', ``/.well-known/'', in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]},
  keywords="well-known locations",
  doi="10.17487/RFC5785",
  }

@misc{rfc5786,
  author="R. Aggarwal and K. Kompella",
  title="{Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions}",
  howpublished="RFC 5786 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5786",
  pages="1--7",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6827",
url="https://www.rfc-editor.org/rfc/rfc5786.txt",
  key="RFC 5786",
  abstract={OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5786",
  }

@misc{rfc5787,
  author="D. Papadimitriou",
  title="{OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing}",
  howpublished="RFC 5787 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5787",
  pages="1--29",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6827",
url="https://www.rfc-editor.org/rfc/rfc5787.txt",
  key="RFC 5787",
  abstract={The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.},
  keywords="itu-t, ospfv2 link state routing protocol",
  doi="10.17487/RFC5787",
  }

@misc{rfc5788,
  author="A. Melnikov and D. Cridland",
  title="{IMAP4 Keyword Registry}",
  howpublished="RFC 5788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5788",
  pages="1--11",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5788.txt",
  key="RFC 5788",
  abstract={The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]},
  keywords="IMAP, email, tag, label, keyword",
  doi="10.17487/RFC5788",
  }

@misc{rfc5789,
  author="L. Dusseault and J. Snell",
  title="{PATCH Method for HTTP}",
  howpublished="RFC 5789 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5789",
  pages="1--10",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5789.txt",
  key="RFC 5789",
  abstract={Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification.  The existing HTTP PUT method only allows a complete replacement of a document.  This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]},
  keywords="HTTP, PATCH, Hypertext Transfer Protocol",
  doi="10.17487/RFC5789",
  }

@misc{rfc5790,
  author="H. Liu and W. Cao and H. Asaeda",
  title="{Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols}",
  howpublished="RFC 5790 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5790",
  pages="1--17",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5790.txt",
  key="RFC 5790",
  abstract={This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2.  The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]},
  keywords="IGMP, MLD, Lite, lightweight",
  doi="10.17487/RFC5790",
  }

@misc{rfc5791,
  author="J. Reschke and J. Kunze",
  title="{RFC 2731 (``Encoding Dublin Core Metadata in HTML'') Is Obsolete}",
  howpublished="RFC 5791 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5791",
  pages="1--2",
  year=2010,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5791.txt",
  key="RFC 5791",
  abstract={This document obsoletes RFC 2731, ``Encoding Dublin Core Metadata in HTML'', as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DCMI, Dublin Core Metadata Initiative, XHTML, HTML, metadata",
  doi="10.17487/RFC5791",
  }

@misc{rfc5792,
  author="P. Sangster and K. Narayan",
  title="{PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)}",
  howpublished="RFC 5792 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5792",
  pages="1--83",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5792.txt",
  key="RFC 5792",
  abstract={This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol.  The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5792",
  }

@misc{rfc5793,
  author="R. Sahita and S. Hanna and R. Hurst and K. Narayan",
  title="{PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)}",
  howpublished="RFC 5793 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5793",
  pages="1--76",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5793.txt",
  key="RFC 5793",
  abstract={This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol.  The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]},
  keywords="NEA, Network Endpoint Assessment",
  doi="10.17487/RFC5793",
  }

@misc{rfc5794,
  author="J. Lee and J. Lee and J. Kim and D. Kwon and C. Kim",
  title="{A Description of the ARIA Encryption Algorithm}",
  howpublished="RFC 5794 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5794",
  pages="1--18",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5794.txt",
  key="RFC 5794",
  abstract={This document describes the ARIA encryption algorithm.  ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys.  The algorithm consists of a key scheduling part and data randomizing part.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ARIA, encryption, block, cipher",
  doi="10.17487/RFC5794",
  }

@misc{rfc5795,
  author="K. Sandlund and G. Pelletier and L-E. Jonsson",
  title="{The RObust Header Compression (ROHC) Framework}",
  howpublished="RFC 5795 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5795",
  pages="1--41",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5795.txt",
  key="RFC 5795",
  abstract={The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5795",
  }

@misc{rfc5796,
  author="W. Atwood and S. Islam and M. Siami",
  title="{Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages}",
  howpublished="RFC 5796 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5796",
  pages="1--21",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5796.txt",
  key="RFC 5796",
  abstract={RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol.  This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH).  It specifies optional mechanisms to provide confidentiality using the ESP.  Manual keying is specified as the mandatory and default group key management solution.  To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided.  However, the procedures for implementing automated group key management are left to other documents.  This document updates RFC 4601. [STANDARDS-TRACK]},
  keywords="security, PIM-SM, routing security, multicast routing, link-local message, Protocol Independent Multicast Sparse Mode",
  doi="10.17487/RFC5796",
  }

@misc{rfc5797,
  author="J. Klensin and A. Hoenes",
  title="{FTP Command and Extension Registry}",
  howpublished="RFC 5797 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5797",
  pages="1--10",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5797.txt",
  key="RFC 5797",
  abstract={Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959.  RFC 2389 established a mechanism for specifying and negotiating FTP extensions.  The number of extensions, both those supported by the mechanism and some that are not, continues to increase.  An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity.  This specification establishes that registry. [STANDARDS-TRACK]},
  keywords="FTP FEAT command, FTP FEAT response",
  doi="10.17487/RFC5797",
  }

@misc{rfc5798,
  author="S. Nadas",
  title="{Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6}",
  howpublished="RFC 5798 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5798",
  pages="1--40",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5798.txt",
  key="RFC 5798",
  abstract={This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6.  It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in ``Virtual Router Redundancy Protocol for IPv6''.  VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.  The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses.  VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol.  Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap.  The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable.  For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.  For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5798",
  }

@misc{rfc5801,
  author="S. Josefsson and N. Williams",
  title="{Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family}",
  howpublished="RFC 5801 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5801",
  pages="1--26",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5801.txt",
  key="RFC 5801",
  abstract={This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework.  This is done by defining a new SASL mechanism family, called GS2.  This mechanism family offers a number of improvements over the previous ``SASL/ GSSAPI'' mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding.  Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5801",
  }

@misc{rfc5802,
  author="C. Newman and A. Menon-Sen and A. Melnikov and N. Williams",
  title="{Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms}",
  howpublished="RFC 5802 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5802",
  pages="1--28",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7677",
url="https://www.rfc-editor.org/rfc/rfc5802.txt",
  key="RFC 5802",
  abstract={The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]},
  keywords="simple authentication and security layer",
  doi="10.17487/RFC5802",
  }

@misc{rfc5803,
  author="A. Melnikov",
  title="{Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets}",
  howpublished="RFC 5803 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5803",
  pages="1--4",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5803.txt",
  key="RFC 5803",
  abstract={This memo describes how the ``authPassword'' Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="authpassword, simple authentication and security layer, sasl",
  doi="10.17487/RFC5803",
  }

@misc{rfc5804,
  author="A. Melnikov and T. Martin",
  title="{A Protocol for Remotely Managing Sieve Scripts}",
  howpublished="RFC 5804 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5804",
  pages="1--49",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7817",
url="https://www.rfc-editor.org/rfc/rfc5804.txt",
  key="RFC 5804",
  abstract={Sieve scripts allow users to filter incoming email.  Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them.  This document describes a protocol ``ManageSieve'' for securely managing Sieve scripts on a remote server.  This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]},
  keywords="managesieve",
  doi="10.17487/RFC5804",
  }

@misc{rfc5805,
  author="K. Zeilenga",
  title="{Lightweight Directory Access Protocol (LDAP) Transactions}",
  howpublished="RFC 5805 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5805",
  pages="1--11",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5805.txt",
  key="RFC 5805",
  abstract={Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties.  Each of these update operations act upon an entry.  It is often desirable to update two or more entries in a single unit of interaction, a transaction.  Transactions are necessary to support a number of applications including resource provisioning.  This document extends LDAP to support transactions.  This document defines an Experimental Protocol for the Internet community.},
  keywords="acid, atomic consistency isolation durability",
  doi="10.17487/RFC5805",
  }

@misc{rfc5806,
  author="S. Levy and M. Mohali",
  title="{Diversion Indication in SIP}",
  howpublished="RFC 5806 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="5806",
  pages="1--53",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5806.txt",
  key="RFC 5806",
  abstract={This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows. This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.},
  doi="10.17487/RFC5806",
  }

@misc{rfc5807,
  author="Y. Ohba and A. Yegin",
  title="{Definition of Master Key between PANA Client and Enforcement Point}",
  howpublished="RFC 5807 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5807",
  pages="1--7",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5807.txt",
  key="RFC 5807",
  abstract={This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering.  The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication.  The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]},
  keywords="protocol for carrying authentication for network access",
  doi="10.17487/RFC5807",
  }

@misc{rfc5808,
  author="R. Marshall",
  title="{Requirements for a Location-by-Reference Mechanism}",
  howpublished="RFC 5808 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5808",
  pages="1--14",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5808.txt",
  key="RFC 5808",
  abstract={This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5808",
  }

@misc{rfc5810,
  author="A. Doria and J. Hadi Salim and R. Haas and H. Khosravi and W. Wang and L. Dong and R. Gopal and J. Halpern",
  title="{Forwarding and Control Element Separation (ForCES) Protocol Specification}",
  howpublished="RFC 5810 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5810",
  pages="1--124",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7121, 7391",
url="https://www.rfc-editor.org/rfc/rfc5810.txt",
  key="RFC 5810",
  abstract={This document specifies the Forwarding and Control Element Separation (ForCES) protocol.  The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE).  This specification is intended to meet the ForCES protocol requirements defined in RFC 3654.  Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]},
  keywords="control elements, forwarding elements, fe, ce, network element, ne, tml, transport mapping layer",
  doi="10.17487/RFC5810",
  }

@misc{rfc5811,
  author="J. Hadi Salim and K. Ogawa",
  title="{SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol}",
  howpublished="RFC 5811 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5811",
  pages="1--28",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5811.txt",
  key="RFC 5811",
  abstract={This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol.  It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]},
  keywords="ForCES, TML, stream conrol transmission protocol",
  doi="10.17487/RFC5811",
  }

@misc{rfc5812,
  author="J. Halpern and J. Hadi Salim",
  title="{Forwarding and Control Element Separation (ForCES) Forwarding Element Model}",
  howpublished="RFC 5812 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5812",
  pages="1--134",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7408",
url="https://www.rfc-editor.org/rfc/rfc5812.txt",
  key="RFC 5812",
  abstract={This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol.  The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly.  More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected.  This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]},
  keywords="forwarding element, control element",
  doi="10.17487/RFC5812",
  }

@misc{rfc5813,
  author="R. Haas",
  title="{Forwarding and Control Element Separation (ForCES) MIB}",
  howpublished="RFC 5813 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5813",
  pages="1--17",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5813.txt",
  key="RFC 5813",
  abstract={This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]},
  keywords="management information base, network element, ne, forces-mib",
  doi="10.17487/RFC5813",
  }

@misc{rfc5814,
  author="W. Sun and G. Zhang",
  title="{Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks}",
  howpublished="RFC 5814 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5814",
  pages="1--44",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5814.txt",
  key="RFC 5814",
  abstract={Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]},
  keywords="Signaling performance, RSVP-TE delay measurement, control plane performance",
  doi="10.17487/RFC5814",
  }

@misc{rfc5815,
  author="T. Dietz and A. Kobayashi and B. Claise and G. Muenz",
  title="{Definitions of Managed Objects for IP Flow Information Export}",
  howpublished="RFC 5815 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5815",
  pages="1--64",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6615",
url="https://www.rfc-editor.org/rfc/rfc5815.txt",
  key="RFC 5815",
  abstract={This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]},
  keywords="Selector, Collector, Exporter, Sampling, Filtering, IPFIX, IPFIX-MIB, IPFIX-SELECTOR-MIB",
  doi="10.17487/RFC5815",
  }

@misc{rfc5816,
  author="S. Santesson and N. Pope",
  title="{ESSCertIDv2 Update for RFC 3161}",
  howpublished="RFC 5816 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5816",
  pages="1--5",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5816.txt",
  key="RFC 5816",
  abstract={This document updates RFC 3161.  It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]},
  keywords="signer certificate, secure hash algorithm, sha-1",
  doi="10.17487/RFC5816",
  }

@misc{rfc5817,
  author="Z. Ali and JP. Vasseur and A. Zamfir and J. Newton",
  title="{Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks}",
  howpublished="RFC 5817 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5817",
  pages="1--11",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5817.txt",
  key="RFC 5817",
  abstract={MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mpls-te, te",
  doi="10.17487/RFC5817",
  }

@misc{rfc5818,
  author="D. Li and H. Xu and S. Bardalai and J. Meuric and D. Caviglia",
  title="{Data Channel Status Confirmation Extensions for the Link Management Protocol}",
  howpublished="RFC 5818 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5818",
  pages="1--15",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6898",
url="https://www.rfc-editor.org/rfc/rfc5818.txt",
  key="RFC 5818",
  abstract={This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found.  As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]},
  keywords="LMP",
  doi="10.17487/RFC5818",
  }

@misc{rfc5819,
  author="A. Melnikov and T. Sirainen",
  title="{IMAP4 Extension for Returning STATUS Information in Extended LIST}",
  howpublished="RFC 5819 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5819",
  pages="1--6",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5819.txt",
  key="RFC 5819",
  abstract={Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes.  In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found.  This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]},
  keywords="list, lsub",
  doi="10.17487/RFC5819",
  }

@misc{rfc5820,
  author="A. Roy and M. Chandra",
  title="{Extensions to OSPF to Support Mobile Ad Hoc Networking}",
  howpublished="RFC 5820 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5820",
  pages="1--41",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7137",
url="https://www.rfc-editor.org/rfc/rfc5820.txt",
  key="RFC 5820",
  abstract={This document describes extensions to OSPF to support mobile ad hoc networks (MANETs).  The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates.  OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]},
  keywords="open shortest path first, manet, ospf-or, ospf-overlapping relay, link-local signaling, lls, ospf-manet",
  doi="10.17487/RFC5820",
  }

@misc{rfc5824,
  author="K. Kumaki and R. Zhang and Y. Kamite",
  title="{Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN}",
  howpublished="RFC 5824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5824",
  pages="1--27",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5824.txt",
  key="RFC 5824",
  abstract={Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase. Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="triple-play service",
  doi="10.17487/RFC5824",
  }

@misc{rfc5825,
  author="K. Fujiwara and B. Leiba",
  title="{Displaying Downgraded Messages for Email Address Internationalization}",
  howpublished="RFC 5825 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5825",
  pages="1--14",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6530",
url="https://www.rfc-editor.org/rfc/rfc5825.txt",
  key="RFC 5825",
  abstract={This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields.  This document defines an Experimental Protocol for the Internet community.},
  keywords="EAI, Email Address Internationalization, Downgrade, MAIL",
  doi="10.17487/RFC5825",
  }

@misc{rfc5826,
  author="A. Brandt and J. Buron and G. Porcu",
  title="{Home Automation Routing Requirements in Low-Power and Lossy Networks}",
  howpublished="RFC 5826 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5826",
  pages="1--17",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5826.txt",
  key="RFC 5826",
  abstract={This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks.  In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes.  Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control).  Because such devices only cover a limited radio range, routing is often required.  The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="roll, routing over low power and lossy",
  doi="10.17487/RFC5826",
  }

@misc{rfc5827,
  author="M. Allman and K. Avrachenkov and U. Ayesta and J. Blanton and P. Hurtig",
  title="{Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 5827 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5827",
  pages="1--15",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5827.txt",
  key="RFC 5827",
  abstract={This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small.  The ``Early Retransmit'' mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission.  This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]},
  keywords="transmission control protocol, fast retransmission",
  doi="10.17487/RFC5827",
  }

@misc{rfc5828,
  author="D. Fedyk and L. Berger and L. Andersson",
  title="{Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework}",
  howpublished="RFC 5828 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5828",
  pages="1--20",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5828.txt",
  key="RFC 5828",
  abstract={There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models.  As a consequence, the role of Ethernet is rapidly expanding into ``transport networks'' that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM).  This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this ``transport network'' capacity.  GMPLS has already been specified for similar technologies.  Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="transport networks",
  doi="10.17487/RFC5828",
  }

@misc{rfc5829,
  author="A. Brown and G. Clemm and J. Reschke",
  title="{Link Relation Types for Simple Version Navigation between Web Resources}",
  howpublished="RFC 5829 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5829",
  pages="1--12",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5829.txt",
  key="RFC 5829",
  abstract={This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5829",
  }

@misc{rfc5830,
  author="V. Dolmatov",
  title="{GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms}",
  howpublished="RFC 5830 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5830",
  pages="1--19",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5830.txt",
  key="RFC 5830",
  abstract={This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="russian federal standard, electronic encryption, decryption, message authentication, russian cryptographic standard",
  doi="10.17487/RFC5830",
  }

@misc{rfc5831,
  author="V. Dolmatov",
  title="{GOST R 34.11-94: Hash Function Algorithm}",
  howpublished="RFC 5831 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5831",
  pages="1--17",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6986",
url="https://www.rfc-editor.org/rfc/rfc5831.txt",
  key="RFC 5831",
  abstract={This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="russian federal standard, russian cryptographic standard, russian cryptography",
  doi="10.17487/RFC5831",
  }

@misc{rfc5832,
  author="V. Dolmatov",
  title="{GOST R 34.10-2001: Digital Signature Algorithm}",
  howpublished="RFC 5832 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5832",
  pages="1--22",
  year=2010,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7091",
url="https://www.rfc-editor.org/rfc/rfc5832.txt",
  key="RFC 5832",
  abstract={This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.},
  keywords="russian federal standard, digital signature, russian cryptographic standard, russian cryptography",
  doi="10.17487/RFC5832",
  }

@misc{rfc5833,
  author="Y. Shi and D. Perkins and C. Elliott and Y. Zhang",
  title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB}",
  howpublished="RFC 5833 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5833",
  pages="1--73",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5833.txt",
  key="RFC 5833",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol.  This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mib, CAPWAP-BASE-MIB",
  doi="10.17487/RFC5833",
  }

@misc{rfc5834,
  author="Y. Shi and D. Perkins and C. Elliott and Y. Zhang",
  title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11}",
  howpublished="RFC 5834 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5834",
  pages="1--25",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5834.txt",
  key="RFC 5834",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding.  This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mib, CAPWAP-DOT11-MIB",
  doi="10.17487/RFC5834",
  }

@misc{rfc5835,
  author="A. Morton and S. Van den Berghe",
  title="{Framework for Metric Composition}",
  howpublished="RFC 5835 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5835",
  pages="1--18",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5835.txt",
  key="RFC 5835",
  abstract={This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF.  This new framework memo describes the generic composition and aggregation mechanisms.  The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5835",
  }

@misc{rfc5836,
  author="Y. Ohba and Q. Wu and G. Zorn",
  title="{Extensible Authentication Protocol (EAP) Early Authentication Problem Statement}",
  howpublished="RFC 5836 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5836",
  pages="1--20",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5836.txt",
  key="RFC 5836",
  abstract={Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival.  This document discusses the EAP early authentication problem in detail.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="eap early authentication",
  doi="10.17487/RFC5836",
  }

@misc{rfc5837,
  author="A. Atlas and R. Bonica and C. Pignataro and N. Shen and JR. Rivers",
  title="{Extending ICMP for Interface and Next-Hop Identification}",
  howpublished="RFC 5837 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5837",
  pages="1--18",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5837.txt",
  key="RFC 5837",
  abstract={This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]},
  keywords="Internet Control Message Protocol",
  doi="10.17487/RFC5837",
  }

@misc{rfc5838,
  author="A. Lindem and S. Mirtorabi and A. Roy and M. Barnes and R. Aggarwal",
  title="{Support of Address Families in OSPFv3}",
  howpublished="RFC 5838 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5838",
  pages="1--13",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6969, 7949",
url="https://www.rfc-editor.org/rfc/rfc5838.txt",
  key="RFC 5838",
  abstract={This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances.  It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header.  This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]},
  keywords="af, instance id",
  doi="10.17487/RFC5838",
  }

@misc{rfc5839,
  author="A. Niemi and D. Willis",
  title="{An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification}",
  howpublished="RFC 5839 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5839",
  pages="1--25",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5839.txt",
  key="RFC 5839",
  abstract={The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents.  This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state.  These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent.  This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received.  When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]},
  keywords="SIP events, subnot-etags, optimization",
  doi="10.17487/RFC5839",
  }

@misc{rfc5840,
  author="K. Grewal and G. Montenegro and M. Bhatia",
  title="{Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility}",
  howpublished="RFC 5840 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5840",
  pages="1--15",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5840.txt",
  key="RFC 5840",
  abstract={This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions.  Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet.  This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop).  The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]},
  keywords="wesp",
  doi="10.17487/RFC5840",
  }

@misc{rfc5841,
  author="R. Hay and W. Turkal",
  title="{TCP Option to Denote Packet Mood}",
  howpublished="RFC 5841 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5841",
  pages="1--9",
  year=2010,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5841.txt",
  key="RFC 5841",
  abstract={This document proposes a new TCP option to denote packet mood.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5841",
  }

@misc{rfc5842,
  author="G. Clemm and J. Crawford and J. Reschke and J. Whitehead",
  title="{Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 5842 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5842",
  pages="1--45",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5842.txt",
  key="RFC 5842",
  abstract={This specification defines bindings, and the BIND method for creating multiple bindings to the same resource.  Creating a new binding to a resource causes at least one new URI to be mapped to that resource.  Servers are required to ensure the integrity of any bindings that they allow to be created.  This document defines an Experimental Protocol for the Internet community.},
  keywords="HTTP, WebDAV, collections, hard link",
  doi="10.17487/RFC5842",
  }

@misc{rfc5843,
  author="A. Bryan",
  title="{Additional Hash Algorithms for HTTP Instance Digests}",
  howpublished="RFC 5843 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5843",
  pages="1--5",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5843.txt",
  key="RFC 5843",
  abstract={The IANA registry named ``Hypertext Transfer Protocol (HTTP) Digest Algorithm Values'' defines values for digest algorithms used by Instance Digests in HTTP.  Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource.  This document adds new values to the registry and updates previous values.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Hypertext Transfer Protocol, HTTP, Digest Algorithm Values registry update",
  doi="10.17487/RFC5843",
  }

@misc{rfc5844,
  author="R. Wakikawa and S. Gundavelli",
  title="{IPv4 Support for Proxy Mobile IPv6}",
  howpublished="RFC 5844 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5844",
  pages="1--49",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5844.txt",
  key="RFC 5844",
  abstract={This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support.  The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]},
  keywords="NAT traversal, Dual Stack, Mobility, IPv4 Support, IPv4 Support for PMIPv6",
  doi="10.17487/RFC5844",
  }

@misc{rfc5845,
  author="A. Muhanna and M. Khalil and S. Gundavelli and K. Leung",
  title="{Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6}",
  howpublished="RFC 5845 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5845",
  pages="1--25",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5845.txt",
  key="RFC 5845",
  abstract={This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session.  In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]},
  keywords="PMIP6, PMIPv6, Downlink GRE Key, Uplink GRE Key, TLV-Header Tunneling, TLV-Header Tunneling, GRE Key Exchange",
  doi="10.17487/RFC5845",
  }

@misc{rfc5846,
  author="A. Muhanna and M. Khalil and S. Gundavelli and K. Chowdhury and P. Yegani",
  title="{Binding Revocation for IPv6 Mobility}",
  howpublished="RFC 5846 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5846",
  pages="1--39",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5846.txt",
  key="RFC 5846",
  abstract={This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources.  This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6.  The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]},
  keywords="PMIP6, PMIPv6, Binding Revocation Indication, BRI, Binding Revocation Acknowledgement, BRA, MIP6, DSMIP6, Multiple Care-of Addresses, PMIPv6 Revocation, Bulk PMIPv6 Revocation",
  doi="10.17487/RFC5846",
  }

@misc{rfc5847,
  author="V. Devarapalli and R. Koodli and H. Lim and N. Kant and S. Krishnan and J. Laganier",
  title="{Heartbeat Mechanism for Proxy Mobile IPv6}",
  howpublished="RFC 5847 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5847",
  pages="1--11",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5847.txt",
  key="RFC 5847",
  abstract={Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol.  The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain.  This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]},
  keywords="Node Reachability, Restarts, Failure Detection",
  doi="10.17487/RFC5847",
  }

@misc{rfc5848,
  author="J. Kelsey and J. Callas and A. Clemm",
  title="{Signed Syslog Messages}",
  howpublished="RFC 5848 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5848",
  pages="1--40",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5848.txt",
  key="RFC 5848",
  abstract={This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages.  This specification is intended to be used in conjunction with the work defined in RFC 5424, ``The Syslog Protocol''. [STANDARDS-TRACK]},
  keywords="syslog, syslog-sign",
  doi="10.17487/RFC5848",
  }

@misc{rfc5849,
  author="E. Hammer-Lahav",
  title="{The OAuth 1.0 Protocol}",
  howpublished="RFC 5849 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5849",
  pages="1--38",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6749",
url="https://www.rfc-editor.org/rfc/rfc5849.txt",
  key="RFC 5849",
  abstract={OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user).  It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="authorization, delegation",
  doi="10.17487/RFC5849",
  }

@misc{rfc5850,
  author="R. Mahy and R. Sparks and J. Rosenberg and D. Petrie and A. Johnston",
  title="{A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5850 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5850",
  pages="1--44",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5850.txt",
  key="RFC 5850",
  abstract={This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP).  To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these.  The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships.  In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history.  This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="call control, multiparty, features, mixing, refer, 3pcc, Refer method, Replaces header field, Join header field, conferencing",
  doi="10.17487/RFC5850",
  }

@misc{rfc5851,
  author="S. Ooghe and N. Voigt and M. Platnic and T. Haag and S. Wadhwa",
  title="{Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks}",
  howpublished="RFC 5851 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5851",
  pages="1--47",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5851.txt",
  key="RFC 5851",
  abstract={The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems. This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Access Node Control Protocol, Topology Discovery, Loop Configuration, Remote Connectivity Test, Multicast, Access Node, Network Access Server",
  doi="10.17487/RFC5851",
  }

@misc{rfc5852,
  author="D. Caviglia and D. Ceccarelli and D. Bramanti and D. Li and S. Bardalai",
  title="{RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network}",
  howpublished="RFC 5852 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5852",
  pages="1--23",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5852.txt",
  key="RFC 5852",
  abstract={In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493. This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]},
  keywords="resource reservation protocol, handover procedures",
  doi="10.17487/RFC5852",
  }

@misc{rfc5853,
  author="J. Hautakorpi and G. Camarillo and R. Penfield and A. Hawrylyshen and M. Bhatia",
  title="{Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments}",
  howpublished="RFC 5853 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5853",
  pages="1--26",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5853.txt",
  key="RFC 5853",
  abstract={This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs).  The goal of this document is to describe the commonly provided functions of SBCs.  A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles.  This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5853",
  }

@misc{rfc5854,
  author="A. Bryan and T. Tsujikawa and N. McNab and P. Poeml",
  title="{The Metalink Download Description Format}",
  howpublished="RFC 5854 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5854",
  pages="1--39",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5854.txt",
  key="RFC 5854",
  abstract={This document specifies Metalink, an XML-based download description format.  Metalink describes download locations (mirrors), cryptographic hashes, and other information.  Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]},
  keywords="file transfer, mirrors, data integrity, hash, xml, http, hypertext transfer protocol, ftp, file transfer protocol, metadata, torrent",
  doi="10.17487/RFC5854",
  }

@misc{rfc5855,
  author="J. Abley and T. Manderson",
  title="{Nameservers for IPv4 and IPv6 Reverse Zones}",
  howpublished="RFC 5855 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="5855",
  pages="1--12",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5855.txt",
  key="RFC 5855",
  abstract={This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS.  These zones contain data that facilitate reverse mapping (address to name).  This memo documents an Internet Best Current Practice.},
  keywords=" IN-ADDR.ARPA, IP6.ARPA, reverse mapping",
  doi="10.17487/RFC5855",
  }

@misc{rfc5856,
  author="E. Ertekin and R. Jasani and C. Christou and C. Bormann",
  title="{Integration of Robust Header Compression over IPsec Security Associations}",
  howpublished="RFC 5856 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5856",
  pages="1--15",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5856.txt",
  key="RFC 5856",
  abstract={IP Security (IPsec) provides various security services for IP traffic.  However, the benefits of IPsec come at the cost of increased overhead.  This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).  By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ROHC, ROHCoIPsec",
  doi="10.17487/RFC5856",
  }

@misc{rfc5857,
  author="E. Ertekin and C. Christou and R. Jasani and T. Kivinen and C. Bormann",
  title="{IKEv2 Extensions to Support Robust Header Compression over IPsec}",
  howpublished="RFC 5857 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5857",
  pages="1--13",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5857.txt",
  key="RFC 5857",
  abstract={In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints.  Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters.  This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]},
  keywords="ROHC, ROHCoIPsec",
  doi="10.17487/RFC5857",
  }

@misc{rfc5858,
  author="E. Ertekin and C. Christou and C. Bormann",
  title="{IPsec Extensions to Support Robust Header Compression over IPsec}",
  howpublished="RFC 5858 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5858",
  pages="1--15",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5858.txt",
  key="RFC 5858",
  abstract={Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization.  However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required.  This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]},
  keywords="ROHC, ROHCoIPsec",
  doi="10.17487/RFC5858",
  }

@misc{rfc5859,
  author="R. Johnson",
  title="{TFTP Server Address Option for DHCPv4}",
  howpublished="RFC 5859 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5859",
  pages="1--6",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5859.txt",
  key="RFC 5859",
  abstract={This memo documents existing usage for the ``TFTP Server Address'' option.  The option number currently in use is 150.  This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options.  The option is defined for DHCPv4 and works only with IPv4 addresses.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="voip",
  doi="10.17487/RFC5859",
  }

@misc{rfc5860,
  author="M. Vigoureux and D. Ward and M. Betts",
  title="{Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks}",
  howpublished="RFC 5860 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5860",
  pages="1--17",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5860.txt",
  key="RFC 5860",
  abstract={This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile.  These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]},
  keywords="MPLS-TP, OAM",
  doi="10.17487/RFC5860",
  }

@misc{rfc5861,
  author="M. Nottingham",
  title="{HTTP Cache-Control Extensions for Stale Content}",
  howpublished="RFC 5861 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5861",
  pages="1--6",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5861.txt",
  key="RFC 5861",
  abstract={This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5861",
  }

@misc{rfc5862,
  author="S. Yasukawa and A. Farrel",
  title="{Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE}",
  howpublished="RFC 5862 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5862",
  pages="1--11",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5862.txt",
  key="RFC 5862",
  abstract={The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, ``Path Computation Element (PCE) Communication Protocol Generic Requirements''. This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mpls, gmpls",
  doi="10.17487/RFC5862",
  }

@misc{rfc5863,
  author="T. Hansen and E. Siegel and P. Hallam-Baker and D. Crocker",
  title="{DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations}",
  howpublished="RFC 5863 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5863",
  pages="1--51",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5863.txt",
  key="RFC 5863",
  abstract={DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient.  The organization can be the author's, the originating sending site, an intermediary, or one of their agents.  A message can contain multiple signatures, from the same or different organizations involved with the message.  DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology.  This permits verification of a responsible organization, as well as the integrity of the message content.  DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.  DKIM's authentication of email identity can assist in the global control of ``spam'' and ``phishing''.  This document provides implementation, deployment, operational, and migration considerations for DKIM.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Email, Electronic Mail, Internet Mail, Message Verification",
  doi="10.17487/RFC5863",
  }

@misc{rfc5864,
  author="R. Allbery",
  title="{DNS SRV Resource Records for AFS}",
  howpublished="RFC 5864 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5864",
  pages="1--10",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5864.txt",
  key="RFC 5864",
  abstract={This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS.  It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]},
  keywords="domain name system, srv rr, distributed file system, afsdb rr",
  doi="10.17487/RFC5864",
  }

@misc{rfc5865,
  author="F. Baker and J. Polk and M. Dolly",
  title="{A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic}",
  howpublished="RFC 5865 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5865",
  pages="1--14",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5865.txt",
  key="RFC 5865",
  abstract={This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic.  This traffic class conforms to the Expedited Forwarding Per-Hop Behavior.  This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission.  This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]},
  keywords="real-time traffic",
  doi="10.17487/RFC5865",
  }

@misc{rfc5866,
  author="D. Sun and P. McCann and H. Tschofenig and T. Tsou and A. Doria and G. Zorn",
  title="{Diameter Quality-of-Service Application}",
  howpublished="RFC 5866 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5866",
  pages="1--51",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5866.txt",
  key="RFC 5866",
  abstract={This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application.  The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network.  In particular, two modes of operation, namely ``Pull'' and ``Push'', are defined. [STANDARDS TRACK]},
  keywords="Diameter, AAA, QoS, Policy, VoIP, SIP",
  doi="10.17487/RFC5866",
  }

@misc{rfc5867,
  author="J. Martocci and P. De Mil and N. Riou and W. Vermeylen",
  title="{Building Automation Routing Requirements in Low-Power and Lossy Networks}",
  howpublished="RFC 5867 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5867",
  pages="1--26",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5867.txt",
  key="RFC 5867",
  abstract={The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks.  Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5867",
  }

@misc{rfc5868,
  author="S. Sakane and K. Kamada and S. Zrelli and M. Ishiyama",
  title="{Problem Statement on the Cross-Realm Operation of Kerberos}",
  howpublished="RFC 5868 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5868",
  pages="1--13",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5868.txt",
  key="RFC 5868",
  abstract={This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120. This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5868",
  }

@misc{rfc5869,
  author="H. Krawczyk and P. Eronen",
  title="{HMAC-based Extract-and-Expand Key Derivation Function (HKDF)}",
  howpublished="RFC 5869 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5869",
  pages="1--14",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5869.txt",
  key="RFC 5869",
  abstract={This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5869",
  }

@misc{rfc5870,
  author="A. Mayrhofer and C. Spanring",
  title="{A Uniform Resource Identifier for Geographic Locations ('geo' URI)}",
  howpublished="RFC 5870 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5870",
  pages="1--23",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5870.txt",
  key="RFC 5870",
  abstract={This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name.  A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way.  The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]},
  keywords="geography, geo, uri, scheme",
  doi="10.17487/RFC5870",
  }

@misc{rfc5871,
  author="J. Arkko and S. Bradner",
  title="{IANA Allocation Guidelines for the IPv6 Routing Header}",
  howpublished="RFC 5871 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5871",
  pages="1--3",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5871.txt",
  key="RFC 5871",
  abstract={This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]},
  keywords="routing type field",
  doi="10.17487/RFC5871",
  }

@misc{rfc5872,
  author="J. Arkko and A. Yegin",
  title="{IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)}",
  howpublished="RFC 5872 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5872",
  pages="1--5",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5872.txt",
  key="RFC 5872",
  abstract={This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5872",
  }

@misc{rfc5873,
  author="Y. Ohba and A. Yegin",
  title="{Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)}",
  howpublished="RFC 5873 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5873",
  pages="1--8",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5873.txt",
  key="RFC 5873",
  abstract={This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move.  This document defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC5873",
  }

@misc{rfc5874,
  author="J. Rosenberg and J. Urpalainen",
  title="{An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources}",
  howpublished="RFC 5874 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5874",
  pages="1--24",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5874.txt",
  key="RFC 5874",
  abstract={This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP).  This format reports which document has changed and its former and new entity tags.  It can report the differences between versions of the document, using an XML patch format.  It can report existing element and attribute content when versions of an XCAP server document change.  XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]},
  keywords="SIP, Instant Messaging",
  doi="10.17487/RFC5874",
  }

@misc{rfc5875,
  author="J. Urpalainen and D. Willis",
  title="{An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package}",
  howpublished="RFC 5875 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5875",
  pages="1--27",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5875.txt",
  key="RFC 5875",
  abstract={This document describes an ``xcap-diff'' SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources.  The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]},
  keywords="xcap-diff, xcap diff",
  doi="10.17487/RFC5875",
  }

@misc{rfc5876,
  author="J. Elwell",
  title="{Updates to Asserted Identity in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5876 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5876",
  pages="1--11",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5876.txt",
  key="RFC 5876",
  abstract={The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields.  These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method.  However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields.  This document extends RFC 3325 to cover these situations.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SIP, P-Asserted-Identity",
  doi="10.17487/RFC5876",
  }

@misc{rfc5877,
  author="R. Housley",
  title="{The application/pkix-attr-cert Media Type for Attribute Certificates}",
  howpublished="RFC 5877 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5877",
  pages="1--4",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5877.txt",
  key="RFC 5877",
  abstract={This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5877",
  }

@misc{rfc5878,
  author="M. Brown and R. Housley",
  title="{Transport Layer Security (TLS) Authorization Extensions}",
  howpublished="RFC 5878 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5878",
  pages="1--19",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5878.txt",
  key="RFC 5878",
  abstract={This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol.  Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message.  This document defines an Experimental Protocol for the Internet community.},
  keywords="handshake protocol",
  doi="10.17487/RFC5878",
  }

@misc{rfc5879,
  author="T. Kivinen and D. McDonald",
  title="{Heuristics for Detecting ESP-NULL Packets}",
  howpublished="RFC 5879 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5879",
  pages="1--32",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5879.txt",
  key="RFC 5879",
  abstract={This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets.  These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected.  Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPsec, Wrapped ESP (WESP), deep-inspection, packet inspection",
  doi="10.17487/RFC5879",
  }

@misc{rfc5880,
  author="D. Katz and D. Ward",
  title="{Bidirectional Forwarding Detection (BFD)}",
  howpublished="RFC 5880 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5880",
  pages="1--49",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7419, 7880",
url="https://www.rfc-editor.org/rfc/rfc5880.txt",
  key="RFC 5880",
  abstract={This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency.  It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5880",
  }

@misc{rfc5881,
  author="D. Katz and D. Ward",
  title="{Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)}",
  howpublished="RFC 5881 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5881",
  pages="1--7",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5881.txt",
  key="RFC 5881",
  abstract={This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5881",
  }

@misc{rfc5882,
  author="D. Katz and D. Ward",
  title="{Generic Application of Bidirectional Forwarding Detection (BFD)}",
  howpublished="RFC 5882 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5882",
  pages="1--17",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5882.txt",
  key="RFC 5882",
  abstract={This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5882",
  }

@misc{rfc5883,
  author="D. Katz and D. Ward",
  title="{Bidirectional Forwarding Detection (BFD) for Multihop Paths}",
  howpublished="RFC 5883 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5883",
  pages="1--6",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5883.txt",
  key="RFC 5883",
  abstract={This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5883",
  }

@misc{rfc5884,
  author="R. Aggarwal and K. Kompella and T. Nadeau and G. Swallow",
  title="{Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)}",
  howpublished="RFC 5884 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5884",
  pages="1--12",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7726",
url="https://www.rfc-editor.org/rfc/rfc5884.txt",
  key="RFC 5884",
  abstract={One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure.  LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane.  BFD can be used for the former, but not for the latter.  However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages.  A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs.  This document describes the applicability of BFD in relation to LSP Ping for this application.  It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]},
  keywords="Multiprotocol Label Switching, lsp ping",
  doi="10.17487/RFC5884",
  }

@misc{rfc5885,
  author="T. Nadeau and C. Pignataro",
  title="{Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)}",
  howpublished="RFC 5885 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5885",
  pages="1--14",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6478, 7885",
url="https://www.rfc-editor.org/rfc/rfc5885.txt",
  key="RFC 5885",
  abstract={This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV).  VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]},
  keywords="Pseudowire, VCCV, BFD, VCCV-BFD, PW OAM",
  doi="10.17487/RFC5885",
  }

@misc{rfc5886,
  author="JP. Vasseur and JL. Le Roux and Y. Ikejiri",
  title="{A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture}",
  howpublished="RFC 5886 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5886",
  pages="1--26",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5886.txt",
  key="RFC 5886",
  abstract={A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a ``path computation chain''. In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]},
  doi="10.17487/RFC5886",
  }

@misc{rfc5887,
  author="B. Carpenter and R. Atkinson and H. Flinck",
  title="{Renumbering Still Needs Work}",
  howpublished="RFC 5887 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5887",
  pages="1--35",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5887.txt",
  key="RFC 5887",
  abstract={This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms.  It also summarises current technical proposals for additional mechanisms.  Finally, there is a gap analysis identifying possible areas for future work.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5887",
  }

@misc{rfc5888,
  author="G. Camarillo and H. Schulzrinne",
  title="{The Session Description Protocol (SDP) Grouping Framework}",
  howpublished="RFC 5888 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5888",
  pages="1--21",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5888.txt",
  key="RFC 5888",
  abstract={In this specification, we define a framework to group ``m'' lines in the Session Description Protocol (SDP) for different purposes.  This framework uses the ``group'' and ``mid'' SDP attributes, both of which are defined in this specification.  Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses.  This document obsoletes RFC 3388. [STANDARDS-TRACK]},
  keywords="SDP, grouping, SIP",
  doi="10.17487/RFC5888",
  }

@misc{rfc5889,
  author="E. Baccelli and M. Townsley",
  title="{IP Addressing Model in Ad Hoc Networks}",
  howpublished="RFC 5889 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5889",
  pages="1--8",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5889.txt",
  key="RFC 5889",
  abstract={This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mobile network, ad hoc network, MANET, network architecture, addressing framework, configuration, routing, IP networks",
  doi="10.17487/RFC5889",
  }

@misc{rfc5890,
  author="J. Klensin",
  title="{Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework}",
  howpublished="RFC 5890 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5890",
  pages="1--23",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5890.txt",
  key="RFC 5890",
  abstract={This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]},
  keywords="IDNA2008, idn, ascii, characters",
  doi="10.17487/RFC5890",
  }

@misc{rfc5891,
  author="J. Klensin",
  title="{Internationalized Domain Names in Applications (IDNA): Protocol}",
  howpublished="RFC 5891 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5891",
  pages="1--17",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5891.txt",
  key="RFC 5891",
  abstract={This document is the revised protocol definition for Internationalized Domain Names (IDNs).  The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents.  This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself.  IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]},
  keywords="IDNA2008, idn, ascii, characters, idna applications",
  doi="10.17487/RFC5891",
  }

@misc{rfc5892,
  author="P. Faltstrom",
  title="{The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)}",
  howpublished="RFC 5892 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5892",
  pages="1--70",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5892.txt",
  key="RFC 5892",
  abstract={This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]},
  keywords="IDNA, DNS, IDN, Unicode, IDNA2008",
  doi="10.17487/RFC5892",
  }

@misc{rfc5893,
  author="H. Alvestrand and C. Karp",
  title="{Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)}",
  howpublished="RFC 5893 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5893",
  pages="1--17",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5893.txt",
  key="RFC 5893",
  abstract={The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges.  This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]},
  keywords="IDNA2008, idn, ascii, characters, Bidi",
  doi="10.17487/RFC5893",
  }

@misc{rfc5894,
  author="J. Klensin",
  title="{Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale}",
  howpublished="RFC 5894 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5894",
  pages="1--43",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5894.txt",
  key="RFC 5894",
  abstract={Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed.  During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode.  Some of these issues require tuning of the existing protocols and the tables on which they depend.  This document provides an overview of a revised system and provides explanatory material for its components.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IDNA2008, idn, ascii, characters",
  doi="10.17487/RFC5894",
  }

@misc{rfc5895,
  author="P. Resnick and P. Hoffman",
  title="{Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008}",
  howpublished="RFC 5895 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5895",
  pages="1--7",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5895.txt",
  key="RFC 5895",
  abstract={In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that ``made sense'', and then encoded and passed to the domain name system (DNS).  The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of ``permitted'' code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input.  This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="user input, character mapping, locale, user interface, Unicode",
  doi="10.17487/RFC5895",
  }

@misc{rfc5896,
  author="L. Hornquist Astrand and S. Hartman",
  title="{Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy}",
  howpublished="RFC 5896 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5896",
  pages="1--6",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5896.txt",
  key="RFC 5896",
  abstract={Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers.  In effect, the server acts as an agent on behalf of the user.  Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers.  However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint.  Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation.  This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5896",
  }

@misc{rfc5897,
  author="J. Rosenberg",
  title="{Identification of Communications Services in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5897 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5897",
  pages="1--23",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5897.txt",
  key="RFC 5897",
  abstract={This document considers the problem of service identification in the Session Initiation Protocol (SIP).  Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA).  This document discusses the uses of service identification, and outlines several architectural principles behind the process.  It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation.  It then outlines a set of recommended practices for service identification.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="service identification",
  doi="10.17487/RFC5897",
  }

@misc{rfc5898,
  author="F. Andreasen and G. Camarillo and D. Oran and D. Wing",
  title="{Connectivity Preconditions for Session Description Protocol (SDP) Media Streams}",
  howpublished="RFC 5898 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5898",
  pages="1--17",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5898.txt",
  key="RFC 5898",
  abstract={This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework.  A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified.  The method of verification may vary depending on the type of transport used for the media.  For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets.  For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]},
  keywords="SIP, preconditions, connection, connectivity",
  doi="10.17487/RFC5898",
  }

@misc{rfc5901,
  author="P. Cain and D. Jevans",
  title="{Extensions to the IODEF-Document Class for Reporting Phishing}",
  howpublished="RFC 5901 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5901",
  pages="1--51",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5901.txt",
  key="RFC 5901",
  abstract={This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud.  These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site.  Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]},
  keywords="Incident Object Description Exchange Format",
  doi="10.17487/RFC5901",
  }

@misc{rfc5902,
  author="D. Thaler and L. Zhang and G. Lebovitz",
  title="{IAB Thoughts on IPv6 Network Address Translation}",
  howpublished="RFC 5902 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5902",
  pages="1--15",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5902.txt",
  key="RFC 5902",
  abstract={There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs).  This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="NAT, IPv6, Transparency, End-to-End, Privacy, Multihoming",
  doi="10.17487/RFC5902",
  }

@misc{rfc5903,
  author="D. Fu and J. Solinas",
  title="{Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2}",
  howpublished="RFC 5903 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5903",
  pages="1--16",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5903.txt",
  key="RFC 5903",
  abstract={This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.  These groups are based on modular arithmetic rather than binary arithmetic.  These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards.  In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups.  This document obsoletes RFC 4753.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Elliptic Curve Cryptography, ECC, Internet Key Exchange, elliptic curve, Diffie-Hellman, suite b, nist curve",
  doi="10.17487/RFC5903",
  }

@misc{rfc5904,
  author="G. Zorn",
  title="{RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support}",
  howpublished="RFC 5904 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5904",
  pages="1--15",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5904.txt",
  key="RFC 5904",
  abstract={This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RADIUS, AAA, IEEE, 802.16",
  doi="10.17487/RFC5904",
  }

@misc{rfc5905,
  author="D. Mills and J. Martin and J. Burbank and W. Kasch",
  title="{Network Time Protocol Version 4: Protocol and Algorithms Specification}",
  howpublished="RFC 5905 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5905",
  pages="1--110",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7822",
url="https://www.rfc-editor.org/rfc/rfc5905.txt",
  key="RFC 5905",
  abstract={The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet.  This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.  NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family.  NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs.  It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required.  It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]},
  keywords="NTP, SNTP, Synchronization",
  doi="10.17487/RFC5905",
  }

@misc{rfc5906,
  author="B. Haberman and D. Mills",
  title="{Network Time Protocol Version 4: Autokey Specification}",
  howpublished="RFC 5906 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5906",
  pages="1--58",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5906.txt",
  key="RFC 5906",
  abstract={This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ntp, ntpv4, public key cryptography",
  doi="10.17487/RFC5906",
  }

@misc{rfc5907,
  author="H. Gerstung and C. Elliott and B. Haberman",
  title="{Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)}",
  howpublished="RFC 5907 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5907",
  pages="1--26",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5907.txt",
  key="RFC 5907",
  abstract={The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment.  As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent.  This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5907",
  }

@misc{rfc5908,
  author="R. Gayraud and B. Lourdelet",
  title="{Network Time Protocol (NTP) Server Option for DHCPv6}",
  howpublished="RFC 5908 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5908",
  pages="1--9",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5908.txt",
  key="RFC 5908",
  abstract={The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]},
  keywords="Dynamic Host Configuration Protocol for IPv6",
  doi="10.17487/RFC5908",
  }

@misc{rfc5909,
  author="J-M. Combes and S. Krishnan and G. Daley",
  title="{Securing Neighbor Discovery Proxy: Problem Statement}",
  howpublished="RFC 5909 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5909",
  pages="1--22",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5909.txt",
  key="RFC 5909",
  abstract={Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages. Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="send, secure neighbor discovery",
  doi="10.17487/RFC5909",
  }

@misc{rfc5910,
  author="J. Gould and S. Hollenbeck",
  title="{Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)}",
  howpublished="RFC 5910 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5910",
  pages="1--36",
  year=2010,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5910.txt",
  key="RFC 5910",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.  This document obsoletes RFC 4310. [STANDARDS-TRACK]},
  keywords="epp, Extensible Provisioning Protocol, xml, dns, security, dnssec, delegation signer, ds",
  doi="10.17487/RFC5910",
  }

@misc{rfc5911,
  author="P. Hoffman and J. Schaad",
  title="{New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME}",
  howpublished="RFC 5911 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5911",
  pages="1--59",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6268",
url="https://www.rfc-editor.org/rfc/rfc5911.txt",
  key="RFC 5911",
  abstract={The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="S/MIME, PKIX, ASN.1 modules",
  doi="10.17487/RFC5911",
  }

@misc{rfc5912,
  author="P. Hoffman and J. Schaad",
  title="{New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)}",
  howpublished="RFC 5912 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5912",
  pages="1--117",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6960",
url="https://www.rfc-editor.org/rfc/rfc5912.txt",
  key="RFC 5912",
  abstract={The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="S/MIME, PKIX, ASN.1 modules",
  doi="10.17487/RFC5912",
  }

@misc{rfc5913,
  author="S. Turner and S. Chokhani",
  title="{Clearance Attribute and Authority Clearance Constraints Certificate Extension}",
  howpublished="RFC 5913 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5913",
  pages="1--19",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5913.txt",
  key="RFC 5913",
  abstract={This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates.  The Clearance attribute is used to indicate the clearance held by the subject.  The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.  The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]},
  keywords="x.509 certificate",
  doi="10.17487/RFC5913",
  }

@misc{rfc5914,
  author="R. Housley and S. Ashmore and C. Wallace",
  title="{Trust Anchor Format}",
  howpublished="RFC 5914 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5914",
  pages="1--14",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5914.txt",
  key="RFC 5914",
  abstract={This document describes a structure for representing trust anchor information.  A trust anchor is an authoritative entity represented by a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative.  The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]},
  keywords="trust anchor management",
  doi="10.17487/RFC5914",
  }

@misc{rfc5915,
  author="S. Turner and D. Brown",
  title="{Elliptic Curve Private Key Structure}",
  howpublished="RFC 5915 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5915",
  pages="1--7",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5915.txt",
  key="RFC 5915",
  abstract={This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information.  The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ec, Standards for Efficient Cryptography Group, SECG",
  doi="10.17487/RFC5915",
  }

@misc{rfc5916,
  author="S. Turner",
  title="{Device Owner Attribute}",
  howpublished="RFC 5916 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5916",
  pages="1--6",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5916.txt",
  key="RFC 5916",
  abstract={This document defines the Device Owner attribute.  It indicates the entity (e.g., company, organization, department, agency) that owns the device.  This attribute may be included in public key certificates and attribute certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5916",
  }

@misc{rfc5917,
  author="S. Turner",
  title="{Clearance Sponsor Attribute}",
  howpublished="RFC 5917 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5917",
  pages="1--7",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5917.txt",
  key="RFC 5917",
  abstract={This document defines the clearance sponsor attribute.  It indicates the entity that sponsored (i.e., granted) the clearance.  This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5917",
  }

@misc{rfc5918,
  author="R. Asati and I. Minei and B. Thomas",
  title="{Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)}",
  howpublished="RFC 5918 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5918",
  pages="1--10",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7358",
url="https://www.rfc-editor.org/rfc/rfc5918.txt",
  key="RFC 5918",
  abstract={The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations.  This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures.  In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]},
  keywords="Wildcard, Typed Wildcard FEC Element, Typed Wildcard FEC Capability",
  doi="10.17487/RFC5918",
  }

@misc{rfc5919,
  author="R. Asati and P. Mohapatra and E. Chen and B. Thomas",
  title="{Signaling LDP Label Advertisement Completion}",
  howpublished="RFC 5919 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5919",
  pages="1--9",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5919.txt",
  key="RFC 5919",
  abstract={There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels.  The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer.  This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]},
  keywords="label distribution protocol, End-of-LIB, Unrecognized Notification",
  doi="10.17487/RFC5919",
  }

@misc{rfc5920,
  author="L. Fang",
  title="{Security Framework for MPLS and GMPLS Networks}",
  howpublished="RFC 5920 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5920",
  pages="1--66",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5920.txt",
  key="RFC 5920",
  abstract={This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks.  This document addresses the security aspects that are relevant in the context of MPLS and GMPLS.  It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting.  This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5920",
  }

@misc{rfc5921,
  author="M. Bocci and S. Bryant and D. Frost and L. Levrau and L. Berger",
  title="{A Framework for MPLS in Transport Networks}",
  howpublished="RFC 5921 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5921",
  pages="1--56",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6215, 7274",
url="https://www.rfc-editor.org/rfc/rfc5921.txt",
  key="RFC 5921",
  abstract={This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="multiprotocol label switching, mpls-tp, transport profile, oam, itu-t",
  doi="10.17487/RFC5921",
  }

@misc{rfc5922,
  author="V. Gurbani and S. Lawrence and A. Jeffrey",
  title="{Domain Certificates in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5922 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5922",
  pages="1--17",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5922.txt",
  key="RFC 5922",
  abstract={This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection.  More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication.  As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]},
  keywords="PKIX, Authentication, Mutual Authentication, X.509, TLS",
  doi="10.17487/RFC5922",
  }

@misc{rfc5923,
  author="V. Gurbani and R. Mahy and B. Tate",
  title="{Connection Reuse in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5923 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5923",
  pages="1--19",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5923.txt",
  key="RFC 5923",
  abstract={This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction.  Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS).  For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP).  This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]},
  keywords="TCP Connection, SCTP Connection, TLS Connection, Transport Connection, TLS, Virtual Server, Authentication",
  doi="10.17487/RFC5923",
  }

@misc{rfc5924,
  author="S. Lawrence and V. Gurbani",
  title="{Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates}",
  howpublished="RFC 5924 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5924",
  pages="1--8",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5924.txt",
  key="RFC 5924",
  abstract={This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service.  As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PKIX, SIP Domain, X.509 Certificate",
  doi="10.17487/RFC5924",
  }

@misc{rfc5925,
  author="J. Touch and A. Mankin and R. Bonica",
  title="{The TCP Authentication Option}",
  howpublished="RFC 5925 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5925",
  pages="1--48",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5925.txt",
  key="RFC 5925",
  abstract={This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5).  TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5.  TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints.  The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes.  TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously.  TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]},
  keywords="transmission control protocol, border, gateway, protocol, transmission control message, digest, algorithm",
  doi="10.17487/RFC5925",
  }

@misc{rfc5926,
  author="G. Lebovitz and E. Rescorla",
  title="{Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)}",
  howpublished="RFC 5926 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5926",
  pages="1--15",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5926.txt",
  key="RFC 5926",
  abstract={The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points.  There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms.  This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]},
  keywords="transmission control protocol",
  doi="10.17487/RFC5926",
  }

@misc{rfc5927,
  author="F. Gont",
  title="{ICMP Attacks against TCP}",
  howpublished="RFC 5927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5927",
  pages="1--36",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5927.txt",
  key="RFC 5927",
  abstract={This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP).  Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="vulnerability, blind attacks, connection-reset attack, performance-degrading attack, throughput-reduction attack, source quench, PMTUD, Path-MTU Discovery, ICMP Destination Unreachable",
  doi="10.17487/RFC5927",
  }

@misc{rfc5928,
  author="M. Petit-Huguenin",
  title="{Traversal Using Relays around NAT (TURN) Resolution Mechanism}",
  howpublished="RFC 5928 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5928",
  pages="1--11",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7350",
url="https://www.rfc-editor.org/rfc/rfc5928.txt",
  key="RFC 5928",
  abstract={This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]},
  keywords="NAT, Traversal",
  doi="10.17487/RFC5928",
  }

@misc{rfc5929,
  author="J. Altman and N. Williams and L. Zhu",
  title="{Channel Bindings for TLS}",
  howpublished="RFC 5929 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5929",
  pages="1--15",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5929.txt",
  key="RFC 5929",
  abstract={This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]},
  keywords="TLS, channel, binding, channel-binding, tls-unique, tls-server-end-point, tls-unique-for-telnet",
  doi="10.17487/RFC5929",
  }

@misc{rfc5930,
  author="S. Shen and Y. Mao and NSS. Murthy",
  title="{Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol}",
  howpublished="RFC 5930 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5930",
  pages="1--6",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5930.txt",
  key="RFC 5930",
  abstract={This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE\_SA\_INIT exchange.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="initialization vector, IKE\_SA\_INIT",
  doi="10.17487/RFC5930",
  }

@misc{rfc5931,
  author="D. Harkins and G. Zorn",
  title="{Extensible Authentication Protocol (EAP) Authentication Using Only a Password}",
  howpublished="RFC 5931 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5931",
  pages="1--40",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8146",
url="https://www.rfc-editor.org/rfc/rfc5931.txt",
  key="RFC 5931",
  abstract={This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.  The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker.  The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Password Authenticated Key Exchange, Dictionary Attack, Authentication EAP",
  doi="10.17487/RFC5931",
  }

@misc{rfc5932,
  author="A. Kato and M. Kanda and S. Kanno",
  title="{Camellia Cipher Suites for TLS}",
  howpublished="RFC 5932 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5932",
  pages="1--6",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5932.txt",
  key="RFC 5932",
  abstract={This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.  It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family.  This document obsoletes RFC 4132. [STANDARDS-TRACK]},
  keywords="block cipher, security, camellia, tls, cbc, sha2, camellia encryption algorithm",
  doi="10.17487/RFC5932",
  }

@misc{rfc5933,
  author="V. Dolmatov and A. Chuprina and I. Ustinov",
  title="{Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC}",
  howpublished="RFC 5933 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5933",
  pages="1--9",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6944",
url="https://www.rfc-editor.org/rfc/rfc5933.txt",
  key="RFC 5933",
  abstract={This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK]},
  keywords="domain name system security extensions, ECC",
  doi="10.17487/RFC5933",
  }

@misc{rfc5934,
  author="R. Housley and S. Ashmore and C. Wallace",
  title="{Trust Anchor Management Protocol (TAMP)}",
  howpublished="RFC 5934 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5934",
  pages="1--91",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5934.txt",
  key="RFC 5934",
  abstract={This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store.  The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication.  The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]},
  keywords="trust anchors, TA",
  doi="10.17487/RFC5934",
  }

@misc{rfc5935,
  author="M. Ellison and B. Natale",
  title="{Expressing SNMP SMI Datatypes in XML Schema Definition Language}",
  howpublished="RFC 5935 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5935",
  pages="1--14",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5935.txt",
  key="RFC 5935",
  abstract={This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language.  The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]},
  keywords="structure of management information",
  doi="10.17487/RFC5935",
  }

@misc{rfc5936,
  author="E. Lewis and A. Hoenes",
  title="{DNS Zone Transfer Protocol (AXFR)}",
  howpublished="RFC 5936 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5936",
  pages="1--29",
  year=2010,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5936.txt",
  key="RFC 5936",
  abstract={The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]},
  keywords="authoritative transfer, AXFR mechanism",
  doi="10.17487/RFC5936",
  }

@misc{rfc5937,
  author="S. Ashmore and C. Wallace",
  title="{Using Trust Anchor Constraints during Certification Path Processing}",
  howpublished="RFC 5937 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5937",
  pages="1--8",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5937.txt",
  key="RFC 5937",
  abstract={This document describes how to use information associated with a trust anchor public key when validating certification paths.  This information can be used to constrain the usage of a trust anchor.  Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="TA",
  doi="10.17487/RFC5937",
  }

@misc{rfc5938,
  author="A. Morton and M. Chiba",
  title="{Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 5938 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5938",
  pages="1--17",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5938.txt",
  key="RFC 5938",
  abstract={The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol.  This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers.  The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5938",
  }

@misc{rfc5939,
  author="F. Andreasen",
  title="{Session Description Protocol (SDP) Capability Negotiation}",
  howpublished="RFC 5939 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5939",
  pages="1--77",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6871",
url="https://www.rfc-editor.org/rfc/rfc5939.txt",
  key="RFC 5939",
  abstract={The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]},
  keywords="multimedia session, session announcement, session invitation",
  doi="10.17487/RFC5939",
  }

@misc{rfc5940,
  author="S. Turner and R. Housley",
  title="{Additional Cryptographic Message Syntax (CMS) Revocation Information Choices}",
  howpublished="RFC 5940 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5940",
  pages="1--9",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5940.txt",
  key="RFC 5940",
  abstract={The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types.  The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats.  This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]},
  keywords="online certificate status protocol, ocsp, server-based certificate validation protocol, scvp",
  doi="10.17487/RFC5940",
  }

@misc{rfc5941,
  author="D. M'Raihi and S. Boeyen and M. Grandcolas and S. Bajaj",
  title="{Sharing Transaction Fraud Data}",
  howpublished="RFC 5941 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5941",
  pages="1--27",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5941.txt",
  key="RFC 5941",
  abstract={This document describes a document format for exchanging transaction fraud (Thraud) information.  It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="thraud, incident object description exchange format, iodef",
  doi="10.17487/RFC5941",
  }

@misc{rfc5942,
  author="H. Singh and W. Beebee and E. Nordmark",
  title="{IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes}",
  howpublished="RFC 5942 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5942",
  pages="1--11",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5942.txt",
  key="RFC 5942",
  abstract={IPv6 specifies a model of a subnet that is different than the IPv4 subnet model.  The subtlety of the differences has resulted in incorrect implementations that do not interoperate.  This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix.  This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of ``on-link'' from RFC 4861. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5942",
  }

@misc{rfc5943,
  author="B. Haberman",
  title="{A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing}",
  howpublished="RFC 5943 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5943",
  pages="1--4",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5943.txt",
  key="RFC 5943",
  abstract={The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document.  In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5943",
  }

@misc{rfc5944,
  author="C. Perkins",
  title="{IP Mobility Support for IPv4, Revised}",
  howpublished="RFC 5944 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5944",
  pages="1--100",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5944.txt",
  key="RFC 5944",
  abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet.  The protocol provides for registering the care-of address with a home agent.  The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address.  After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]},
  keywords="MOBILEIPSUPIP, Internet Protocol, MIPv4",
  doi="10.17487/RFC5944",
  }

@misc{rfc5945,
  author="F. Le Faucheur and J. Manner and D. Wing and A. Guillou",
  title="{Resource Reservation Protocol (RSVP) Proxy Approaches}",
  howpublished="RFC 5945 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5945",
  pages="1--50",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5945.txt",
  key="RFC 5945",
  abstract={The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows.  RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling.  Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.  This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable.  This allows resource reservations to be established on a critical subset of the end-to-end path.  This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP.  This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach.  However, such extensions are outside the scope of this document.  Finally, practical use cases for RSVP proxy are described.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5945",
  }

@misc{rfc5946,
  author="F. Le Faucheur and J. Manner and A. Narayanan and A. Guillou and H. Malik",
  title="{Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy}",
  howpublished="RFC 5946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5946",
  pages="1--35",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5946.txt",
  key="RFC 5946",
  abstract={Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows.  With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling.  Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.  Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver.  This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy.  However, as discussed in the companion document ``RSVP Proxy Approaches'', RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender.  This document specifies these extensions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC5946",
  }

@misc{rfc5947,
  author="J. Elwell and H. Kaplan",
  title="{Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 5947 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5947",
  pages="1--13",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5947.txt",
  key="RFC 5947",
  abstract={This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs).  The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Trunking, pbx, private branch exchange",
  doi="10.17487/RFC5947",
  }

@misc{rfc5948,
  author="S. Madanapalli and S. Park and S. Chakrabarti and G. Montenegro",
  title="{Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16}",
  howpublished="RFC 5948 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5948",
  pages="1--13",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5948.txt",
  key="RFC 5948",
  abstract={IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer. This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]},
  keywords="packet cs",
  doi="10.17487/RFC5948",
  }

@misc{rfc5949,
  author="H. Yokota and K. Chowdhury and R. Koodli and B. Patil and F. Xia",
  title="{Fast Handovers for Proxy Mobile IPv6}",
  howpublished="RFC 5949 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5949",
  pages="1--32",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5949.txt",
  key="RFC 5949",
  abstract={Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6. When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]},
  keywords="PFMIPv6, handoff, PMIPv6, predictive, reactive",
  doi="10.17487/RFC5949",
  }

@misc{rfc5950,
  author="S. Mansfield and E. Gray and K. Lam",
  title="{Network Management Framework for MPLS-based Transport Networks}",
  howpublished="RFC 5950 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5950",
  pages="1--18",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5950.txt",
  key="RFC 5950",
  abstract={This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mpls-tp, network management framework",
  doi="10.17487/RFC5950",
  }

@misc{rfc5951,
  author="K. Lam and S. Mansfield and E. Gray",
  title="{Network Management Requirements for MPLS-based Transport Networks}",
  howpublished="RFC 5951 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5951",
  pages="1--24",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5951.txt",
  key="RFC 5951",
  abstract={This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP).  The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed.  That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP.  This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]},
  keywords="MPLS Transport Profile, mpls-tp",
  doi="10.17487/RFC5951",
  }

@misc{rfc5952,
  author="S. Kawamura and M. Kawashima",
  title="{A Recommendation for IPv6 Address Text Representation}",
  howpublished="RFC 5952 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5952",
  pages="1--14",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5952.txt",
  key="RFC 5952",
  abstract={As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text.  While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users.  This document defines a canonical textual representation format.  It does not define a format for internal storage, such as within an application or database.  It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]},
  keywords="IPv6, text representation, canonical",
  doi="10.17487/RFC5952",
  }

@misc{rfc5953,
  author="W. Hardaker",
  title="{Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 5953 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5953",
  pages="1--65",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6353",
url="https://www.rfc-editor.org/rfc/rfc5953.txt",
  key="RFC 5953",
  abstract={This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]},
  keywords="dtls, datagram transport layer security, tls transport model, tlstm, SNMP-TLS-TM-MIB",
  doi="10.17487/RFC5953",
  }

@misc{rfc5954,
  author="V. Gurbani and B. Carpenter and B. Tate",
  title="{Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261}",
  howpublished="RFC 5954 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5954",
  pages="1--7",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5954.txt",
  key="RFC 5954",
  abstract={This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261.  It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]},
  keywords="SIP, session initiation protocol, Augmented Backus-Naur Form, Uniform Resource Identifier, IPv6reference, IPv6address",
  doi="10.17487/RFC5954",
  }

@misc{rfc5955,
  author="A. Santoni",
  title="{The application/timestamped-data Media Type}",
  howpublished="RFC 5955 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5955",
  pages="1--3",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5955.txt",
  key="RFC 5955",
  abstract={This document defines a new media type for TimeStampedData envelopes as described in RFC 5544.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="TimeStampedData envelopes",
  doi="10.17487/RFC5955",
  }

@misc{rfc5956,
  author="A. Begen",
  title="{Forward Error Correction Grouping Semantics in the Session Description Protocol}",
  howpublished="RFC 5956 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5956",
  pages="1--14",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5956.txt",
  key="RFC 5956",
  abstract={This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP).  The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888).  These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows.  SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]},
  keywords="FEC, loss repair, grouping, sdp, media lines",
  doi="10.17487/RFC5956",
  }

@misc{rfc5957,
  author="D. Karp",
  title="{Display-Based Address Sorting for the IMAP4 SORT Extension}",
  howpublished="RFC 5957 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5957",
  pages="1--5",
  year=2010,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5957.txt",
  key="RFC 5957",
  abstract={This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]},
  keywords="Internet Message Access Protocol",
  doi="10.17487/RFC5957",
  }

@misc{rfc5958,
  author="S. Turner",
  title="{Asymmetric Key Packages}",
  howpublished="RFC 5958 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5958",
  pages="1--14",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5958.txt",
  key="RFC 5958",
  abstract={This document defines the syntax for private-key information and a content type for it.  Private-key information includes a private key for a specified public-key algorithm and a set of attributes.  The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type.  This document obsoletes RFC 5208. [STANDARDS-TRACK]},
  keywords="private key, private-key information, rsa laboratories, private-key syntax, change control",
  doi="10.17487/RFC5958",
  }

@misc{rfc5959,
  author="S. Turner",
  title="{Algorithms for Asymmetric Key Package Content Type}",
  howpublished="RFC 5959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5959",
  pages="1--7",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6162",
url="https://www.rfc-editor.org/rfc/rfc5959.txt",
  key="RFC 5959",
  abstract={This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958.  It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]},
  keywords="EncryptedPrivateKeyInfo, AsymmetricKeyPackage",
  doi="10.17487/RFC5959",
  }

@misc{rfc5960,
  author="D. Frost and S. Bryant and M. Bocci",
  title="{MPLS Transport Profile Data Plane Architecture}",
  howpublished="RFC 5960 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5960",
  pages="1--15",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc5960.txt",
  key="RFC 5960",
  abstract={The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]},
  keywords="mpls-tp, transport profile, itu-t, dataplane, gal, gach",
  doi="10.17487/RFC5960",
  }

@misc{rfc5961,
  author="A. Ramaiah and R. Stewart and M. Dalal",
  title="{Improving TCP's Robustness to Blind In-Window Attacks}",
  howpublished="RFC 5961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5961",
  pages="1--19",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5961.txt",
  key="RFC 5961",
  abstract={TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s).  A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]},
  keywords="RST, SYN, FIN, attack, Data Injection, vulnerability, blind attacks, BGP, spoof, mitigation",
  doi="10.17487/RFC5961",
  }

@misc{rfc5962,
  author="H. Schulzrinne and V. Singh and H. Tschofenig and M. Thomson",
  title="{Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)}",
  howpublished="RFC 5962 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5962",
  pages="1--11",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5962.txt",
  key="RFC 5962",
  abstract={The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity.  This document defines PIDF-LO extensions to convey information about moving objects.  Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]},
  keywords="PIDF-LO,location,dynamic,speed,velocity,orientation",
  doi="10.17487/RFC5962",
  }

@misc{rfc5963,
  author="R. Gagliano",
  title="{IPv6 Deployment in Internet Exchange Points (IXPs)}",
  howpublished="RFC 5963 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5963",
  pages="1--10",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5963.txt",
  key="RFC 5963",
  abstract={This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs).  It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed.  IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6, IXP, deployment, exchange",
  doi="10.17487/RFC5963",
  }

@misc{rfc5964,
  author="J. Winterbottom and M. Thomson",
  title="{Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries}",
  howpublished="RFC 5964 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5964",
  pages="1--11",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5964.txt",
  key="RFC 5964",
  abstract={This document describes how holes can be specified in geodetic service boundaries.  One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]},
  keywords="hole, polygon, pidf-lo, service boundary, location, LoST",
  doi="10.17487/RFC5964",
  }

@misc{rfc5965,
  author="Y. Shafranovich and J. Levine and M. Kucherawy",
  title="{An Extensible Format for Email Feedback Reports}",
  howpublished="RFC 5965 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5965",
  pages="1--25",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6650",
url="https://www.rfc-editor.org/rfc/rfc5965.txt",
  key="RFC 5965",
  abstract={This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties.  This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]},
  keywords="feedback-report",
  doi="10.17487/RFC5965",
  }

@misc{rfc5966,
  author="R. Bellis",
  title="{DNS Transport over TCP - Implementation Requirements}",
  howpublished="RFC 5966 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5966",
  pages="1--7",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7766",
url="https://www.rfc-editor.org/rfc/rfc5966.txt",
  key="RFC 5966",
  abstract={This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]},
  keywords="DNS, TCP/IP",
  doi="10.17487/RFC5966",
  }

@misc{rfc5967,
  author="S. Turner",
  title="{The application/pkcs10 Media Type}",
  howpublished="RFC 5967 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5967",
  pages="1--6",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5967.txt",
  key="RFC 5967",
  abstract={This document specifies a media type used to carry PKCS \#10 certification requests as defined in RFC 2986.  It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5967",
  }

@misc{rfc5968,
  author="J. Ott and C. Perkins",
  title="{Guidelines for Extending the RTP Control Protocol (RTCP)}",
  howpublished="RFC 5968 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5968",
  pages="1--17",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5968.txt",
  key="RFC 5968",
  abstract={The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers.  This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses.  The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses.  This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="real-time transport protocol",
  doi="10.17487/RFC5968",
  }

@misc{rfc5969,
  author="W. Townsley and O. Troan",
  title="{IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification}",
  howpublished="RFC 5969 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5969",
  pages="1--18",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5969.txt",
  key="RFC 5969",
  abstract={This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure.  Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]},
  keywords="6rd, Provider 6to4,  IPv6 softwire, IPv6 Transition, 6to4",
  doi="10.17487/RFC5969",
  }

@misc{rfc5970,
  author="T. Huth and J. Freimann and V. Zimmer and D. Thaler",
  title="{DHCPv6 Options for Network Boot}",
  howpublished="RFC 5970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5970",
  pages="1--11",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5970.txt",
  key="RFC 5970",
  abstract={The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network.  This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]},
  keywords="boot, IPv6, DHCPv6",
  doi="10.17487/RFC5970",
  }

@misc{rfc5971,
  author="H. Schulzrinne and R. Hancock",
  title="{GIST: General Internet Signalling Transport}",
  howpublished="RFC 5971 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5971",
  pages="1--154",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5971.txt",
  key="RFC 5971",
  abstract={This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network.  The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications.  GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path.  The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the ``Next Steps in Signalling'' (NSIS) framework.  This document defines an Experimental Protocol for the Internet community.},
  keywords="nsis, next steps in signaling",
  doi="10.17487/RFC5971",
  }

@misc{rfc5972,
  author="T. Tsenov and H. Tschofenig and X. Fu and C. Aoun and E. Davies",
  title="{General Internet Signaling Transport (GIST) State Machine}",
  howpublished="RFC 5972 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5972",
  pages="1--27",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5972.txt",
  key="RFC 5972",
  doi="10.17487/RFC5972",
  }

@misc{rfc5973,
  author="M. Stiemerling and H. Tschofenig and C. Aoun and E. Davies",
  title="{NAT/Firewall NSIS Signaling Layer Protocol (NSLP)}",
  howpublished="RFC 5973 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5973",
  pages="1--90",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5973.txt",
  key="RFC 5973",
  abstract={This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls.  This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows.  For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic.  The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group.  The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Next Steps in Signaling, NSIS, Path-coupled signaling, Middlebox",
  doi="10.17487/RFC5973",
  }

@misc{rfc5974,
  author="J. Manner and G. Karagiannis and A. McDonald",
  title="{NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling}",
  howpublished="RFC 5974 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5974",
  pages="1--102",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5974.txt",
  key="RFC 5974",
  abstract={This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.  It is in accordance with the framework and requirements developed in NSIS.  Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it.  The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models.  It is simplified by the elimination of support for multicast flows.  This specification explains the overall protocol approach, describes the design decisions made, and provides examples.  It specifies object, message formats, and processing rules.  This document defines an Experimental Protocol for the Internet community.},
  keywords="QoS",
  doi="10.17487/RFC5974",
  }

@misc{rfc5975,
  author="G. Ash and A. Bader and C. Kappler and D. Oran",
  title="{QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)}",
  howpublished="RFC 5975 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5975",
  pages="1--64",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5975.txt",
  key="RFC 5975",
  abstract={The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv.  Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.  This document defines a template for the QSPEC including a number of QSPEC parameters.  The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP.  While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models.  The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC5975",
  }

@misc{rfc5976,
  author="G. Ash and A. Morton and M. Dolly and P. Tarapore and C. Dvorak and Y. El Mghazli",
  title="{Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes}",
  howpublished="RFC 5976 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5976",
  pages="1--19",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5976.txt",
  key="RFC 5976",
  abstract={This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling.  Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.  This document defines an Experimental Protocol for the Internet community.},
  keywords="qos-nslp, qos-nslp quality-of-service model, qspec",
  doi="10.17487/RFC5976",
  }

@misc{rfc5977,
  author="A. Bader and L. Westberg and G. Karagiannis and C. Kappler and T. Phelan",
  title="{RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv}",
  howpublished="RFC 5977 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5977",
  pages="1--128",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5977.txt",
  key="RFC 5977",
  abstract={This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept.  RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks.  The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network.  The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow.  Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.  In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.  This document defines an Experimental Protocol for the Internet community.},
  keywords="next steps in signaling, resource managment in diffserv",
  doi="10.17487/RFC5977",
  }

@misc{rfc5978,
  author="J. Manner and R. Bless and J. Loughney and E. Davies",
  title="{Using and Extending the NSIS Protocol Family}",
  howpublished="RFC 5978 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5978",
  pages="1--30",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5978.txt",
  key="RFC 5978",
  abstract={This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010.  It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Signaling, NTLP, NSLP, GIST, QoS NSLP, NAT/Firewall, NSLP, IP resources, Extensibility",
  doi="10.17487/RFC5978",
  }

@misc{rfc5979,
  author="C. Shen and H. Schulzrinne and S. Lee and J. Bang",
  title="{NSIS Operation over IP Tunnels}",
  howpublished="RFC 5979 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5979",
  pages="1--27",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5979.txt",
  key="RFC 5979",
  abstract={NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path.  When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments.  Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path.  The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields.  Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets.  This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.  This document defines an Experimental Protocol for the Internet community.},
  keywords="nsis qos, next steps in signaling",
  doi="10.17487/RFC5979",
  }

@misc{rfc5980,
  author="T. Sanda and X. Fu and S. Jeong and J. Manner and H. Tschofenig",
  title="{NSIS Protocol Operation in Mobile Environments}",
  howpublished="RFC 5980 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5980",
  pages="1--32",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5980.txt",
  key="RFC 5980",
  abstract={Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management.  This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC5980",
  }

@misc{rfc5981,
  author="J. Manner and M. Stiemerling and H. Tschofenig and R. Bless",
  title="{Authorization for NSIS Signaling Layer Protocols}",
  howpublished="RFC 5981 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5981",
  pages="1--37",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5981.txt",
  key="RFC 5981",
  abstract={Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization.  Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources.  This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols.  The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Next Steps in Signaling, gist, General Internet Signaling Transport",
  doi="10.17487/RFC5981",
  }

@misc{rfc5982,
  author="A. Kobayashi and B. Claise",
  title="{IP Flow Information Export (IPFIX) Mediation: Problem Statement}",
  howpublished="RFC 5982 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5982",
  pages="1--25",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5982.txt",
  key="RFC 5982",
  abstract={Flow-based measurement is a popular method for various network monitoring usages.  The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve.  This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="flow-based measurement",
  doi="10.17487/RFC5982",
  }

@misc{rfc5983,
  author="R. Gellens",
  title="{Mailing Lists and Internationalized Email Addresses}",
  howpublished="RFC 5983 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5983",
  pages="1--10",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6783",
url="https://www.rfc-editor.org/rfc/rfc5983.txt",
  key="RFC 5983",
  abstract={This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC5983",
  }

@misc{rfc5984,
  author="K-M. Moller",
  title="{Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding}",
  howpublished="RFC 5984 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="5984",
  pages="1--9",
  year=2011,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5984.txt",
  key="RFC 5984",
  abstract={This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.  This document defines an Experimental Protocol for the Internet community.},
  keywords="extra sensory perception",
  doi="10.17487/RFC5984",
  }

@misc{rfc5985,
  author="M. Barnes",
  title="{HTTP-Enabled Location Delivery (HELD)}",
  howpublished="RFC 5985 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5985",
  pages="1--39",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7840",
url="https://www.rfc-editor.org/rfc/rfc5985.txt",
  key="RFC 5985",
  abstract={This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP.  The L7 LCP is used for retrieving location information from a server within an access network.  It includes options for retrieving location information in two forms: by value and by reference.  The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]},
  keywords="layer 7 location configuration protocol, l7 lcp",
  doi="10.17487/RFC5985",
  }

@misc{rfc5986,
  author="M. Thomson and J. Winterbottom",
  title="{Discovering the Local Location Information Server (LIS)}",
  howpublished="RFC 5986 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5986",
  pages="1--16",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5986.txt",
  key="RFC 5986",
  abstract={Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network.  A method is described for the discovery of a LIS in the access network serving a Device.  Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name.  This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]},
  keywords="u-naptr, uri-enabled naptr",
  doi="10.17487/RFC5986",
  }

@misc{rfc5987,
  author="J. Reschke",
  title="{Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters}",
  howpublished="RFC 5987 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5987",
  pages="1--10",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5987.txt",
  key="RFC 5987",
  abstract={By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set.  RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers.  This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]},
  keywords="HTTP, header field parameter, internationalization",
  doi="10.17487/RFC5987",
  }

@misc{rfc5988,
  author="M. Nottingham",
  title="{Web Linking}",
  howpublished="RFC 5988 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5988",
  pages="1--23",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5988.txt",
  key="RFC 5988",
  abstract={This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]},
  keywords="Link, linking, http header, link relation, web",
  doi="10.17487/RFC5988",
  }

@misc{rfc5989,
  author="A.B. Roach",
  title="{A SIP Event Package for Subscribing to Changes to an HTTP Resource}",
  howpublished="RFC 5989 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5989",
  pages="1--19",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5989.txt",
  key="RFC 5989",
  abstract={The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons.  In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted.  This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]},
  keywords="Link Relations, Syndication, Atom",
  doi="10.17487/RFC5989",
  }

@misc{rfc5990,
  author="J. Randall and B. Kaliski and J. Brainard and S. Turner",
  title="{Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 5990 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5990",
  pages="1--27",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5990.txt",
  key="RFC 5990",
  abstract={The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. (``KEM'' stands for ``key encapsulation mechanism''.) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS).  The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.},
  keywords="key encapsulation mechanism, generic hybrid cipher",
  doi="10.17487/RFC5990",
  }

@misc{rfc5991,
  author="D. Thaler and S. Krishnan and J. Hoagland",
  title="{Teredo Security Updates}",
  howpublished="RFC 5991 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5991",
  pages="1--10",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5991.txt",
  key="RFC 5991",
  abstract={The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address.  This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]},
  keywords="teredo ipv6 address",
  doi="10.17487/RFC5991",
  }

@misc{rfc5992,
  author="S. Sharikov and D. Miloshevic and J. Klensin",
  title="{Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic}",
  howpublished="RFC 5992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5992",
  pages="1--21",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5992.txt",
  key="RFC 5992",
  abstract={This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone.  It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Bosnian and Serbian, Bulgarian, Byelorussian, Belarusian, Belarusan, Kildin Sami, Macedonian, Montenegrin, Russian, Ukrainian",
  doi="10.17487/RFC5992",
  }

@misc{rfc5993,
  author="X. Duan and S. Wang and M. Westerlund and K. Hellwig and I. Johansson",
  title="{RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)}",
  howpublished="RFC 5993 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5993",
  pages="1--18",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5993.txt",
  key="RFC 5993",
  abstract={This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]},
  keywords="speech codec, real-time transport protocol",
  doi="10.17487/RFC5993",
  }

@misc{rfc5994,
  author="S. Bryant and M. Morrow and G. Swallow and R. Cherukuri and T. Nadeau and N. Harrison and B. Niven-Jenkins",
  title="{Application of Ethernet Pseudowires to MPLS Transport Networks}",
  howpublished="RFC 5994 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5994",
  pages="1--11",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5994.txt",
  key="RFC 5994",
  abstract={Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks. Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available. This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mpls-tp",
  doi="10.17487/RFC5994",
  }

@misc{rfc5995,
  author="J. Reschke",
  title="{Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections}",
  howpublished="RFC 5995 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5995",
  pages="1--12",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5995.txt",
  key="RFC 5995",
  abstract={The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the ``POST'' method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of ``POST''. This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned ``add collection member'' semantics. [STANDARDS-TRACK]},
  keywords="HTTP, POST, WebDAV, Collections, Collection Members",
  doi="10.17487/RFC5995",
  }

@misc{rfc5996,
  author="C. Kaufman and P. Hoffman and Y. Nir and P. Eronen",
  title="{Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 5996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5996",
  pages="1--138",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7296, updated by RFCs 5998, 6989",
url="https://www.rfc-editor.org/rfc/rfc5996.txt",
  key="RFC 5996",
  abstract={This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]},
  keywords="IKE, IPsec",
  doi="10.17487/RFC5996",
  }

@misc{rfc5997,
  author="A. DeKok",
  title="{Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol}",
  howpublished="RFC 5997 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5997",
  pages="1--24",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5997.txt",
  key="RFC 5997",
  abstract={This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server.  This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="status-server",
  doi="10.17487/RFC5997",
  }

@misc{rfc5998,
  author="P. Eronen and H. Tschofenig and Y. Sheffer",
  title="{An Extension for EAP-Only Authentication in IKEv2}",
  howpublished="RFC 5998 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5998",
  pages="1--16",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5998.txt",
  key="RFC 5998",
  abstract={IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]},
  keywords="mutual authentication, password, credentials, AAA, key agreement, channel binding",
  doi="10.17487/RFC5998",
  }

@misc{rfc6001,
  author="D. Papadimitriou and M. Vigoureux and K. Shiomoto and D. Brungard and JL. Le Roux",
  title="{Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)}",
  howpublished="RFC 6001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6001",
  pages="1--24",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6001.txt",
  key="RFC 6001",
  abstract={There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6001",
  }

@misc{rfc6002,
  author="L. Berger and D. Fedyk",
  title="{Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions}",
  howpublished="RFC 6002 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6002",
  pages="1--10",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6002.txt",
  key="RFC 6002",
  abstract={This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS).  The first extension defines the new switching type Data Channel Switching Capable.  Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces.  The second extension defines a new type of generalized label and updates related objects.  The new label is called the Generalized Channel\_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]},
  keywords="Generalized Multi-Protocol Label Switching",
  doi="10.17487/RFC6002",
  }

@misc{rfc6003,
  author="D. Papadimitriou",
  title="{Ethernet Traffic Parameters}",
  howpublished="RFC 6003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6003",
  pages="1--14",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6003.txt",
  key="RFC 6003",
  abstract={This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]},
  keywords="mef, Metro Ethernet Forum, MEF10.1",
  doi="10.17487/RFC6003",
  }

@misc{rfc6004,
  author="L. Berger and D. Fedyk",
  title="{Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching}",
  howpublished="RFC 6004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6004",
  pages="1--15",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6004.txt",
  key="RFC 6004",
  keywords="Generalized Multi-Protocol Label Switching, Metro Ethernet Forum, MEF",
  doi="10.17487/RFC6004",
  }

@misc{rfc6005,
  author="L. Berger and D. Fedyk",
  title="{Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)}",
  howpublished="RFC 6005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6005",
  pages="1--10",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6005.txt",
  key="RFC 6005",
  abstract={This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI).  This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011.  This document is the UNI companion to ``Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching''.  This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]},
  keywords="mef, itu, International Telecommunication Union, i-nni, internal nni",
  doi="10.17487/RFC6005",
  }

@misc{rfc6006,
  author="Q. Zhao and D. King and F. Verhaeghe and T. Takeda and Z. Ali and J. Meuric",
  title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths}",
  howpublished="RFC 6006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6006",
  pages="1--33",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6006.txt",
  key="RFC 6006",
  abstract={Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]},
  keywords="END-POINTS, fragmentation",
  doi="10.17487/RFC6006",
  }

@misc{rfc6007,
  author="I. Nishioka and D. King",
  title="{Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations}",
  howpublished="RFC 6007 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6007",
  pages="1--18",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6007.txt",
  key="RFC 6007",
  abstract={A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message. This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6007",
  }

@misc{rfc6008,
  author="M. Kucherawy",
  title="{Authentication-Results Registration for Differentiating among Cryptographic Results}",
  howpublished="RFC 6008 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6008",
  pages="1--7",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6008.txt",
  key="RFC 6008",
  abstract={This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]},
  keywords="DKIM, DomainKeys, SenderID, SPF, Authentication, Reputation",
  doi="10.17487/RFC6008",
  }

@misc{rfc6009,
  author="N. Freed",
  title="{Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions}",
  howpublished="RFC 6009 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6009",
  pages="1--15",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6009.txt",
  key="RFC 6009",
  abstract={This document describes the ``envelope-dsn'', ``redirect-dsn'', ``envelope-deliverby'', and ``redirect-deliverby'' extensions to the Sieve email filtering language.  The ``envelope-dsn'' and ``envelope- deliverby'' extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively.  The ``redirect-dsn'' and ``redirect-deliverby'' extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]},
  keywords="SMTP, ESMTP, Sieve",
  doi="10.17487/RFC6009",
  }

@misc{rfc6010,
  author="R. Housley and S. Ashmore and C. Wallace",
  title="{Cryptographic Message Syntax (CMS) Content Constraints Extension}",
  howpublished="RFC 6010 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6010",
  pages="1--38",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6010.txt",
  key="RFC 6010",
  abstract={This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension.  This extension is used to determine whether a public key is appropriate to use in the processing of a protected content.  In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content.  The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate.  If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]},
  keywords="authorization, PKI, certificate, trust anchor, TAMP,",
  doi="10.17487/RFC6010",
  }

@misc{rfc6011,
  author="S. Lawrence and J. Elwell",
  title="{Session Initiation Protocol (SIP) User Agent Configuration}",
  howpublished="RFC 6011 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6011",
  pages="1--29",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6011.txt",
  key="RFC 6011",
  abstract={This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="HTTP, DHCP, DHCPv6",
  doi="10.17487/RFC6011",
  }

@misc{rfc6012,
  author="J. Salowey and T. Petch and R. Gerhards and H. Feng",
  title="{Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog}",
  howpublished="RFC 6012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6012",
  pages="1--12",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6012.txt",
  key="RFC 6012",
  abstract={This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol.  It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]},
  keywords="TLS",
  doi="10.17487/RFC6012",
  }

@misc{rfc6013,
  author="W. Simpson",
  title="{TCP Cookie Transactions (TCPCT)}",
  howpublished="RFC 6013 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6013",
  pages="1--37",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc6013.txt",
  key="RFC 6013",
  abstract={TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake.  The Initiator (client) has sole responsibility for ensuring required delays between connections.  The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6013",
  }

@misc{rfc6014,
  author="P. Hoffman",
  title="{Cryptographic Algorithm Identifier Allocation for DNSSEC}",
  howpublished="RFC 6014 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6014",
  pages="1--6",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6014.txt",
  key="RFC 6014",
  abstract={This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated.  It changes the requirement from ``standard required'' to ``RFC Required''.  It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]},
  keywords="DNSSEC, digital signatures, algorithms",
  doi="10.17487/RFC6014",
  }

@misc{rfc6015,
  author="A. Begen",
  title="{RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)}",
  howpublished="RFC 6015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6015",
  pages="1--31",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6015.txt",
  key="RFC 6015",
  abstract={This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP.  The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols.  The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity.  The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]},
  keywords="FEC, interleaving, loss repair, loss protection, DVB AL-FEC",
  doi="10.17487/RFC6015",
  }

@misc{rfc6016,
  author="B. Davie and F. Le Faucheur and A. Narayanan",
  title="{Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs}",
  howpublished="RFC 6016 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6016",
  pages="1--38",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6016.txt",
  key="RFC 6016",
  abstract={RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6.  It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers.  This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links.  Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]},
  keywords="l3vpn",
  doi="10.17487/RFC6016",
  }

@misc{rfc6017,
  author="K. Meadors",
  title="{Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field}",
  howpublished="RFC 6017 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6017",
  pages="1--5",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6017.txt",
  key="RFC 6017",
  abstract={With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality.  These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations.  The EDIINT-Features header field provides a means to resolve these problems and support new functionality.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="EDIINT-Features",
  doi="10.17487/RFC6017",
  }

@misc{rfc6018,
  author="F. Baker and W. Harrop and G. Armitage",
  title="{IPv4 and IPv6 Greynets}",
  howpublished="RFC 6018 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6018",
  pages="1--9",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6018.txt",
  key="RFC 6018",
  abstract={This note discusses a feature to support building Greynets for IPv4 and IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="darknets",
  doi="10.17487/RFC6018",
  }

@misc{rfc6019,
  author="R. Housley",
  title="{BinaryTime: An Alternate Format for Representing Date and Time in ASN.1}",
  howpublished="RFC 6019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6019",
  pages="1--6",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6019.txt",
  key="RFC 6019",
  abstract={This document specifies a new ASN.1 type for representing time: BinaryTime.  This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime.  CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]},
  keywords="signing-time attribute, cryptographic message syntax, cms, SignedData, AuthenticatedData",
  doi="10.17487/RFC6019",
  }

@misc{rfc6020,
  author="M. Bjorklund",
  title="{YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)}",
  howpublished="RFC 6020 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6020",
  pages="1--173",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6020.txt",
  key="RFC 6020",
  abstract={YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]},
  keywords="NETCONF, XML, data modelling",
  doi="10.17487/RFC6020",
  }

@misc{rfc6021,
  author="J. Schoenwaelder",
  title="{Common YANG Data Types}",
  howpublished="RFC 6021 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6021",
  pages="1--26",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6991",
url="https://www.rfc-editor.org/rfc/rfc6021.txt",
  key="RFC 6021",
  abstract={This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]},
  keywords="YANG, NETCONF",
  doi="10.17487/RFC6021",
  }

@misc{rfc6022,
  author="M. Scott and M. Bjorklund",
  title="{YANG Module for NETCONF Monitoring}",
  howpublished="RFC 6022 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6022",
  pages="1--28",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6022.txt",
  key="RFC 6022",
  abstract={This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol.  The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics.  This data facilitates the management of a NETCONF server.  This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema> operation to retrieve them. [STANDARDS-TRACK]},
  keywords="XML, NETCONF, YANG, monitoring",
  doi="10.17487/RFC6022",
  }

@misc{rfc6023,
  author="Y. Nir and H. Tschofenig and H. Deng and R. Singh",
  title="{A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)}",
  howpublished="RFC 6023 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6023",
  pages="1--7",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6023.txt",
  key="RFC 6023",
  abstract={This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA.  This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.},
  doi="10.17487/RFC6023",
  }

@misc{rfc6024,
  author="R. Reddy and C. Wallace",
  title="{Trust Anchor Management Requirements}",
  howpublished="RFC 6024 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6024",
  pages="1--14",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6024.txt",
  key="RFC 6024",
  abstract={A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.  A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.  This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="PKI, certificates, digital signatures",
  doi="10.17487/RFC6024",
  }

@misc{rfc6025,
  author="C. Wallace and C. Gardiner",
  title="{ASN.1 Translation}",
  howpublished="RFC 6025 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6025",
  pages="1--19",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6025.txt",
  key="RFC 6025",
  abstract={Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years.  Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1.  Not all ASN.1 compilers support both older and current syntax.  This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the ``bits on the wire''.  This document does not provide a comprehensive tutorial of any version of ASN.1.  Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Basic Encoding Rules, Distinguished Encoding Rules, PKIX, S/MIME",
  doi="10.17487/RFC6025",
  }

@misc{rfc6026,
  author="R. Sparks and T. Zourzouvillys",
  title="{Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests}",
  howpublished="RFC 6026 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6026",
  pages="1--20",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6026.txt",
  key="RFC 6026",
  abstract={This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests.  Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request.  The correction involves modifying the INVITE transaction state machines.  The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]},
  keywords="state machine, retransmission",
  doi="10.17487/RFC6026",
  }

@misc{rfc6027,
  author="Y. Nir",
  title="{IPsec Cluster Problem Statement}",
  howpublished="RFC 6027 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6027",
  pages="1--12",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6027.txt",
  key="RFC 6027",
  abstract={This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters.  It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors.  Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IKE, IKEv2, high-availability, load-sharing, failover, hot-standby",
  doi="10.17487/RFC6027",
  }

@misc{rfc6028,
  author="G. Camarillo and A. Keranen",
  title="{Host Identity Protocol (HIP) Multi-Hop Routing Extension}",
  howpublished="RFC 6028 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6028",
  pages="1--10",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6028.txt",
  key="RFC 6028",
  abstract={This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing.  The first extension allows implementing source routing in HIP.  That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.  The second extension allows a HIP packet to carry and record the list of nodes that forwarded it.  This document defines an Experimental Protocol for the Internet community.},
  keywords="source routing, route recording, overlay network",
  doi="10.17487/RFC6028",
  }

@misc{rfc6029,
  author="I. Rimac and V. Hilt and M. Tomsu and V. Gurbani and E. Marocco",
  title="{A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem}",
  howpublished="RFC 6029 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6029",
  pages="1--19",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6029.txt",
  key="RFC 6029",
  abstract={A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming.  Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology.  As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices.  This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Peer-to-Peer, topology estimation, Internet coordinate system",
  doi="10.17487/RFC6029",
  }

@misc{rfc6030,
  author="P. Hoyer and M. Pei and S. Machani",
  title="{Portable Symmetric Key Container (PSKC)}",
  howpublished="RFC 6030 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6030",
  pages="1--58",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6030.txt",
  key="RFC 6030",
  abstract={This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.  For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices.  A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]},
  keywords="Symmetric Key, provisioning, AES, 3DES, TDES, OTP, Key transport format, key provisioning format, symmetric key protection, symmetric key transport, PIN transport, PIN, provisioning, PIN Policy, key usage policy",
  doi="10.17487/RFC6030",
  }

@misc{rfc6031,
  author="S. Turner and R. Housley",
  title="{Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type}",
  howpublished="RFC 6031 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6031",
  pages="1--29",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6031.txt",
  key="RFC 6031",
  abstract={This document defines the symmetric key format content type.  It is transport independent.  The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6031",
  }

@misc{rfc6032,
  author="S. Turner and R. Housley",
  title="{Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}",
  howpublished="RFC 6032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6032",
  pages="1--11",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6032.txt",
  key="RFC 6032",
  abstract={This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package.  It is transport independent.  CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type.  It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]},
  keywords="CCC, CMS content constraints",
  doi="10.17487/RFC6032",
  }

@misc{rfc6033,
  author="S. Turner",
  title="{Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}",
  howpublished="RFC 6033 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6033",
  pages="1--5",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6161",
url="https://www.rfc-editor.org/rfc/rfc6033.txt",
  key="RFC 6033",
  abstract={This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6033",
  }

@misc{rfc6034,
  author="D. Thaler",
  title="{Unicast-Prefix-Based IPv4 Multicast Addresses}",
  howpublished="RFC 6034 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6034",
  pages="1--5",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6034.txt",
  key="RFC 6034",
  abstract={This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol.  The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses.  By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]},
  keywords="internet protocol",
  doi="10.17487/RFC6034",
  }

@misc{rfc6035,
  author="A. Pendleton and A. Clark and A. Johnston and H. Sinnreich",
  title="{Session Initiation Protocol Event Package for Voice Quality Reporting}",
  howpublished="RFC 6035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6035",
  pages="1--41",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6035.txt",
  key="RFC 6035",
  abstract={This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.  Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector.  A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]},
  keywords="sip, Voice over Internet Protocol, voip, RTP Control Protocol Extended Reports, RTCP-XR",
  doi="10.17487/RFC6035",
  }

@misc{rfc6036,
  author="B. Carpenter and S. Jiang",
  title="{Emerging Service Provider Scenarios for IPv6 Deployment}",
  howpublished="RFC 6036 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6036",
  pages="1--23",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6036.txt",
  key="RFC 6036",
  abstract={This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services.  They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010.  This document identifies a number of technology gaps, but it does not make recommendations.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="isp",
  doi="10.17487/RFC6036",
  }

@misc{rfc6037,
  author="E. Rosen and Y. Cai and IJ. Wijnands",
  title="{Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs}",
  howpublished="RFC 6037 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6037",
  pages="1--25",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6037.txt",
  key="RFC 6037",
  abstract={This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems.  The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF.  However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation.  These differences are pointed out in the document.  This document defines a Historic Document for the Internet community.},
  keywords="mvpn",
  doi="10.17487/RFC6037",
  }

@misc{rfc6038,
  author="A. Morton and L. Ciavattone",
  title="{Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features}",
  howpublished="RFC 6038 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6038",
  pages="1--18",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6038.txt",
  key="RFC 6038",
  abstract={This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]},
  keywords="Testing, Performance, Metric",
  doi="10.17487/RFC6038",
  }

@misc{rfc6039,
  author="V. Manral and M. Bhatia and J. Jaeggli and R. White",
  title="{Issues with Existing Cryptographic Protection Methods for Routing Protocols}",
  howpublished="RFC 6039 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6039",
  pages="1--21",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6039.txt",
  key="RFC 6039",
  abstract={Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6039",
  }

@misc{rfc6040,
  author="B. Briscoe",
  title="{Tunnelling of Explicit Congestion Notification}",
  howpublished="RFC 6040 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6040",
  pages="1--35",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6040.txt",
  key="RFC 6040",
  abstract={This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers.  The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported.  Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility.  Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification.  A thorough analysis of the reasoning for these changes and the implications is included.  In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]},
  keywords="Congestion Control and Management, Congestion Notification, Information Security, Tunnelling, Encapsulation, Decapsulation, Protocol, ECN, IPsec",
  doi="10.17487/RFC6040",
  }

@misc{rfc6041,
  author="A. Crouch and H. Khosravi and A. Doria and X. Wang and K. Ogawa",
  title="{Forwarding and Control Element Separation (ForCES) Applicability Statement}",
  howpublished="RFC 6041 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6041",
  pages="1--14",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6041.txt",
  key="RFC 6041",
  abstract={The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices.  In this document we describe the applicability of the ForCES model and protocol.  We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Routing, Control Plane, Management, Protocol",
  doi="10.17487/RFC6041",
  }

@misc{rfc6042,
  author="A. Keromytis",
  title="{Transport Layer Security (TLS) Authorization Using KeyNote}",
  howpublished="RFC 6042 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6042",
  pages="1--7",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6042.txt",
  key="RFC 6042",
  abstract={This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878.  Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="trust management, authorization, access control, certificates",
  doi="10.17487/RFC6042",
  }

@misc{rfc6043,
  author="J. Mattsson and T. Tian",
  title="{MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 6043 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6043",
  pages="1--58",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6309",
url="https://www.rfc-editor.org/rfc/rfc6043.txt",
  key="RFC 6043",
  abstract={The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications.  In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service.  Interest in such deployments is increasing.  Therefore, a set of new MIKEY modes that work well in such scenarios are defined.  The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos.  The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MIKEY, MIKEY-TICKET, KMS, SRTP, IMS, key management, ticket",
  doi="10.17487/RFC6043",
  }

@misc{rfc6044,
  author="M. Mohali",
  title="{Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6044 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6044",
  pages="1--24",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7544",
url="https://www.rfc-editor.org/rfc/rfc6044.txt",
  key="RFC 6044",
  abstract={Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling. This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806. Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6044",
  }

@misc{rfc6045,
  author="K. Moriarty",
  title="{Real-time Inter-network Defense (RID)}",
  howpublished="RFC 6045 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6045",
  pages="1--75",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6545",
url="https://www.rfc-editor.org/rfc/rfc6045.txt",
  key="RFC 6045",
  abstract={Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Coordinated Incident Response, CSIRT, CIRT, IODEF, Incident Object Exchange, Description Format",
  doi="10.17487/RFC6045",
  }

@misc{rfc6046,
  author="K. Moriarty and B. Trammell",
  title="{Transport of Real-time Inter-network Defense (RID) Messages}",
  howpublished="RFC 6046 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6046",
  pages="1--7",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6546",
url="https://www.rfc-editor.org/rfc/rfc6046.txt",
  key="RFC 6046",
  abstract={The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises.  This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Coordinate Incident Response, CSIRT, CIRT, IODEF, Incident Object Exchange, Description Format",
  doi="10.17487/RFC6046",
  }

@misc{rfc6047,
  author="A. Melnikov",
  title="{iCalendar Message-Based Interoperability Protocol (iMIP)}",
  howpublished="RFC 6047 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6047",
  pages="1--22",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6047.txt",
  key="RFC 6047",
  abstract={This document, ``iCalendar Message-Based Interoperability Protocol (iMIP)'', specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports.  Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]},
  keywords="IMIP], electronic mail, transport, itip, iCalendar Transport-independent Interoperability Protocol, iCalendar Object Model",
  doi="10.17487/RFC6047",
  }

@misc{rfc6048,
  author="J. Elie",
  title="{Network News Transfer Protocol (NNTP) Additions to LIST Command}",
  howpublished="RFC 6048 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6048",
  pages="1--25",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6048.txt",
  key="RFC 6048",
  abstract={This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977. This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]},
  keywords="Usenet, NetNews, capabilities",
  doi="10.17487/RFC6048",
  }

@misc{rfc6049,
  author="A. Morton and E. Stephan",
  title="{Spatial Composition of Metrics}",
  howpublished="RFC 6049 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6049",
  pages="1--29",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6248",
url="https://www.rfc-editor.org/rfc/rfc6049.txt",
  key="RFC 6049",
  abstract={This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics.  This is called ``spatial composition'' in RFC 2330.  The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others.  The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]},
  keywords="Performance, Measurement, IPPM",
  doi="10.17487/RFC6049",
  }

@misc{rfc6050,
  author="K. Drage",
  title="{A Session Initiation Protocol (SIP) Extension for the Identification of Services}",
  howpublished="RFC 6050 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6050",
  pages="1--19",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6050.txt",
  key="RFC 6050",
  abstract={This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large. The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SIP, trust domain, service identifier",
  doi="10.17487/RFC6050",
  }

@misc{rfc6051,
  author="C. Perkins and T. Schierl",
  title="{Rapid Synchronisation of RTP Flows}",
  howpublished="RFC 6051 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6051",
  pages="1--22",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6051.txt",
  key="RFC 6051",
  abstract={This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]},
  keywords="rtcp, rtp control protocol, mcu, multipoint conference units, ssm, source-specific multicast",
  doi="10.17487/RFC6051",
  }

@misc{rfc6052,
  author="C. Bao and C. Huitema and M. Bagnulo and M. Boucadair and X. Li",
  title="{IPv6 Addressing of IPv4/IPv6 Translators}",
  howpublished="RFC 6052 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6052",
  pages="1--18",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6052.txt",
  key="RFC 6052",
  abstract={This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information.  It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate.  Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]},
  keywords="address, prefix, transition, translation, NAT, NAT64, BEHAVE, stateless, stateful",
  doi="10.17487/RFC6052",
  }

@misc{rfc6053,
  author="E. Haleplidis and K. Ogawa and W. Wang and J. Hadi Salim",
  title="{Implementation Report for Forwarding and Control Element Separation (ForCES)}",
  howpublished="RFC 6053 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6053",
  pages="1--34",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6984",
url="https://www.rfc-editor.org/rfc/rfc6053.txt",
  key="RFC 6053",
  abstract={Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework. This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Stream Control Transmission Protocol-based Transport Mapping Layer, SCTP TML, forces Model",
  doi="10.17487/RFC6053",
  }

@misc{rfc6054,
  author="D. McGrew and B. Weis",
  title="{Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic}",
  howpublished="RFC 6054 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6054",
  pages="1--10",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6054.txt",
  key="RFC 6054",
  abstract={Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES).  Counter modes use a counter, which is typically assumed to be incremented by a single sender.  This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6054",
  }

@misc{rfc6055,
  author="D. Thaler and J. Klensin and S. Cheshire",
  title="{IAB Thoughts on Encodings for Internationalized Domain Names}",
  howpublished="RFC 6055 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6055",
  pages="1--24",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6055.txt",
  key="RFC 6055",
  abstract={This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm.  It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.},
  keywords="Unicode, UTF-8,",
  doi="10.17487/RFC6055",
  }

@misc{rfc6056,
  author="M. Larsen and F. Gont",
  title="{Recommendations for Transport-Protocol Port Randomization}",
  howpublished="RFC 6056 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6056",
  pages="1--29",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6056.txt",
  key="RFC 6056",
  abstract={During the last few years, awareness has been raised about a number of ``blind'' attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols.  The consequences of these attacks range from throughput reduction to broken connections or data corruption.  These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked.  This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced.  While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead.  The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers).  This memo documents an Internet Best Current Practice.},
  keywords="tcp, transmission control protocl, blind attacks",
  doi="10.17487/RFC6056",
  }

@misc{rfc6057,
  author="C. Bastian and T. Klieber and J. Livingood and J. Mills and R. Woundy",
  title="{Comcast's Protocol-Agnostic Congestion Management System}",
  howpublished="RFC 6057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6057",
  pages="1--29",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6057.txt",
  key="RFC 6057",
  abstract={This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S.  Comcast completed deployment of this congestion management system on December 31, 2008.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ISP, Internet Service Provider, Network Management",
  doi="10.17487/RFC6057",
  }

@misc{rfc6058,
  author="M. Liebsch and A. Muhanna and O. Blume",
  title="{Transient Binding for Proxy Mobile IPv6}",
  howpublished="RFC 6058 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6058",
  pages="1--35",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6058.txt",
  key="RFC 6058",
  abstract={This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover.  This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces.  The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described.  The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PMIP, handover optimization, handover delay, tBCE, late path switch, forwarding, make-before-break, dual radio handover, single radio handover, transient binding cache entry",
  doi="10.17487/RFC6058",
  }

@misc{rfc6059,
  author="S. Krishnan and G. Daley",
  title="{Simple Procedures for Detecting Network Attachment in IPv6}",
  howpublished="RFC 6059 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6059",
  pages="1--19",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6059.txt",
  key="RFC 6059",
  abstract={Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network.  This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]},
  keywords="DNA, DNAv6, ND, IPv6 neighbor discovery, neighbor discovery, send, secure neighbor discovery, DHCPv6, stateless autoconfiguration, change detection, movement detection, DNAv4, link detection, mobility",
  doi="10.17487/RFC6059",
  }

@misc{rfc6060,
  author="D. Fedyk and H. Shah and N. Bitar and A. Takacs",
  title="{Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)}",
  howpublished="RFC 6060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6060",
  pages="1--20",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6060.txt",
  key="RFC 6060",
  abstract={This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE).  The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections.  This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]},
  keywords="IEEE data plane",
  doi="10.17487/RFC6060",
  }

@misc{rfc6061,
  author="B. Rosen",
  title="{Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)}",
  howpublished="RFC 6061 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6061",
  pages="1--7",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6061.txt",
  key="RFC 6061",
  abstract={This document describes the Namespace Identifier (NID) ``nena'' for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA).  NENA defines and manages resources that utilize this URN model.  Management activities for these and other resource types are provided by the NENA Registry System (NRS).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6061",
  }

@misc{rfc6062,
  author="S. Perreault and J. Rosenberg",
  title="{Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations}",
  howpublished="RFC 6062 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6062",
  pages="1--13",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6062.txt",
  key="RFC 6062",
  abstract={This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal.  This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers.  TURN and this extension both purposefully restrict the ways in which the relayed address can be used.  In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]},
  keywords="NAT, TURN, STUN",
  doi="10.17487/RFC6062",
  }

@misc{rfc6063,
  author="A. Doherty and M. Pei and S. Machani and M. Nystrom",
  title="{Dynamic Symmetric Key Provisioning Protocol (DSKPP)}",
  howpublished="RFC 6063 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6063",
  pages="1--105",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6063.txt",
  key="RFC 6063",
  abstract={The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure. Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]},
  keywords="Cryptographic module, Cryptographic Token, key initialization, credentials, online provisioning",
  doi="10.17487/RFC6063",
  }

@misc{rfc6064,
  author="M. Westerlund and P. Frojdh",
  title="{SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service}",
  howpublished="RFC 6064 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6064",
  pages="1--22",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6064.txt",
  key="RFC 6064",
  abstract={The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions.  This document provides information about these extensions and registers the RTSP and SDP extensions with IANA.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="3GPP, PSS, MBMS, SDP, RTSP, IANA",
  doi="10.17487/RFC6064",
  }

@misc{rfc6065,
  author="K. Narayan and D. Nelson and R. Presuhn",
  title="{Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings}",
  howpublished="RFC 6065 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6065",
  pages="1--19",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6065.txt",
  key="RFC 6065",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]},
  keywords="Network Management, Security, Management Information Base, MIB, SMIv2, RADIUS, AAA, VACM",
  doi="10.17487/RFC6065",
  }

@misc{rfc6066,
  author="D. {Eastlake 3rd}",
  title="{Transport Layer Security (TLS) Extensions: Extension Definitions}",
  howpublished="RFC 6066 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6066",
  pages="1--25",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6066.txt",
  key="RFC 6066",
  abstract={This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, ``The Transport Layer Security (TLS) Protocol Version 1.2''.  The extensions specified are server\_name, max\_fragment\_length, client\_certificate\_url, trusted\_ca\_keys, truncated\_hmac, and status\_request. [STANDARDS-TRACK]},
  keywords="server\_name, max\_fragment\_length, client\_certificate\_url, trusted\_ca\_keys, truncated\_hmac, status\_request",
  doi="10.17487/RFC6066",
  }

@misc{rfc6067,
  author="M. Davis and A. Phillips and Y. Umaoka",
  title="{BCP 47 Extension U}",
  howpublished="RFC 6067 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6067",
  pages="1--8",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6067.txt",
  key="RFC 6067",
  abstract={This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="locale, bcp 47",
  doi="10.17487/RFC6067",
  }

@misc{rfc6068,
  author="M. Duerst and L. Masinter and J. Zawinski",
  title="{The 'mailto' URI Scheme}",
  howpublished="RFC 6068 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6068",
  pages="1--17",
  year=2010,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6068.txt",
  key="RFC 6068",
  abstract={This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail.  It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]},
  keywords="mailto, email address, URI scheme, IRI",
  doi="10.17487/RFC6068",
  }

@misc{rfc6069,
  author="A. Zimmermann and A. Hannemann",
  title="{Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)}",
  howpublished="RFC 6069 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6069",
  pages="1--23",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6069.txt",
  key="RFC 6069",
  abstract={Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.},
  keywords="Internet Control Message Protocol (ICMP), Retranmission Timeout (RTO)",
  doi="10.17487/RFC6069",
  }

@misc{rfc6070,
  author="S. Josefsson",
  title="{PKCS \#5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors}",
  howpublished="RFC 6070 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6070",
  pages="1--5",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6070.txt",
  key="RFC 6070",
  abstract={This document contains test vectors for the Public-Key Cryptography Standards (PKCS) \#5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6070",
  }

@misc{rfc6071,
  author="S. Frankel and S. Krishnan",
  title="{IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap}",
  howpublished="RFC 6071 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6071",
  pages="1--63",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6071.txt",
  key="RFC 6071",
  abstract={Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous ``IP Security Document Roadmap.'' The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="internet protocol, privacy, authentication",
  doi="10.17487/RFC6071",
  }

@misc{rfc6072,
  author="C. Jennings and J. Fischl",
  title="{Certificate Management Service for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6072 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6072",
  pages="1--30",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6072.txt",
  key="RFC 6072",
  abstract={This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users.  This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate.  The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]},
  keywords="credential service, aor, address of record",
  doi="10.17487/RFC6072",
  }

@misc{rfc6073,
  author="L. Martini and C. Metz and T. Nadeau and M. Bocci and M. Aissaoui",
  title="{Segmented Pseudowire}",
  howpublished="RFC 6073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6073",
  pages="1--43",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6723, 7267",
url="https://www.rfc-editor.org/rfc/rfc6073.txt",
  key="RFC 6073",
  abstract={This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW.  The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point.  The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]},
  keywords="pws, psn, packet switched network, pw control plane domain",
  doi="10.17487/RFC6073",
  }

@misc{rfc6074,
  author="E. Rosen and B. Davie and V. Radoaca and W. Luo",
  title="{Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)}",
  howpublished="RFC 6074 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6074",
  pages="1--32",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6074.txt",
  key="RFC 6074",
  abstract={Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different ``provisioning models'', i.e., models for what information needs to be configured in what entities.  Once configured, the provisioning information is distributed by a ``discovery process''.  When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN.  This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model.  It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP).  It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]},
  keywords="",
  doi="10.17487/RFC6074",
  }

@misc{rfc6075,
  author="D. Cridland",
  title="{The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry}",
  howpublished="RFC 6075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6075",
  pages="1--7",
  year=2010,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6075.txt",
  key="RFC 6075",
  abstract={The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols.  This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]},
  keywords="annotate, metadata",
  doi="10.17487/RFC6075",
  }

@misc{rfc6076,
  author="D. Malas and A. Morton",
  title="{Basic Telephony SIP End-to-End Performance Metrics}",
  howpublished="RFC 6076 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6076",
  pages="1--27",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6076.txt",
  key="RFC 6076",
  abstract={This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments.  The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]},
  keywords="Benchmarking, Lab, Test, Time, Measurement, Service, Session, Protocol",
  doi="10.17487/RFC6076",
  }

@misc{rfc6077,
  author="D. Papadimitriou and M. Welzl and M. Scharf and B. Briscoe",
  title="{Open Research Issues in Internet Congestion Control}",
  howpublished="RFC 6077 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6077",
  pages="1--51",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6077.txt",
  key="RFC 6077",
  abstract={This document describes some of the open problems in Internet congestion control that are known today.  This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years.  These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Signalling, Performance, Robustness, Fairness, Stability, Misbehaviour, Architecture",
  doi="10.17487/RFC6077",
  }

@misc{rfc6078,
  author="G. Camarillo and J. Melen",
  title="{Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)}",
  howpublished="RFC 6078 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6078",
  pages="1--17",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6078.txt",
  key="RFC 6078",
  abstract={This document defines a new Host Identity Protocol (HIP) packet type called DATA.  HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.  This document defines an Experimental Protocol for the Internet community.},
  keywords="HIP DATA",
  doi="10.17487/RFC6078",
  }

@misc{rfc6079,
  author="G. Camarillo and P. Nikander and J. Hautakorpi and A. Keranen and A. Johnston",
  title="{HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)}",
  howpublished="RFC 6079 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6079",
  pages="1--21",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6079.txt",
  key="RFC 6079",
  abstract={This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks.  This framework uses HIP to perform connection management.  Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP.  These protocols are loosely referred to as ``peer protocols''.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6079",
  }

@misc{rfc6080,
  author="D. Petrie and S. Channabasappa",
  title="{A Framework for Session Initiation Protocol User Agent Profile Delivery}",
  howpublished="RFC 6080 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6080",
  pages="1--54",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6080.txt",
  key="RFC 6080",
  abstract={This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments.  The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention.  The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications.  As part of this framework, a new SIP event package is defined for notification of profile changes.  The framework provides minimal data retrieval options to ensure interoperability.  The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]},
  keywords="SIP, Configuration, Framework, User Agent, profile",
  doi="10.17487/RFC6080",
  }

@misc{rfc6081,
  author="D. Thaler",
  title="{Teredo Extensions}",
  howpublished="RFC 6081 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6081",
  pages="1--59",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6081.txt",
  key="RFC 6081",
  abstract={This document specifies a set of extensions to the Teredo protocol.  These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]},
  keywords="IPv6, NAT, traversal, transition, translation, translator",
  doi="10.17487/RFC6081",
  }

@misc{rfc6082,
  author="K. Whistler and G. Adams and M. Duerst and R. Presuhn and J. Klensin",
  title="{Deprecating Unicode Language Tag Characters: RFC 2482 is Historic}",
  howpublished="RFC 6082 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6082",
  pages="1--4",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6082.txt",
  key="RFC 6082",
  abstract={RFC 2482, ``Language Tagging in Unicode Plain Text'', describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML.  The Unicode Consortium has deprecated that facility and strongly recommends against its use.  RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="characters, strings, ASCII",
  doi="10.17487/RFC6082",
  }

@misc{rfc6083,
  author="M. Tuexen and R. Seggelmann and E. Rescorla",
  title="{Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 6083 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6083",
  pages="1--9",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6083.txt",
  key="RFC 6083",
  abstract={This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6083",
  }

@misc{rfc6084,
  author="X. Fu and C. Dickmann and J. Crowcroft",
  title="{General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 6084 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6084",
  pages="1--12",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6084.txt",
  key="RFC 6084",
  abstract={The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation.  This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).  This document defines an Experimental Protocol for the Internet community.},
  keywords="Multihoming, Signaling, Partial Reliability",
  doi="10.17487/RFC6084",
  }

@misc{rfc6085,
  author="S. Gundavelli and M. Townsley and O. Troan and W. Dec",
  title="{Address Mapping of IPv6 Multicast Packets on Ethernet}",
  howpublished="RFC 6085 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6085",
  pages="1--3",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6085.txt",
  key="RFC 6085",
  abstract={When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address.  This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6085",
  }

@misc{rfc6086,
  author="C. Holmberg and E. Burger and H. Kaplan",
  title="{Session Initiation Protocol (SIP) INFO Method and Package Framework}",
  howpublished="RFC 6086 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6086",
  pages="1--36",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6086.txt",
  key="RFC 6086",
  abstract={This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism.  This document obsoletes RFC 2976.  For backward compatibility, this document also specifies a ``legacy'' mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as ``legacy INFO Usage'' in this document. [STANDARDS-TRACK]},
  keywords="Info Package, Info-Package, Recv-Info",
  doi="10.17487/RFC6086",
  }

@misc{rfc6087,
  author="A. Bierman",
  title="{Guidelines for Authors and Reviewers of YANG Data Model Documents}",
  howpublished="RFC 6087 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6087",
  pages="1--26",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6087.txt",
  key="RFC 6087",
  abstract={This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules.  Applicable portions may be used as a basis for reviews of other YANG data model documents.  Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="NETMOD, NETCONF, XML, YANG",
  doi="10.17487/RFC6087",
  }

@misc{rfc6088,
  author="G. Tsirtsis and G. Giarreta and H. Soliman and N. Montavont",
  title="{Traffic Selectors for Flow Bindings}",
  howpublished="RFC 6088 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6088",
  pages="1--13",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6088.txt",
  key="RFC 6088",
  abstract={This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]},
  keywords="Mobile IPv6, Binary Traffic Selectors",
  doi="10.17487/RFC6088",
  }

@misc{rfc6089,
  author="G. Tsirtsis and H. Soliman and N. Montavont and G. Giaretta and K. Kuladinithi",
  title="{Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support}",
  howpublished="RFC 6089 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6089",
  pages="1--31",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6089.txt",
  key="RFC 6089",
  abstract={This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address.  These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]},
  keywords="Flow Identification, Flow Summary, Binding Reference, Traffic Selector, Flow Binding Entry",
  doi="10.17487/RFC6089",
  }

@misc{rfc6090,
  author="D. McGrew and K. Igoe and M. Salter",
  title="{Fundamental Elliptic Curve Cryptography Algorithms}",
  howpublished="RFC 6090 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6090",
  pages="1--34",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6090.txt",
  key="RFC 6090",
  abstract={This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier.  These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years.  Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ECC",
  doi="10.17487/RFC6090",
  }

@misc{rfc6091,
  author="N. Mavrogiannopoulos and D. Gillmor",
  title="{Using OpenPGP Keys for Transport Layer Security (TLS) Authentication}",
  howpublished="RFC 6091 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6091",
  pages="1--9",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6091.txt",
  key="RFC 6091",
  abstract={This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS.  It also defines the registry for non-X.509 certificate types.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Certificate type negotiation, tls handshake protocol, handshake",
  doi="10.17487/RFC6091",
  }

@misc{rfc6092,
  author="J. Woodyatt",
  title="{Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service}",
  howpublished="RFC 6092 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6092",
  pages="1--36",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6092.txt",
  key="RFC 6092",
  abstract={This document identifies a set of recommendations for the makers of devices and describes how to provide for ``simple security'' capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="cpe, firewall, filter",
  doi="10.17487/RFC6092",
  }

@misc{rfc6093,
  author="F. Gont and A. Yourtchenko",
  title="{On the Implementation of the TCP Urgent Mechanism}",
  howpublished="RFC 6093 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6093",
  pages="1--12",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6093.txt",
  key="RFC 6093",
  abstract={This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications.  This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]},
  keywords="Transmission Control Protocol",
  doi="10.17487/RFC6093",
  }

@misc{rfc6094,
  author="M. Bhatia and V. Manral",
  title="{Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols}",
  howpublished="RFC 6094 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6094",
  pages="1--11",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6094.txt",
  key="RFC 6094",
  abstract={The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common. Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets. This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IGP security",
  doi="10.17487/RFC6094",
  }

@misc{rfc6095,
  author="B. Linowski and M. Ersue and S. Kuryla",
  title="{Extending YANG with Language Abstractions}",
  howpublished="RFC 6095 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6095",
  pages="1--75",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6095.txt",
  key="RFC 6095",
  abstract={YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF.  This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.  This document defines an Experimental Protocol for the Internet community.},
  keywords="YANG, model, complex-type, Complex Types, Typed Instance, Resource Model, Inheritance, class",
  doi="10.17487/RFC6095",
  }

@misc{rfc6096,
  author="M. Tuexen and R. Stewart",
  title="{Stream Control Transmission Protocol (SCTP) Chunk Flags Registration}",
  howpublished="RFC 6096 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6096",
  pages="1--8",
  year=2011,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6096.txt",
  key="RFC 6096",
  abstract={This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP).  It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types.  It does not change SCTP in any other way. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6096",
  }

@misc{rfc6097,
  author="J. Korhonen and V. Devarapalli",
  title="{Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6}",
  howpublished="RFC 6097 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6097",
  pages="1--10",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6097.txt",
  key="RFC 6097",
  abstract={Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway.  This document describes several possible dynamic Local Mobility Anchor discovery solutions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="PMIPv6, 3GPP, DNS, AAA",
  doi="10.17487/RFC6097",
  }

@misc{rfc6098,
  author="H. Deng and H. Levkowetz and V. Devarapalli and S. Gundavelli and B. Haley",
  title="{Generic Notification Message for Mobile IPv4}",
  howpublished="RFC 6098 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6098",
  pages="1--33",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6098.txt",
  key="RFC 6098",
  abstract={This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]},
  keywords="mipv4",
  doi="10.17487/RFC6098",
  }

@misc{rfc6101,
  author="A. Freier and P. Karlton and P. Kocher",
  title="{The Secure Sockets Layer (SSL) Protocol Version 3.0}",
  howpublished="RFC 6101 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6101",
  pages="1--67",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6101.txt",
  key="RFC 6101",
  abstract={This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows. This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.},
  keywords="Transport layer security",
  doi="10.17487/RFC6101",
  }

@misc{rfc6104,
  author="T. Chown and S. Venaas",
  title="{Rogue IPv6 Router Advertisement Problem Statement}",
  howpublished="RFC 6104 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6104",
  pages="1--16",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6104.txt",
  key="RFC 6104",
  abstract={When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network.  This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information.  However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network.  In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem.  We focus on the unintended causes of rogue RAs in the text.  The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RA, rogue ra",
  doi="10.17487/RFC6104",
  }

@misc{rfc6105,
  author="E. Levy-Abegnoli and G. Van de Velde and C. Popoviciu and J. Mohacsi",
  title="{IPv6 Router Advertisement Guard}",
  howpublished="RFC 6105 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6105",
  pages="1--10",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7113",
url="https://www.rfc-editor.org/rfc/rfc6105.txt",
  key="RFC 6105",
  abstract={Routed protocols are often susceptible to spoof attacks.  The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy.  This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SEcure Neighbor Discovery, Stateless Address Autoconfiguration",
  doi="10.17487/RFC6105",
  }

@misc{rfc6106,
  author="J. Jeong and S. Park and L. Beloeil and S. Madanapalli",
  title="{IPv6 Router Advertisement Options for DNS Configuration}",
  howpublished="RFC 6106 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6106",
  pages="1--19",
  year=2010,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8106",
url="https://www.rfc-editor.org/rfc/rfc6106.txt",
  key="RFC 6106",
  abstract={This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]},
  keywords="DNS Service, DNS Option, Recursive DNS Server Address, DNS Search List, Stateless Autoconfiguration",
  doi="10.17487/RFC6106",
  }

@misc{rfc6107,
  author="K. Shiomoto and A. Farrel",
  title="{Procedures for Dynamically Signaled Hierarchical Label Switched Paths}",
  howpublished="RFC 6107 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6107",
  pages="1--30",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6107.txt",
  key="RFC 6107",
  abstract={Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]},
  keywords="TE links, Bundled links, GMPLS, dynamically provisioned networks",
  doi="10.17487/RFC6107",
  }

@misc{rfc6108,
  author="C. Chung and A. Kasyanov and J. Livingood and N. Mody and B. Van Lieu",
  title="{Comcast's Web Notification System Design}",
  howpublished="RFC 6108 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6108",
  pages="1--24",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6108.txt",
  key="RFC 6108",
  abstract={The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP).  Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection.  There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology.  In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ISP, Internet Service Provider, bot remediation, bot notification",
  doi="10.17487/RFC6108",
  }

@misc{rfc6109,
  author="C. Petrucci and F. Gennai and A. Shahin and A. Vinciarelli",
  title="{La Posta Elettronica Certificata - Italian Certified Electronic Mail}",
  howpublished="RFC 6109 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6109",
  pages="1--65",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6109.txt",
  key="RFC 6109",
  abstract={Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian ``Posta Elettronica Certificata'') were defined, giving the system legal standing. The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="PEC, Registered mail, Return receipt, Digitally signed email, Digitally signed notification, MIME, SMIME",
  doi="10.17487/RFC6109",
  }

@misc{rfc6110,
  author="L. Lhotka",
  title="{Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content}",
  howpublished="RFC 6110 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6110",
  pages="1--100",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7952",
url="https://www.rfc-editor.org/rfc/rfc6110.txt",
  key="RFC 6110",
  abstract={This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757.  The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL).  The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.  Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]},
  keywords="DSDL, validation, RELAX NG, Schematron, DSRL",
  doi="10.17487/RFC6110",
  }

@misc{rfc6111,
  author="L. Zhu",
  title="{Additional Kerberos Naming Constraints}",
  howpublished="RFC 6111 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6111",
  pages="1--6",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6111.txt",
  key="RFC 6111",
  abstract={This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]},
  keywords="principal names, realm names",
  doi="10.17487/RFC6111",
  }

@misc{rfc6112,
  author="L. Zhu and P. Leach and S. Hartman",
  title="{Anonymity Support for Kerberos}",
  howpublished="RFC 6112 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6112",
  pages="1--16",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8062",
url="https://www.rfc-editor.org/rfc/rfc6112.txt",
  key="RFC 6112",
  abstract={This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm.  It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC).  This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]},
  keywords="kerberos realm",
  doi="10.17487/RFC6112",
  }

@misc{rfc6113,
  author="S. Hartman and L. Zhu",
  title="{A Generalized Framework for Kerberos Pre-Authentication}",
  howpublished="RFC 6113 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6113",
  pages="1--48",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6113.txt",
  key="RFC 6113",
  abstract={Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal. This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6113",
  }

@misc{rfc6114,
  author="M. Katagi and S. Moriai",
  title="{The 128-Bit Blockcipher CLEFIA}",
  howpublished="RFC 6114 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6114",
  pages="1--33",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6114.txt",
  key="RFC 6114",
  abstract={This document describes the specification of the blockcipher CLEFIA.  CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES).  The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community.  CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES.  Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware.  CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="security, lightweight cryptography, encryption algorithm",
  doi="10.17487/RFC6114",
  }

@misc{rfc6115,
  author="T. Li",
  title="{Recommendation for a Routing Architecture}",
  howpublished="RFC 6115 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6115",
  pages="1--73",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6115.txt",
  key="RFC 6115",
  abstract={It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering.  This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet.  To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs.  This document is a product of the Routing Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6115",
  }

@misc{rfc6116,
  author="S. Bradner and L. Conroy and K. Fujiwara",
  title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)}",
  howpublished="RFC 6116 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6116",
  pages="1--22",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6116.txt",
  key="RFC 6116",
  abstract={This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup.  This document also describes how the DNS can be used to identify the services associated with an E.164 number.  This document obsoletes RFC 3761. [STANDARDS-TRACK]},
  keywords="DNS, E.164, NAPTR, dynamic delegation discovery system, e164.arpa",
  doi="10.17487/RFC6116",
  }

@misc{rfc6117,
  author="B. Hoeneisen and A. Mayrhofer and J. Livingood",
  title="{IANA Registration of Enumservices: Guide, Template, and IANA Considerations}",
  howpublished="RFC 6117 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6117",
  pages="1--40",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6117.txt",
  key="RFC 6117",
  abstract={This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]},
  keywords="domain name system",
  doi="10.17487/RFC6117",
  }

@misc{rfc6118,
  author="B. Hoeneisen and A. Mayrhofer",
  title="{Update of Legacy IANA Registrations of Enumservices}",
  howpublished="RFC 6118 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6118",
  pages="1--68",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6118.txt",
  key="RFC 6118",
  abstract={This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]},
  keywords="domain name system",
  doi="10.17487/RFC6118",
  }

@misc{rfc6119,
  author="J. Harrison and J. Berger and M. Bartlett",
  title="{IPv6 Traffic Engineering in IS-IS}",
  howpublished="RFC 6119 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6119",
  pages="1--10",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6119.txt",
  key="RFC 6119",
  abstract={This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol.  This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6119",
  }

@misc{rfc6120,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Core}",
  howpublished="RFC 6120 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6120",
  pages="1--211",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7590",
url="https://www.rfc-editor.org/rfc/rfc6120.txt",
  key="RFC 6120",
  abstract={The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability (``presence''), and request-response interactions.  This document obsoletes RFC 3920. [STANDARDS-TRACK]},
  keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, Messaging, Instant Messaging, Presence, Extensible Markup Language, XML",
  doi="10.17487/RFC6120",
  }

@misc{rfc6121,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence}",
  howpublished="RFC 6121 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6121",
  pages="1--114",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6121.txt",
  key="RFC 6121",
  abstract={This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779.  This document obsoletes RFC 3921. [STANDARDS-TRACK]},
  keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, IM, Instant Messaging, Presence, XML, Extensible Markup Language",
  doi="10.17487/RFC6121",
  }

@misc{rfc6122,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Address Format}",
  howpublished="RFC 6122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6122",
  pages="1--23",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7622",
url="https://www.rfc-editor.org/rfc/rfc6122.txt",
  key="RFC 6122",
  abstract={This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters.  This document updates RFC 3920. [STANDARDS-TRACK]},
  keywords="XMPP, Jabber, Messaging, Instant Messaging, Presence, Extensible Markup Language, XML",
  doi="10.17487/RFC6122",
  }

@misc{rfc6123,
  author="A. Farrel",
  title="{Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts}",
  howpublished="RFC 6123 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6123",
  pages="1--13",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6123.txt",
  key="RFC 6123",
  abstract={It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. The Operations Area has developed ``Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions'' (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group. Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of ``Manageability Considerations'' sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.},
  doi="10.17487/RFC6123",
  }

@misc{rfc6124,
  author="Y. Sheffer and G. Zorn and H. Tschofenig and S. Fluhrer",
  title="{An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol}",
  howpublished="RFC 6124 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6124",
  pages="1--33",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6124.txt",
  key="RFC 6124",
  abstract={The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms.  This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol.  This method provides mutual authentication through the use of a short, easy to remember password.  Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks.  Neither does it require the availability of public-key certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="password-based authentication, mutual authentication, password-based cryptography, password authenticated key exchange, weak password authentication",
  doi="10.17487/RFC6124",
  }

@misc{rfc6125,
  author="P. Saint-Andre and J. Hodges",
  title="{Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)}",
  howpublished="RFC 6125 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6125",
  pages="1--57",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6125.txt",
  key="RFC 6125",
  abstract={Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS).  This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6125",
  }

@misc{rfc6126,
  author="J. Chroboczek",
  title="{The Babel Routing Protocol}",
  howpublished="RFC 6126 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6126",
  pages="1--45",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7298, 7557",
url="https://www.rfc-editor.org/rfc/rfc6126.txt",
  key="RFC 6126",
  abstract={Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6126",
  }

@misc{rfc6127,
  author="J. Arkko and M. Townsley",
  title="{IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios}",
  howpublished="RFC 6127 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6127",
  pages="1--20",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6127.txt",
  key="RFC 6127",
  abstract={When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="address depletion, translation, NAT-PT, dual-stack, Softwire, Behave, NAT, NAT444",
  doi="10.17487/RFC6127",
  }

@misc{rfc6128,
  author="A. Begen",
  title="{RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions}",
  howpublished="RFC 6128 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6128",
  pages="1--6",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6128.txt",
  key="RFC 6128",
  abstract={The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic.  In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description.  However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the ``m='' line of the media description.  Deriving the RTCP port from the ``m='' line imposes an unnecessary restriction.  This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6128",
  }

@misc{rfc6129,
  author="L. Romary and S. Lundberg",
  title="{The 'application/tei+xml' Media Type}",
  howpublished="RFC 6129 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6129",
  pages="1--8",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6129.txt",
  key="RFC 6129",
  abstract={This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Text Encoding Initiative, xml, text encoding, text representation, MIME type",
  doi="10.17487/RFC6129",
  }

@misc{rfc6130,
  author="T. Clausen and C. Dearlove and J. Dean",
  title="{Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)}",
  howpublished="RFC 6130 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6130",
  pages="1--88",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7183, 7188, 7466",
url="https://www.rfc-editor.org/rfc/rfc6130.txt",
  key="RFC 6130",
  abstract={This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]},
  keywords="MANET, OLSRv2, packetbb, Routing Protocol, NHDP, ad hoc network, bi-directional, 2-hop discovery, Wireless, SMF",
  doi="10.17487/RFC6130",
  }

@misc{rfc6131,
  author="R. George and B. Leiba",
  title="{Sieve Vacation Extension: ``Seconds'' Parameter}",
  howpublished="RFC 6131 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6131",
  pages="1--5",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6131.txt",
  key="RFC 6131",
  abstract={This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ``:seconds'' parameter. [STANDARDS-TRACK]},
  keywords="email, filters, auto-replies",
  doi="10.17487/RFC6131",
  }

@misc{rfc6132,
  author="R. George and B. Leiba",
  title="{Sieve Notification Using Presence Information}",
  howpublished="RFC 6132 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6132",
  pages="1--8",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6132.txt",
  key="RFC 6132",
  abstract={This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify\_method\_capability feature. [STANDARDS-TRACK]},
  keywords="email, filters, context, status",
  doi="10.17487/RFC6132",
  }

@misc{rfc6133,
  author="R. George and B. Leiba and A. Melnikov",
  title="{Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality}",
  howpublished="RFC 6133 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6133",
  pages="1--9",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6133.txt",
  key="RFC 6133",
  abstract={This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6133",
  }

@misc{rfc6134,
  author="A. Melnikov and B. Leiba",
  title="{Sieve Extension: Externally Stored Lists}",
  howpublished="RFC 6134 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6134",
  pages="1--18",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6134.txt",
  key="RFC 6134",
  abstract={The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6134",
  }

@misc{rfc6135,
  author="C. Holmberg and S. Blau",
  title="{An Alternative Connection Model for the Message Session Relay Protocol (MSRP)}",
  howpublished="RFC 6135 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6135",
  pages="1--8",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6135.txt",
  key="RFC 6135",
  abstract={This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection.  The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]},
  keywords="comedia, comedia-tls, relay, SBC",
  doi="10.17487/RFC6135",
  }

@misc{rfc6136,
  author="A. Sajassi and D. Mohan",
  title="{Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework}",
  howpublished="RFC 6136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6136",
  pages="1--42",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6136.txt",
  key="RFC 6136",
  abstract={This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM).  The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels.  This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS).  Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6136",
  }

@misc{rfc6137,
  author="D. Zisiadis and S. Kopsidas and M. Tsavli and G. Cessieux",
  title="{The Network Trouble Ticket Data Model (NTTDM)}",
  howpublished="RFC 6137 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6137",
  pages="1--46",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6137.txt",
  key="RFC 6137",
  abstract={Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.},
  keywords="Grid, Management, EGEE",
  doi="10.17487/RFC6137",
  }

@misc{rfc6138,
  author="S. Kini and W. Lu",
  title="{LDP IGP Synchronization for Broadcast Networks}",
  howpublished="RFC 6138 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6138",
  pages="1--9",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6138.txt",
  key="RFC 6138",
  abstract={RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not.  If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer.  When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network.  This document describes a mechanism to address that use-case without dropping traffic.  The mechanism does not introduce any protocol message changes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6138",
  }

@misc{rfc6139,
  author="S. Russert and E. Fleischman and F. Templin",
  title="{Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios}",
  howpublished="RFC 6139 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6139",
  pages="1--39",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6139.txt",
  key="RFC 6139",
  abstract={``Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)'' (RFC 5720) provides an architectural framework for scalable routing and addressing.  It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security.  This document describes a series of use cases in order to showcase the architectural capabilities.  It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Encapsulation, Tunnel, Architecture, Scalability, Mobility, MANET, Security, IPv6, Aerospace, IRON, VET, SEAL, ISATAP",
  doi="10.17487/RFC6139",
  }

@misc{rfc6140,
  author="A.B. Roach",
  title="{Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6140 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6140",
  pages="1--35",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6140.txt",
  key="RFC 6140",
  abstract={This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs).  In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts.  This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.  This document therefore focuses on this use case. [STANDARDS-TRACK]},
  keywords="Bulk Registration, Implicit Registration, GIN, PBX, SSP, SIP-PBX",
  doi="10.17487/RFC6140",
  }

@misc{rfc6141,
  author="G. Camarillo and C. Holmberg and Y. Gao",
  title="{Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6141 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6141",
  pages="1--26",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6141.txt",
  key="RFC 6141",
  abstract={The procedures for handling SIP re-INVITEs are described in RFC 3261.  Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues.  In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE.  Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]},
  keywords="re-INVITE, offer/answer, rollback",
  doi="10.17487/RFC6141",
  }

@misc{rfc6142,
  author="A. Moise and J. Brodkin",
  title="{ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP}",
  howpublished="RFC 6142 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6142",
  pages="1--26",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6142.txt",
  key="RFC 6142",
  abstract={This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network. This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Advanced Metering Infrastructure, ami, application layer message",
  doi="10.17487/RFC6142",
  }

@misc{rfc6143,
  author="T. Richardson and J. Levine",
  title="{The Remote Framebuffer Protocol}",
  howpublished="RFC 6143 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6143",
  pages="1--39",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6143.txt",
  key="RFC 6143",
  abstract={RFB (``remote framebuffer'') is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer.  Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications.  This document describes the protocol used to communicate between an RFB client and RFB server.  RFB is the protocol used in VNC.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="vnc, rfb, remote framebuffer, remote GUI",
  doi="10.17487/RFC6143",
  }

@misc{rfc6144,
  author="F. Baker and X. Li and C. Bao and K. Yin",
  title="{Framework for IPv4/IPv6 Translation}",
  howpublished="RFC 6144 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6144",
  pages="1--31",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6144.txt",
  key="RFC 6144",
  abstract={This note describes a framework for IPv4/IPv6 translation.  This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="stateless translation, stateful translation",
  doi="10.17487/RFC6144",
  }

@misc{rfc6145,
  author="X. Li and C. Bao and F. Baker",
  title="{IP/ICMP Translation Algorithm}",
  howpublished="RFC 6145 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6145",
  pages="1--33",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7915, updated by RFCs 6791, 7757",
url="https://www.rfc-editor.org/rfc/rfc6145.txt",
  key="RFC 6145",
  abstract={This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers).  This document obsoletes RFC 2765. [STANDARDS-TRACK]},
  keywords="SIIT], internet, protocol, control, message, IPv4, IPv6, Stateless IP/ICMP Translation Algorithm,",
  doi="10.17487/RFC6145",
  }

@misc{rfc6146,
  author="M. Bagnulo and P. Matthews and I. van Beijnum",
  title="{Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers}",
  howpublished="RFC 6146 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6146",
  pages="1--45",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6146.txt",
  key="RFC 6146",
  keywords="NAT64, IPv6",
  doi="10.17487/RFC6146",
  }

@misc{rfc6147,
  author="M. Bagnulo and A. Sullivan and P. Matthews and I. van Beijnum",
  title="{DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers}",
  howpublished="RFC 6147 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6147",
  pages="1--32",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6147.txt",
  key="RFC 6147",
  abstract={DNS64 is a mechanism for synthesizing AAAA records from A records.  DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs.  This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]},
  keywords="AAAA",
  doi="10.17487/RFC6147",
  }

@misc{rfc6148,
  author="P. Kurapati and R. Desetti and B. Joshi",
  title="{DHCPv4 Lease Query by Relay Agent Remote ID}",
  howpublished="RFC 6148 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6148",
  pages="1--13",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6148.txt",
  key="RFC 6148",
  abstract={Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server.  This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding.  RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost.  The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients.  In certain scenarios, this model is not scalable.  This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]},
  keywords="dynamic host configuration protocol",
  doi="10.17487/RFC6148",
  }

@misc{rfc6149,
  author="S. Turner and L. Chen",
  title="{MD2 to Historic Status}",
  howpublished="RFC 6149 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6149",
  pages="1--7",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6149.txt",
  key="RFC 6149",
  abstract={This document retires MD2 and discusses the reasons for doing so.  This document moves RFC 1319 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="security, encryption, signature",
  doi="10.17487/RFC6149",
  }

@misc{rfc6150,
  author="S. Turner and L. Chen",
  title="{MD4 to Historic Status}",
  howpublished="RFC 6150 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6150",
  pages="1--10",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6150.txt",
  key="RFC 6150",
  abstract={This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so.  This document moves RFC 1320 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MD4, security, encryption, signature",
  doi="10.17487/RFC6150",
  }

@misc{rfc6151,
  author="S. Turner and L. Chen",
  title="{Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms}",
  howpublished="RFC 6151 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6151",
  pages="1--7",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6151.txt",
  key="RFC 6151",
  abstract={This document updates the security considerations for the MD5 message digest algorithm.  It also updates the security considerations for HMAC-MD5.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="signature, eneryption, ipsec, Message Digest, encryption",
  doi="10.17487/RFC6151",
  }

@misc{rfc6152,
  author="J. Klensin and N. Freed and M. Rose and D. Crocker",
  title="{SMTP Service Extension for 8-bit MIME Transport}",
  howpublished="RFC 6152 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6152",
  pages="1--7",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6152.txt",
  key="RFC 6152",
  abstract={This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]},
  keywords="simple mail transfer",
  doi="10.17487/RFC6152",
  }

@misc{rfc6153,
  author="S. Das and G. Bajko",
  title="{DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery}",
  howpublished="RFC 6153 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6153",
  pages="1--7",
  year=2011,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6153.txt",
  key="RFC 6153",
  abstract={This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network.  ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]},
  keywords="Dynamic Host Configuration Protocol",
  doi="10.17487/RFC6153",
  }

@misc{rfc6154,
  author="B. Leiba and J. Nicolson",
  title="{IMAP LIST Extension for Special-Use Mailboxes}",
  howpublished="RFC 6154 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6154",
  pages="1--12",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6154.txt",
  key="RFC 6154",
  abstract={Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages.  Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes.  This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]},
  keywords="IMAP, email",
  doi="10.17487/RFC6154",
  }

@misc{rfc6155,
  author="J. Winterbottom and M. Thomson and H. Tschofenig and R. Barnes",
  title="{Use of Device Identity in HTTP-Enabled Location Delivery (HELD)}",
  howpublished="RFC 6155 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6155",
  pages="1--27",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6915",
url="https://www.rfc-editor.org/rfc/rfc6155.txt",
  key="RFC 6155",
  abstract={When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address. Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6155",
  }

@misc{rfc6156,
  author="G. Camarillo and O. Novo and S. Perreault",
  title="{Traversal Using Relays around NAT (TURN) Extension for IPv6}",
  howpublished="RFC 6156 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6156",
  pages="1--14",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6156.txt",
  key="RFC 6156",
  abstract={This document adds IPv6 support to Traversal Using Relays around NAT (TURN).  IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying.  This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN.  The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]},
  keywords="STUN, TURN, IPv6",
  doi="10.17487/RFC6156",
  }

@misc{rfc6157,
  author="G. Camarillo and K. El Malki and V. Gurbani",
  title="{IPv6 Transition in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6157 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6157",
  pages="1--15",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6157.txt",
  key="RFC 6157",
  abstract={This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up.  Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6157",
  }

@misc{rfc6158,
  author="A. DeKok and G. Weber",
  title="{RADIUS Design Guidelines}",
  howpublished="RFC 6158 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6158",
  pages="1--38",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6929, 8044",
url="https://www.rfc-editor.org/rfc/rfc6158.txt",
  key="RFC 6158",
  abstract={This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.  It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs).  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6158",
  }

@misc{rfc6159,
  author="T. Tsou and G. Zorn and T. Taylor",
  title="{Session-Specific Explicit Diameter Request Routing}",
  howpublished="RFC 6159 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6159",
  pages="1--19",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6159.txt",
  key="RFC 6159",
  abstract={This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Diameter routing",
  doi="10.17487/RFC6159",
  }

@misc{rfc6160,
  author="S. Turner",
  title="{Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types}",
  howpublished="RFC 6160 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6160",
  pages="1--5",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6160.txt",
  key="RFC 6160",
  abstract={This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6160",
  }

@misc{rfc6161,
  author="S. Turner",
  title="{Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}",
  howpublished="RFC 6161 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6161",
  pages="1--3",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6161.txt",
  key="RFC 6161",
  abstract={This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 6033. [STANDARDS-TRACK]},
  keywords="ecdsa, ecdh, EnvelopedData and Elliptic Curve Digital Signature Algorithm",
  doi="10.17487/RFC6161",
  }

@misc{rfc6162,
  author="S. Turner",
  title="{Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type}",
  howpublished="RFC 6162 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6162",
  pages="1--4",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6162.txt",
  key="RFC 6162",
  abstract={This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 5959. [STANDARDS-TRACK]},
  keywords="ecdsa, ecdh, EnvelopedData and Elliptic Curve Digital Signature Algorithm",
  doi="10.17487/RFC6162",
  }

@misc{rfc6163,
  author="Y. Lee and G. Bernstein and W. Imajuku",
  title="{Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)}",
  howpublished="RFC 6163 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6163",
  pages="1--51",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6163.txt",
  key="RFC 6163",
  abstract={This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Generalized Multi-Protocol Label Switching, Routing and Wavelength Assignment, RWA",
  doi="10.17487/RFC6163",
  }

@misc{rfc6164,
  author="M. Kohno and B. Nitzan and R. Bush and Y. Matsuzaki and L. Colitti and T. Narten",
  title="{Using 127-Bit IPv6 Prefixes on Inter-Router Links}",
  howpublished="RFC 6164 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6164",
  pages="1--8",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6547",
url="https://www.rfc-editor.org/rfc/rfc6164.txt",
  key="RFC 6164",
  abstract={On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes.  Such a practice parallels the use of 31-bit prefixes in IPv4.  This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]},
  keywords="addressing, prefix length, security",
  doi="10.17487/RFC6164",
  }

@misc{rfc6165,
  author="A. Banerjee and D. Ward",
  title="{Extensions to IS-IS for Layer-2 Systems}",
  howpublished="RFC 6165 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6165",
  pages="1--7",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6165.txt",
  key="RFC 6165",
  abstract={This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2.  While supporting this concept involves several pieces, this document only describes extensions to IS-IS.  Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions.  We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]},
  keywords="Intermediate System to Intermediate System",
  doi="10.17487/RFC6165",
  }

@misc{rfc6166,
  author="S. Venaas",
  title="{A Registry for PIM Message Types}",
  howpublished="RFC 6166 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6166",
  pages="1--4",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6166.txt",
  key="RFC 6166",
  abstract={This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types. In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]},
  keywords="IANA, Protocol Independent Multicast",
  doi="10.17487/RFC6166",
  }

@misc{rfc6167,
  author="M. Phillips and P. Adams and D. Rokicki and E. Johnson",
  title="{URI Scheme for Java(tm) Message Service 1.0}",
  howpublished="RFC 6167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6167",
  pages="1--22",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6167.txt",
  key="RFC 6167",
  abstract={This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS).  It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination.  The syntax of this JMS URI is not compatible with previously existing, but unregistered, ``jms'' URI schemes.  However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SOAP, JMS, JNDI, IRI",
  doi="10.17487/RFC6167",
  }

@misc{rfc6168,
  author="W. Hardaker",
  title="{Requirements for Management of Name Servers for the DNS}",
  howpublished="RFC 6168 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6168",
  pages="1--17",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6168.txt",
  key="RFC 6168",
  abstract={Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself. This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DNS, Domain Name System, Management",
  doi="10.17487/RFC6168",
  }

@misc{rfc6169,
  author="S. Krishnan and D. Thaler and J. Hoagland",
  title="{Security Concerns with IP Tunneling}",
  howpublished="RFC 6169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6169",
  pages="1--20",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6169.txt",
  key="RFC 6169",
  abstract={A number of security concerns with IP tunnels are documented in this memo.  The intended audience of this document includes network administrators and future protocol developers.  The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6169",
  }

@misc{rfc6170,
  author="S. Santesson and R. Housley and S. Bajaj and L. Rosenthol",
  title="{Internet X.509 Public Key Infrastructure -- Certificate Image}",
  howpublished="RFC 6170 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6170",
  pages="1--12",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6170.txt",
  key="RFC 6170",
  abstract={This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new ``otherLogos'' image type according to RFC 3709. [STANDARDS-TRACK]},
  keywords="otherLogos",
  doi="10.17487/RFC6170",
  }

@misc{rfc6171,
  author="K. Zeilenga",
  title="{The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control}",
  howpublished="RFC 6171 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6171",
  pages="1--6",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6171.txt",
  key="RFC 6171",
  abstract={This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service.  This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]},
  keywords="x.511, dontusecopy",
  doi="10.17487/RFC6171",
  }

@misc{rfc6172,
  author="D. Black and D. Peterson",
  title="{Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode}",
  howpublished="RFC 6172 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6172",
  pages="1--6",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6172.txt",
  key="RFC 6172",
  abstract={Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document. This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]},
  keywords="FCIP",
  doi="10.17487/RFC6172",
  }

@misc{rfc6173,
  author="P. Venkatesen",
  title="{Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)}",
  howpublished="RFC 6173 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6173",
  pages="1--31",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6173.txt",
  key="RFC 6173",
  abstract={This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols. This document obsoletes RFC 4369. [STANDARDS-TRACK]},
  keywords="Management Information Base, mib, IFCP-MGMT-MIB",
  doi="10.17487/RFC6173",
  }

@misc{rfc6174,
  author="E. Juskevicius",
  title="{Definition of IETF Working Group Document States}",
  howpublished="RFC 6174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6174",
  pages="1--25",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6174.txt",
  key="RFC 6174",
  abstract={The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible. This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="WG I-D States, I-D Availability States",
  doi="10.17487/RFC6174",
  }

@misc{rfc6175,
  author="E. Juskevicius",
  title="{Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors}",
  howpublished="RFC 6175 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6175",
  pages="1--23",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6175.txt",
  key="RFC 6175",
  abstract={This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs.  After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="WG Document States, I-D States",
  doi="10.17487/RFC6175",
  }

@misc{rfc6176,
  author="S. Turner and T. Polk",
  title="{Prohibiting Secure Sockets Layer (SSL) Version 2.0}",
  howpublished="RFC 6176 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6176",
  pages="1--4",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6176.txt",
  key="RFC 6176",
  abstract={This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0.  This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6176",
  }

@misc{rfc6177,
  author="T. Narten and G. Huston and L. Roberts",
  title="{IPv6 Address Assignment to End Sites}",
  howpublished="RFC 6177 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6177",
  pages="1--9",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6177.txt",
  key="RFC 6177",
  abstract={RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. [STANDARDS-TRACK]},
  keywords="internet architecture board, engineering steering group, protocol",
  doi="10.17487/RFC6177",
  }

@misc{rfc6178,
  author="D. Smith and J. Mullooly and W. Jaeger and T. Scholl",
  title="{Label Edge Router Forwarding of IPv4 Option Packets}",
  howpublished="RFC 6178 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6178",
  pages="1--9",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6178.txt",
  key="RFC 6178",
  abstract={This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options.  Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC).  IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure.  Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments.  While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]},
  keywords="FEC, MPLS, LER, Security, DoS",
  doi="10.17487/RFC6178",
  }

@misc{rfc6179,
  author="F. Templin",
  title="{The Internet Routing Overlay Network (IRON)}",
  howpublished="RFC 6179 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6179",
  pages="1--37",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6179.txt",
  key="RFC 6179",
  abstract={Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated.  This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system.  IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal.  While business considerations are an important determining factor for widespread adoption, they are out of scope for this document.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Encapsulation, Tunnel, Architecture, Scalability, Mobility, MANET, Security, Recursion, Addressing, Routing, IPv6, Aerospace, Aeronautics, Space, IRON, RANGER, VET, SEAL, ISATAP",
  doi="10.17487/RFC6179",
  }

@misc{rfc6180,
  author="J. Arkko and F. Baker",
  title="{Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment}",
  howpublished="RFC 6180 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6180",
  pages="1--20",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6180.txt",
  key="RFC 6180",
  abstract={The Internet continues to grow beyond the capabilities of IPv4.  An expansion in the address space is clearly required.  With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table.  Yet, IPv6 deployment requires some effort, resources, and expertise.  The availability of many different deployment models is one reason why expertise is required.  This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6180",
  }

@misc{rfc6181,
  author="M. Bagnulo",
  title="{Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses}",
  howpublished="RFC 6181 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6181",
  pages="1--17",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6181.txt",
  key="RFC 6181",
  abstract={Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data.  Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios.  Some level of multihoming and mobility support can be achieved through these extensions.  However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP.  This note includes a threat analysis for MPTCP.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Multipath TCP, threats, security, MPTCP",
  doi="10.17487/RFC6181",
  }

@misc{rfc6182,
  author="A. Ford and C. Raiciu and M. Handley and S. Barre and J. Iyengar",
  title="{Architectural Guidelines for Multipath TCP Development}",
  howpublished="RFC 6182 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6182",
  pages="1--28",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6182.txt",
  key="RFC 6182",
  abstract={Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="multipath tcp architecture",
  doi="10.17487/RFC6182",
  }

@misc{rfc6183,
  author="A. Kobayashi and B. Claise and G. Muenz and K. Ishibashi",
  title="{IP Flow Information Export (IPFIX) Mediation: Framework}",
  howpublished="RFC 6183 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6183",
  pages="1--29",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6183.txt",
  key="RFC 6183",
  abstract={This document describes a framework for IP Flow Information Export (IPFIX) Mediation.  This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6183",
  }

@misc{rfc6184,
  author="Y.-K. Wang and R. Even and T. Kristensen and R. Jesup",
  title="{RTP Payload Format for H.264 Video}",
  howpublished="RFC 6184 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6184",
  pages="1--101",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6184.txt",
  key="RFC 6184",
  abstract={This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]},
  keywords="AVC, H.264/AVC, Advanced Video Coding",
  doi="10.17487/RFC6184",
  }

@misc{rfc6185,
  author="T. Kristensen and P. Luthi",
  title="{RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video}",
  howpublished="RFC 6185 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6185",
  pages="1--22",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6185.txt",
  key="RFC 6185",
  abstract={This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241.  RCDO reduces the decoding cost and resource consumption of the video processing.  The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]},
  keywords="H.264, H.241, ITU-T, RTP, Video, SDP, RCDO",
  doi="10.17487/RFC6185",
  }

@misc{rfc6186,
  author="C. Daboo",
  title="{Use of SRV Records for Locating Email Submission/Access Services}",
  howpublished="RFC 6186 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6186",
  pages="1--9",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6186.txt",
  key="RFC 6186",
  abstract={This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]},
  keywords="imap, pop3, smtp, dns, discovery",
  doi="10.17487/RFC6186",
  }

@misc{rfc6187,
  author="K. Igoe and D. Stebila",
  title="{X.509v3 Certificates for Secure Shell Authentication}",
  howpublished="RFC 6187 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6187",
  pages="1--16",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6187.txt",
  key="RFC 6187",
  abstract={X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity.  This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6187",
  }

@misc{rfc6188,
  author="D. McGrew",
  title="{The Use of AES-192 and AES-256 in Secure RTP}",
  howpublished="RFC 6188 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6188",
  pages="1--16",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6188.txt",
  key="RFC 6188",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol.  It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]},
  keywords="SRTP",
  doi="10.17487/RFC6188",
  }

@misc{rfc6189,
  author="P. Zimmermann and A. Johnston and J. Callas",
  title="{ZRTP: Media Path Key Agreement for Unicast Secure RTP}",
  howpublished="RFC 6189 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6189",
  pages="1--115",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6189.txt",
  key="RFC 6189",
  abstract={This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications.  The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol.  ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices.  For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication.  ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel.  To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles.  ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6189",
  }

@misc{rfc6190,
  author="S. Wenger and Y.-K. Wang and T. Schierl and A. Eleftheriadis",
  title="{RTP Payload Format for Scalable Video Coding}",
  howpublished="RFC 6190 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6190",
  pages="1--100",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6190.txt",
  key="RFC 6190",
  abstract={This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10.  The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets.  Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions.  The payload format defines a new media subtype name ``H264-SVC'', but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name (``H264'') and the packetization method specified in RFC 6184.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]},
  keywords="SVC, AVC, H.264/AVC, Advanced Video Coding, Scalable Video Coding",
  doi="10.17487/RFC6190",
  }

@misc{rfc6191,
  author="F. Gont",
  title="{Reducing the TIME-WAIT State Using TCP Timestamps}",
  howpublished="RFC 6191 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6191",
  pages="1--10",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6191.txt",
  key="RFC 6191",
  abstract={This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment.  This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6191",
  }

@misc{rfc6192,
  author="D. Dugal and C. Pignataro and R. Dunn",
  title="{Protecting the Router Control Plane}",
  howpublished="RFC 6192 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6192",
  pages="1--25",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6192.txt",
  key="RFC 6192",
  abstract={This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level. Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ACL, Router Control Plane Protection, Filter",
  doi="10.17487/RFC6192",
  }

@misc{rfc6193,
  author="M. Saito and D. Wing and M. Toyama",
  title="{Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)}",
  howpublished="RFC 6193 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6193",
  pages="1--22",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6193.txt",
  key="RFC 6193",
  abstract={This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers.  It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model.  It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SIP, IPsec, setup, VPN",
  doi="10.17487/RFC6193",
  }

@misc{rfc6194,
  author="T. Polk and L. Chen and S. Turner and P. Hoffman",
  title="{Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms}",
  howpublished="RFC 6194 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6194",
  pages="1--7",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6194.txt",
  key="RFC 6194",
  abstract={This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6194",
  }

@misc{rfc6195,
  author="D. {Eastlake 3rd}",
  title="{Domain Name System (DNS) IANA Considerations}",
  howpublished="RFC 6195 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6195",
  pages="1--17",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6895",
url="https://www.rfc-editor.org/rfc/rfc6195.txt",
  key="RFC 6195",
  abstract={This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  This memo documents an Internet Best Current Practice.},
  keywords="RRTYPE, RCODE, AFSDB",
  doi="10.17487/RFC6195",
  }

@misc{rfc6196,
  author="A. Melnikov",
  title="{Moving mailserver: URI Scheme to Historic}",
  howpublished="RFC 6196 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6196",
  pages="1--3",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6196.txt",
  key="RFC 6196",
  abstract={This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]},
  keywords="mailserver, URI",
  doi="10.17487/RFC6196",
  }

@misc{rfc6197,
  author="K. Wolf",
  title="{Location-to-Service Translation (LoST) Service List Boundary Extension}",
  howpublished="RFC 6197 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6197",
  pages="1--15",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6197.txt",
  key="RFC 6197",
  abstract={Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs.  If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server.  However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid.  Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.  This document defines an Experimental Protocol for the Internet community.},
  keywords="listservicesbylocation",
  doi="10.17487/RFC6197",
  }

@misc{rfc6198,
  author="B. Decraene and P. Francois and C. Pelsser and Z. Ahmad and A.J. Elizondo Armengol and T. Takeda",
  title="{Requirements for the Graceful Shutdown of BGP Sessions}",
  howpublished="RFC 6198 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6198",
  pages="1--20",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6198.txt",
  key="RFC 6198",
  abstract={The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services.  For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic.  However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence.  This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN).  Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown.  This document expresses requirements for such a solution.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="routing, BGP, graceful, shutdown, connectivity loss, maintenance, network operation, make-before-break, planned",
  doi="10.17487/RFC6198",
  }

@misc{rfc6201,
  author="R. Asati and C. Pignataro and F. Calabria and C. Olvera",
  title="{Device Reset Characterization}",
  howpublished="RFC 6201 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6201",
  pages="1--17",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6201.txt",
  key="RFC 6201",
  abstract={An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a ``reset'' in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation. This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term ``reset time'' and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="operation redundancy failover",
  doi="10.17487/RFC6201",
  }

@misc{rfc6202,
  author="S. Loreto and P. Saint-Andre and S. Salsano and G. Wilkins",
  title="{Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP}",
  howpublished="RFC 6202 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6202",
  pages="1--19",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6202.txt",
  key="RFC 6202",
  abstract={On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, ``server- initiated'' communication from a server to a client as well as communication from a client to a server.  This document describes known issues and best practices related to such ``bidirectional HTTP'' applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Hypertext Transfer Protocol, bidirectional HTTP, HTTP long polling, HTTP streaming",
  doi="10.17487/RFC6202",
  }

@misc{rfc6203,
  author="T. Sirainen",
  title="{IMAP4 Extension for Fuzzy Search}",
  howpublished="RFC 6203 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6203",
  pages="1--7",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6203.txt",
  key="RFC 6203",
  abstract={This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]},
  keywords="email",
  doi="10.17487/RFC6203",
  }

@misc{rfc6204,
  author="H. Singh and W. Beebee and C. Donley and B. Stark and O. Troan",
  title="{Basic Requirements for IPv6 Customer Edge Routers}",
  howpublished="RFC 6204 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6204",
  pages="1--17",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7084",
url="https://www.rfc-editor.org/rfc/rfc6204.txt",
  key="RFC 6204",
  abstract={This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6 CE requirements",
  doi="10.17487/RFC6204",
  }

@misc{rfc6205,
  author="T. Otani and D. Li",
  title="{Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers}",
  howpublished="RFC 6205 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6205",
  pages="1--15",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7699",
url="https://www.rfc-editor.org/rfc/rfc6205.txt",
  key="RFC 6205",
  abstract={Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed. Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered. In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]},
  keywords="DWDM, CWDM, Wavelength Label, LSC",
  doi="10.17487/RFC6205",
  }

@misc{rfc6206,
  author="P. Levis and T. Clausen and J. Hui and O. Gnawali and J. Ko",
  title="{The Trickle Algorithm}",
  howpublished="RFC 6206 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6206",
  pages="1--13",
  year=2011,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6206.txt",
  key="RFC 6206",
  abstract={The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner.  Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change.  A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density.  This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]},
  keywords="Consistency, Eventual consistency, Low-power, Low power",
  doi="10.17487/RFC6206",
  }

@misc{rfc6207,
  author="R. Denenberg",
  title="{The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml}",
  howpublished="RFC 6207 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6207",
  pages="1--11",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6207.txt",
  key="RFC 6207",
  abstract={This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema.  These are all XML schemas providing representations of various forms of information including metadata and search results.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mods, Metadata Object Description Schema, MADS, Metadata Authority Description Schema, METS, Metadata Encoding and Transmission Standard, MARCXML, MARC21 XML Schema, SRU, Search/Retrieve via URL Response Format",
  doi="10.17487/RFC6207",
  }

@misc{rfc6208,
  author="K. Sankar and A. Jones",
  title="{Cloud Data Management Interface (CDMI) Media Types}",
  howpublished="RFC 6208 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6208",
  pages="1--13",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6208.txt",
  key="RFC 6208",
  abstract={This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are: o application/cdmi-object o application/cdmi-container o application/cdmi-domain o application/cdmi-capability o application/cdmi-queue This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="snia, Storage Networking Industry Association",
  doi="10.17487/RFC6208",
  }

@misc{rfc6209,
  author="W. Kim and J. Lee and J. Park and D. Kwon",
  title="{Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)}",
  howpublished="RFC 6209 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6209",
  pages="1--9",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6209.txt",
  key="RFC 6209",
  abstract={This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="aria encryption",
  doi="10.17487/RFC6209",
  }

@misc{rfc6210,
  author="J. Schaad",
  title="{Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME}",
  howpublished="RFC 6210 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6210",
  pages="1--14",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6210.txt",
  key="RFC 6210",
  abstract={New hash algorithms are being developed that may include parameters.  Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems.  This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be.  This document defines an Experimental Protocol for the Internet community.},
  keywords="example, MD5-XOR, Parameterized",
  doi="10.17487/RFC6210",
  }

@misc{rfc6211,
  author="J. Schaad",
  title="{Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute}",
  howpublished="RFC 6211 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6211",
  pages="1--11",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6211.txt",
  key="RFC 6211",
  abstract={The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks.  In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process.  In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process.  This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]},
  keywords="example, s/mime, SMIME",
  doi="10.17487/RFC6211",
  }

@misc{rfc6212,
  author="M. Kucherawy",
  title="{Authentication-Results Registration for Vouch by Reference Results}",
  howpublished="RFC 6212 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6212",
  pages="1--7",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6212.txt",
  key="RFC 6212",
  abstract={This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]},
  keywords="VBR, Reputation, DKIM",
  doi="10.17487/RFC6212",
  }

@misc{rfc6213,
  author="C. Hopps and L. Ginsberg",
  title="{IS-IS BFD-Enabled TLV}",
  howpublished="RFC 6213 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6213",
  pages="1--7",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6213.txt",
  key="RFC 6213",
  abstract={This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol.  There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]},
  keywords="type-length-value, Bidirectional Forwarding Detection",
  doi="10.17487/RFC6213",
  }

@misc{rfc6214,
  author="B. Carpenter and R. Hinden",
  title="{Adaptation of RFC 1149 for IPv6}",
  howpublished="RFC 6214 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6214",
  pages="1--7",
  year=2011,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6214.txt",
  key="RFC 6214",
  abstract={This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="avian carrier, april fool",
  doi="10.17487/RFC6214",
  }

@misc{rfc6215,
  author="M. Bocci and L. Levrau and D. Frost",
  title="{MPLS Transport Profile User-to-Network and Network-to-Network Interfaces}",
  howpublished="RFC 6215 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6215",
  pages="1--6",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6215.txt",
  key="RFC 6215",
  abstract={The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6215",
  }

@misc{rfc6216,
  author="C. Jennings and K. Ono and R. Sparks and B. Hibbard",
  title="{Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms}",
  howpublished="RFC 6216 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6216",
  pages="1--67",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6216.txt",
  key="RFC 6216",
  abstract={This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP).  It also provides information that helps implementers build interoperable SIP software.  To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6216",
  }

@misc{rfc6217,
  author="T. Ritter",
  title="{Regional Broadcast Using an Atmospheric Link Layer}",
  howpublished="RFC 6217 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6217",
  pages="1--9",
  year=2011,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6217.txt",
  key="RFC 6217",
  abstract={Broadcasting is a technology that has been largely discarded in favor of technologies like multicast.  This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer.  It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6217",
  }

@misc{rfc6218,
  author="G. Zorn and T. Zhang and J. Walker and J. Salowey",
  title="{Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material}",
  howpublished="RFC 6218 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6218",
  pages="1--18",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6218.txt",
  key="RFC 6218",
  abstract={This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.  These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Security",
  doi="10.17487/RFC6218",
  }

@misc{rfc6219,
  author="X. Li and C. Bao and M. Chen and H. Zhang and J. Wu",
  title="{The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition}",
  howpublished="RFC 6219 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6219",
  pages="1--22",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6219.txt",
  key="RFC 6219",
  abstract={This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IVI is a prefix-specific and stateless address mapping mechanism for ``an IPv6 network to the IPv4 Internet'' and ``the IPv4 Internet to an IPv6 network'' scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Stateless IPv4/IPv6 translation, IPv4/IPv6 Header Translation, IPv4-embedded IPv6 Address, IPv4/IPv6 Multicast Translation, stateless NAT64",
  doi="10.17487/RFC6219",
  }

@misc{rfc6220,
  author="D. McPherson and O. Kolkman and J. Klensin and G. Huston and Internet Architecture Board",
  title="{Defining the Role and Function of IETF Protocol Parameter Registry Operators}",
  howpublished="RFC 6220 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6220",
  pages="1--11",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6220.txt",
  key="RFC 6220",
  abstract={Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets.  To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined.  The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions.  For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity.  This document provides a description of, and the requirements for, these delegated functions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6220",
  }

@misc{rfc6221,
  author="D. Miles and S. Ooghe and W. Dec and S. Krishnan and A. Kavanagh",
  title="{Lightweight DHCPv6 Relay Agent}",
  howpublished="RFC 6221 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6221",
  pages="1--17",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6221.txt",
  key="RFC 6221",
  abstract={This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces.  The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]},
  keywords="ipv6, dsl",
  doi="10.17487/RFC6221",
  }

@misc{rfc6222,
  author="A. Begen and C. Perkins and D. Wing",
  title="{Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)}",
  howpublished="RFC 6222 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6222",
  pages="1--9",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7022",
url="https://www.rfc-editor.org/rfc/rfc6222.txt",
  key="RFC 6222",
  abstract={The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint.  While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.  For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness.  This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6222",
  }

@misc{rfc6223,
  author="C. Holmberg",
  title="{Indication of Support for Keep-Alive}",
  howpublished="RFC 6223 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6223",
  pages="1--18",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6223.txt",
  key="RFC 6223",
  abstract={This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, ``keep'', which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]},
  keywords="SIP, STUN, outbound, NAT traversal",
  doi="10.17487/RFC6223",
  }

@misc{rfc6224,
  author="T. Schmidt and M. Waehlisch and S. Krishnan",
  title="{Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains}",
  howpublished="RFC 6224 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6224",
  pages="1--19",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6224.txt",
  key="RFC 6224",
  abstract={This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards.  Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions.  In this scenario, mobile nodes remain agnostic of multicast mobility operations.  Support for mobile multicast senders is outside the scope of this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MLD proxy, multicast routing, mobility management, transparent handover",
  doi="10.17487/RFC6224",
  }

@misc{rfc6225,
  author="J. Polk and M. Linsner and M. Thomson and B. Aboba",
  title="{Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information}",
  howpublished="RFC 6225 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6225",
  pages="1--36",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6225.txt",
  key="RFC 6225",
  abstract={This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client.  The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each.  Separate parameters indicate the reference datum for each of these values.  This document obsoletes RFC 3825. [STANDARDS-TRACK]},
  doi="10.17487/RFC6225",
  }

@misc{rfc6226,
  author="B. Joshi and A. Kessler and D. McWalter",
  title="{PIM Group-to-Rendezvous-Point Mapping}",
  howpublished="RFC 6226 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6226",
  pages="1--11",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6226.txt",
  key="RFC 6226",
  abstract={Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]},
  keywords="auto-RP BSR hash, algorithm",
  doi="10.17487/RFC6226",
  }

@misc{rfc6227,
  author="T. Li",
  title="{Design Goals for Scalable Internet Routing}",
  howpublished="RFC 6227 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6227",
  pages="1--8",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6227.txt",
  key="RFC 6227",
  abstract={It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering.  The Routing Research Group is investigating an alternate architecture to meet these challenges.  This document consists of a prioritized list of design goals for the target architecture.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="routing  architecture, addressing architecture",
  doi="10.17487/RFC6227",
  }

@misc{rfc6228,
  author="C. Holmberg",
  title="{Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog}",
  howpublished="RFC 6228 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6228",
  pages="1--14",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6228.txt",
  key="RFC 6228",
  abstract={This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]},
  keywords="199, Early dialog, Forking, Provisional response",
  doi="10.17487/RFC6228",
  }

@misc{rfc6229,
  author="J. Strombergson and S. Josefsson",
  title="{Test Vectors for the Stream Cipher RC4}",
  howpublished="RFC 6229 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6229",
  pages="1--12",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6229.txt",
  key="RFC 6229",
  abstract={This document contains test vectors for the stream cipher RC4.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="arcfour128, arcfour256, arcfour, ARC4m, Stream Cipher, Test Vectors, Known Answer Test, arcfour, ARC4, WEP, WPA, RFC 4345",
  doi="10.17487/RFC6229",
  }

@misc{rfc6230,
  author="C. Boulton and T. Melanchuk and S. McGlashan",
  title="{Media Control Channel Framework}",
  howpublished="RFC 6230 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6230",
  pages="1--49",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6230.txt",
  key="RFC 6230",
  abstract={This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6230",
  }

@misc{rfc6231,
  author="S. McGlashan and T. Melanchuk and C. Boulton",
  title="{An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework}",
  howpublished="RFC 6231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6231",
  pages="1--134",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6623",
url="https://www.rfc-editor.org/rfc/rfc6231.txt",
  key="RFC 6231",
  abstract={This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences.  The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.  Dialog interactions are specified in a dialog language.  This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used.  The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6231",
  }

@misc{rfc6232,
  author="F. Wei and Y. Qin and Z. Li and T. Li and J. Dong",
  title="{Purge Originator Identification TLV for IS-IS}",
  howpublished="RFC 6232 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6232",
  pages="1--6",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6232.txt",
  key="RFC 6232",
  abstract={At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS. To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge. This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]},
  keywords="Purge Originator Identification, IIH:n, LSP:y, SNP:n, Purge:y",
  doi="10.17487/RFC6232",
  }

@misc{rfc6233,
  author="T. Li and L. Ginsberg",
  title="{IS-IS Registry Extension for Purges}",
  howpublished="RFC 6233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6233",
  pages="1--4",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6233.txt",
  key="RFC 6233",
  abstract={IANA maintains the ``IS-IS TLV Codepoints'' registry.  This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a.  purges.  This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication.  This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]},
  keywords="Intermediate System to Intermediate System, LSP, security, authentication, IANA",
  doi="10.17487/RFC6233",
  }

@misc{rfc6234,
  author="D. {Eastlake 3rd} and T. Hansen",
  title="{US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)}",
  howpublished="RFC 6234 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6234",
  pages="1--127",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6234.txt",
  key="RFC 6234",
  abstract={Federal Information Processing Standard, FIPS},
  doi="10.17487/RFC6234",
  }

@misc{rfc6235,
  author="E. Boschi and B. Trammell",
  title="{IP Flow Anonymization Support}",
  howpublished="RFC 6235 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6235",
  pages="1--43",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6235.txt",
  key="RFC 6235",
  abstract={This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol.  It categorizes common anonymization schemes and defines the parameters needed to describe them.  It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.  This document defines an Experimental Protocol for the Internet community.},
  keywords="IPFIX, flow information export, address anonymization, pseudonymization, data protection, privacy",
  doi="10.17487/RFC6235",
  }

@misc{rfc6236,
  author="I. Johansson and K. Jung",
  title="{Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)}",
  howpublished="RFC 6236 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6236",
  pages="1--23",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6236.txt",
  key="RFC 6236",
  abstract={This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size.  A possible use case is to make it possible for a \\%low-end \\%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power.  The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6236",
  }

@misc{rfc6237,
  author="B. Leiba and A. Melnikov",
  title="{IMAP4 Multimailbox SEARCH Extension}",
  howpublished="RFC 6237 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6237",
  pages="1--10",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7377",
url="https://www.rfc-editor.org/rfc/rfc6237.txt",
  key="RFC 6237",
  abstract={The IMAP4 specification allows the searching of only the selected mailbox.  A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next.  This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox.  This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.  This document updates RFC 4466.  This document defines an Experimental Protocol for the Internet community.},
  keywords="email, multiple mailboxes, imapext",
  doi="10.17487/RFC6237",
  }

@misc{rfc6238,
  author="D. M'Raihi and S. Machani and M. Pei and J. Rydell",
  title="{TOTP: Time-Based One-Time Password Algorithm}",
  howpublished="RFC 6238 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6238",
  pages="1--16",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6238.txt",
  key="RFC 6238",
  abstract={This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security. The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="OTP, OATH, HOTP, two factor authentication, strong authentication",
  doi="10.17487/RFC6238",
  }

@misc{rfc6239,
  author="K. Igoe",
  title="{Suite B Cryptographic Suites for Secure Shell (SSH)}",
  howpublished="RFC 6239 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6239",
  pages="1--14",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6239.txt",
  key="RFC 6239",
  abstract={This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol.  Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6239",
  }

@misc{rfc6240,
  author="D. Zelig and R. Cohen and T. Nadeau",
  title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2}",
  howpublished="RFC 6240 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6240",
  pages="1--67",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6240.txt",
  key="RFC 6240",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]},
  keywords="management information base, PW-CEP-STD-MIB",
  doi="10.17487/RFC6240",
  }

@misc{rfc6241,
  author="R. Enns and M. Bjorklund and J. Schoenwaelder and A. Bierman",
  title="{Network Configuration Protocol (NETCONF)}",
  howpublished="RFC 6241 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6241",
  pages="1--113",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7803",
url="https://www.rfc-editor.org/rfc/rfc6241.txt",
  key="RFC 6241",
  abstract={The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741. [STANDARDS-TRACK]},
  keywords="XML, Configuration, Network Management, Extensible Markup Language",
  doi="10.17487/RFC6241",
  }

@misc{rfc6242,
  author="M. Wasserman",
  title="{Using the NETCONF Protocol over Secure Shell (SSH)}",
  howpublished="RFC 6242 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6242",
  pages="1--11",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6242.txt",
  key="RFC 6242",
  abstract={This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742. [STANDARDS-TRACK]},
  keywords="network configuration protocol",
  doi="10.17487/RFC6242",
  }

@misc{rfc6243,
  author="A. Bierman and B. Lengyel",
  title="{With-defaults Capability for NETCONF}",
  howpublished="RFC 6243 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6243",
  pages="1--26",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6243.txt",
  key="RFC 6243",
  abstract={The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server.  In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead.  In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply.  In other situations the NETCONF client will need this data from the server.  Not all server implementations treat this default data the same way.  This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]},
  keywords="network configuration protocol",
  doi="10.17487/RFC6243",
  }

@misc{rfc6244,
  author="P. Shafer",
  title="{An Architecture for Network Management Using NETCONF and YANG}",
  howpublished="RFC 6244 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6244",
  pages="1--30",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6244.txt",
  key="RFC 6244",
  abstract={The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="network configuration protocol",
  doi="10.17487/RFC6244",
  }

@misc{rfc6245,
  author="P. Yegani and K. Leung and A. Lior and K. Chowdhury and J. Navali",
  title="{Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4}",
  howpublished="RFC 6245 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6245",
  pages="1--8",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6245.txt",
  key="RFC 6245",
  abstract={The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream.  This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field.  This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic.  The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4.  GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses.  When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key.  In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6245",
  }

@misc{rfc6246,
  author="A. Sajassi and F. Brockners and D. Mohan and Y. Serbest",
  title="{Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges}",
  howpublished="RFC 6246 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6246",
  pages="1--20",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6246.txt",
  key="RFC 6246",
  abstract={One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ieee bridges",
  doi="10.17487/RFC6246",
  }

@misc{rfc6247,
  author="L. Eggert",
  title="{Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status}",
  howpublished="RFC 6247 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6247",
  pages="1--4",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6247.txt",
  key="RFC 6247",
  abstract={This document reclassifies several TCP extensions that have never seen widespread use to Historic status.  The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6247",
  }

@misc{rfc6248,
  author="A. Morton",
  title="{RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete}",
  howpublished="RFC 6248 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6248",
  pages="1--6",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6248.txt",
  key="RFC 6248",
  abstract={This memo reclassifies RFC 4148, ``IP Performance Metrics (IPPM) Metrics Registry'', as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete.  The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics.  Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6248",
  }

@misc{rfc6249,
  author="A. Bryan and N. McNab and T. Tsujikawa and P. Poeml and H. Nordstrom",
  title="{Metalink/HTTP: Mirrors and Hashes}",
  howpublished="RFC 6249 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6249",
  pages="1--21",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6249.txt",
  key="RFC 6249",
  abstract={This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format.  Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields.  Metalink clients can use this information to make file transfers more robust and reliable.  Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]},
  keywords="file transfer, download, link, signature, data integrity, hypertext transfer protocol, ftp, file transfer protocol, metadata, torrent",
  doi="10.17487/RFC6249",
  }

@misc{rfc6250,
  author="D. Thaler",
  title="{Evolution of the IP Model}",
  howpublished="RFC 6250 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6250",
  pages="1--25",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6250.txt",
  key="RFC 6250",
  abstract={This RFC attempts to document various aspects of the IP service model and how it has evolved over time.  In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed.  The discussion of these properties is organized around evaluating a set of claims, or misconceptions.  Finally, this document provides some guidance to protocol designers and implementers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Internet Protocol, IPv4, IPv6, service model",
  doi="10.17487/RFC6250",
  }

@misc{rfc6251,
  author="S. Josefsson",
  title="{Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol}",
  howpublished="RFC 6251 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6251",
  pages="1--8",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6251.txt",
  key="RFC 6251",
  abstract={This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="kerberos, tls, starttls, kdc",
  doi="10.17487/RFC6251",
  }

@misc{rfc6252,
  author="A. Dutta and V. Fajardo and Y. Ohba and K. Taniuchi and H. Schulzrinne",
  title="{A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization}",
  howpublished="RFC 6252 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6252",
  pages="1--57",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6252.txt",
  key="RFC 6252",
  abstract={This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document. This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Mobility, Optimization, Proactive handoff, Link-layer security, Handover taxonomy, Layer 2 handoff, Layer 3 handoff, Network discovery, Handover delay, Packet loss, Proactive binding update, Multi-interface, IP address acquisition, Tunnel management",
  doi="10.17487/RFC6252",
  }

@misc{rfc6253,
  author="T. Heer and S. Varjonen",
  title="{Host Identity Protocol Certificates}",
  howpublished="RFC 6253 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6253",
  pages="1--12",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8002",
url="https://www.rfc-editor.org/rfc/rfc6253.txt",
  key="RFC 6253",
  abstract={The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates. The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter. This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6253",
  }

@misc{rfc6254,
  author="M. McFadden",
  title="{Request to Move RFC 2754 to Historic Status}",
  howpublished="RFC 6254 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6254",
  pages="1--3",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6254.txt",
  key="RFC 6254",
  abstract={RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them.  The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System.  In practice, this was never done on the public Internet.  This document requests that RFC 2754 be moved to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RPS",
  doi="10.17487/RFC6254",
  }

@misc{rfc6255,
  author="M. Blanchet",
  title="{Delay-Tolerant Networking Bundle Protocol IANA Registries}",
  howpublished="RFC 6255 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6255",
  pages="1--9",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6255.txt",
  key="RFC 6255",
  abstract={The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol.  The specifications of these protocols contain fields that are subject to a registry.  For the purpose of its research work, the group created ad hoc registries.  As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody.  This document describes the actions executed by IANA.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DTN, SNDV, DTNRG, Space networking",
  doi="10.17487/RFC6255",
  }

@misc{rfc6256,
  author="W. Eddy and E. Davies",
  title="{Using Self-Delimiting Numeric Values in Protocols}",
  howpublished="RFC 6256 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6256",
  pages="1--17",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6256.txt",
  key="RFC 6256",
  abstract={Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.  SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead.  They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development.  This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SDNV, DTN",
  doi="10.17487/RFC6256",
  }

@misc{rfc6257,
  author="S. Symington and S. Farrell and H. Weiss and P. Lovell",
  title="{Bundle Security Protocol Specification}",
  howpublished="RFC 6257 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6257",
  pages="1--60",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6257.txt",
  key="RFC 6257",
  abstract={This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6257",
  }

@misc{rfc6258,
  author="S. Symington",
  title="{Delay-Tolerant Networking Metadata Extension Block}",
  howpublished="RFC 6258 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6258",
  pages="1--10",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6258.txt",
  key="RFC 6258",
  abstract={This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol.  This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle.  The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field.  One specific metadata type, for carrying URIs as metadata, is defined in this document.  Other metadata types may be defined in separate documents.  This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document defines an Experimental Protocol for the Internet community.},
  keywords="DTN, Delay-Tolerant Networking, Distruption-Tolerant Networking",
  doi="10.17487/RFC6258",
  }

@misc{rfc6259,
  author="S. Symington",
  title="{Delay-Tolerant Networking Previous-Hop Insertion Block}",
  howpublished="RFC 6259 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6259",
  pages="1--10",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6259.txt",
  key="RFC 6259",
  abstract={This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol.  This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node.  Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing).  If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle.  Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop.  This document defines the format and processing of this PHIB.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document defines an Experimental Protocol for the Internet community.},
  keywords="DTN, Delay-Tolerant Networking, Distruption-Tolerant Networking",
  doi="10.17487/RFC6259",
  }

@misc{rfc6260,
  author="S. Burleigh",
  title="{Compressed Bundle Header Encoding (CBHE)}",
  howpublished="RFC 6260 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6260",
  pages="1--12",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6260.txt",
  key="RFC 6260",
  abstract={This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) ``convergence-layer'' adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.},
  keywords="DTN, delay-tolerant networking, BP, bundle protocol, IPN",
  doi="10.17487/RFC6260",
  }

@misc{rfc6261,
  author="A. Keranen",
  title="{Encrypted Signaling Transport Modes for the Host Identity Protocol}",
  howpublished="RFC 6261 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6261",
  pages="1--13",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6261.txt",
  key="RFC 6261",
  abstract={This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6261",
  }

@misc{rfc6262,
  author="S. Ikonin",
  title="{RTP Payload Format for IP-MR Speech Codec}",
  howpublished="RFC 6262 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6262",
  pages="1--19",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6262.txt",
  key="RFC 6262",
  abstract={This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]},
  keywords="ipmr, vocoder, multirate, scalable, scalability",
  doi="10.17487/RFC6262",
  }

@misc{rfc6263,
  author="X. Marjou and A. Sollaud",
  title="{Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows}",
  howpublished="RFC 6263 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6263",
  pages="1--12",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6263.txt",
  key="RFC 6263",
  abstract={This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive.  It also makes a recommendation for a preferred mechanism.  This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]},
  keywords="AVT, SDP, port",
  doi="10.17487/RFC6263",
  }

@misc{rfc6264,
  author="S. Jiang and D. Guo and B. Carpenter",
  title="{An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition}",
  howpublished="RFC 6264 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6264",
  pages="1--13",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6264.txt",
  key="RFC 6264",
  abstract={Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period. This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6264",
  }

@misc{rfc6265,
  author="A. Barth",
  title="{HTTP State Management Mechanism}",
  howpublished="RFC 6265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6265",
  pages="1--37",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6265.txt",
  key="RFC 6265",
  abstract={This document defines the HTTP Cookie and Set-Cookie header fields.  These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965. [STANDARDS-TRACK]},
  keywords="Cookie, Set-Cookie, Secure, HttpOnly",
  doi="10.17487/RFC6265",
  }

@misc{rfc6266,
  author="J. Reschke",
  title="{Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)}",
  howpublished="RFC 6266 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6266",
  pages="1--14",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6266.txt",
  key="RFC 6266",
  abstract={RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard.  This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]},
  keywords="filename, attachment, inline",
  doi="10.17487/RFC6266",
  }

@misc{rfc6267,
  author="V. Cakulev and G. Sundaram",
  title="{MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 6267 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6267",
  pages="1--30",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6267.txt",
  key="RFC 6267",
  abstract={This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service.  In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework.  This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Identity based encryption, authentication, key agreement",
  doi="10.17487/RFC6267",
  }

@misc{rfc6268,
  author="J. Schaad and S. Turner",
  title="{Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)}",
  howpublished="RFC 6268 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6268",
  pages="1--33",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6268.txt",
  key="RFC 6268",
  abstract={The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version.  There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ASN.1, Certficate Extensions, HMAC",
  doi="10.17487/RFC6268",
  }

@misc{rfc6269,
  author="M. Ford and M. Boucadair and A. Durand and P. Levis and P. Roberts",
  title="{Issues with IP Address Sharing}",
  howpublished="RFC 6269 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6269",
  pages="1--29",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6269.txt",
  key="RFC 6269",
  abstract={The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv4 address exhaustion, completion, shared, sharing issues",
  doi="10.17487/RFC6269",
  }

@misc{rfc6270,
  author="M. Yevstifeyev",
  title="{The 'tn3270' URI Scheme}",
  howpublished="RFC 6270 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6270",
  pages="1--6",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6270.txt",
  key="RFC 6270",
  abstract={This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E).  It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]},
  keywords="URI, Telnet, Telnet 3270, TN3270",
  doi="10.17487/RFC6270",
  }

@misc{rfc6271,
  author="J-F. Mule",
  title="{Requirements for SIP-Based Session Peering}",
  howpublished="RFC 6271 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6271",
  pages="1--23",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6271.txt",
  key="RFC 6271",
  abstract={This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic.  This informational document is intended to link the various use cases described for session peering to protocol solutions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IETF speermint, guidelines, requirements for session interconnects, session peering, SIP interconnects, VoIP peering",
  doi="10.17487/RFC6271",
  }

@misc{rfc6272,
  author="F. Baker and D. Meyer",
  title="{Internet Protocols for the Smart Grid}",
  howpublished="RFC 6272 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6272",
  pages="1--66",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6272.txt",
  key="RFC 6272",
  abstract={This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid.  The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid.  In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6272",
  }

@misc{rfc6273,
  author="A. Kukec and S. Krishnan and S. Jiang",
  title="{The Secure Neighbor Discovery (SEND) Hash Threat Analysis}",
  howpublished="RFC 6273 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6273",
  pages="1--7",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6273.txt",
  key="RFC 6273",
  abstract={This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND.  The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility.  This document provides an analysis of possible threats to the hash algorithms used in SEND.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6273",
  }

@misc{rfc6274,
  author="F. Gont",
  title="{Security Assessment of the Internet Protocol Version 4}",
  howpublished="RFC 6274 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6274",
  pages="1--75",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6274.txt",
  key="RFC 6274",
  abstract={This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations.  It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="vulnerabilities, Denial of Service, resiliency, hardening, information leakage",
  doi="10.17487/RFC6274",
  }

@misc{rfc6275,
  author="C. Perkins and D. Johnson and J. Arkko",
  title="{Mobility Support in IPv6}",
  howpublished="RFC 6275 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6275",
  pages="1--169",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6275.txt",
  key="RFC 6275",
  abstract={This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location.  IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address.  The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address.  To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option.  All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.  This document obsoletes RFC 3775. [STANDARDS-TRACK]},
  keywords="MIPv6, mobility, IPv6, internet protocol, nodes",
  doi="10.17487/RFC6275",
  }

@misc{rfc6276,
  author="R. Droms and P. Thubert and F. Dupont and W. Haddad and C. Bernardos",
  title="{DHCPv6 Prefix Delegation for Network Mobility (NEMO)}",
  howpublished="RFC 6276 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6276",
  pages="1--14",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6276.txt",
  key="RFC 6276",
  abstract={One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network.  This document specifies how DHCPv6 prefix delegation can be used for this configuration task.  The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router.  When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]},
  keywords="IPv6, mobile router, home agent, mobile network prefix",
  doi="10.17487/RFC6276",
  }

@misc{rfc6277,
  author="S. Santesson and P. Hallam-Baker",
  title="{Online Certificate Status Protocol Algorithm Agility}",
  howpublished="RFC 6277 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6277",
  pages="1--11",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6960",
url="https://www.rfc-editor.org/rfc/rfc6277.txt",
  key="RFC 6277",
  abstract={The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used.  This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use.  This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]},
  keywords="ocsp",
  doi="10.17487/RFC6277",
  }

@misc{rfc6278,
  author="J. Herzog and R. Khazan",
  title="{Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax}",
  howpublished="RFC 6278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6278",
  pages="1--16",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6278.txt",
  key="RFC 6278",
  abstract={This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax.  In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="set-key, group-key",
  doi="10.17487/RFC6278",
  }

@misc{rfc6279,
  author="M. Liebsch and S. Jeong and Q. Wu",
  title="{Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement}",
  howpublished="RFC 6279 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6279",
  pages="1--14",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6279.txt",
  key="RFC 6279",
  abstract={Proxy Mobile IPv6 is the IETF Standard for network-based mobility management.  In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes.  The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered.  This document describes the problem space of localized routing in Proxy Mobile IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Local Routing, Route Optimization, Traffic Offload",
  doi="10.17487/RFC6279",
  }

@misc{rfc6280,
  author="R. Barnes and M. Lepinski and A. Cooper and J. Morris and H. Tschofenig and H. Schulzrinne",
  title="{An Architecture for Location and Location Privacy in Internet Applications}",
  howpublished="RFC 6280 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6280",
  pages="1--41",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6280.txt",
  key="RFC 6280",
  abstract={Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities.  These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved.  This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.  This memo documents an Internet Best Current Practice.},
  keywords="geolocation, geopriv",
  doi="10.17487/RFC6280",
  }

@misc{rfc6281,
  author="S. Cheshire and Z. Zhu and R. Wakikawa and L. Zhang",
  title="{Understanding Apple's Back to My Mac (BTMM) Service}",
  howpublished="RFC 6281 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6281",
  pages="1--16",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6281.txt",
  key="RFC 6281",
  abstract={This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service.  BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road.  The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6281",
  }

@misc{rfc6282,
  author="J. Hui and P. Thubert",
  title="{Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks}",
  howpublished="RFC 6282 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6282",
  pages="1--24",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8066",
url="https://www.rfc-editor.org/rfc/rfc6282.txt",
  key="RFC 6282",
  abstract={This document updates RFC 4944, ``Transmission of IPv6 Packets over IEEE 802.15.4 Networks''.  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope.  This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework. [STANDARDS-TRACK]},
  keywords="LLN, Low Power, radio 802.15.4, powerline, ISA100.11a, RFC 4944",
  doi="10.17487/RFC6282",
  }

@misc{rfc6283,
  author="A. Jerman Blazic and S. Saljic and T. Gondrom",
  title="{Extensible Markup Language Evidence Record Syntax (XMLERS)}",
  howpublished="RFC 6283 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6283",
  pages="1--43",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6283.txt",
  key="RFC 6283",
  abstract={In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time.  This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data.  The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]},
  keywords="long term, trust, integrity, long term integrity, data preservation, document preservation, time-stamp, time-stamping, archive time stamp, electronic archive, electronic archiving, trusted archiving, long-term archive, archive data, evidence, evidence record, evidence record syntax, hash tree, ERS, XML, hash, signature, renewal, algorithm, cryptography",
  doi="10.17487/RFC6283",
  }

@misc{rfc6284,
  author="A. Begen and D. Wing and T. Van Caenegem",
  title="{Port Mapping between Unicast and Multicast RTP Sessions}",
  howpublished="RFC 6284 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6284",
  pages="1--30",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6284.txt",
  key="RFC 6284",
  abstract={This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services.  The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]},
  keywords="Port mapping, port translation, RTP, multicast, NAT",
  doi="10.17487/RFC6284",
  }

@misc{rfc6285,
  author="B. Ver Steeg and A. Begen and T. Van Caenegem and Z. Vax",
  title="{Unicast-Based Rapid Acquisition of Multicast RTP Sessions}",
  howpublished="RFC 6285 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6285",
  pages="1--56",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6285.txt",
  key="RFC 6285",
  abstract={When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]},
  keywords="SSM, multicast, IPTV, fast channel change",
  doi="10.17487/RFC6285",
  }

@misc{rfc6286,
  author="E. Chen and J. Yuan",
  title="{Autonomous-System-Wide Unique BGP Identifier for BGP-4}",
  howpublished="RFC 6286 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6286",
  pages="1--4",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6286.txt",
  key="RFC 6286",
  abstract={To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the ``uniqueness'' requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required.  These revisions to the base BGP specification do not introduce any backward compatibility issues.  This document updates RFC 4271. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6286",
  }

@misc{rfc6287,
  author="D. M'Raihi and J. Rydell and S. Bajaj and S. Machani and D. Naccache",
  title="{OCRA: OATH Challenge-Response Algorithm}",
  howpublished="RFC 6287 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6287",
  pages="1--38",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6287.txt",
  key="RFC 6287",
  abstract={This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH).  The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="HOTP, TOTP, One-Time Password, Authentication, Signature",
  doi="10.17487/RFC6287",
  }

@misc{rfc6288,
  author="C. Reed",
  title="{URN Namespace for the Defence Geospatial Information Working Group (DGIWG)}",
  howpublished="RFC 6288 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6288",
  pages="1--8",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6288.txt",
  key="RFC 6288",
  abstract={This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Namespace Identifier, nid, DGIWG Registry System, drs",
  doi="10.17487/RFC6288",
  }

@misc{rfc6289,
  author="E. Cardona and S. Channabasappa and J-F. Mule",
  title="{A Uniform Resource Name (URN) Namespace for CableLabs}",
  howpublished="RFC 6289 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6289",
  pages="1--7",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6289.txt",
  key="RFC 6289",
  abstract={This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs).  CableLabs specifies and manages resources that utilize this URN identification model.  Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="namespace identifier, nid",
  doi="10.17487/RFC6289",
  }

@misc{rfc6290,
  author="Y. Nir and D. Wierbowski and F. Detienne and P. Sethi",
  title="{A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)}",
  howpublished="RFC 6290 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6290",
  pages="1--22",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6290.txt",
  key="RFC 6290",
  abstract={This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]},
  keywords="QCD",
  doi="10.17487/RFC6290",
  }

@misc{rfc6291,
  author="L. Andersson and H. van Helvoort and R. Bonica and D. Romascanu and S. Mansfield",
  title="{Guidelines for the Use of the ``OAM'' Acronym in the IETF}",
  howpublished="RFC 6291 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6291",
  pages="1--9",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6291.txt",
  key="RFC 6291",
  abstract={At first glance, the acronym ``OAM'' seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym ``OAM'' (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the ``OAM'' term. This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6291",
  }

@misc{rfc6292,
  author="P. Hoffman",
  title="{Requirements for a Working Group Charter Tool}",
  howpublished="RFC 6292 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6292",
  pages="1--11",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6433",
url="https://www.rfc-editor.org/rfc/rfc6292.txt",
  key="RFC 6292",
  abstract={The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups.  The tool will also allow the IETF community to view the status of the chartering process.  This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6292",
  }

@misc{rfc6293,
  author="P. Hoffman",
  title="{Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker}",
  howpublished="RFC 6293 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6293",
  pages="1--17",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6293.txt",
  key="RFC 6293",
  abstract={The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6293",
  }

@misc{rfc6294,
  author="Q. Hu and B. Carpenter",
  title="{Survey of Proposed Use Cases for the IPv6 Flow Label}",
  howpublished="RFC 6294 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6294",
  pages="1--18",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6294.txt",
  key="RFC 6294",
  abstract={The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice.  This paper describes the flow label standard and discusses the implementation issues that it raises.  It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard.  Methods to address this problem are briefly reviewed.  We also question whether the standard should be revised.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Quality of service, QoS",
  doi="10.17487/RFC6294",
  }

@misc{rfc6295,
  author="J. Lazzaro and J. Wawrzynek",
  title="{RTP Payload Format for MIDI}",
  howpublished="RFC 6295 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6295",
  pages="1--171",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6295.txt",
  key="RFC 6295",
  abstract={This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language.  The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable.  The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming).  The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss.  Stream behavior, including the MIDI rendering method, may be customized during session setup.  The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.  This document obsoletes RFC 4695. [STANDARDS-TRACK]},
  keywords="asc, content streaming, DLS 2, General MIDI, MIDI, MIDI file, MIDI file streaming, MIDI light control, MIDI rendering, MIDI ringtone, MIDI streaming MIDI sequencer, MIDI time code, MIDI timecode, MIDI Manufacturers Association, MMA mpeg4generic MPEG 4, MPEG 4 Structured Audio, MPEG 4 Synthetic Coding, MTC, musical notes, network musical performance, recovery journal, Show Control, sonification, ringtone, rtpmidi, RTP, RTP MIDI, SMPTE time code, SMPTE timecode, Standard MIDI Files, XMF",
  doi="10.17487/RFC6295",
  }

@misc{rfc6296,
  author="M. Wasserman and F. Baker",
  title="{IPv6-to-IPv6 Network Prefix Translation}",
  howpublished="RFC 6296 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6296",
  pages="1--32",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6296.txt",
  key="RFC 6296",
  abstract={This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the ``inside'' and ``outside'' prefixes, preserving end-to-end reachability at the network layer.  This document defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC6296",
  }

@misc{rfc6297,
  author="M. Welzl and D. Ros",
  title="{A Survey of Lower-than-Best-Effort Transport Protocols}",
  howpublished="RFC 6297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6297",
  pages="1--18",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6297.txt",
  key="RFC 6297",
  abstract={This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it.  Such protocols could be used for delay-insensitive ``background'' traffic, as they provide what is sometimes called a ``less than'' (or ``lower than'') best-effort service.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Less-than-Best-Effort, Congestion Control, LEDBAT",
  doi="10.17487/RFC6297",
  }

@misc{rfc6298,
  author="V. Paxson and M. Allman and J. Chu and M. Sargent",
  title="{Computing TCP's Retransmission Timer}",
  howpublished="RFC 6298 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6298",
  pages="1--11",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6298.txt",
  key="RFC 6298",
  abstract={This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988. [STANDARDS-TRACK]},
  keywords="RTO",
  doi="10.17487/RFC6298",
  }

@misc{rfc6301,
  author="Z. Zhu and R. Wakikawa and L. Zhang",
  title="{A Survey of Mobility Support in the Internet}",
  howpublished="RFC 6301 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6301",
  pages="1--33",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6301.txt",
  key="RFC 6301",
  abstract={Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions.  We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support.  This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6301",
  }

@misc{rfc6302,
  author="A. Durand and I. Gashinsky and D. Lee and S. Sheppard",
  title="{Logging Recommendations for Internet-Facing Servers}",
  howpublished="RFC 6302 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6302",
  pages="1--5",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6302.txt",
  key="RFC 6302",
  abstract={In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address.  This memo documents an Internet Best Current Practice.},
  keywords="port logging",
  doi="10.17487/RFC6302",
  }

@misc{rfc6303,
  author="M. Andrews",
  title="{Locally Served DNS Zones}",
  howpublished="RFC 6303 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6303",
  pages="1--10",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6303.txt",
  key="RFC 6303",
  abstract={Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise.  RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics.  This memo documents an Internet Best Current Practice.},
  keywords="AS112,  Reverse,  IN-ADDR.ARPA,  IP6.ARPA,  RFC1918",
  doi="10.17487/RFC6303",
  }

@misc{rfc6304,
  author="J. Abley and W. Maton",
  title="{AS112 Nameserver Operations}",
  howpublished="RFC 6304 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6304",
  pages="1--18",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7534",
url="https://www.rfc-editor.org/rfc/rfc6304.txt",
  key="RFC 6304",
  abstract={Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called ``reverse lookups'') corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DNS, RFC1918",
  doi="10.17487/RFC6304",
  }

@misc{rfc6305,
  author="J. Abley and W. Maton",
  title="{I'm Being Attacked by PRISONER.IANA.ORG!}",
  howpublished="RFC 6305 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6305",
  pages="1--8",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6305.txt",
  key="RFC 6305",
  abstract={Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6305",
  }

@misc{rfc6306,
  author="P. Frejborg",
  title="{Hierarchical IPv4 Framework}",
  howpublished="RFC 6306 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6306",
  pages="1--65",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6306.txt",
  key="RFC 6306",
  abstract={This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet. This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.},
  keywords="core address space, area locators, alocs, edge address space, endpoint locators, elocs",
  doi="10.17487/RFC6306",
  }

@misc{rfc6307,
  author="D. Black and L. Dunbar and M. Roth and R. Solomon",
  title="{Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks}",
  howpublished="RFC 6307 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6307",
  pages="1--21",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6307.txt",
  key="RFC 6307",
  abstract={A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network.  This enables service providers to take advantage of MPLS to offer ``emulated'' Fibre Channel services.  This document specifies the encapsulation of Fibre Channel traffic within a pseudowire.  It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6307",
  }

@misc{rfc6308,
  author="P. Savola",
  title="{Overview of the Internet Multicast Addressing Architecture}",
  howpublished="RFC 6308 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6308",
  pages="1--14",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6308.txt",
  key="RFC 6308",
  abstract={The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion.  To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="assignment, allocation, SSM, ASM, GLOP",
  doi="10.17487/RFC6308",
  }

@misc{rfc6309,
  author="J. Arkko and A. Keranen and J. Mattsson",
  title="{IANA Rules for MIKEY (Multimedia Internet KEYing)}",
  howpublished="RFC 6309 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6309",
  pages="1--6",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6309.txt",
  key="RFC 6309",
  abstract={This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY).  This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]},
  keywords="short-term key message, long-term key message, oma, bac, browser and content, broadcast",
  doi="10.17487/RFC6309",
  }

@misc{rfc6310,
  author="M. Aissaoui and P. Busschbach and L. Martini and M. Morrow and T. Nadeau and Y(J). Stein",
  title="{Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping}",
  howpublished="RFC 6310 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6310",
  pages="1--40",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6310.txt",
  key="RFC 6310",
  abstract={This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service.  It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects.  It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]},
  keywords="interworking, defect state, defect indication, pseudowire, OAM",
  doi="10.17487/RFC6310",
  }

@misc{rfc6311,
  author="R. Singh and G. Kalyani and Y. Nir and Y. Sheffer and D. Zhang",
  title="{Protocol Support for High Availability of IKEv2/IPsec}",
  howpublished="RFC 6311 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6311",
  pages="1--26",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6311.txt",
  key="RFC 6311",
  abstract={The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, ``IPsec Cluster Problem Statement'', enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol. This document defines an extension to the IKEv2 protocol to solve the main issues of ``IPsec Cluster Problem Statement'' in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]},
  keywords="IPsec high availability, load sharing, clustering, fail-over",
  doi="10.17487/RFC6311",
  }

@misc{rfc6312,
  author="R. Koodli",
  title="{Mobile Networks Considerations for IPv6 Deployment}",
  howpublished="RFC 6312 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6312",
  pages="1--17",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6342",
url="https://www.rfc-editor.org/rfc/rfc6312.txt",
  key="RFC 6312",
  abstract={Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks.  This document discusses the issues that arise when deploying IPv6 in mobile networks.  Hence, this document can be a useful reference for service providers and network designers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6312",
  }

@misc{rfc6313,
  author="B. Claise and G. Dhandapani and P. Aitken and S. Yates",
  title="{Export of Structured Data in IP Flow Information Export (IPFIX)}",
  howpublished="RFC 6313 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6313",
  pages="1--71",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6313.txt",
  key="RFC 6313",
  abstract={This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records.  This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates.  Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]},
  keywords="ipfix information model",
  doi="10.17487/RFC6313",
  }

@misc{rfc6314,
  author="C. Boulton and J. Rosenberg and G. Camarillo and F. Audet",
  title="{NAT Traversal Practices for Client-Server SIP}",
  howpublished="RFC 6314 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6314",
  pages="1--60",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6314.txt",
  key="RFC 6314",
  abstract={Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem.  Currently, there are many deployment scenarios and traversal mechanisms for media traffic.  This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6314",
  }

@misc{rfc6315,
  author="E. Guy and K. Darilion",
  title="{IANA Registration for Enumservice 'iax'}",
  howpublished="RFC 6315 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6315",
  pages="1--6",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6315.txt",
  key="RFC 6315",
  abstract={This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ENUM, E.164, VoIP, Voice over IP",
  doi="10.17487/RFC6315",
  }

@misc{rfc6316,
  author="M. Komu and M. Bagnulo and K. Slavov and S. Sugimoto",
  title="{Sockets Application Program Interface (API) for Multihoming Shim}",
  howpublished="RFC 6316 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6316",
  pages="1--44",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6316.txt",
  key="RFC 6316",
  abstract={This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration. This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called ``shim sub- layer'') inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Shim6, HIP, identifier/locator split",
  doi="10.17487/RFC6316",
  }

@misc{rfc6317,
  author="M. Komu and T. Henderson",
  title="{Basic Socket Interface Extensions for the Host Identity Protocol (HIP)}",
  howpublished="RFC 6317 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6317",
  pages="1--18",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6317.txt",
  key="RFC 6317",
  abstract={This document defines extensions to the current sockets API for the Host Identity Protocol (HIP).  The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators.  With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies.  The extensions in this document are experimental and provide basic tools for further experimentation with policies.  This document defines an Experimental Protocol for the Internet community.},
  keywords="host identity tag, cryptographic identity, cryptographic namespace, sockets API, Shim6, opportunistic mode, resolver, HIP wildcard address, ORCHID, source address selection, HIT prefix, locator handling",
  doi="10.17487/RFC6317",
  }

@misc{rfc6318,
  author="R. Housley and J. Solinas",
  title="{Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)}",
  howpublished="RFC 6318 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6318",
  pages="1--15",
  year=2011,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6318.txt",
  key="RFC 6318",
  abstract={This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751.  This document obsoletes RFC 5008.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6318",
  }

@misc{rfc6319,
  author="M. Azinger and L. Vegoda",
  title="{Issues Associated with Designating Additional Private IPv4 Address Space}",
  howpublished="RFC 6319 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6319",
  pages="1--12",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6319.txt",
  key="RFC 6319",
  abstract={When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space. While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="private network",
  doi="10.17487/RFC6319",
  }

@misc{rfc6320,
  author="S. Wadhwa and J. Moisand and T. Haag and N. Voigt and T. Taylor",
  title="{Protocol for Access Node Control Mechanism in Broadband Networks}",
  howpublished="RFC 6320 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6320",
  pages="1--82",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7256",
url="https://www.rfc-editor.org/rfc/rfc6320.txt",
  key="RFC 6320",
  abstract={This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]},
  keywords="ancp",
  doi="10.17487/RFC6320",
  }

@misc{rfc6321,
  author="C. Daboo and M. Douglass and S. Lees",
  title="{xCal: The XML Format for iCalendar}",
  howpublished="RFC 6321 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6321",
  pages="1--54",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6868, 7529",
url="https://www.rfc-editor.org/rfc/rfc6321.txt",
  key="RFC 6321",
  abstract={This specification defines ``xCal'', an XML format for iCalendar data. [STANDARDS-TRACK]},
  keywords="extensible markup language",
  doi="10.17487/RFC6321",
  }

@misc{rfc6322,
  author="P. Hoffman",
  title="{Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams}",
  howpublished="RFC 6322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6322",
  pages="1--11",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6322.txt",
  key="RFC 6322",
  abstract={This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor.  The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft.  The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6322",
  }

@misc{rfc6323,
  author="G. Renker and G. Fairhurst",
  title="{Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)}",
  howpublished="RFC 6323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6323",
  pages="1--13",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6323.txt",
  key="RFC 6323",
  abstract={This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP. The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender. It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]},
  keywords="DCCP, TFRC, CCID-3, CCID-4",
  doi="10.17487/RFC6323",
  }

@misc{rfc6324,
  author="G. Nakibly and F. Templin",
  title="{Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations}",
  howpublished="RFC 6324 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6324",
  pages="1--19",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6324.txt",
  key="RFC 6324",
  abstract={This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels.  These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state.  The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks.  The first aim of this document is to inform on this attack and its root causes.  The second aim is to present some possible mitigation measures.  It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities.  Nonetheless, these vulnerabilities can be activated by accidental misconfiguration.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Encapsulation, ISATAP, 6rd",
  doi="10.17487/RFC6324",
  }

@misc{rfc6325,
  author="R. Perlman and D. {Eastlake 3rd} and D. Dutt and S. Gai and A. Ghanwani",
  title="{Routing Bridges (RBridges): Base Protocol Specification}",
  howpublished="RFC 6325 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6325",
  pages="1--99",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6327, 6439, 7172, 7177, 7357, 7179, 7180, 7455, 7780, 7783",
url="https://www.rfc-editor.org/rfc/rfc6325.txt",
  key="RFC 6325",
  abstract={Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]},
  keywords="TRILL",
  doi="10.17487/RFC6325",
  }

@misc{rfc6326,
  author="D. Eastlake and A. Banerjee and D. Dutt and R. Perlman and A. Ghanwani",
  title="{Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS}",
  howpublished="RFC 6326 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6326",
  pages="1--25",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7176",
url="https://www.rfc-editor.org/rfc/rfc6326.txt",
  key="RFC 6326",
  abstract={The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.  This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]},
  keywords="TRILL, RBridge, IS-IS, ISIS",
  doi="10.17487/RFC6326",
  }

@misc{rfc6327,
  author="D. {Eastlake 3rd} and R. Perlman and A. Ghanwani and D. Dutt and V. Manral",
  title="{Routing Bridges (RBridges): Adjacency}",
  howpublished="RFC 6327 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6327",
  pages="1--26",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7177, updated by RFC 7180",
url="https://www.rfc-editor.org/rfc/rfc6327.txt",
  key="RFC 6327",
  abstract={The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges). TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]},
  keywords="RBridge, TRILL, Adjacency",
  doi="10.17487/RFC6327",
  }

@misc{rfc6328,
  author="D. {Eastlake 3rd}",
  title="{IANA Considerations for Network Layer Protocol Identifiers}",
  howpublished="RFC 6328 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6328",
  pages="1--9",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6328.txt",
  key="RFC 6328",
  abstract={Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID).  This document provides NLPID IANA considerations.  This memo documents an Internet Best Current Practice.},
  keywords="NLPID",
  doi="10.17487/RFC6328",
  }

@misc{rfc6329,
  author="D. Fedyk and P. Ashwood-Smith and D. Allan and A. Bragg and P. Unbehagen",
  title="{IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging}",
  howpublished="RFC 6329 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6329",
  pages="1--37",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6329.txt",
  key="RFC 6329",
  abstract={802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols.  802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths.  This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology.  Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations.  This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]},
  keywords="spb",
  doi="10.17487/RFC6329",
  }

@misc{rfc6330,
  author="M. Luby and A. Shokrollahi and M. Watson and T. Stockhammer and L. Minder",
  title="{RaptorQ Forward Error Correction Scheme for Object Delivery}",
  howpublished="RFC 6330 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6330",
  pages="1--69",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6330.txt",
  key="RFC 6330",
  abstract={This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects. RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required. The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]},
  keywords="FEC code, fountain code, systematic code, AL FEC code, Sub-blocking, FEC object delivery",
  doi="10.17487/RFC6330",
  }

@misc{rfc6331,
  author="A. Melnikov",
  title="{Moving DIGEST-MD5 to Historic}",
  howpublished="RFC 6331 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6331",
  pages="1--6",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6331.txt",
  key="RFC 6331",
  abstract={This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831.  It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="http, hypertext transfer protocol, security, simple, layer",
  doi="10.17487/RFC6331",
  }

@misc{rfc6332,
  author="A. Begen and E. Friedrich",
  title="{Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)}",
  howpublished="RFC 6332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6332",
  pages="1--16",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6332.txt",
  key="RFC 6332",
  abstract={In most RTP-based multicast applications, the RTP source sends inter- related data.  Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session.  Thus, they often experience a random acquisition delay.  An RTP receiver can use one or more different approaches to achieve rapid acquisition.  Yet, due to various factors, performance of the rapid acquisition methods usually varies.  Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so).  For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences.  This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611).  This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]},
  keywords="SSM, multicast, IPTV, RAMS, rapid acquisition, fast channel change",
  doi="10.17487/RFC6332",
  }

@misc{rfc6333,
  author="A. Durand and R. Droms and J. Woodyatt and Y. Lee",
  title="{Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion}",
  howpublished="RFC 6333 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6333",
  pages="1--32",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7335",
url="https://www.rfc-editor.org/rfc/rfc6333.txt",
  key="RFC 6333",
  abstract={This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks.  Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]},
  keywords="NAT",
  doi="10.17487/RFC6333",
  }

@misc{rfc6334,
  author="D. Hankins and T. Mrugalski",
  title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite}",
  howpublished="RFC 6334 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6334",
  pages="1--7",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6334.txt",
  key="RFC 6334",
  abstract={This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]},
  keywords="Softwire, DS-Lite",
  doi="10.17487/RFC6334",
  }

@misc{rfc6335,
  author="M. Cotton and L. Eggert and J. Touch and M. Westerlund and S. Cheshire",
  title="{Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry}",
  howpublished="RFC 6335 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6335",
  pages="1--33",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6335.txt",
  key="RFC 6335",
  abstract={This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.},
  keywords="IANA, transport, ports, port numbers, allocation, assignment, procedures",
  doi="10.17487/RFC6335",
  }

@misc{rfc6336,
  author="M. Westerlund and C. Perkins",
  title="{IANA Registry for Interactive Connectivity Establishment (ICE) Options}",
  howpublished="RFC 6336 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6336",
  pages="1--5",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6336.txt",
  key="RFC 6336",
  abstract={It has been identified that ``Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols'' (RFC 5245) is missing a registry for ICE options.  This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6336",
  }

@misc{rfc6337,
  author="S. Okumura and T. Sawada and P. Kyzivat",
  title="{Session Initiation Protocol (SIP) Usage of the Offer/Answer Model}",
  howpublished="RFC 6337 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6337",
  pages="1--33",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6337.txt",
  key="RFC 6337",
  abstract={The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP).  The description of the offer/answer model in SIP is dispersed across multiple RFCs.  This document summarizes all the current usages of the offer/answer model in SIP communication.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="answer, offer, SDP, SIP",
  doi="10.17487/RFC6337",
  }

@misc{rfc6338,
  author="V. Giralt and R. McDuff",
  title="{Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)}",
  howpublished="RFC 6338 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6338",
  pages="1--11",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6338.txt",
  key="RFC 6338",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="TERENA, tf-emc2",
  doi="10.17487/RFC6338",
  }

@misc{rfc6339,
  author="S. Josefsson and L. Hornquist Astrand",
  title="{Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)}",
  howpublished="RFC 6339 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6339",
  pages="1--8",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6339.txt",
  key="RFC 6339",
  abstract={This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs.  This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6339",
  }

@misc{rfc6340,
  author="R. Presuhn",
  title="{Textual Conventions for the Representation of Floating-Point Numbers}",
  howpublished="RFC 6340 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6340",
  pages="1--7",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6340.txt",
  key="RFC 6340",
  abstract={This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]},
  keywords="Network Management, IEEE 754, Floating-point, MIB, SMIv2, Textual Convention, FLOAT-TC-MIB",
  doi="10.17487/RFC6340",
  }

@misc{rfc6341,
  author="K. Rehor and L. Portman and A. Hutton and R. Jain",
  title="{Use Cases and Requirements for SIP-Based Media Recording (SIPREC)}",
  howpublished="RFC 6341 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6341",
  pages="1--16",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6341.txt",
  key="RFC 6341",
  abstract={Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6341",
  }

@misc{rfc6342,
  author="R. Koodli",
  title="{Mobile Networks Considerations for IPv6 Deployment}",
  howpublished="RFC 6342 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6342",
  pages="1--17",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6342.txt",
  key="RFC 6342",
  abstract={Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks.  This document discusses the issues that arise when deploying IPv6 in mobile networks.  Hence, this document can be a useful reference for service providers and network designers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6342",
  }

@misc{rfc6343,
  author="B. Carpenter",
  title="{Advisory Guidelines for 6to4 Deployment}",
  howpublished="RFC 6343 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6343",
  pages="1--20",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6343.txt",
  key="RFC 6343",
  abstract={This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4.  It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers.  Some advice to implementers is also included.  The intention of the advice is to minimize both user dissatisfaction and help-desk calls.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6 relay",
  doi="10.17487/RFC6343",
  }

@misc{rfc6344,
  author="G. Bernstein and D. Caviglia and R. Rabbat and H. van Helvoort",
  title="{Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)}",
  howpublished="RFC 6344 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6344",
  pages="1--21",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6344.txt",
  key="RFC 6344",
  abstract={This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS).  LCAS can be used for hitless dynamic resizing of the inverse multiplex group.  These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.  This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6344",
  }

@misc{rfc6345,
  author="P. Duffy and S. Chakrabarti and R. Cragie and Y. Ohba and A. Yegin",
  title="{Protocol for Carrying Authentication for Network Access (PANA) Relay Element}",
  howpublished="RFC 6345 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6345",
  pages="1--12",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6345.txt",
  key="RFC 6345",
  abstract={This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]},
  keywords="EAP, ZigBee",
  doi="10.17487/RFC6345",
  }

@misc{rfc6346,
  author="R. Bush",
  title="{The Address plus Port (A+P) Approach to the IPv4 Address Shortage}",
  howpublished="RFC 6346 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6346",
  pages="1--38",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6346.txt",
  key="RFC 6346",
  abstract={We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6346",
  }

@misc{rfc6347,
  author="E. Rescorla and N. Modadugu",
  title="{Datagram Transport Layer Security Version 1.2}",
  howpublished="RFC 6347 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6347",
  pages="1--32",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7507, 7905",
url="https://www.rfc-editor.org/rfc/rfc6347.txt",
  key="RFC 6347",
  abstract={This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]},
  keywords="dtls, dtls protocol",
  doi="10.17487/RFC6347",
  }

@misc{rfc6348,
  author="JL. Le Roux and T. Morin",
  title="{Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol}",
  howpublished="RFC 6348 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6348",
  pages="1--20",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6348.txt",
  key="RFC 6348",
  abstract={This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure. This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.},
  keywords="MPLS, LDP, multipoint, P2MP, multicast",
  doi="10.17487/RFC6348",
  }

@misc{rfc6349,
  author="B. Constantine and G. Forget and R. Geib and R. Schrage",
  title="{Framework for TCP Throughput Testing}",
  howpublished="RFC 6349 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6349",
  pages="1--27",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6349.txt",
  key="RFC 6349",
  abstract={This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network.  The goal is to provide a better indication in regard to user experience.  In this framework, TCP and IP parameters are specified to optimize TCP Throughput.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="metric, TCP testing",
  doi="10.17487/RFC6349",
  }

@misc{rfc6350,
  author="S. Perreault",
  title="{vCard Format Specification}",
  howpublished="RFC 6350 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6350",
  pages="1--74",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6868",
url="https://www.rfc-editor.org/rfc/rfc6350.txt",
  key="RFC 6350",
  abstract={This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]},
  keywords="vCard",
  doi="10.17487/RFC6350",
  }

@misc{rfc6351,
  author="S. Perreault",
  title="{xCard: vCard XML Representation}",
  howpublished="RFC 6351 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6351",
  pages="1--22",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6868",
url="https://www.rfc-editor.org/rfc/rfc6351.txt",
  key="RFC 6351",
  abstract={This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]},
  keywords="vCard",
  doi="10.17487/RFC6351",
  }

@misc{rfc6352,
  author="C. Daboo",
  title="{CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 6352 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6352",
  pages="1--48",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6764",
url="https://www.rfc-editor.org/rfc/rfc6352.txt",
  key="RFC 6352",
  abstract={This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]},
  keywords="address, address book, contact",
  doi="10.17487/RFC6352",
  }

@misc{rfc6353,
  author="W. Hardaker",
  title="{Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)}",
  howpublished="RFC 6353 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6353",
  pages="1--65",
  year=2011,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6353.txt",
  key="RFC 6353",
  abstract={This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way. This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]},
  keywords="dtls, datagram transport layer security, tls transport model, tlstm, SNMP-TLS-TM-MIB",
  doi="10.17487/RFC6353",
  }

@misc{rfc6354,
  author="Q. Xie",
  title="{Forward-Shifted RTP Redundancy Payload Support}",
  howpublished="RFC 6354 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6354",
  pages="1--13",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6354.txt",
  key="RFC 6354",
  abstract={This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data.  Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6354",
  }

@misc{rfc6355,
  author="T. Narten and J. Johnson",
  title="{Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)}",
  howpublished="RFC 6355 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6355",
  pages="1--5",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6355.txt",
  key="RFC 6355",
  abstract={This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID.  DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format.  DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa.  UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]},
  keywords="universally unique identifier",
  doi="10.17487/RFC6355",
  }

@misc{rfc6356,
  author="C. Raiciu and M. Handley and D. Wischik",
  title="{Coupled Congestion Control for Multipath Transport Protocols}",
  howpublished="RFC 6356 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6356",
  pages="1--12",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6356.txt",
  key="RFC 6356",
  abstract={Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called ``resource pooling'' where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.},
  keywords="multipath, tcp, congestion control",
  doi="10.17487/RFC6356",
  }

@misc{rfc6357,
  author="V. Hilt and E. Noel and C. Shen and A. Abdelal",
  title="{Design Considerations for Session Initiation Protocol (SIP) Overload Control}",
  howpublished="RFC 6357 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6357",
  pages="1--25",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6357.txt",
  key="RFC 6357",
  abstract={Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive.  Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload.  This document discusses models and design considerations for a SIP overload control mechanism.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Session Initiation Protocol, Overload Control, Congestion Collapse",
  doi="10.17487/RFC6357",
  }

@misc{rfc6358,
  author="P. Hoffman",
  title="{Additional Master Secret Inputs for TLS}",
  howpublished="RFC 6358 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6358",
  pages="1--4",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6358.txt",
  key="RFC 6358",
  abstract={This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS).  This document defines an Experimental Protocol for the Internet community.},
  keywords="tls, dtls, datagram tls",
  doi="10.17487/RFC6358",
  }

@misc{rfc6359,
  author="S. Ginoza and M. Cotton and A. Morris",
  title="{Datatracker Extensions to Include IANA and RFC Editor Processing Information}",
  howpublished="RFC 6359 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6359",
  pages="1--18",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6359.txt",
  key="RFC 6359",
  abstract={This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC.  Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay.  Therefore, this document also describes the requirements to make such automation possible.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="id-tracker, backend extensions",
  doi="10.17487/RFC6359",
  }

@misc{rfc6360,
  author="R. Housley",
  title="{Conclusion of FYI RFC Sub-Series}",
  howpublished="RFC 6360 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6360",
  pages="1--3",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6360.txt",
  key="RFC 6360",
  abstract={This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists.  The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision.  This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6360",
  }

@misc{rfc6361,
  author="J. Carlson and D. {Eastlake 3rd}",
  title="{PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol}",
  howpublished="RFC 6361 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6361",
  pages="1--8",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6361.txt",
  key="RFC 6361",
  abstract={The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links.  This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]},
  keywords="point-to-point protocol, rbridges, routing bridges",
  doi="10.17487/RFC6361",
  }

@misc{rfc6362,
  author="K. Meadors",
  title="{Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)}",
  howpublished="RFC 6362 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6362",
  pages="1--8",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6362.txt",
  key="RFC 6362",
  abstract={The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents.  Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message.  As adoption of EDIINT grew, other uses developed aside from single EDI document transport.  Some transactions required multiple attachments to be interpreted together and stored in a single message.  This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message.  The attachments are stored within the MIME multipart/related structure.  A minimal list of content-types to be supported as attachments is provided.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="EDIINT, AS2, Multiple, Attachments",
  doi="10.17487/RFC6362",
  }

@misc{rfc6363,
  author="M. Watson and A. Begen and V. Roca",
  title="{Forward Error Correction (FEC) Framework}",
  howpublished="RFC 6363 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6363",
  pages="1--42",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6363.txt",
  key="RFC 6363",
  abstract={This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss.  The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media.  This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows.  Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.  Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]},
  keywords="Reliable streaming, content delivery, FEC schemes",
  doi="10.17487/RFC6363",
  }

@misc{rfc6364,
  author="A. Begen",
  title="{Session Description Protocol Elements for the Forward Error Correction (FEC) Framework}",
  howpublished="RFC 6364 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6364",
  pages="1--18",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6364.txt",
  key="RFC 6364",
  abstract={This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s).  This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]},
  keywords="FEC configuration, FEC topologies",
  doi="10.17487/RFC6364",
  }

@misc{rfc6365,
  author="P. Hoffman and J. Klensin",
  title="{Terminology Used in Internationalization in the IETF}",
  howpublished="RFC 6365 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6365",
  pages="1--47",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6365.txt",
  key="RFC 6365",
  abstract={This document provides a list of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.  This memo documents an Internet Best Current Practice.},
  keywords="i18n, vocabulary, terms",
  doi="10.17487/RFC6365",
  }

@misc{rfc6366,
  author="J. Valin and K. Vos",
  title="{Requirements for an Internet Audio Codec}",
  howpublished="RFC 6366 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6366",
  pages="1--17",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6366.txt",
  key="RFC 6366",
  abstract={This document provides specific requirements for an Internet audio codec.  These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6366",
  }

@misc{rfc6367,
  author="S. Kanno and M. Kanda",
  title="{Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)}",
  howpublished="RFC 6367 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6367",
  pages="1--8",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6367.txt",
  key="RFC 6367",
  abstract={This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="TLS, GCM, Eliptic Curve Encryption, Block Cipher, psk",
  doi="10.17487/RFC6367",
  }

@misc{rfc6368,
  author="P. Marques and R. Raszuk and K. Patel and K. Kumaki and T. Yamagata",
  title="{Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)}",
  howpublished="RFC 6368 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6368",
  pages="1--14",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7606",
url="https://www.rfc-editor.org/rfc/rfc6368.txt",
  key="RFC 6368",
  abstract={This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs.  These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]},
  keywords="l3vpn, iBGP, loops, as-override, attribute set, attr\_set",
  doi="10.17487/RFC6368",
  }

@misc{rfc6369,
  author="E. Haleplidis and O. Koufopavlou and S. Denazis",
  title="{Forwarding and Control Element Separation (ForCES) Implementation Experience}",
  howpublished="RFC 6369 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6369",
  pages="1--18",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6369.txt",
  key="RFC 6369",
  abstract={The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE).  This document captures the experience of implementing the ForCES protocol and model.  Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6369",
  }

@misc{rfc6370,
  author="M. Bocci and G. Swallow and E. Gray",
  title="{MPLS Transport Profile (MPLS-TP) Identifiers}",
  howpublished="RFC 6370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6370",
  pages="1--17",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6370.txt",
  key="RFC 6370",
  abstract={This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]},
  doi="10.17487/RFC6370",
  }

@misc{rfc6371,
  author="I. Busi and D. Allan",
  title="{Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks}",
  howpublished="RFC 6371 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6371",
  pages="1--62",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6435",
url="https://www.rfc-editor.org/rfc/rfc6371.txt",
  key="RFC 6371",
  abstract={The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6371",
  }

@misc{rfc6372,
  author="N. Sprecher and A. Farrel",
  title="{MPLS Transport Profile (MPLS-TP) Survivability Framework}",
  howpublished="RFC 6372 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6372",
  pages="1--56",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6372.txt",
  key="RFC 6372",
  abstract={Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes. This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Protection, Restoration, Recovery",
  doi="10.17487/RFC6372",
  }

@misc{rfc6373,
  author="L. Andersson and L. Berger and L. Fang and N. Bitar and E. Gray",
  title="{MPLS Transport Profile (MPLS-TP) Control Plane Framework}",
  howpublished="RFC 6373 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6373",
  pages="1--57",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6373.txt",
  key="RFC 6373",
  abstract={The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6373",
  }

@misc{rfc6374,
  author="D. Frost and S. Bryant",
  title="{Packet Loss and Delay Measurement for MPLS Networks}",
  howpublished="RFC 6374 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6374",
  pages="1--52",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7214",
url="https://www.rfc-editor.org/rfc/rfc6374.txt",
  key="RFC 6374",
  abstract={Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput.  This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation.  This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6374",
  }

@misc{rfc6375,
  author="D. Frost and S. Bryant",
  title="{A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks}",
  howpublished="RFC 6375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6375",
  pages="1--5",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6375.txt",
  key="RFC 6375",
  abstract={Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6375",
  }

@misc{rfc6376,
  author="D. Crocker and T. Hansen and M. Kucherawy",
  title="{DomainKeys Identified Mail (DKIM) Signatures}",
  howpublished="RFC 6376 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6376",
  pages="1--76",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6376.txt",
  key="RFC 6376",
  abstract={DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]},
  keywords="email, architecture, abuse, verification, anti-abuse, identity, integrity, responsible, author, sender, originator, email filtering, anti-phishing, mail signature",
  doi="10.17487/RFC6376",
  }

@misc{rfc6377,
  author="M. Kucherawy",
  title="{DomainKeys Identified Mail (DKIM) and Mailing Lists}",
  howpublished="RFC 6377 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6377",
  pages="1--26",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6377.txt",
  key="RFC 6377",
  abstract={DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message.  Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs).  This memo documents an Internet Best Current Practice.},
  keywords="email, architecture, verification, anti-abuse, identity, integrity, responsible, author, sender, originator",
  doi="10.17487/RFC6377",
  }

@misc{rfc6378,
  author="Y. Weingarten and S. Bryant and E. Osborne and N. Sprecher and A. Fulignoli",
  title="{MPLS Transport Profile (MPLS-TP) Linear Protection}",
  howpublished="RFC 6378 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6378",
  pages="1--45",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7214, 7271, 7324",
url="https://www.rfc-editor.org/rfc/rfc6378.txt",
  key="RFC 6378",
  abstract={This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]},
  keywords="PSC, Protection State Coordination Protocol,",
  doi="10.17487/RFC6378",
  }

@misc{rfc6379,
  author="L. Law and J. Solinas",
  title="{Suite B Cryptographic Suites for IPsec}",
  howpublished="RFC 6379 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6379",
  pages="1--7",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6379.txt",
  key="RFC 6379",
  abstract={This document proposes four cryptographic user interface suites (``UI suites'') for IP Security (IPsec), similar to the two suites specified in RFC 4308.  The four new suites provide compatibility with the United States National Security Agency's Suite B specifications.  This document obsoletes RFC 4869, which presented earlier versions of these suites.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="UI suites, user interface suites, elliptic curve, ike",
  doi="10.17487/RFC6379",
  }

@misc{rfc6380,
  author="K. Burgin and M. Peck",
  title="{Suite B Profile for Internet Protocol Security (IPsec)}",
  howpublished="RFC 6380 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6380",
  pages="1--10",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6380.txt",
  key="RFC 6380",
  abstract={The United States Government has published guidelines for ``NSA Suite B Cryptography'' dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec). Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="cryptographic algorithm policy, security application, suite b cryptography",
  doi="10.17487/RFC6380",
  }

@misc{rfc6381,
  author="R. Gellens and D. Singer and P. Frojdh",
  title="{The 'Codecs' and 'Profiles' Parameters for ``Bucket'' Media Types}",
  howpublished="RFC 6381 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6381",
  pages="1--19",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6381.txt",
  key="RFC 6381",
  abstract={Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.). Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]},
  keywords="codec, container, audio, video, 3gpp, 3gpp2",
  doi="10.17487/RFC6381",
  }

@misc{rfc6382,
  author="D. McPherson and R. Donnelly and F. Scalzo",
  title="{Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services}",
  howpublished="RFC 6382 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6382",
  pages="1--10",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6382.txt",
  key="RFC 6382",
  abstract={This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix.  Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.  This memo documents an Internet Best Current Practice.},
  keywords="BGP, SIDR, RPKI, security, routing, operations, root, TLD, DNS, DDOS, peering, RIR, IRR, MITM",
  doi="10.17487/RFC6382",
  }

@misc{rfc6383,
  author="K. Shiomoto and A. Farrel",
  title="{Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE}",
  howpublished="RFC 6383 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6383",
  pages="1--11",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6383.txt",
  key="RFC 6383",
  abstract={The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with ``cross-connect'' information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages. This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RSVP-TE, GMPLS, MPLS-TE, cross-connect, data plane",
  doi="10.17487/RFC6383",
  }

@misc{rfc6384,
  author="I. van Beijnum",
  title="{An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation}",
  howpublished="RFC 6384 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6384",
  pages="1--16",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6384.txt",
  key="RFC 6384",
  abstract={The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent. FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]},
  keywords="FTP, SIIT, NAT64",
  doi="10.17487/RFC6384",
  }

@misc{rfc6385,
  author="M. Barnes and A. Doria and H. Alvestrand and B. Carpenter",
  title="{General Area Review Team (Gen-ART) Experiences}",
  howpublished="RFC 6385 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6385",
  pages="1--23",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6385.txt",
  key="RFC 6385",
  abstract={The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004.  This document discusses the experience and the lessons learned over the past 7 years of this process.  The review team initially reviewed the I-Ds before each of the IESG telechats.  Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D.  The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="genart",
  doi="10.17487/RFC6385",
  }

@misc{rfc6386,
  author="J. Bankoski and J. Koleszar and L. Quillio and J. Salonen and P. Wilkins and Y. Xu",
  title="{VP8 Data Format and Decoding Guide}",
  howpublished="RFC 6386 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6386",
  pages="1--304",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6386.txt",
  key="RFC 6386",
  abstract={This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6386",
  }

@misc{rfc6387,
  author="A. Takacs and L. Berger and D. Caviglia and D. Fedyk and J. Meuric",
  title="{GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)}",
  howpublished="RFC 6387 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6387",
  pages="1--11",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6387.txt",
  key="RFC 6387",
  abstract={This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs).  The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters.  This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]},
  keywords="rsvp, resource reservation protocol",
  doi="10.17487/RFC6387",
  }

@misc{rfc6388,
  author="IJ. Wijnands and I. Minei and K. Kompella and B. Thomas",
  title="{Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths}",
  howpublished="RFC 6388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6388",
  pages="1--39",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7358",
url="https://www.rfc-editor.org/rfc/rfc6388.txt",
  key="RFC 6388",
  abstract={This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.  These extensions are also referred to as multipoint LDP.  Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.  Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner.  There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs).  Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6388",
  }

@misc{rfc6389,
  author="R. Aggarwal and JL. Le Roux",
  title="{MPLS Upstream Label Assignment for LDP}",
  howpublished="RFC 6389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6389",
  pages="1--13",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6389.txt",
  key="RFC 6389",
  abstract={This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP).  It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6389",
  }

@misc{rfc6390,
  author="A. Clark and B. Claise",
  title="{Guidelines for Considering New Performance Metric Development}",
  howpublished="RFC 6390 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6390",
  pages="1--23",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6390.txt",
  key="RFC 6390",
  abstract={This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols.  These metrics can be used to characterize traffic on live networks and services.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6390",
  }

@misc{rfc6391,
  author="S. Bryant and C. Filsfils and U. Drafz and V. Kompella and J. Regan and S. Amante",
  title="{Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network}",
  howpublished="RFC 6391 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6391",
  pages="1--19",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc6391.txt",
  key="RFC 6391",
  abstract={Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6391",
  }

@misc{rfc6392,
  author="R. Alimi and A. Rahman and Y. Yang",
  title="{A Survey of In-Network Storage Systems}",
  howpublished="RFC 6392 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6392",
  pages="1--44",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6392.txt",
  key="RFC 6392",
  abstract={This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="P2P, DECADE, DECoupled Application Data Enroute",
  doi="10.17487/RFC6392",
  }

@misc{rfc6393,
  author="M. Yevstifeyev",
  title="{Moving RFC 4693 to Historic}",
  howpublished="RFC 6393 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6393",
  pages="1--3",
  year=2011,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6393.txt",
  key="RFC 6393",
  abstract={This document moves RFC 4693 to Historic status.  It also obsoletes RFC 4693.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ION, historic",
  doi="10.17487/RFC6393",
  }

@misc{rfc6394,
  author="R. Barnes",
  title="{Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)}",
  howpublished="RFC 6394 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6394",
  pages="1--12",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6394.txt",
  key="RFC 6394",
  abstract={Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name.  Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself.  This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process.  The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]},
  keywords="TLS, PKIX",
  doi="10.17487/RFC6394",
  }

@misc{rfc6395,
  author="S. Gulrajani and S. Venaas",
  title="{An Interface Identifier (ID) Hello Option for PIM}",
  howpublished="RFC 6395 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6395",
  pages="1--6",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6395.txt",
  key="RFC 6395",
  abstract={This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6395",
  }

@misc{rfc6396,
  author="L. Blunk and M. Karir and C. Labovitz",
  title="{Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format}",
  howpublished="RFC 6396 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6396",
  pages="1--33",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6396.txt",
  key="RFC 6396",
  abstract={This document describes the MRT format for routing information export.  This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name.  The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6396",
  }

@misc{rfc6397,
  author="T. Manderson",
  title="{Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions}",
  howpublished="RFC 6397 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6397",
  pages="1--8",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6397.txt",
  key="RFC 6397",
  abstract={This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]},
  keywords="GPS Coordinates, Terrestrial Coordinates, BGP Speaker, BGP Peer, BGP Latitude, BGP Longitude",
  doi="10.17487/RFC6397",
  }

@misc{rfc6398,
  author="F. Le Faucheur",
  title="{IP Router Alert Considerations and Usage}",
  howpublished="RFC 6398 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6398",
  pages="1--19",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6398.txt",
  key="RFC 6398",
  abstract={The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet.  The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option.  This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711.  Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  It also provides recommendations about protection approaches for service providers.  Finally, it provides brief guidelines for Router Alert implementation on routers.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6398",
  }

@misc{rfc6401,
  author="F. Le Faucheur and J. Polk and K. Carlberg",
  title="{RSVP Extensions for Admission Priority}",
  howpublished="RFC 6401 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6401",
  pages="1--32",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6401.txt",
  key="RFC 6401",
  abstract={Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6401",
  }

@misc{rfc6402,
  author="J. Schaad",
  title="{Certificate Management over CMS (CMC) Updates}",
  howpublished="RFC 6402 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6402",
  pages="1--37",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6402.txt",
  key="RFC 6402",
  abstract={This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]},
  keywords="cyrptographic message syntax",
  doi="10.17487/RFC6402",
  }

@misc{rfc6403,
  author="L. Zieglar and S. Turner and M. Peck",
  title="{Suite B Profile of Certificate Management over CMS}",
  howpublished="RFC 6403 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6403",
  pages="1--16",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6403.txt",
  key="RFC 6403",
  abstract={The United States government has published guidelines for ``NSA Suite\0B Cryptography'', which defines cryptographic algorithm policy for national security applications.  This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates.  This profile is a refinement of RFCs 5272, 5273, and 5274.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="cmc, suite b x.509 public key certificates",
  doi="10.17487/RFC6403",
  }

@misc{rfc6404,
  author="J. Seedorf and S. Niccolini and E. Chen and H. Scholz",
  title="{Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures}",
  howpublished="RFC 6404 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6404",
  pages="1--22",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6404.txt",
  key="RFC 6404",
  abstract={The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs).  The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures.  Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements.  In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider.  Various instances of the threats are briefly introduced inside the classification.  Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats.  Each SSP may have connections to one or more remote SSPs through peering or transit contracts.  A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="VoIP, Security, Threats, multimedia, Threat countermeasures, SIP Interconnect, VoIP peering, Fraud prevention, Network protection, SIP, RTP, RTCP, control plane, user plane",
  doi="10.17487/RFC6404",
  }

@misc{rfc6405,
  author="A. Uzelac and Y. Lee",
  title="{Voice over IP (VoIP) SIP Peering Use Cases}",
  howpublished="RFC 6405 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6405",
  pages="1--23",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6405.txt",
  key="RFC 6405",
  abstract={This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering.  These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect.  These use cases are not an exhaustive set, but rather the most common use cases deployed today.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="VoIP, SIP Peering",
  doi="10.17487/RFC6405",
  }

@misc{rfc6406,
  author="D. Malas and J. Livingood",
  title="{Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture}",
  howpublished="RFC 6406 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6406",
  pages="1--16",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6406.txt",
  key="RFC 6406",
  abstract={This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces.  It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6406",
  }

@misc{rfc6407,
  author="B. Weis and S. Rowles and T. Hardjono",
  title="{The Group Domain of Interpretation}",
  howpublished="RFC 6407 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6407",
  pages="1--64",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6407.txt",
  key="RFC 6407",
  abstract={This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547.  The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046.  The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols.  This document replaces RFC 3547. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6407",
  }

@misc{rfc6408,
  author="M. Jones and J. Korhonen and L. Morand",
  title="{Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage}",
  howpublished="RFC 6408 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6408",
  pages="1--14",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6408.txt",
  key="RFC 6408",
  abstract={The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol.  However, these mechanisms do not reveal the Diameter applications that each node supports.  A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application.  This document updates RFC 3588, ``Diameter Base Protocol'', and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]},
  keywords="Services Field, Peer Discovery",
  doi="10.17487/RFC6408",
  }

@misc{rfc6409,
  author="R. Gellens and J. Klensin",
  title="{Message Submission for Mail}",
  howpublished="RFC 6409 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6409",
  pages="1--20",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6409.txt",
  key="RFC 6409",
  abstract={This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]},
  keywords="Text, Internationalization, ASCII, Unicode, UTF-8",
  doi="10.17487/RFC6409",
  }

@misc{rfc6410,
  author="R. Housley and D. Crocker and E. Burger",
  title="{Reducing the Standards Track to Two Maturity Levels}",
  howpublished="RFC 6410 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6410",
  pages="1--6",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6410.txt",
  key="RFC 6410",
  abstract={This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026.  Primarily, it reduces the Standards Process from three Standards Track maturity levels to two.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6410",
  }

@misc{rfc6411,
  author="M. Behringer and F. Le Faucheur and B. Weis",
  title="{Applicability of Keying Methods for RSVP Security}",
  howpublished="RFC 6411 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6411",
  pages="1--19",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6411.txt",
  key="RFC 6411",
  abstract={The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors.  This requires messages to be cryptographically protected using a shared secret between participating nodes.  This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches.  This document also discusses applicability of encrypting RSVP messages.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RSVP authentication, RSVP integrity, Resource reservation protocol, GDOI, Group domain of interpretation",
  doi="10.17487/RFC6411",
  }

@misc{rfc6412,
  author="S. Poretsky and B. Imhoff and K. Michielsen",
  title="{Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence}",
  howpublished="RFC 6412 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6412",
  pages="1--29",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6412.txt",
  key="RFC 6412",
  abstract={This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence.  The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements.  The terminology can be applied to any link-state IGP, such as IS-IS and OSPF.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6412",
  }

@misc{rfc6413,
  author="S. Poretsky and B. Imhoff and K. Michielsen",
  title="{Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence}",
  howpublished="RFC 6413 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6413",
  pages="1--42",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6413.txt",
  key="RFC 6413",
  abstract={This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence.  The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements.  The methodology can be applied to any link-state IGP, such as IS-IS and OSPF.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Interior Gateway Protocol",
  doi="10.17487/RFC6413",
  }

@misc{rfc6414,
  author="S. Poretsky and R. Papneja and J. Karthik and S. Vapiwala",
  title="{Benchmarking Terminology for Protection Performance}",
  howpublished="RFC 6414 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6414",
  pages="1--33",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6414.txt",
  key="RFC 6414",
  abstract={This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms.  The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer.  The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6414",
  }

@misc{rfc6415,
  author="E. Hammer-Lahav and B. Cook",
  title="{Web Host Metadata}",
  howpublished="RFC 6415 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6415",
  pages="1--16",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6415.txt",
  key="RFC 6415",
  abstract={This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6415",
  }

@misc{rfc6416,
  author="M. Schmidt and F. de Bont and S. Doehla and J. Kim",
  title="{RTP Payload Format for MPEG-4 Audio/Visual Streams}",
  howpublished="RFC 6416 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6416",
  pages="1--35",
  year=2011,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6416.txt",
  key="RFC 6416",
  abstract={This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]},
  keywords="RFC3016, RTP, MPEG-4, Audio, Visual, Video, AAC, HE AAC, HE AAC v2, MPEG Surround",
  doi="10.17487/RFC6416",
  }

@misc{rfc6417,
  author="P. Eardley and L. Eggert and M. Bagnulo and R. Winter",
  title="{How to Contribute Research Results to Internet Standardization}",
  howpublished="RFC 6417 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6417",
  pages="1--14",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6417.txt",
  key="RFC 6417",
  abstract={The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community. For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6417",
  }

@misc{rfc6418,
  author="M. Blanchet and P. Seite",
  title="{Multiple Interfaces and Provisioning Domains Problem Statement}",
  howpublished="RFC 6418 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6418",
  pages="1--22",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6418.txt",
  key="RFC 6418",
  abstract={This document describes issues encountered by a node attached to multiple provisioning domains.  This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface.  Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used.  Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism.  While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="multi-homing, MIF, DNS, DHCP",
  doi="10.17487/RFC6418",
  }

@misc{rfc6419,
  author="M. Wasserman and P. Seite",
  title="{Current Practices for Multiple-Interface Hosts}",
  howpublished="RFC 6419 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6419",
  pages="1--21",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6419.txt",
  key="RFC 6419",
  abstract={An increasing number of hosts are operating in multiple-interface environments.  This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="current practices, multi-homing, MIF",
  doi="10.17487/RFC6419",
  }

@misc{rfc6420,
  author="Y. Cai and H. Ou",
  title="{PIM Multi-Topology ID (MT-ID) Join Attribute}",
  howpublished="RFC 6420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6420",
  pages="1--13",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6420.txt",
  key="RFC 6420",
  abstract={This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6420",
  }

@misc{rfc6421,
  author="D. Nelson",
  title="{Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)}",
  howpublished="RFC 6421 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6421",
  pages="1--12",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6421.txt",
  key="RFC 6421",
  abstract={This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6421",
  }

@misc{rfc6422,
  author="T. Lemon and Q. Wu",
  title="{Relay-Supplied DHCP Options}",
  howpublished="RFC 6422 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6422",
  pages="1--8",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6422.txt",
  key="RFC 6422",
  abstract={DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client. This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]},
  keywords="DHCPv6 Relay, DHCPv6 option",
  doi="10.17487/RFC6422",
  }

@misc{rfc6423,
  author="H. Li and L. Martini and J. He and F. Huang",
  title="{Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)}",
  howpublished="RFC 6423 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6423",
  pages="1--5",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6423.txt",
  key="RFC 6423",
  abstract={This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6423",
  }

@misc{rfc6424,
  author="N. Bahadur and K. Kompella and G. Swallow",
  title="{Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels}",
  howpublished="RFC 6424 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6424",
  pages="1--23",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8029, updated by RFC 7537",
url="https://www.rfc-editor.org/rfc/rfc6424.txt",
  key="RFC 6424",
  abstract={This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs).  The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP.  This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]},
  keywords="MPLS OAM, lsp ping, LSP-Ping",
  doi="10.17487/RFC6424",
  }

@misc{rfc6425,
  author="S. Saxena and G. Swallow and Z. Ali and A. Farrel and S. Yasukawa and T. Nadeau",
  title="{Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping}",
  howpublished="RFC 6425 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6425",
  pages="1--28",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6425.txt",
  key="RFC 6425",
  abstract={Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as ``LSP ping''. The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment. This document updates RFC 4379. [STANDARDS-TRACK]},
  keywords="p2mp",
  doi="10.17487/RFC6425",
  }

@misc{rfc6426,
  author="E. Gray and N. Bahadur and S. Boutros and R. Aggarwal",
  title="{MPLS On-Demand Connectivity Verification and Route Tracing}",
  howpublished="RFC 6426 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6426",
  pages="1--22",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6426.txt",
  key="RFC 6426",
  abstract={Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs).  This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires.  This document also clarifies procedures to be used for processing the related OAM packets.  Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks.  Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]},
  keywords="lsp ping, mpls tp, mpls-tp",
  doi="10.17487/RFC6426",
  }

@misc{rfc6427,
  author="G. Swallow and A. Fulignoli and M. Vigoureux and S. Boutros and D. Ward",
  title="{MPLS Fault Management Operations, Administration, and Maintenance (OAM)}",
  howpublished="RFC 6427 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6427",
  pages="1--17",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7214",
url="https://www.rfc-editor.org/rfc/rfc6427.txt",
  key="RFC 6427",
  abstract={This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths.  The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point.  This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]},
  keywords="mpls-oam",
  doi="10.17487/RFC6427",
  }

@misc{rfc6428,
  author="D. Allan and G. Swallow and J. Drake",
  title="{Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile}",
  howpublished="RFC 6428 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6428",
  pages="1--21",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7214",
url="https://www.rfc-editor.org/rfc/rfc6428.txt",
  key="RFC 6428",
  abstract={Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section. This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]},
  keywords="mpls-tp, oam, Operations, Administration, and Maintenance, bfd, bidirectional forwarding dectection",
  doi="10.17487/RFC6428",
  }

@misc{rfc6429,
  author="M. Bashyam and M. Jethanandani and A. Ramaiah",
  title="{TCP Sender Clarification for Persist Condition}",
  howpublished="RFC 6429 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6429",
  pages="1--7",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6429.txt",
  key="RFC 6429",
  abstract={This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 (``Requirements for Internet Hosts -- Communication Layers'').  In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition.  Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="zero window probe, denial of service (DoS), security vulnerability",
  doi="10.17487/RFC6429",
  }

@misc{rfc6430,
  author="K. Li and B. Leiba",
  title="{Email Feedback Report Type Value: not-spam}",
  howpublished="RFC 6430 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6430",
  pages="1--7",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6430.txt",
  key="RFC 6430",
  abstract={This document defines a new Abuse Reporting Format (ARF) feedback report type value: ``not-spam''.  It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]},
  keywords="arf, abuse reporting format",
  doi="10.17487/RFC6430",
  }

@misc{rfc6431,
  author="M. Boucadair and P. Levis and G. Bajko and T. Savolainen and T. Tsou",
  title="{Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)}",
  howpublished="RFC 6431 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6431",
  pages="1--16",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6431.txt",
  key="RFC 6431",
  abstract={This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports.  These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv4 Address Exhaustion, IPv4 service continuity, IPv6, A+P",
  doi="10.17487/RFC6431",
  }

@misc{rfc6432,
  author="R. Jesske and L. Liess",
  title="{Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses}",
  howpublished="RFC 6432 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6432",
  pages="1--4",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6432.txt",
  key="RFC 6432",
  abstract={Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code.  Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems.  This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]},
  keywords="cause code",
  doi="10.17487/RFC6432",
  }

@misc{rfc6433,
  author="P. Hoffman",
  title="{Requirements for a Working Group Milestones Tool}",
  howpublished="RFC 6433 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6433",
  pages="1--7",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6433.txt",
  key="RFC 6433",
  abstract={The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters.  This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool.  This document updates RFC 6292.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="working group charter, charter",
  doi="10.17487/RFC6433",
  }

@misc{rfc6434,
  author="E. Jankiewicz and J. Loughney and T. Narten",
  title="{IPv6 Node Requirements}",
  howpublished="RFC 6434 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6434",
  pages="1--30",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6434.txt",
  key="RFC 6434",
  abstract={This document defines requirements for IPv6 nodes.  It is expected that IPv6 will be deployed in a wide range of devices and situations.  Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Internet Protocol Version 6, Internet Protocol, IP",
  doi="10.17487/RFC6434",
  }

@misc{rfc6435,
  author="S. Boutros and S. Sivabalan and R. Aggarwal and M. Vigoureux and X. Dai",
  title="{MPLS Transport Profile Lock Instruct and Loopback Functions}",
  howpublished="RFC 6435 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6435",
  pages="1--12",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6435.txt",
  key="RFC 6435",
  abstract={Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are ``lock'' and ``loopback''. The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]},
  keywords="oam, operations, administration, and maintenance",
  doi="10.17487/RFC6435",
  }

@misc{rfc6436,
  author="S. Amante and B. Carpenter and S. Jiang",
  title="{Rationale for Update to the IPv6 Flow Label Specification}",
  howpublished="RFC 6436 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6436",
  pages="1--13",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6436.txt",
  key="RFC 6436",
  abstract={Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697.  Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification.  This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ECMP, LAG",
  doi="10.17487/RFC6436",
  }

@misc{rfc6437,
  author="S. Amante and B. Carpenter and S. Jiang and J. Rajahalme",
  title="{IPv6 Flow Label Specification}",
  howpublished="RFC 6437 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6437",
  pages="1--15",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6437.txt",
  key="RFC 6437",
  abstract={This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6437",
  }

@misc{rfc6438,
  author="B. Carpenter and S. Amante",
  title="{Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels}",
  howpublished="RFC 6438 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6438",
  pages="1--9",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6438.txt",
  key="RFC 6438",
  abstract={The IPv6 flow label has certain restrictions on its use.  This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]},
  keywords="ECMP, LAG",
  doi="10.17487/RFC6438",
  }

@misc{rfc6439,
  author="R. Perlman and D. Eastlake and Y. Li and A. Banerjee and F. Hu",
  title="{Routing Bridges (RBridges): Appointed Forwarders}",
  howpublished="RFC 6439 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6439",
  pages="1--15",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7180",
url="https://www.rfc-editor.org/rfc/rfc6439.txt",
  key="RFC 6439",
  abstract={The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called ``RBridges'' (Routing Bridges). TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called ``Appointed Forwarders'', with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]},
  keywords="trill, TRansparent Interconnection of Lots of Links",
  doi="10.17487/RFC6439",
  }

@misc{rfc6440,
  author="G. Zorn and Q. Wu and Y. Wang",
  title="{The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option}",
  howpublished="RFC 6440 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6440",
  pages="1--6",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6440.txt",
  key="RFC 6440",
  abstract={In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]},
  keywords="re-authentication, handover, LDN, Discovery",
  doi="10.17487/RFC6440",
  }

@misc{rfc6441,
  author="L. Vegoda",
  title="{Time to Remove Filters for Previously Unallocated IPv4 /8s}",
  howpublished="RFC 6441 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6441",
  pages="1--5",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6441.txt",
  key="RFC 6441",
  abstract={It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space. This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.},
  keywords="bogons, IPv4, martians, filters",
  doi="10.17487/RFC6441",
  }

@misc{rfc6442,
  author="J. Polk and B. Rosen and J. Peterson",
  title="{Location Conveyance for the Session Initiation Protocol}",
  howpublished="RFC 6442 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6442",
  pages="1--35",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6442.txt",
  key="RFC 6442",
  abstract={This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity.  The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]},
  keywords="sip, geographic location, location target",
  doi="10.17487/RFC6442",
  }

@misc{rfc6443,
  author="B. Rosen and H. Schulzrinne and J. Polk and A. Newton",
  title="{Framework for Emergency Calling Using Internet Multimedia}",
  howpublished="RFC 6443 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6443",
  pages="1--38",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7852",
url="https://www.rfc-editor.org/rfc/rfc6443.txt",
  key="RFC 6443",
  abstract={The IETF has standardized various aspects of placing emergency calls.  This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6443",
  }

@misc{rfc6444,
  author="H. Schulzrinne and L. Liess and H. Tschofenig and B. Stark and A. Kuett",
  title="{Location Hiding: Problem Statement and Requirements}",
  howpublished="RFC 6444 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6444",
  pages="1--9",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6444.txt",
  key="RFC 6444",
  abstract={The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="emergency call, privacy, PSAP, Location by Reference",
  doi="10.17487/RFC6444",
  }

@misc{rfc6445,
  author="T. Nadeau and A. Koushik and R. Cetin",
  title="{Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute}",
  howpublished="RFC 6445 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6445",
  pages="1--53",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6445.txt",
  key="RFC 6445",
  abstract={This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community.  In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE).  The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]},
  keywords="mib, frr, MPLS-FRR-GENERAL-STD-MIB, MPLS-FRR-ONE2ONE-STD-MIB, MPLS-FRR-FACILITY-STD-MIB",
  doi="10.17487/RFC6445",
  }

@misc{rfc6446,
  author="A. Niemi and K. Kiss and S. Loreto",
  title="{Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control}",
  howpublished="RFC 6446 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6446",
  pages="1--25",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6446.txt",
  key="RFC 6446",
  abstract={This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications.  These mechanisms can be applied in subscriptions to all SIP event packages.  This document updates RFC 3265. [STANDARDS-TRACK]},
  keywords="SIP, events, rate control",
  doi="10.17487/RFC6446",
  }

@misc{rfc6447,
  author="R. Mahy and B. Rosen and H. Tschofenig",
  title="{Filtering Location Notifications in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6447 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6447",
  pages="1--19",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6447.txt",
  key="RFC 6447",
  abstract={This document describes filters that limit asynchronous location notifications to compelling events.  These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package.  The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]},
  keywords="geopriv, location",
  doi="10.17487/RFC6447",
  }

@misc{rfc6448,
  author="R. Yount",
  title="{The Unencrypted Form of Kerberos 5 KRB-CRED Message}",
  howpublished="RFC 6448 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6448",
  pages="1--4",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6448.txt",
  key="RFC 6448",
  abstract={The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications.  When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable.  This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]},
  keywords="credential",
  doi="10.17487/RFC6448",
  }

@misc{rfc6449,
  author="J. Falk",
  title="{Complaint Feedback Loop Operational Recommendations}",
  howpublished="RFC 6449 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6449",
  pages="1--31",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6449.txt",
  key="RFC 6449",
  abstract={Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices. This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MAAWG, ARF, MARF, feedback loop, spam reporting",
  doi="10.17487/RFC6449",
  }

@misc{rfc6450,
  author="S. Venaas",
  title="{Multicast Ping Protocol}",
  howpublished="RFC 6450 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6450",
  pages="1--24",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6450.txt",
  key="RFC 6450",
  abstract={The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also be used to obtain additional multicast-related information, such as multicast tree setup time.  This protocol is based on an implementation of tools called ``ssmping'' and ``asmping''. [STANDARDS-TRACK]},
  keywords="ssm, asm, ssmping, asmping",
  doi="10.17487/RFC6450",
  }

@misc{rfc6451,
  author="A. Forte and H. Schulzrinne",
  title="{Location-to-Service Translation (LoST) Protocol Extensions}",
  howpublished="RFC 6451 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6451",
  pages="1--23",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6451.txt",
  key="RFC 6451",
  abstract={An important class of location-based services answers the question, ``What instances of this service are closest to me?'' Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces.  Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions.  This document describes an extension that allows queries of the type ``N nearest'', ``within distance X'', and ``served by''.  This document defines an Experimental Protocol for the Internet community.},
  keywords="location-based services, location, GPS, point of interest",
  doi="10.17487/RFC6451",
  }

@misc{rfc6452,
  author="P. Faltstrom and P. Hoffman",
  title="{The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0}",
  howpublished="RFC 6452 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6452",
  pages="1--4",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6452.txt",
  key="RFC 6452",
  abstract={This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released.  The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]},
  keywords="DNS, IDN",
  doi="10.17487/RFC6452",
  }

@misc{rfc6453,
  author="F. Dijkstra and R. Hughes-Jones",
  title="{A URN Namespace for the Open Grid Forum (OGF)}",
  howpublished="RFC 6453 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6453",
  pages="1--9",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6453.txt",
  key="RFC 6453",
  abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="identifier",
  doi="10.17487/RFC6453",
  }

@misc{rfc6454,
  author="A. Barth",
  title="{The Web Origin Concept}",
  howpublished="RFC 6454 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6454",
  pages="1--20",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6454.txt",
  key="RFC 6454",
  abstract={This document defines the concept of an ``origin'', which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named ``Origin'', that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]},
  keywords="same-origin, policy, security, cross-origin",
  doi="10.17487/RFC6454",
  }

@misc{rfc6455,
  author="I. Fette and A. Melnikov",
  title="{The WebSocket Protocol}",
  howpublished="RFC 6455 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6455",
  pages="1--71",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7936",
url="https://www.rfc-editor.org/rfc/rfc6455.txt",
  key="RFC 6455",
  abstract={The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.  The security model used for this is the origin-based security model commonly used by web browsers.  The protocol consists of an opening handshake followed by basic message framing, layered over TCP.  The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]},
  keywords="HyBi Working Group, HYBI, websocket",
  doi="10.17487/RFC6455",
  }

@misc{rfc6456,
  author="H. Li and R. Zheng and A. Farrel",
  title="{Multi-Segment Pseudowires in Passive Optical Networks}",
  howpublished="RFC 6456 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6456",
  pages="1--12",
  year=2011,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6456.txt",
  key="RFC 6456",
  abstract={This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN). PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager. This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration. This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MPLS, PSN, PON, G-PON, XG-PON, OMCI",
  doi="10.17487/RFC6456",
  }

@misc{rfc6457,
  author="T. Takeda and A. Farrel",
  title="{PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering}",
  howpublished="RFC 6457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6457",
  pages="1--12",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6457.txt",
  key="RFC 6457",
  abstract={The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, ``Path Computation Element (PCE) Communication Protocol Generic Requirements''. Generic requirements for a PCE discovery protocol are presented in RFC 4674, ``Requirements for Path Computation Element (PCE) Discovery''. This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="PCEP, inter-layer, traffic engineering, MPLS, GMPLS, VNT",
  doi="10.17487/RFC6457",
  }

@misc{rfc6458,
  author="R. Stewart and M. Tuexen and K. Poon and P. Lei and V. Yasevich",
  title="{Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)}",
  howpublished="RFC 6458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6458",
  pages="1--115",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6458.txt",
  key="RFC 6458",
  abstract={This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API.  The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6458",
  }

@misc{rfc6459,
  author="J. Korhonen and J. Soininen and B. Patil and T. Savolainen and G. Bajko and K. Iisakkila",
  title="{IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)}",
  howpublished="RFC 6459 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6459",
  pages="1--36",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6459.txt",
  key="RFC 6459",
  abstract={The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed.  Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6.  This document describes the support for IPv6 in 3GPP network architectures.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Transition, Migration",
  doi="10.17487/RFC6459",
  }

@misc{rfc6460,
  author="M. Salter and R. Housley",
  title="{Suite B Profile for Transport Layer Security (TLS)}",
  howpublished="RFC 6460 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6460",
  pages="1--14",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6460.txt",
  key="RFC 6460",
  abstract={The United States government has published guidelines for ``NSA Suite B Cryptography'' that define cryptographic algorithm policy for national security applications.  This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="cryptographic algorithm policy",
  doi="10.17487/RFC6460",
  }

@misc{rfc6461,
  author="S. Channabasappa",
  title="{Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements}",
  howpublished="RFC 6461 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6461",
  pages="1--15",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6461.txt",
  key="RFC 6461",
  abstract={This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing.  Specifically, this document focuses on the provisioning of one such element termed the ``registry''.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="registry, registry provisioning, registrar, destination group, route group",
  doi="10.17487/RFC6461",
  }

@misc{rfc6462,
  author="A. Cooper",
  title="{Report from the Internet Privacy Workshop}",
  howpublished="RFC 6462 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6462",
  pages="1--23",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6462.txt",
  key="RFC 6462",
  abstract={On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6462",
  }

@misc{rfc6463,
  author="J. Korhonen and S. Gundavelli and H. Yokota and X. Cui",
  title="{Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6}",
  howpublished="RFC 6463 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6463",
  pages="1--22",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6463.txt",
  key="RFC 6463",
  abstract={This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6.  The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor.  The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6463",
  }

@misc{rfc6464,
  author="J. Lennox and E. Ivov and E. Marocco",
  title="{A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication}",
  howpublished="RFC 6464 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6464",
  pages="1--9",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6464.txt",
  key="RFC 6464",
  abstract={This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet.  In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]},
  keywords="ssrc-audio-level, ssrc, speech, sound, energy, conference, bridge",
  doi="10.17487/RFC6464",
  }

@misc{rfc6465,
  author="E. Ivov and E. Marocco and J. Lennox",
  title="{A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication}",
  howpublished="RFC 6465 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6465",
  pages="1--15",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6465.txt",
  key="RFC 6465",
  abstract={This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants.  Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]},
  keywords="csrc-audio-level, csrc, speech, sound, energy, conference, bridge",
  doi="10.17487/RFC6465",
  }

@misc{rfc6466,
  author="G. Salgueiro",
  title="{IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)}",
  howpublished="RFC 6466 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6466",
  pages="1--6",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6466.txt",
  key="RFC 6466",
  abstract={This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP).  This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]},
  keywords="t.38 media",
  doi="10.17487/RFC6466",
  }

@misc{rfc6467,
  author="T. Kivinen",
  title="{Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)}",
  howpublished="RFC 6467 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6467",
  pages="1--10",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6467.txt",
  key="RFC 6467",
  abstract={This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods.  Multiple methods are already specified in other documents, and this document does not add any new one.  This document specifies a way to agree on which method is to be used in the current connection.  This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.},
  keywords="IPsec, IKE, mutual authentication, credentials, VPN gateway",
  doi="10.17487/RFC6467",
  }

@misc{rfc6468,
  author="A. Melnikov and B. Leiba and K. Li",
  title="{Sieve Notification Mechanism: SIP MESSAGE}",
  howpublished="RFC 6468 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6468",
  pages="1--10",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6468.txt",
  key="RFC 6468",
  abstract={This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]},
  keywords="Sieve, SIP, notification",
  doi="10.17487/RFC6468",
  }

@misc{rfc6469,
  author="K. Kobayashi and K. Mishima and S. Casner and C. Bormann",
  title="{RTP Payload Format for DV (IEC 61834) Video}",
  howpublished="RFC 6469 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6469",
  pages="1--18",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6469.txt",
  key="RFC 6469",
  abstract={This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as ``DV'' into a payload format for the Real-Time Transport Protocol (RTP).  This document obsoletes RFC 3189. [STANDARDS-TRACK]},
  keywords="DV/RTP, real-time transport protocol",
  doi="10.17487/RFC6469",
  }

@misc{rfc6470,
  author="A. Bierman",
  title="{Network Configuration Protocol (NETCONF) Base Notifications}",
  howpublished="RFC 6470 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6470",
  pages="1--15",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6470.txt",
  key="RFC 6470",
  abstract={The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores.  However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications.  Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server.  This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]},
  keywords="XML",
  doi="10.17487/RFC6470",
  }

@misc{rfc6471,
  author="C. Lewis and M. Sergeant",
  title="{Overview of Best Email DNS-Based List (DNSBL) Operational Practices}",
  howpublished="RFC 6471 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6471",
  pages="1--21",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6471.txt",
  key="RFC 6471",
  abstract={The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering.  This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties.  It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DNSBL policy",
  doi="10.17487/RFC6471",
  }

@misc{rfc6472,
  author="W. Kumari and K. Sriram",
  title="{Recommendation for Not Using AS\_SET and AS\_CONFED\_SET in BGP}",
  howpublished="RFC 6472 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6472",
  pages="1--5",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6472.txt",
  key="RFC 6472",
  abstract={This document recommends against the use of the AS\_SET and AS\_CONFED\_SET types of the AS\_PATH in BGPv4.  This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear.  This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group.  This memo documents an Internet Best Current Practice.},
  keywords="BGPv4, Operator, RPKI, Aggregation, Route Origin",
  doi="10.17487/RFC6472",
  }

@misc{rfc6473,
  author="P. Saint-Andre",
  title="{vCard KIND:application}",
  howpublished="RFC 6473 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6473",
  pages="1--5",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6473.txt",
  key="RFC 6473",
  abstract={This document defines a value of ``application'' for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]},
  keywords="vCard",
  doi="10.17487/RFC6473",
  }

@misc{rfc6474,
  author="K. Li and B. Leiba",
  title="{vCard Format Extensions: Place of Birth, Place and Date of Death}",
  howpublished="RFC 6474 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6474",
  pages="1--6",
  year=2011,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6474.txt",
  key="RFC 6474",
  abstract={The base vCard 4.0 specification defines a large number of properties, including date of birth.  This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]},
  keywords="contacts, address-book, personal-information",
  doi="10.17487/RFC6474",
  }

@misc{rfc6475,
  author="G. Keeni and K. Koide and S. Gundavelli and R. Wakikawa",
  title="{Proxy Mobile IPv6 Management Information Base}",
  howpublished="RFC 6475 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6475",
  pages="1--63",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6475.txt",
  key="RFC 6475",
  abstract={This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6475",
  }

@misc{rfc6476,
  author="P. Gutmann",
  title="{Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 6476 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6476",
  pages="1--15",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6476.txt",
  key="RFC 6476",
  abstract={This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type.  This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]},
  keywords="authenticated data",
  doi="10.17487/RFC6476",
  }

@misc{rfc6477,
  author="A. Melnikov and G. Lunt",
  title="{Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail}",
  howpublished="RFC 6477 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6477",
  pages="1--21",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6477.txt",
  key="RFC 6477",
  abstract={A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks.  The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123.  This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service.  In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6477",
  }

@misc{rfc6478,
  author="L. Martini and G. Swallow and G. Heron and M. Bocci",
  title="{Pseudowire Status for Static Pseudowires}",
  howpublished="RFC 6478 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6478",
  pages="1--13",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7274",
url="https://www.rfc-editor.org/rfc/rfc6478.txt",
  key="RFC 6478",
  abstract={This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh).  Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE.  The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs.  This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6478",
  }

@misc{rfc6479,
  author="X. Zhang and T. Tsou",
  title="{IPsec Anti-Replay Algorithm without Bit Shifting}",
  howpublished="RFC 6479 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6479",
  pages="1--9",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6479.txt",
  key="RFC 6479",
  abstract={This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP).  The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6479",
  }

@misc{rfc6480,
  author="M. Lepinski and S. Kent",
  title="{An Infrastructure to Support Secure Internet Routing}",
  howpublished="RFC 6480 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6480",
  pages="1--24",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6480.txt",
  key="RFC 6480",
  abstract={This document describes an architecture for an infrastructure to support improved security of Internet routing.  The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security.  As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space.  Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RPKI, BGP, ROA",
  doi="10.17487/RFC6480",
  }

@misc{rfc6481,
  author="G. Huston and R. Loomans and G. Michaelson",
  title="{A Profile for Resource Certificate Repository Structure}",
  howpublished="RFC 6481 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6481",
  pages="1--15",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6481.txt",
  key="RFC 6481",
  abstract={This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository.  Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects.  This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]},
  keywords="rpki, Resource Public Key Infrastructure",
  doi="10.17487/RFC6481",
  }

@misc{rfc6482,
  author="M. Lepinski and S. Kent and D. Kong",
  title="{A Profile for Route Origin Authorizations (ROAs)}",
  howpublished="RFC 6482 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6482",
  pages="1--9",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6482.txt",
  key="RFC 6482",
  abstract={This document defines a standard profile for Route Origin Authorizations (ROAs).  A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]},
  keywords="RPKI, BGP",
  doi="10.17487/RFC6482",
  }

@misc{rfc6483,
  author="G. Huston and G. Michaelson",
  title="{Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)}",
  howpublished="RFC 6483 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6483",
  pages="1--8",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6483.txt",
  key="RFC 6483",
  abstract={This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="rpki, bgp, Resource Public Key Infrastructure",
  doi="10.17487/RFC6483",
  }

@misc{rfc6484,
  author="S. Kent and D. Kong and K. Seo and R. Watro",
  title="{Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6484 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6484",
  pages="1--35",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6484.txt",
  key="RFC 6484",
  abstract={This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings.  Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution.  These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.  This memo documents an Internet Best Current Practice.},
  keywords="Certification Practice Statement, CPS",
  doi="10.17487/RFC6484",
  }

@misc{rfc6485,
  author="G. Huston",
  title="{The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6485 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6485",
  pages="1--6",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7935",
url="https://www.rfc-editor.org/rfc/rfc6485.txt",
  key="RFC 6485",
  abstract={This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6485",
  }

@misc{rfc6486,
  author="R. Austein and G. Huston and S. Kent and M. Lepinski",
  title="{Manifests for the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6486 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6486",
  pages="1--19",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6486.txt",
  key="RFC 6486",
  abstract={This document defines a ``manifest'' for use in the Resource Public Key Infrastructure (RPKI).  A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository.  For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content.  Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository.  Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect ``stale'' (valid) data and deletion of signed objects. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6486",
  }

@misc{rfc6487,
  author="G. Huston and G. Michaelson and R. Loomans",
  title="{A Profile for X.509 PKIX Resource Certificates}",
  howpublished="RFC 6487 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6487",
  pages="1--32",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7318",
url="https://www.rfc-editor.org/rfc/rfc6487.txt",
  key="RFC 6487",
  abstract={This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of ``right-of-use'' of Internet Number Resources (INRs).  The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a ``right-of-use'' of the INRs that are described in the certificate.  This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI).  This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]},
  keywords="rpki, Resource Public Key Infrastructure, Internet Number Resources, INR",
  doi="10.17487/RFC6487",
  }

@misc{rfc6488,
  author="M. Lepinski and A. Chi and S. Kent",
  title="{Signed Object Template for the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6488 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6488",
  pages="1--13",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6488.txt",
  key="RFC 6488",
  abstract={This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI).  These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]},
  keywords="ROA, manifest, GhostBusters",
  doi="10.17487/RFC6488",
  }

@misc{rfc6489,
  author="G. Huston and G. Michaelson and S. Kent",
  title="{Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6489 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6489",
  pages="1--10",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6489.txt",
  key="RFC 6489",
  abstract={This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair.  This document also notes the implications of this key rollover procedure for relying parties (RPs).  In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs.  This memo documents an Internet Best Current Practice.},
  keywords="RPKI",
  doi="10.17487/RFC6489",
  }

@misc{rfc6490,
  author="G. Huston and S. Weiler and G. Michaelson and S. Kent",
  title="{Resource Public Key Infrastructure (RPKI) Trust Anchor Locator}",
  howpublished="RFC 6490 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6490",
  pages="1--7",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7730",
url="https://www.rfc-editor.org/rfc/rfc6490.txt",
  key="RFC 6490",
  abstract={This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]},
  keywords="tal",
  doi="10.17487/RFC6490",
  }

@misc{rfc6491,
  author="T. Manderson and L. Vegoda and S. Kent",
  title="{Resource Public Key Infrastructure (RPKI) Objects Issued by IANA}",
  howpublished="RFC 6491 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6491",
  pages="1--12",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6491.txt",
  key="RFC 6491",
  abstract={This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]},
  keywords="sidr, rpki, iana, as0, as 0, roa",
  doi="10.17487/RFC6491",
  }

@misc{rfc6492,
  author="G. Huston and R. Loomans and B. Ellacott and R. Austein",
  title="{A Protocol for Provisioning Resource Certificates}",
  howpublished="RFC 6492 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6492",
  pages="1--32",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6492.txt",
  key="RFC 6492",
  abstract={This document defines a framework for certificate management interactions between an Internet Number Resource issuer (``issuer'') and an Internet Number Resource recipient (``subject'') through the specification of a protocol for interaction between the two parties.  The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports.  This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]},
  keywords="RPKI",
  doi="10.17487/RFC6492",
  }

@misc{rfc6493,
  author="R. Bush",
  title="{The Resource Public Key Infrastructure (RPKI) Ghostbusters Record}",
  howpublished="RFC 6493 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6493",
  pages="1--8",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6493.txt",
  key="RFC 6493",
  abstract={In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc.  This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate.  The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]},
  keywords="RPKI, Resource Certificate, Human Contact, vCard",
  doi="10.17487/RFC6493",
  }

@misc{rfc6494,
  author="R. Gagliano and S. Krishnan and A. Kukec",
  title="{Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)}",
  howpublished="RFC 6494 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6494",
  pages="1--12",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6494.txt",
  key="RFC 6494",
  abstract={SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization.  This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]},
  keywords="RPKI, ND",
  doi="10.17487/RFC6494",
  }

@misc{rfc6495,
  author="R. Gagliano and S. Krishnan and A. Kukec",
  title="{Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields}",
  howpublished="RFC 6495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6495",
  pages="1--5",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6495.txt",
  key="RFC 6495",
  abstract={SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option.  This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6495",
  }

@misc{rfc6496,
  author="S. Krishnan and J. Laganier and M. Bonola and A. Garcia-Martinez",
  title="{Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)}",
  howpublished="RFC 6496 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6496",
  pages="1--24",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6496.txt",
  key="RFC 6496",
  abstract={SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats.  As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message.  This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND.  This document extends the current SEND specification in order to secure Proxy ND operation.  This document defines an Experimental Protocol for the Internet community.},
  keywords="SPND, CGA, Mobile IPv6, MIPv6, Proxy Mobile IPv6, PMIPv6",
  doi="10.17487/RFC6496",
  }

@misc{rfc6497,
  author="M. Davis and A. Phillips and Y. Umaoka and C. Falk",
  title="{BCP 47 Extension T - Transformed Content}",
  howpublished="RFC 6497 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6497",
  pages="1--15",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6497.txt",
  key="RFC 6497",
  abstract={This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source.  It also provides for additional information used for identification.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="locale",
  doi="10.17487/RFC6497",
  }

@misc{rfc6498,
  author="J. Stone and R. Kumar and F. Andreasen",
  title="{Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package}",
  howpublished="RFC 6498 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6498",
  pages="1--47",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6498.txt",
  key="RFC 6498",
  abstract={This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction).  Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec.  In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6498",
  }

@misc{rfc6501,
  author="O. Novo and G. Camarillo and D. Morgan and J. Urpalainen",
  title="{Conference Information Data Model for Centralized Conferencing (XCON)}",
  howpublished="RFC 6501 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6501",
  pages="1--94",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6501.txt",
  key="RFC 6501",
  abstract={RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus.  The state of a conference is represented by a conference object.  This document defines an XML- based conference information data model to be used for conference objects.  A conference information data model is designed to convey information about the conference and about participation in the conference.  The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6501",
  }

@misc{rfc6502,
  author="G. Camarillo and S. Srinivasan and R. Even and J. Urpalainen",
  title="{Conference Event Package Data Format Extension for Centralized Conferencing (XCON)}",
  howpublished="RFC 6502 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6502",
  pages="1--14",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6502.txt",
  key="RFC 6502",
  abstract={This document specifies the notification mechanism for XCON (centralized conferencing).  This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state.  Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6502",
  }

@misc{rfc6503,
  author="M. Barnes and C. Boulton and S. Romano and H. Schulzrinne",
  title="{Centralized Conferencing Manipulation Protocol}",
  howpublished="RFC 6503 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6503",
  pages="1--119",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6503.txt",
  key="RFC 6503",
  abstract={The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference.  CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details.  CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]},
  keywords="conference user, ad hoc conference, sidebar conference, scheduled conference",
  doi="10.17487/RFC6503",
  }

@misc{rfc6504,
  author="M. Barnes and L. Miniero and R. Presta and S P. Romano",
  title="{Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples}",
  howpublished="RFC 6504 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6504",
  pages="1--78",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6504.txt",
  key="RFC 6504",
  abstract={This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597).  The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503).  The objective is to provide detailed examples for reference by both protocol researchers and developers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6504",
  }

@misc{rfc6505,
  author="S. McGlashan and T. Melanchuk and C. Boulton",
  title="{A Mixer Control Package for the Media Control Channel Framework}",
  howpublished="RFC 6505 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6505",
  pages="1--89",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6505.txt",
  key="RFC 6505",
  abstract={This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections.  The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications.  The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]},
  keywords="conference mixer",
  doi="10.17487/RFC6505",
  }

@misc{rfc6506,
  author="M. Bhatia and V. Manral and A. Lindem",
  title="{Supporting Authentication Trailer for OSPFv3}",
  howpublished="RFC 6506 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6506",
  pages="1--20",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7166",
url="https://www.rfc-editor.org/rfc/rfc6506.txt",
  key="RFC 6506",
  abstract={Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets.  This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).  In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used.  This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]},
  keywords="Routing security",
  doi="10.17487/RFC6506",
  }

@misc{rfc6507,
  author="M. Groves",
  title="{Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)}",
  howpublished="RFC 6507 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6507",
  pages="1--17",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6507.txt",
  key="RFC 6507",
  abstract={Many signature schemes currently in use rely on certificates for authentication of identity.  In Identity-based cryptography, this adds unnecessary overhead and administration.  The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless.  This scheme has the additional advantages of low bandwidth and low computational requirements.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6507",
  }

@misc{rfc6508,
  author="M. Groves",
  title="{Sakai-Kasahara Key Encryption (SAKKE)}",
  howpublished="RFC 6508 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6508",
  pages="1--21",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6508.txt",
  key="RFC 6508",
  abstract={In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described.  This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6508",
  }

@misc{rfc6509,
  author="M. Groves",
  title="{MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)}",
  howpublished="RFC 6509 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6509",
  pages="1--21",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6509.txt",
  key="RFC 6509",
  abstract={This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication.  MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6509",
  }

@misc{rfc6510,
  author="L. Berger and G. Swallow",
  title="{Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects}",
  howpublished="RFC 6510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6510",
  pages="1--8",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6510.txt",
  key="RFC 6510",
  abstract={Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes.  These attributes may be carried in both Path and Resv messages.  This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats.  This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6510",
  }

@misc{rfc6511,
  author="Z. Ali and G. Swallow and R. Aggarwal",
  title="{Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths}",
  howpublished="RFC 6511 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6511",
  pages="1--10",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6511.txt",
  key="RFC 6511",
  abstract={There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some ``out-of-band'' (OOB) mechanism.  This document defines protocol mechanisms to address this requirement.  The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6511",
  }

@misc{rfc6512,
  author="IJ. Wijnands and E. Rosen and M. Napierala and N. Leymann",
  title="{Using Multipoint LDP When the Backbone Has No Route to the Root}",
  howpublished="RFC 6512 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6512",
  pages="1--12",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6512.txt",
  key="RFC 6512",
  abstract={The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (``MP LSPs'') contains a field that identifies the address of a ``root node''.  Intermediate nodes are expected to be able to look up that address in their routing tables.  However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core.  This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core.  In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6512",
  }

@misc{rfc6513,
  author="E. Rosen and R. Aggarwal",
  title="{Multicast in MPLS/BGP IP VPNs}",
  howpublished="RFC 6513 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6513",
  pages="1--88",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7582, 7900, 7988",
url="https://www.rfc-editor.org/rfc/rfc6513.txt",
  key="RFC 6513",
  abstract={In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider.  These protocols and procedures are specified in this document. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6513",
  }

@misc{rfc6514,
  author="R. Aggarwal and E. Rosen and T. Morin and Y. Rekhter",
  title="{BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs}",
  howpublished="RFC 6514 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6514",
  pages="1--59",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 6515, 6625, 7385, 7441, 7582, 7899, 7900, 7902, 7988",
url="https://www.rfc-editor.org/rfc/rfc6514.txt",
  key="RFC 6514",
  abstract={This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6514",
  }

@misc{rfc6515,
  author="R. Aggarwal and E. Rosen",
  title="{IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN}",
  howpublished="RFC 6515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6515",
  pages="1--8",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6515.txt",
  key="RFC 6515",
  abstract={To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN (``MCAST-VPN'') BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes.  These routes encode addresses from the customer's address space, as well as addresses from the provider's address space.  These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same.  These routes always contain an ``address family'' field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses.  However, there is no field that explicitly specifies the address family of the provider addresses.  To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field.  Specific cases are explained in detail.  This document updates RFC 6514. [STANDARDS-TRACK]},
  keywords="mvpn, mcast-vpn, multicast-vpn",
  doi="10.17487/RFC6515",
  }

@misc{rfc6516,
  author="Y. Cai and E. Rosen and I. Wijnands",
  title="{IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages}",
  howpublished="RFC 6516 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6516",
  pages="1--6",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6516.txt",
  key="RFC 6516",
  abstract={The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers.  It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network.  This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6516",
  }

@misc{rfc6517,
  author="T. Morin and B. Niven-Jenkins and Y. Kamite and R. Zhang and N. Leymann and N. Bitar",
  title="{Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution}",
  howpublished="RFC 6517 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6517",
  pages="1--41",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6517.txt",
  key="RFC 6517",
  abstract={More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mpls, vpn, multicast, l3vpn, bgp, pim, p2mp, ldp, rsvp-te",
  doi="10.17487/RFC6517",
  }

@misc{rfc6518,
  author="G. Lebovitz and M. Bhatia",
  title="{Keying and Authentication for Routing Protocols (KARP) Design Guidelines}",
  howpublished="RFC 6518 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6518",
  pages="1--30",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6518.txt",
  key="RFC 6518",
  abstract={This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols.  In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="MAC, hash, security, securing, secure, authorization, protection, harden, hardening, infrastructure, router, crypto, cryptography, cryptographic, roadmap, guide, guideline, message, framework, key, keys, management, protocol, KMP, key management protocol,",
  doi="10.17487/RFC6518",
  }

@misc{rfc6519,
  author="R. Maglione and A. Durand",
  title="{RADIUS Extensions for Dual-Stack Lite}",
  howpublished="RFC 6519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6519",
  pages="1--11",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6519.txt",
  key="RFC 6519",
  abstract={Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix.  Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element.  In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP).  This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION\_AFTR\_NAME option.  This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]},
  keywords="IPv6, tunnel, attribute",
  doi="10.17487/RFC6519",
  }

@misc{rfc6520,
  author="R. Seggelmann and M. Tuexen and M. Williams",
  title="{Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension}",
  howpublished="RFC 6520 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6520",
  pages="1--9",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6520.txt",
  key="RFC 6520",
  abstract={This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]},
  keywords="tls/dtls",
  doi="10.17487/RFC6520",
  }

@misc{rfc6521,
  author="A. Makela and J. Korhonen",
  title="{Home Agent-Assisted Route Optimization between Mobile IPv4 Networks}",
  howpublished="RFC 6521 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6521",
  pages="1--53",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6521.txt",
  key="RFC 6521",
  abstract={This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol.  The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity.  The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes.  This document defines an Experimental Protocol for the Internet community.},
  keywords="mobile router, mobile network prefix, correspondent router",
  doi="10.17487/RFC6521",
  }

@misc{rfc6522,
  author="M. Kucherawy",
  title="{The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages}",
  howpublished="RFC 6522 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6522",
  pages="1--9",
  year=2012,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6533",
url="https://www.rfc-editor.org/rfc/rfc6522.txt",
  key="RFC 6522",
  abstract={The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general ``family'' or ``container'' type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports. This memo obsoletes ``The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages'', RFC 3462, and marks RFC 3462 and its predecessor as ``Historic''. [STANDARDS-TRACK]},
  keywords="MIME, Multipurpose Internet Mail Extensions",
  doi="10.17487/RFC6522",
  }

@misc{rfc6525,
  author="R. Stewart and M. Tuexen and P. Lei",
  title="{Stream Control Transmission Protocol (SCTP) Stream Reconfiguration}",
  howpublished="RFC 6525 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6525",
  pages="1--34",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6525.txt",
  key="RFC 6525",
  abstract={Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to ``reset'' a stream.  The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed.  Applications requiring this feature want it so that they can ``reuse'' streams for different purposes but still utilize the stream sequence number so that the application can track the message flows.  Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to ``reset the streams back to zero''.  This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6525",
  }

@misc{rfc6526,
  author="B. Claise and P. Aitken and A. Johnson and G. Muenz",
  title="{IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream}",
  howpublished="RFC 6526 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6526",
  pages="1--23",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6526.txt",
  key="RFC 6526",
  abstract={This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6526",
  }

@misc{rfc6527,
  author="K. Tata",
  title="{Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)}",
  howpublished="RFC 6527 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6527",
  pages="1--31",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6527.txt",
  key="RFC 6527",
  abstract={This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP).  In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798.  This memo obsoletes RFC 2787. [STANDARDS-TRACK]},
  keywords="management information base",
  doi="10.17487/RFC6527",
  }

@misc{rfc6528,
  author="F. Gont and S. Bellovin",
  title="{Defending against Sequence Number Attacks}",
  howpublished="RFC 6528 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6528",
  pages="1--12",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6528.txt",
  key="RFC 6528",
  abstract={This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced.  This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]},
  keywords="TCP security, TCP Sequence Numbers, Sequence Number Randomization, obfuscation, TCP vulnerabilities",
  doi="10.17487/RFC6528",
  }

@misc{rfc6529,
  author="A. McKenzie and S. Crocker",
  title="{Host/Host Protocol for the ARPA Network}",
  howpublished="RFC 6529 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6529",
  pages="1--34",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6529.txt",
  key="RFC 6529",
  abstract={This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971.  It describes a protocol used to manage communication between processes residing on independent Hosts.  It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface.  It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983.  It is offered as an RFC at this late date to help complete the historical record available through the RFC series.  This document is not an Internet Standards Track specification; it is published for the historical record.},
  doi="10.17487/RFC6529",
  }

@misc{rfc6530,
  author="J. Klensin and Y. Ko",
  title="{Overview and Framework for Internationalized Email}",
  howpublished="RFC 6530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6530",
  pages="1--26",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6530.txt",
  key="RFC 6530",
  abstract={Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses.  This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses.  These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data.  The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.  This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]},
  keywords="SMTP, Email I18n, Internationalization, SMTPUTF8",
  doi="10.17487/RFC6530",
  }

@misc{rfc6531,
  author="J. Yao and W. Mao",
  title="{SMTP Extension for Internationalized Email}",
  howpublished="RFC 6531 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6531",
  pages="1--18",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6531.txt",
  key="RFC 6531",
  abstract={This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]},
  keywords="SMTP, Email I18n, Internationalization, SMTPUTF8",
  doi="10.17487/RFC6531",
  }

@misc{rfc6532,
  author="A. Yang and S. Steele and N. Freed",
  title="{Internationalized Email Headers}",
  howpublished="RFC 6532 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6532",
  pages="1--11",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6532.txt",
  key="RFC 6532",
  abstract={Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like ``From:'', ``To:'', and ``Subject:'', without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of ``message/''. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6532",
  }

@misc{rfc6533,
  author="T. Hansen and C. Newman and A. Melnikov",
  title="{Internationalized Delivery Status and Disposition Notifications}",
  howpublished="RFC 6533 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6533",
  pages="1--19",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6533.txt",
  key="RFC 6533",
  abstract={Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]},
  keywords="dsn",
  doi="10.17487/RFC6533",
  }

@misc{rfc6534,
  author="N. Duffield and A. Morton and J. Sommers",
  title="{Loss Episode Metrics for IP Performance Metrics (IPPM)}",
  howpublished="RFC 6534 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6534",
  pages="1--21",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6534.txt",
  key="RFC 6534",
  abstract={The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts.  However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets).  This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6534",
  }

@misc{rfc6535,
  author="B. Huang and H. Deng and T. Savolainen",
  title="{Dual-Stack Hosts Using ``Bump-in-the-Host'' (BIH)}",
  howpublished="RFC 6535 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6535",
  pages="1--25",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6535.txt",
  key="RFC 6535",
  abstract={Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers.  The host on which applications are running may be connected to IPv6-only or dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]},
  keywords="NAT, NAT46, DNS, DNS46, translation, IPv4, applications, IPv6, ENR",
  doi="10.17487/RFC6535",
  }

@misc{rfc6536,
  author="A. Bierman and M. Bjorklund",
  title="{Network Configuration Protocol (NETCONF) Access Control Model}",
  howpublished="RFC 6536 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6536",
  pages="1--49",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6536.txt",
  key="RFC 6536",
  abstract={The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content.  This document defines such an access control model. [STANDARDS-TRACK]},
  keywords="NETCONF, YANG, XML",
  doi="10.17487/RFC6536",
  }

@misc{rfc6537,
  author="J. Ahrenholz",
  title="{Host Identity Protocol Distributed Hash Table Interface}",
  howpublished="RFC 6537 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6537",
  pages="1--20",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6537.txt",
  key="RFC 6537",
  abstract={This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service.  This document defines an Experimental Protocol for the Internet community.},
  keywords="HIP, Host Identity Protocol, DHT, DIstributed Hash Table, HIT, Host Identity Tag, resolution, service",
  doi="10.17487/RFC6537",
  }

@misc{rfc6538,
  author="T. Henderson and A. Gurtov",
  title="{The Host Identity Protocol (HIP) Experiment Report}",
  howpublished="RFC 6538 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6538",
  pages="1--35",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6538.txt",
  key="RFC 6538",
  abstract={This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group.  The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications.  The perspective of a network operator, as well as a list of HIP experiments, are presented as well.  Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Security, ID/locator split, IPsec, Research",
  doi="10.17487/RFC6538",
  }

@misc{rfc6539,
  author="V. Cakulev and G. Sundaram and I. Broustis",
  title="{IBAKE: Identity-Based Authenticated Key Exchange}",
  howpublished="RFC 6539 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6539",
  pages="1--13",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6539.txt",
  key="RFC 6539",
  abstract={Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management.  The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility.  However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences.  Another observed deficiency is a lack of mutual authentication of communicating parties.  This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol.  IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ibe, identity based encryption",
  doi="10.17487/RFC6539",
  }

@misc{rfc6540,
  author="W. George and C. Donley and C. Liljenstolpe and L. Howard",
  title="{IPv6 Support Required for All IP-Capable Nodes}",
  howpublished="RFC 6540 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6540",
  pages="1--6",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6540.txt",
  key="RFC 6540",
  abstract={Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional.  It also cautions that there are places in existing IETF documents where the term ``IP'' is used in a way that could be misunderstood by implementers as the term ``IP'' becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application.  This memo documents an Internet Best Current Practice.},
  keywords="IPv4, requirement",
  doi="10.17487/RFC6540",
  }

@misc{rfc6541,
  author="M. Kucherawy",
  title="{DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures}",
  howpublished="RFC 6541 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6541",
  pages="1--16",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6541.txt",
  key="RFC 6541",
  abstract={This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Authentication, Reputation",
  doi="10.17487/RFC6541",
  }

@misc{rfc6542,
  author="S. Emery",
  title="{Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility}",
  howpublished="RFC 6542 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6542",
  pages="1--6",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6542.txt",
  key="RFC 6542",
  abstract={Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121).  This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961.  In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6542",
  }

@misc{rfc6543,
  author="S. Gundavelli",
  title="{Reserved IPv6 Interface Identifier for Proxy Mobile IPv6}",
  howpublished="RFC 6543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6543",
  pages="1--5",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6543.txt",
  key="RFC 6543",
  abstract={Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes.  This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another.  In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required.  This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose.  This document also updates RFC 5213. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6543",
  }

@misc{rfc6544,
  author="J. Rosenberg and A. Keranen and B. B. Lowekamp and A. B. Roach",
  title="{TCP Candidates with Interactive Connectivity Establishment (ICE)}",
  howpublished="RFC 6544 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6544",
  pages="1--29",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6544.txt",
  key="RFC 6544",
  abstract={Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation.  ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN).  ICE provides a general framework for describing candidates but only defines UDP-based media streams.  This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]},
  keywords="ICE, TCP, NAT, NAT traversal",
  doi="10.17487/RFC6544",
  }

@misc{rfc6545,
  author="K. Moriarty",
  title="{Real-time Inter-network Defense (RID)}",
  howpublished="RFC 6545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6545",
  pages="1--84",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6545.txt",
  key="RFC 6545",
  abstract={Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.  Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack.  Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution.  Combining these capabilities in a communication system provides a way to achieve higher security levels on networks.  Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.  This document obsoletes RFC 6045. [STANDARDS-TRACK]},
  keywords="incident response, incident coordination, incident handling, incident communication",
  doi="10.17487/RFC6545",
  }

@misc{rfc6546,
  author="B. Trammell",
  title="{Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS}",
  howpublished="RFC 6546 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6546",
  pages="1--8",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6546.txt",
  key="RFC 6546",
  abstract={The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises.  This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]},
  keywords="Coordinated Incident Response, CSIRT, Incident Object Description Exchange Format, IODEF",
  doi="10.17487/RFC6546",
  }

@misc{rfc6547,
  author="W. George",
  title="{RFC 3627 to Historic Status}",
  howpublished="RFC 6547 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6547",
  pages="1--3",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6547.txt",
  key="RFC 6547",
  abstract={This document moves ``Use of /127 Prefix Length Between Routers Considered Harmful'' (RFC 3627) to Historic status to reflect the updated guidance contained in ``Using 127-Bit IPv6 Prefixes on Inter- Router Links'' (RFC 6164).  A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict.  This document links the two RFCs so that the IETF's updated guidance on this topic is clearer.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6, /127, point-to-point address, inter-router links",
  doi="10.17487/RFC6547",
  }

@misc{rfc6548,
  author="N. Brownlee and IAB",
  title="{Independent Submission Editor Model}",
  howpublished="RFC 6548 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6548",
  pages="1--5",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6548.txt",
  key="RFC 6548",
  abstract={This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE).  The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver.  The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE).  The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Independent Stream Editor",
  doi="10.17487/RFC6548",
  }

@misc{rfc6549,
  author="A. Lindem and A. Roy and S. Mirtorabi",
  title="{OSPFv2 Multi-Instance Extensions}",
  howpublished="RFC 6549 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6549",
  pages="1--9",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6549.txt",
  key="RFC 6549",
  abstract={OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances. This document updates RFC 2328. [STANDARDS-TRACK]},
  keywords="Instance ID",
  doi="10.17487/RFC6549",
  }

@misc{rfc6550,
  author="T. Winter and P. Thubert and A. Brandt and J. Hui and R. Kelsey and P. Levis and K. Pister and R. Struik and JP. Vasseur and R. Alexander",
  title="{RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks}",
  howpublished="RFC 6550 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6550",
  pages="1--157",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6550.txt",
  key="RFC 6550",
  abstract={Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available. [STANDARDS-TRACK]},
  keywords="WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, Distance Vector, Objective Function, DAG for Directed Acyclic Graph",
  doi="10.17487/RFC6550",
  }

@misc{rfc6551,
  author="JP. Vasseur and M. Kim and K. Pister and N. Dejean and D. Barthel",
  title="{Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks}",
  howpublished="RFC 6551 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6551",
  pages="1--30",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6551.txt",
  key="RFC 6551",
  abstract={Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints.  By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]},
  keywords="RPL, ROLL, LLN, Constrained based routing,",
  doi="10.17487/RFC6551",
  }

@misc{rfc6552,
  author="P. Thubert",
  title="{Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)}",
  howpublished="RFC 6552 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6552",
  pages="1--14",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6552.txt",
  key="RFC 6552",
  abstract={The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]},
  keywords="WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, Distance Vector, Objective Function, DAG for Directed Acyclic Graph, RPL",
  doi="10.17487/RFC6552",
  }

@misc{rfc6553,
  author="J. Hui and JP. Vasseur",
  title="{The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams}",
  howpublished="RFC 6553 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6553",
  pages="1--9",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6553.txt",
  key="RFC 6553",
  abstract={The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology.  This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]},
  keywords="LLN, LLNs, Trickle",
  doi="10.17487/RFC6553",
  }

@misc{rfc6554,
  author="J. Hui and JP. Vasseur and D. Culler and V. Manral",
  title="{An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)}",
  howpublished="RFC 6554 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6554",
  pages="1--13",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6554.txt",
  key="RFC 6554",
  abstract={In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes.  In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN.  The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers.  This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]},
  keywords="LLN, LLNs",
  doi="10.17487/RFC6554",
  }

@misc{rfc6555,
  author="D. Wing and A. Yourtchenko",
  title="{Happy Eyeballs: Success with Dual-Stack Hosts}",
  howpublished="RFC 6555 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6555",
  pages="1--15",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6555.txt",
  key="RFC 6555",
  abstract={When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client.  This is undesirable because it causes the dual- stack client to have a worse user experience.  This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6555",
  }

@misc{rfc6556,
  author="F. Baker",
  title="{Testing Eyeball Happiness}",
  howpublished="RFC 6556 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6556",
  pages="1--10",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6556.txt",
  key="RFC 6556",
  abstract={The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment.  This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering.  This test is not a test of a specific algorithm, but of the external behavior of the system as a black box.  Any algorithm that has the intended external behavior will be accepted by it.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="test methodology, IPv4, IPv6, session startup, metrics",
  doi="10.17487/RFC6556",
  }

@misc{rfc6557,
  author="E. Lear and P. Eggert",
  title="{Procedures for Maintaining the Time Zone Database}",
  howpublished="RFC 6557 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6557",
  pages="1--9",
  year=2012,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6557.txt",
  key="RFC 6557",
  abstract={Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP.  The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world.  This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire.  This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community.  The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6557",
  }

@misc{rfc6558,
  author="A. Melnikov and B. Leiba and K. Li",
  title="{Sieve Extension for Converting Messages before Delivery}",
  howpublished="RFC 6558 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6558",
  pages="1--8",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6558.txt",
  key="RFC 6558",
  abstract={This document describes how the ``CONVERT'' IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]},
  keywords="Sieve, CONVERT",
  doi="10.17487/RFC6558",
  }

@misc{rfc6559,
  author="D. Farinacci and IJ. Wijnands and S. Venaas and M. Napierala",
  title="{A Reliable Transport Mechanism for PIM}",
  howpublished="RFC 6559 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6559",
  pages="1--29",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6559.txt",
  key="RFC 6559",
  abstract={This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages.  This eliminates the need for periodic Join/Prune message transmission and processing.  The reliable transport mechanism can use either TCP or SCTP as the transport protocol.  This document defines an Experimental Protocol for the Internet community.},
  keywords="",
  doi="10.17487/RFC6559",
  }

@misc{rfc6560,
  author="G. Richards",
  title="{One-Time Password (OTP) Pre-Authentication}",
  howpublished="RFC 6560 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6560",
  pages="1--43",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6560.txt",
  key="RFC 6560",
  abstract={The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data.  This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6560",
  }

@misc{rfc6561,
  author="J. Livingood and N. Mody and M. O'Reirdan",
  title="{Recommendations for the Remediation of Bots in ISP Networks}",
  howpublished="RFC 6561 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6561",
  pages="1--29",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6561.txt",
  key="RFC 6561",
  abstract={This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers.  Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud.  Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack.  Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ISP, Internet Service Provider, Bot, Botnet, Remediation, malware, notification",
  doi="10.17487/RFC6561",
  }

@misc{rfc6562,
  author="C. Perkins and JM. Valin",
  title="{Guidelines for the Use of Variable Bit Rate Audio with Secure RTP}",
  howpublished="RFC 6562 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6562",
  pages="1--6",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6562.txt",
  key="RFC 6562",
  abstract={This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.  Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]},
  keywords="vbr",
  doi="10.17487/RFC6562",
  }

@misc{rfc6563,
  author="S. Jiang and D. Conrad and B. Carpenter",
  title="{Moving A6 to Historic Status}",
  howpublished="RFC 6563 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6563",
  pages="1--8",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6563.txt",
  key="RFC 6563",
  abstract={This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6563",
  }

@misc{rfc6564,
  author="S. Krishnan and J. Woodyatt and E. Kline and J. Hoagland and M. Bhatia",
  title="{A Uniform Format for IPv6 Extension Headers}",
  howpublished="RFC 6564 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6564",
  pages="1--6",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6564.txt",
  key="RFC 6564",
  abstract={In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header.  There are a small number of such extension headers currently defined.  This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6.  It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6564",
  }

@misc{rfc6565,
  author="P. Pillay-Esnault and P. Moyer and J. Doyle and E. Ertekin and M. Lundberg",
  title="{OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol}",
  howpublished="RFC 6565 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6565",
  pages="1--20",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6565.txt",
  key="RFC 6565",
  abstract={Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers.  The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone.  Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified.  This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol.  The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]},
  keywords="L3VPN, BGP/MPLS, VPN",
  doi="10.17487/RFC6565",
  }

@misc{rfc6566,
  author="Y. Lee and G. Bernstein and D. Li and G. Martinelli",
  title="{A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments}",
  howpublished="RFC 6566 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6566",
  pages="1--31",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6566.txt",
  key="RFC 6566",
  abstract={As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as ``impairments''. These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6566",
  }

@misc{rfc6567,
  author="A. Johnston and L. Liess",
  title="{Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP}",
  howpublished="RFC 6567 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6567",
  pages="1--11",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6567.txt",
  key="RFC 6567",
  abstract={This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism.  Some SIP sessions are established by or related to a non-SIP application.  This application may have information that needs to be transported between the SIP User Agents during session establishment.  In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6567",
  }

@misc{rfc6568,
  author="E. Kim and D. Kaspar and JP. Vasseur",
  title="{Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}",
  howpublished="RFC 6568 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6568",
  pages="1--28",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6568.txt",
  key="RFC 6568",
  abstract={This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs).  This document provides dimensions of design space for LoWPAN applications.  A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension.  A complete list of practical use cases is not the goal of this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6568",
  }

@misc{rfc6569,
  author="JM. Valin and S. Borilin and K. Vos and C. Montgomery and R. Chen",
  title="{Guidelines for Development of an Audio Codec within the IETF}",
  howpublished="RFC 6569 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6569",
  pages="1--14",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6569.txt",
  key="RFC 6569",
  abstract={This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF.  These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="audio codec, speech codec",
  doi="10.17487/RFC6569",
  }

@misc{rfc6570,
  author="J. Gregorio and R. Fielding and M. Hadley and M. Nottingham and D. Orchard",
  title="{URI Template}",
  howpublished="RFC 6570 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6570",
  pages="1--34",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6570.txt",
  key="RFC 6570",
  abstract={A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.  This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]},
  keywords="template, Uniform Resource Identifier, URI, URI Template, Internationalized Resource Identifier, IRI, IRI Template",
  doi="10.17487/RFC6570",
  }

@misc{rfc6571,
  author="C. Filsfils and P. Francois and M. Shand and B. Decraene and J. Uttaro and N. Leymann and M. Horneffer",
  title="{Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks}",
  howpublished="RFC 6571 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6571",
  pages="1--35",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6571.txt",
  key="RFC 6571",
  abstract={In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks.  We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IP Fast Reroute, Routing Convergence, Network Topology, IS-IS, OSPF",
  doi="10.17487/RFC6571",
  }

@misc{rfc6572,
  author="F. Xia and B. Sarikaya and J. Korhonen and S. Gundavelli and D. Damic",
  title="{RADIUS Support for Proxy Mobile IPv6}",
  howpublished="RFC 6572 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6572",
  pages="1--36",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8044",
url="https://www.rfc-editor.org/rfc/rfc6572.txt",
  key="RFC 6572",
  abstract={This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure.  The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions.  The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.  Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session.  In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6572",
  }

@misc{rfc6573,
  author="M. Amundsen",
  title="{The Item and Collection Link Relations}",
  howpublished="RFC 6573 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6573",
  pages="1--5",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6573.txt",
  key="RFC 6573",
  abstract={RFC 5988 standardized a means of indicating the relationships between resources on the Web.  This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6573",
  }

@misc{rfc6574,
  author="H. Tschofenig and J. Arkko",
  title="{Report from the Smart Object Workshop}",
  howpublished="RFC 6574 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6574",
  pages="1--32",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6574.txt",
  key="RFC 6574",
  abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Smart Objects, Internet of Things",
  doi="10.17487/RFC6574",
  }

@misc{rfc6575,
  author="H. Shah and E. Rosen and G. Heron and V. Kompella",
  title="{Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs}",
  howpublished="RFC 6575 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6575",
  pages="1--28",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6575.txt",
  key="RFC 6575",
  abstract={The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices.  It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs).  In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology.  However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies.  This requires the PEs to perform a function known as ``Address Resolution Protocol (ARP) Mediation''.  ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit.  The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6575",
  }

@misc{rfc6576,
  author="R. Geib and A. Morton and R. Fardid and A. Steinmitz",
  title="{IP Performance Metrics (IPPM) Standard Advancement Testing}",
  howpublished="RFC 6576 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6576",
  pages="1--37",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6576.txt",
  key="RFC 6576",
  abstract={This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way.  This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track.  Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods.  The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track.  This document is an Internet Best Current Practice.},
  keywords="inter-operability, equivalence, measurement, compliance, metric",
  doi="10.17487/RFC6576",
  }

@misc{rfc6577,
  author="M. Kucherawy",
  title="{Authentication-Results Registration Update for Sender Policy Framework (SPF) Results}",
  howpublished="RFC 6577 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6577",
  pages="1--5",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7001",
url="https://www.rfc-editor.org/rfc/rfc6577.txt",
  key="RFC 6577",
  abstract={This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]},
  keywords="SPF, Authentication",
  doi="10.17487/RFC6577",
  }

@misc{rfc6578,
  author="C. Daboo and A. Quillaud",
  title="{Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 6578 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6578",
  pages="1--29",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6578.txt",
  key="RFC 6578",
  abstract={This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]},
  keywords="sync-collection, sync-token",
  doi="10.17487/RFC6578",
  }

@misc{rfc6579,
  author="M. Yevstifeyev",
  title="{The 'disclosure' Link Relation Type}",
  howpublished="RFC 6579 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6579",
  pages="1--5",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6579.txt",
  key="RFC 6579",
  abstract={This document specifies the 'disclosure' link relation type.  It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]},
  doi="10.17487/RFC6579",
  }

@misc{rfc6580,
  author="M. Ko and D. Black",
  title="{IANA Registries for the Remote Direct Data Placement (RDDP) Protocols}",
  howpublished="RFC 6580 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6580",
  pages="1--10",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6580.txt",
  key="RFC 6580",
  abstract={The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes.  Extensions to the RDDP protocols now require these registries to be created.  This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6580",
  }

@misc{rfc6581,
  author="A. Kanevsky and C. Bestler and R. Sharp and S. Wise",
  title="{Enhanced Remote Direct Memory Access (RDMA) Connection Establishment}",
  howpublished="RFC 6581 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6581",
  pages="1--25",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6581.txt",
  key="RFC 6581",
  abstract={This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment.  The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP).  The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6581",
  }

@misc{rfc6582,
  author="T. Henderson and S. Floyd and A. Gurtov and Y. Nishida",
  title="{The NewReno Modification to TCP's Fast Recovery Algorithm}",
  howpublished="RFC 6582 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6582",
  pages="1--16",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6582.txt",
  key="RFC 6582",
  abstract={RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to ``partial acknowledgments'' (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK.  This document describes a specific algorithm for responding to partial acknowledgments, referred to as ``NewReno''.  This response to partial acknowledgments was first proposed by Janey Hoe.  This document obsoletes RFC 3782. [STANDARDS-TRACK]},
  keywords="congestion avoidance, congestion control, fast retransmit",
  doi="10.17487/RFC6582",
  }

@misc{rfc6583,
  author="I. Gashinsky and J. Jaeggli and W. Kumari",
  title="{Operational Neighbor Discovery Problems}",
  howpublished="RFC 6583 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6583",
  pages="1--12",
  year=2012,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6583.txt",
  key="RFC 6583",
  abstract={In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to ``join'' a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]},
  doi="10.17487/RFC6583",
  }

@misc{rfc6584,
  author="V. Roca",
  title="{Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}",
  howpublished="RFC 6584 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6584",
  pages="1--30",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6584.txt",
  key="RFC 6584",
  abstract={This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols.  The first scheme is based on RSA Digital Signatures.  The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA).  The third scheme relies on a Group- keyed Message Authentication Code (MAC).  Finally, the fourth scheme merges the Digital Signature and group schemes.  These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]},
  keywords="TESLA, FLUTE",
  doi="10.17487/RFC6584",
  }

@misc{rfc6585,
  author="M. Nottingham and R. Fielding",
  title="{Additional HTTP Status Codes}",
  howpublished="RFC 6585 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6585",
  pages="1--10",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6585.txt",
  key="RFC 6585",
  abstract={This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]},
  keywords="Hypertext Transfer Protocol",
  doi="10.17487/RFC6585",
  }

@misc{rfc6586,
  author="J. Arkko and A. Keranen",
  title="{Experiences from an IPv6-Only Network}",
  howpublished="RFC 6586 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6586",
  pages="1--21",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6586.txt",
  key="RFC 6586",
  abstract={This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device.  The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup.  The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design.  The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6, NAT64",
  doi="10.17487/RFC6586",
  }

@misc{rfc6587,
  author="R. Gerhards and C. Lonvick",
  title="{Transmission of Syslog Messages over TCP}",
  howpublished="RFC 6587 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6587",
  pages="1--11",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6587.txt",
  key="RFC 6587",
  abstract={There have been many implementations and deployments of legacy syslog over TCP for many years.  That protocol has evolved without being standardized and has proven to be quite interoperable in practice.  This memo describes how TCP has been used as a transport for syslog messages.  This document defines a Historic Document for the Internet community.},
  keywords="SYSLOG, SYSLOG transport TCP",
  doi="10.17487/RFC6587",
  }

@misc{rfc6588,
  author="C. Ishikawa",
  title="{A URN Namespace for ucode}",
  howpublished="RFC 6588 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6588",
  pages="1--8",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6588.txt",
  key="RFC 6588",
  abstract={This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places.  ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6588",
  }

@misc{rfc6589,
  author="J. Livingood",
  title="{Considerations for Transitioning Content to IPv6}",
  howpublished="RFC 6589 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6589",
  pages="1--27",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6589.txt",
  key="RFC 6589",
  abstract={This document describes considerations for the transition of end-user content on the Internet to IPv6.  While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services.  This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations.  The audience for this document is the Internet community generally, particularly IPv6 implementers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6589",
  }

@misc{rfc6590,
  author="J. Falk and M. Kucherawy",
  title="{Redaction of Potentially Sensitive Data from Mail Abuse Reports}",
  howpublished="RFC 6590 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6590",
  pages="1--8",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6590.txt",
  key="RFC 6590",
  abstract={Email messages often contain information that might be considered private or sensitive, per either regulation or social norms.  When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message.  This memo suggests one method for doing so effectively. [STANDARDS-TRACK]},
  keywords="ARF, MARF, feedback loop, spam reporting",
  doi="10.17487/RFC6590",
  }

@misc{rfc6591,
  author="H. Fontana",
  title="{Authentication Failure Reporting Using the Abuse Reporting Format}",
  howpublished="RFC 6591 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6591",
  pages="1--16",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6692",
url="https://www.rfc-editor.org/rfc/rfc6591.txt",
  key="RFC 6591",
  abstract={This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]},
  keywords="auth, auth failure, dkim, spf, AFRF, ARF",
  doi="10.17487/RFC6591",
  }

@misc{rfc6592,
  author="C. Pignataro",
  title="{The Null Packet}",
  howpublished="RFC 6592 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6592",
  pages="1--6",
  year=2012,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6592.txt",
  key="RFC 6592",
  abstract={The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined.  This memo corrects that omission.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6592",
  }

@misc{rfc6593,
  author="C. Pignataro and J. Clarke and G. Salgueiro",
  title="{Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)}",
  howpublished="RFC 6593 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6593",
  pages="1--8",
  year=2012,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6593.txt",
  key="RFC 6593",
  abstract={With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery. This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6593",
  }

@misc{rfc6594,
  author="O. Sury",
  title="{Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records}",
  howpublished="RFC 6594 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6594",
  pages="1--9",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6594.txt",
  key="RFC 6594",
  abstract={This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC).  This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]},
  keywords="DNS, Domain Name System, SSHFP, SHA-256, Secure Shell, ECDSA",
  doi="10.17487/RFC6594",
  }

@misc{rfc6595,
  author="K. Wierenga and E. Lear and S. Josefsson",
  title="{A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)}",
  howpublished="RFC 6595 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6595",
  pages="1--22",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6595.txt",
  key="RFC 6595",
  abstract={The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On.  The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication.  This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]},
  keywords="Generic Security Service Application Program Interface, SAML 2.0",
  doi="10.17487/RFC6595",
  }

@misc{rfc6596,
  author="M. Ohye and J. Kupke",
  title="{The Canonical Link Relation}",
  howpublished="RFC 6596 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6596",
  pages="1--8",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6596.txt",
  key="RFC 6596",
  abstract={RFC 5988 specifies a way to define relationships between links on the web.  This document describes a new type of such a relationship, ``canonical'', to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6596",
  }

@misc{rfc6597,
  author="J. Downs and J. Arbeiter",
  title="{RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data}",
  howpublished="RFC 6597 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6597",
  pages="1--13",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6597.txt",
  key="RFC 6597",
  abstract={This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]},
  keywords="KLV",
  doi="10.17487/RFC6597",
  }

@misc{rfc6598,
  author="J. Weil and V. Kuarsingh and C. Donley and C. Liljenstolpe and M. Azinger",
  title="{IANA-Reserved IPv4 Prefix for Shared Address Space}",
  howpublished="RFC 6598 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6598",
  pages="1--11",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6598.txt",
  key="RFC 6598",
  abstract={This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.},
  keywords="shared block, CGN, NAT, Carrier Grade NAT, private address space, service provider, address translation, non-globally routable, non-overlapping address space",
  doi="10.17487/RFC6598",
  }

@misc{rfc6601,
  author="G. Ash and D. McDysan",
  title="{Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks}",
  howpublished="RFC 6601 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6601",
  pages="1--34",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6601.txt",
  key="RFC 6601",
  abstract={This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks.  Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.  Without MPLS GCAC, connections on congested links will suffer degraded quality.  The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.  MPLS GCAC interoperates between vendor equipment and across multiple service provider domains.  The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF.  The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms.  MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints.  The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request.  In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective.  MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6601",
  }

@misc{rfc6602,
  author="F. Abinader and S. Gundavelli and K. Leung and S. Krishnan and D. Premec",
  title="{Bulk Binding Update Support for Proxy Mobile IPv6}",
  howpublished="RFC 6602 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6602",
  pages="1--23",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6602.txt",
  key="RFC 6602",
  abstract={For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis.  In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor.  This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]},
  keywords="Proxy Mobile IPv6, PMIPv6, bulk registrations, MN group ID",
  doi="10.17487/RFC6602",
  }

@misc{rfc6603,
  author="J. Korhonen and T. Savolainen and S. Krishnan and O. Troan",
  title="{Prefix Exclude Option for DHCPv6-based Prefix Delegation}",
  howpublished="RFC 6603 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6603",
  pages="1--10",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6603.txt",
  key="RFC 6603",
  abstract={This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation.  The new mechanism updates RFC 3633. [STANDARDS-TRACK]},
  keywords="OPTION\_PD\_EXCLUDE",
  doi="10.17487/RFC6603",
  }

@misc{rfc6604,
  author="D. {Eastlake 3rd}",
  title="{xNAME RCODE and Status Bits Clarification}",
  howpublished="RFC 6604 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6604",
  pages="1--5",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6604.txt",
  key="RFC 6604",
  abstract={The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name.  A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits.  This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]},
  keywords="DNS, DNSSEC, CNAME, DNAME, Domain Name, response code, canonical name",
  doi="10.17487/RFC6604",
  }

@misc{rfc6605,
  author="P. Hoffman and W.C.A. Wijngaards",
  title="{Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC}",
  howpublished="RFC 6605 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6605",
  pages="1--8",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6605.txt",
  key="RFC 6605",
  abstract={This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC).  It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]},
  keywords="dnskey algorithm, ds hash algo, crypto, DNS key, DNSKEY algorithm, DS, digest hash cryptography, SHA-384, ECDSAP256SHA256, ECDSAP384SHA384",
  doi="10.17487/RFC6605",
  }

@misc{rfc6606,
  author="E. Kim and D. Kaspar and C. Gomez and C. Bormann",
  title="{Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing}",
  howpublished="RFC 6606 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6606",
  pages="1--32",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6606.txt",
  key="RFC 6606",
  abstract={IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="WSN, Sensor Network, Wireless Sensor Network, WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, ieee 802.15.4, LLN, Low Power, radio 802.15.4, powerline, ISA100.11a, RFC 4944",
  doi="10.17487/RFC6606",
  }

@misc{rfc6607,
  author="K. Kinnear and R. Johnson and M. Stapp",
  title="{Virtual Subnet Selection Options for DHCPv4 and DHCPv6}",
  howpublished="RFC 6607 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6607",
  pages="1--26",
  year=2012,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6607.txt",
  key="RFC 6607",
  doi="10.17487/RFC6607",
  }

@misc{rfc6608,
  author="J. Dong and M. Chen and A. Suryanarayana",
  title="{Subcodes for BGP Finite State Machine Error}",
  howpublished="RFC 6608 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6608",
  pages="1--5",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6608.txt",
  key="RFC 6608",
  abstract={This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events.  This document updates RFC 4271. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6608",
  }

@misc{rfc6609,
  author="C. Daboo and A. Stone",
  title="{Sieve Email Filtering: Include Extension}",
  howpublished="RFC 6609 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6609",
  pages="1--14",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6609.txt",
  key="RFC 6609",
  abstract={The Sieve Email Filtering ``include'' extension permits users to include one Sieve script inside another.  This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts.  Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6609",
  }

@misc{rfc6610,
  author="H. Jang and A. Yegin and K. Chowdhury and J. Choi and T. Lemon",
  title="{DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)}",
  howpublished="RFC 6610 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6610",
  pages="1--16",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6610.txt",
  key="RFC 6610",
  abstract={This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information.  New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6610",
  }

@misc{rfc6611,
  author="K. Chowdhury and A. Yegin",
  title="{Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario}",
  howpublished="RFC 6611 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6611",
  pages="1--12",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6611.txt",
  key="RFC 6611",
  abstract={Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario.  In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer.  In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer.  This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6611",
  }

@misc{rfc6612,
  author="G. Giaretta",
  title="{Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues}",
  howpublished="RFC 6612 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6612",
  pages="1--18",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6612.txt",
  key="RFC 6612",
  abstract={The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care.  This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms.  Solutions and recommendations to enable these scenarios are also described.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6612",
  }

@misc{rfc6613,
  author="A. DeKok",
  title="{RADIUS over TCP}",
  howpublished="RFC 6613 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6613",
  pages="1--16",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7930",
url="https://www.rfc-editor.org/rfc/rfc6613.txt",
  key="RFC 6613",
  abstract={The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer.  This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS).  It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Remote Authentication Dial-In User Server, Transmission Control Protocol, RADIUS/TCP",
  doi="10.17487/RFC6613",
  }

@misc{rfc6614,
  author="S. Winter and M. McCauley and S. Venaas and K. Wierenga",
  title="{Transport Layer Security (TLS) Encryption for RADIUS}",
  howpublished="RFC 6614 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6614",
  pages="1--22",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6614.txt",
  key="RFC 6614",
  abstract={This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol.  This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]},
  keywords="RADIUS, AAA, Security, Reliability, Remote Authentication Dial-In User Server",
  doi="10.17487/RFC6614",
  }

@misc{rfc6615,
  author="T. Dietz and A. Kobayashi and B. Claise and G. Muenz",
  title="{Definitions of Managed Objects for IP Flow Information Export}",
  howpublished="RFC 6615 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6615",
  pages="1--65",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6615.txt",
  key="RFC 6615",
  abstract={This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]},
  keywords="IPFIX, MIB, Filtering, Sampling, Selection",
  doi="10.17487/RFC6615",
  }

@misc{rfc6616,
  author="E. Lear and H. Tschofenig and H. Mauldin and S. Josefsson",
  title="{A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID}",
  howpublished="RFC 6616 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6616",
  pages="1--18",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6616.txt",
  key="RFC 6616",
  abstract={OpenID has found its usage on the Internet for Web Single Sign-On.  Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication.  This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]},
  keywords="web single sign-on",
  doi="10.17487/RFC6616",
  }

@misc{rfc6617,
  author="D. Harkins",
  title="{Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)}",
  howpublished="RFC 6617 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6617",
  pages="1--24",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6617.txt",
  key="RFC 6617",
  abstract={This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE).  It is resistant to dictionary attack and retains security even when used with weak pre-shared keys.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Authenticated Key Exchange, Dictionary Attack",
  doi="10.17487/RFC6617",
  }

@misc{rfc6618,
  author="J. Korhonen and B. Patil and H. Tschofenig and D. Kroeselberg",
  title="{Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent}",
  howpublished="RFC 6618 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6618",
  pages="1--38",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6618.txt",
  key="RFC 6618",
  abstract={Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec.  The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2.  The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack.  This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Mobile IPv6, Security",
  doi="10.17487/RFC6618",
  }

@misc{rfc6619,
  author="J. Arkko and L. Eggert and M. Townsley",
  title="{Scalable Operation of Address Translators with Per-Interface Bindings}",
  howpublished="RFC 6619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6619",
  pages="1--9",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6619.txt",
  key="RFC 6619",
  abstract={This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]},
  keywords="NAT, IPv4, IPv6",
  doi="10.17487/RFC6619",
  }

@misc{rfc6620,
  author="E. Nordmark and M. Bagnulo and E. Levy-Abegnoli",
  title="{FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses}",
  howpublished="RFC 6620 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6620",
  pages="1--35",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6620.txt",
  key="RFC 6620",
  abstract={This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle.  The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]},
  keywords="ingress filtering, BCP38",
  doi="10.17487/RFC6620",
  }

@misc{rfc6621,
  author="J. Macker",
  title="{Simplified Multicast Forwarding}",
  howpublished="RFC 6621 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6621",
  pages="1--55",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6621.txt",
  key="RFC 6621",
  abstract={This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use.  It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off.  It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use.  This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.  Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described.  Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices.  Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.  This document defines an Experimental Protocol for the Internet community.},
  keywords="routing, flooding, optimized flooding, CDS, connected dominating set, duplicate packet detection, hash-based packet detection, MPR, MPR-CDS, E-CDS, edge mobility, mobile ad hoc, mesh network",
  doi="10.17487/RFC6621",
  }

@misc{rfc6622,
  author="U. Herberg and T. Clausen",
  title="{Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)}",
  howpublished="RFC 6622 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6622",
  pages="1--21",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7182",
url="https://www.rfc-editor.org/rfc/rfc6622.txt",
  key="RFC 6622",
  abstract={This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444.  It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]},
  keywords="packetbb, NHDP, OLSRv2, security, integrity, routing",
  doi="10.17487/RFC6622",
  }

@misc{rfc6623,
  author="E. Burger",
  title="{IANA Registry for MEDIACTRL Interactive Voice Response Control Package}",
  howpublished="RFC 6623 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6623",
  pages="1--6",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6623.txt",
  key="RFC 6623",
  abstract={This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6623",
  }

@misc{rfc6624,
  author="K. Kompella and B. Kothari and R. Cherukuri",
  title="{Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling}",
  howpublished="RFC 6624 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6624",
  pages="1--26",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6624.txt",
  key="RFC 6624",
  abstract={Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular.  Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs.  In addition, L2VPN provisioning was cumbersome.  This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="BGP, L2VPN, discovery, signaling, pseudowire",
  doi="10.17487/RFC6624",
  }

@misc{rfc6625,
  author="E. Rosen and Y. Rekhter and W. Hendrickx and R. Qiu",
  title="{Wildcards in Multicast VPN Auto-Discovery Routes}",
  howpublished="RFC 6625 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6625",
  pages="1--17",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7582, 7900",
url="https://www.rfc-editor.org/rfc/rfc6625.txt",
  key="RFC 6625",
  abstract={In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in ``tunnels'' through a service provider's network.  The base specifications for MVPN define BGP multicast VPN ``auto-discovery routes'' and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel.  However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel.  Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN.  This document eliminates these restrictions by specifying the use of ``wildcard'' elements in the customer flow identifiers.  With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]},
  keywords="mvpn",
  doi="10.17487/RFC6625",
  }

@misc{rfc6626,
  author="G. Tsirtsis and V. Park and V. Narayanan and K. Leung",
  title="{Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)}",
  howpublished="RFC 6626 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6626",
  pages="1--5",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6626.txt",
  key="RFC 6626",
  abstract={The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks.  This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]},
  keywords="mobile router",
  doi="10.17487/RFC6626",
  }

@misc{rfc6627,
  author="G. Karagiannis and K. Chan and T. Moncaster and M. Menth and P. Eardley and B. Briscoe",
  title="{Overview of Pre-Congestion Notification Encoding}",
  howpublished="RFC 6627 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6627",
  pages="1--20",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6627.txt",
  key="RFC 6627",
  abstract={The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious \\%pre-congestion. The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6627",
  }

@misc{rfc6628,
  author="S. Shin and K. Kobara",
  title="{Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2}",
  howpublished="RFC 6628 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6628",
  pages="1--20",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6628.txt",
  key="RFC 6628",
  abstract={This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server.  In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks).  The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security).  In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2).  This document defines an Experimental Protocol for the Internet community.},
  keywords="PAKE, augmented PAKE, off-line dictionary attacks, resistance to server compromise",
  doi="10.17487/RFC6628",
  }

@misc{rfc6629,
  author="J. Abley and M. Bagnulo and A. Garcia-Martinez",
  title="{Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)}",
  howpublished="RFC 6629 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6629",
  pages="1--28",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6629.txt",
  key="RFC 6629",
  abstract={This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Cryptographically Generated Address, CGA, Hash-Based Address, HBA, Fault tolerance",
  doi="10.17487/RFC6629",
  }

@misc{rfc6630,
  author="Z. Cao and H. Deng and Q. Wu and G. Zorn",
  title="{EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)}",
  howpublished="RFC 6630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6630",
  pages="1--20",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6630.txt",
  key="RFC 6630",
  abstract={The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]},
  keywords="ERP, AAK, EAP, Early-authentication",
  doi="10.17487/RFC6630",
  }

@misc{rfc6631,
  author="D. Kuegler and Y. Sheffer",
  title="{Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)}",
  howpublished="RFC 6631 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6631",
  pages="1--26",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6631.txt",
  key="RFC 6631",
  abstract={The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords.  Several proposals have been made to integrate password-authentication protocols into IKE.  This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.  This document defines an Experimental Protocol for the Internet community.},
  keywords="pace, password authenticated connection establishment",
  doi="10.17487/RFC6631",
  }

@misc{rfc6632,
  author="M. Ersue and B. Claise",
  title="{An Overview of the IETF Network Management Standards}",
  howpublished="RFC 6632 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6632",
  pages="1--85",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6632.txt",
  key="RFC 6632",
  abstract={This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models.  The document refers to other overview documents, where they exist and classifies the standards for easy orientation.  The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs.  On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models.  This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="network management, data model, monitoring, configuration, alarm, notification",
  doi="10.17487/RFC6632",
  }

@misc{rfc6633,
  author="F. Gont",
  title="{Deprecation of ICMP Source Quench Messages}",
  howpublished="RFC 6633 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6633",
  pages="1--8",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6633.txt",
  key="RFC 6633",
  abstract={This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]},
  keywords="congestion control, icmp attacks, tcp, tcp security, udp, dccp, sctp",
  doi="10.17487/RFC6633",
  }

@misc{rfc6635,
  author="O. Kolkman and J. Halpern and IAB",
  title="{RFC Editor Model (Version 2)}",
  howpublished="RFC 6635 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6635",
  pages="1--21",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6635.txt",
  key="RFC 6635",
  abstract={The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher.  Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC.  This document reflects the experience gained with ``RFC Editor Model (Version 1)'', documented in RFC 5620, and obsoletes that document.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RFC Series Editor, Independenet Series Editor, RSE, ISE, RSOC, RFC Series Oversight Committee",
  doi="10.17487/RFC6635",
  }

@misc{rfc6636,
  author="H. Asaeda and H. Liu and Q. Wu",
  title="{Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks}",
  howpublished="RFC 6636 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6636",
  pages="1--12",
  year=2012,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6636.txt",
  key="RFC 6636",
  abstract={The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other.  This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Mobility, PMIPv6",
  doi="10.17487/RFC6636",
  }

@misc{rfc6637,
  author="A. Jivsov",
  title="{Elliptic Curve Cryptography (ECC) in OpenPGP}",
  howpublished="RFC 6637 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6637",
  pages="1--15",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6637.txt",
  key="RFC 6637",
  abstract={This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology.  The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]},
  doi="10.17487/RFC6637",
  }

@misc{rfc6638,
  author="C. Daboo and B. Desruisseaux",
  title="{Scheduling Extensions to CalDAV}",
  howpublished="RFC 6638 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6638",
  pages="1--78",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7953",
url="https://www.rfc-editor.org/rfc/rfc6638.txt",
  key="RFC 6638",
  abstract={This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) ``calendar-access'' feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components.  This document defines the ``calendar-auto-schedule'' feature of CalDAV. [STANDARDS-TRACK]},
  keywords="calsify, calsched, calsch, calendar, calendaring, webcal, ical, icalendar, ischedule, itip, imip, text/calendar, http",
  doi="10.17487/RFC6638",
  }

@misc{rfc6639,
  author="D. King and M. Venkatesan",
  title="{Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview}",
  howpublished="RFC 6639 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6639",
  pages="1--29",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6639.txt",
  key="RFC 6639",
  abstract={A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6639",
  }

@misc{rfc6640,
  author="W. George",
  title="{IETF Meeting Attendees' Frequently Asked (Travel) Questions}",
  howpublished="RFC 6640 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6640",
  pages="1--13",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6640.txt",
  key="RFC 6640",
  abstract={This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information.  It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from.  It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Meetings",
  doi="10.17487/RFC6640",
  }

@misc{rfc6641,
  author="C. Everhart and W. Adamson and J. Zhang",
  title="{Using DNS SRV to Specify a Global File Namespace with NFS Version 4}",
  howpublished="RFC 6641 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6641",
  pages="1--11",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6641.txt",
  key="RFC 6641",
  abstract={The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace.  The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization.  The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]},
  keywords="domainroot, domain root file system",
  doi="10.17487/RFC6641",
  }

@misc{rfc6642,
  author="Q. Wu and F. Xia and R. Even",
  title="{RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report}",
  howpublished="RFC 6642 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6642",
  pages="1--13",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6642.txt",
  key="RFC 6642",
  abstract={In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once.  This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports.  However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion.  This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback.  Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]},
  keywords="Feedback Suppression, NACK, Retransmission",
  doi="10.17487/RFC6642",
  }

@misc{rfc6643,
  author="J. Schoenwaelder",
  title="{Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules}",
  howpublished="RFC 6643 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6643",
  pages="1--36",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6643.txt",
  key="RFC 6643",
  abstract={YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.  The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP).  This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]},
  keywords="SMIv2, YANG, data modeling",
  doi="10.17487/RFC6643",
  }

@misc{rfc6644,
  author="D. Evans and R. Droms and S. Jiang",
  title="{Rebind Capability in DHCPv6 Reconfigure Messages}",
  howpublished="RFC 6644 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6644",
  pages="1--10",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6644.txt",
  key="RFC 6644",
  abstract={This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message.  It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message.  The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK]},
  keywords="internet protocol, parameters, addresses",
  doi="10.17487/RFC6644",
  }

@misc{rfc6645,
  author="J. Novak",
  title="{IP Flow Information Accounting and Export Benchmarking Methodology}",
  howpublished="RFC 6645 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6645",
  pages="1--39",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6645.txt",
  key="RFC 6645",
  abstract={This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector.  It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput.  The metric is only applicable to the devices compliant with RFC 5470, ``Architecture for IP Flow Information Export''.  The methodology quantifies the impact of the IP flow monitoring process on the network equipment.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Performance, Flow monitoring, IPFIX, Netflow",
  doi="10.17487/RFC6645",
  }

@misc{rfc6646,
  author="H. Song and N. Zong and Y. Yang and R. Alimi",
  title="{DECoupled Application Data Enroute (DECADE) Problem Statement}",
  howpublished="RFC 6646 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6646",
  pages="1--12",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6646.txt",
  key="RFC 6646",
  abstract={Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks.  In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network.  Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache.  This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="In-network storage, P2P",
  doi="10.17487/RFC6646",
  }

@misc{rfc6647,
  author="M. Kucherawy and D. Crocker",
  title="{Email Greylisting: An Applicability Statement for SMTP}",
  howpublished="RFC 6647 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6647",
  pages="1--17",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6647.txt",
  key="RFC 6647",
  abstract={This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]},
  keywords="Email, Greylisting, Spam",
  doi="10.17487/RFC6647",
  }

@misc{rfc6648,
  author="P. Saint-Andre and D. Crocker and M. Nottingham",
  title="{Deprecating the ``X-'' Prefix and Similar Constructs in Application Protocols}",
  howpublished="RFC 6648 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6648",
  pages="1--13",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6648.txt",
  key="RFC 6648",
  abstract={Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string ``X-'' or similar constructs.  In practice, that convention causes more problems than it solves.  Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6648",
  }

@misc{rfc6649,
  author="L. Hornquist Astrand and T. Yu",
  title="{Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos}",
  howpublished="RFC 6649 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6649",
  pages="1--7",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6649.txt",
  key="RFC 6649",
  abstract={The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption.  Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure.  By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average.  DES is long past its sell-by date.  Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos.  Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic.  This memo documents an Internet Best Current Practice.},
  keywords="",
  doi="10.17487/RFC6649",
  }

@misc{rfc6650,
  author="J. Falk and M. Kucherawy",
  title="{Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)}",
  howpublished="RFC 6650 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6650",
  pages="1--15",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6650.txt",
  key="RFC 6650",
  abstract={RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties.  This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events.  Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them.  Some related optional mechanisms are also discussed. [STANDARDS-TRACK]},
  keywords="marf, spam reporting",
  doi="10.17487/RFC6650",
  }

@misc{rfc6651,
  author="M. Kucherawy",
  title="{Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting}",
  howpublished="RFC 6651 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6651",
  pages="1--18",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6651.txt",
  key="RFC 6651",
  abstract={This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. [STANDARDS-TRACK]},
  keywords="authentication, fraud, phishing, spoofing",
  doi="10.17487/RFC6651",
  }

@misc{rfc6652,
  author="S. Kitterman",
  title="{Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format}",
  howpublished="RFC 6652 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6652",
  pages="1--8",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6652.txt",
  key="RFC 6652",
  abstract={This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]},
  keywords="fraud, phishing, spoofing",
  doi="10.17487/RFC6652",
  }

@misc{rfc6653,
  author="B. Sarikaya and F. Xia and T. Lemon",
  title="{DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks}",
  howpublished="RFC 6653 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6653",
  pages="1--13",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6653.txt",
  key="RFC 6653",
  abstract={As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document.  Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server.  The access router first requests a prefix for an incoming mobile node from the DHCPv6 server.  The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP.  We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6653",
  }

@misc{rfc6654,
  author="T. Tsou and C. Zhou and T. Taylor and Q. Chen",
  title="{Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)}",
  howpublished="RFC 6654 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6654",
  pages="1--8",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6654.txt",
  key="RFC 6654",
  abstract={This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969.  The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels.  6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address.  The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed ``Gateway-initiated 6rd'' (GI 6rd).  The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment.  The latter point means less pressure on IPv4 addresses in a high-growth environment.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPv6 transition",
  doi="10.17487/RFC6654",
  }

@misc{rfc6655,
  author="D. McGrew and D. Bailey",
  title="{AES-CCM Cipher Suites for Transport Layer Security (TLS)}",
  howpublished="RFC 6655 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6655",
  pages="1--8",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6655.txt",
  key="RFC 6655",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]},
  keywords="Authentication, Encryption, Advanced Encryption Standard (AES)",
  doi="10.17487/RFC6655",
  }

@misc{rfc6656,
  author="R. Johnson and K. Kinnear and M. Stapp",
  title="{Description of Cisco Systems' Subnet Allocation Option for DHCPv4}",
  howpublished="RFC 6656 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6656",
  pages="1--24",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6656.txt",
  key="RFC 6656",
  abstract={This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4.  The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics.  This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6656",
  }

@misc{rfc6657,
  author="A. Melnikov and J. Reschke",
  title="{Update to MIME regarding ``charset'' Parameter Handling in Textual Media Types}",
  howpublished="RFC 6657 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6657",
  pages="1--6",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6657.txt",
  key="RFC 6657",
  abstract={This document changes RFC 2046 rules regarding default ``charset'' parameter values for ``text/*'' media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]},
  keywords="MIME, charset, text",
  doi="10.17487/RFC6657",
  }

@misc{rfc6658,
  author="S. Bryant and L. Martini and G. Swallow and A. Malis",
  title="{Packet Pseudowire Encapsulation over an MPLS PSN}",
  howpublished="RFC 6658 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6658",
  pages="1--15",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6658.txt",
  key="RFC 6658",
  abstract={This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment.  This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6658",
  }

@misc{rfc6659,
  author="A. Begen",
  title="{Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method}",
  howpublished="RFC 6659 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6659",
  pages="1--12",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6659.txt",
  key="RFC 6659",
  abstract={The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data.  Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate.  This often precedes, but may also accompany, the multicast stream itself.  When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner.  However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately.  This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="IPTV, FEC, retransmission",
  doi="10.17487/RFC6659",
  }

@misc{rfc6660,
  author="B. Briscoe and T. Moncaster and M. Menth",
  title="{Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)}",
  howpublished="RFC 6660 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6660",
  pages="1--24",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6660.txt",
  key="RFC 6660",
  abstract={The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]},
  keywords="Quality of Service, QoS, Congestion Control, Congestion Notification, Tunnelling, Encapsulation \& Decapsulation, Differentiated Services, Integrated Services, Signalling, Protocol, Flow Admission Control, Flow Termination",
  doi="10.17487/RFC6660",
  }

@misc{rfc6661,
  author="A. Charny and F. Huang and G. Karagiannis and M. Menth and T. Taylor",
  title="{Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation}",
  howpublished="RFC 6661 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6661",
  pages="1--33",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6661.txt",
  key="RFC 6661",
  abstract={Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo is one of a series describing possible boundary-node behaviors for a PCN-domain.  The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked.  This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PCN, controlled load, CL, boundary node behavior",
  doi="10.17487/RFC6661",
  }

@misc{rfc6662,
  author="A. Charny and J. Zhang and G. Karagiannis and M. Menth and T. Taylor",
  title="{Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation}",
  howpublished="RFC 6662 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6662",
  pages="1--31",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6662.txt",
  key="RFC 6662",
  abstract={Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo is one of a series describing possible boundary-node behaviors for a PCN-domain.  The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked.  This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior.  This document defines an Experimental Protocol for the Internet community.},
  keywords="PCN, single marking, SM, edge node behavior",
  doi="10.17487/RFC6662",
  }

@misc{rfc6663,
  author="G. Karagiannis and T. Taylor and K. Chan and M. Menth and P. Eardley",
  title="{Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain}",
  howpublished="RFC 6663 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6663",
  pages="1--7",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6663.txt",
  key="RFC 6663",
  abstract={Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo describes the requirements for the signaling applied within the PCN-domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node.  The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required).  The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM).  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6663",
  }

@misc{rfc6664,
  author="J. Schaad",
  title="{S/MIME Capabilities for Public Key Definitions}",
  howpublished="RFC 6664 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6664",
  pages="1--19",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6664.txt",
  key="RFC 6664",
  abstract={This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group.  This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. ``Online Certificate Status Protocol Algorithm Agility'' (RFC 6277) details an example of where this is used.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="OCSP, CMS",
  doi="10.17487/RFC6664",
  }

@misc{rfc6665,
  author="A.B. Roach",
  title="{SIP-Specific Event Notification}",
  howpublished="RFC 6665 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6665",
  pages="1--53",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7621",
url="https://www.rfc-editor.org/rfc/rfc6665.txt",
  key="RFC 6665",
  abstract={This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]},
  keywords="SUBSCRIBE, NOTIFY, state",
  doi="10.17487/RFC6665",
  }

@misc{rfc6666,
  author="N. Hilliard and D. Freedman",
  title="{A Discard Prefix for IPv6}",
  howpublished="RFC 6666 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6666",
  pages="1--6",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6666.txt",
  key="RFC 6666",
  abstract={Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address.  Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address.  This document updates the ``IPv6 Special Purpose Address Registry'' by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="RTBH, black hole",
  doi="10.17487/RFC6666",
  }

@misc{rfc6667,
  author="K. Raza and S. Boutros and C. Pignataro",
  title="{LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements}",
  howpublished="RFC 6667 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6667",
  pages="1--8",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6667.txt",
  key="RFC 6667",
  abstract={The ``Typed Wildcard Forwarding Equivalence Class (FEC) Element'' defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired.  However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type.  This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6667",
  }

@misc{rfc6668,
  author="D. Bider and M. Baushke",
  title="{SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 6668 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6668",
  pages="1--5",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6668.txt",
  key="RFC 6668",
  abstract={This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol.  It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6668",
  }

@misc{rfc6669,
  author="N. Sprecher and L. Fang",
  title="{An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks}",
  howpublished="RFC 6669 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6669",
  pages="1--21",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6669.txt",
  key="RFC 6669",
  abstract={This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks.  The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.  This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets.  The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6669",
  }

@misc{rfc6670,
  author="N. Sprecher and KY. Hong",
  title="{The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)}",
  howpublished="RFC 6670 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6670",
  pages="1--33",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6670.txt",
  key="RFC 6670",
  abstract={The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6670",
  }

@misc{rfc6671,
  author="M. Betts",
  title="{Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)}",
  howpublished="RFC 6671 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6671",
  pages="1--5",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6671.txt",
  key="RFC 6671",
  abstract={This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6671",
  }

@misc{rfc6672,
  author="S. Rose and W. Wijngaards",
  title="{DNAME Redirection in the DNS}",
  howpublished="RFC 6672 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6672",
  pages="1--22",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6672.txt",
  key="RFC 6672",
  abstract={The DNAME record provides redirection for a subtree of the domain name tree in the DNS.  That is, all names that end with a particular suffix are redirected to another part of the DNS.  This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6672",
  }

@misc{rfc6673,
  author="A. Morton",
  title="{Round-Trip Packet Loss Metrics}",
  howpublished="RFC 6673 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6673",
  pages="1--14",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6673.txt",
  key="RFC 6673",
  abstract={Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]},
  keywords="IP, IPPM",
  doi="10.17487/RFC6673",
  }

@misc{rfc6674,
  author="F. Brockners and S. Gundavelli and S. Speicher and D. Ward",
  title="{Gateway-Initiated Dual-Stack Lite Deployment}",
  howpublished="RFC 6674 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6674",
  pages="1--15",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6674.txt",
  key="RFC 6674",
  abstract={Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures.  GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong.  The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]},
  keywords="GI-DS-Lite, Gateway Initiated Dual-Stack Lite, Dual-Stack Lite, IPv6 Transitioning, IPv6 Migration",
  doi="10.17487/RFC6674",
  }

@misc{rfc6675,
  author="E. Blanton and M. Allman and L. Wang and I. Jarvinen and M. Kojo and Y. Nishida",
  title="{A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP}",
  howpublished="RFC 6675 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6675",
  pages="1--15",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6675.txt",
  key="RFC 6675",
  abstract={This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option.  The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.  This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]},
  keywords="transmission control protocol, retransmission, congestion control",
  doi="10.17487/RFC6675",
  }

@misc{rfc6676,
  author="S. Venaas and R. Parekh and G. Van de Velde and T. Chown and M. Eubanks",
  title="{Multicast Addresses for Documentation}",
  howpublished="RFC 6676 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6676",
  pages="1--7",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6676.txt",
  key="RFC 6676",
  abstract={This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use.  Some multicast addresses are derived from AS numbers or unicast addresses.  This document also explains how these can be used for documentation purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6676",
  }

@misc{rfc6677,
  author="S. Hartman and T. Clancy and K. Hoeper",
  title="{Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods}",
  howpublished="RFC 6677 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6677",
  pages="1--31",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6677.txt",
  key="RFC 6677",
  abstract={This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the ``lying Network Access Service (NAS)'' problem as well as the ``lying provider'' problem. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6677",
  }

@misc{rfc6678,
  author="K. Hoeper and S. Hanna and H. Zhou and J. Salowey",
  title="{Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method}",
  howpublished="RFC 6678 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6678",
  pages="1--23",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6678.txt",
  key="RFC 6678",
  abstract={This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method.  This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel.  The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6678",
  }

@misc{rfc6679,
  author="M. Westerlund and I. Johansson and C. Perkins and P. O'Hanlon and K. Carlberg",
  title="{Explicit Congestion Notification (ECN) for RTP over UDP}",
  howpublished="RFC 6679 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6679",
  pages="1--58",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6679.txt",
  key="RFC 6679",
  abstract={This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism.  It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE).  Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]},
  keywords="ECN, RTP, UDP, Congestion Control, VoIP, IPTV, Packet Loss",
  doi="10.17487/RFC6679",
  }

@misc{rfc6680,
  author="N. Williams and L. Johansson and S. Hartman and S. Josefsson",
  title="{Generic Security Service Application Programming Interface (GSS-API) Naming Extensions}",
  howpublished="RFC 6680 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6680",
  pages="1--18",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6680.txt",
  key="RFC 6680",
  abstract={The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization.  This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.},
  keywords="",
  doi="10.17487/RFC6680",
  }

@misc{rfc6681,
  author="M. Watson and T. Stockhammer and M. Luby",
  title="{Raptor Forward Error Correction (FEC) Schemes for FECFRAME}",
  howpublished="RFC 6681 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6681",
  pages="1--22",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6681.txt",
  key="RFC 6681",
  abstract={This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework.  The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow.  The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity.  Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number.  Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6681",
  }

@misc{rfc6682,
  author="M. Watson and T. Stockhammer and M. Luby",
  title="{RTP Payload Format for Raptor Forward Error Correction (FEC)}",
  howpublished="RFC 6682 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6682",
  pages="1--18",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6682.txt",
  key="RFC 6682",
  abstract={This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes.  Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP.  This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6682",
  }

@misc{rfc6683,
  author="A. Begen and T. Stockhammer",
  title="{Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection}",
  howpublished="RFC 6683 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6683",
  pages="1--11",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6683.txt",
  key="RFC 6683",
  abstract={Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP.  The DVB-IPTV AL-FEC protocol uses two layers for FEC protection.  The first (base) layer is based on the 1-D interleaved parity code.  The second (enhancement) layer is based on the Raptor code.  By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity.  This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DVB, FEC, AL-FEC, IPTV, parity codes, Raptor codes",
  doi="10.17487/RFC6683",
  }

@misc{rfc6684,
  author="B. Trammell",
  title="{Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)}",
  howpublished="RFC 6684 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6684",
  pages="1--12",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6684.txt",
  key="RFC 6684",
  abstract={This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="mile, incident handling",
  doi="10.17487/RFC6684",
  }

@misc{rfc6685,
  author="B. Trammell",
  title="{Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry}",
  howpublished="RFC 6685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6685",
  pages="1--3",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7970",
url="https://www.rfc-editor.org/rfc/rfc6685.txt",
  key="RFC 6685",
  abstract={This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]},
  keywords="mile, xml schema",
  doi="10.17487/RFC6685",
  }

@misc{rfc6686,
  author="M. Kucherawy",
  title="{Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments}",
  howpublished="RFC 6686 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6686",
  pages="1--12",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6686.txt",
  key="RFC 6686",
  abstract={In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="SPF, Sender ID, authentication, authorization, email",
  doi="10.17487/RFC6686",
  }

@misc{rfc6687,
  author="J. Tripathi and J. de Oliveira and JP. Vasseur",
  title="{Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)}",
  howpublished="RFC 6687 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6687",
  pages="1--26",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6687.txt",
  key="RFC 6687",
  abstract={This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network.  Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios.  Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="ROLL",
  doi="10.17487/RFC6687",
  }

@misc{rfc6688,
  author="D. Black and J. Glasgow and S. Faibish",
  title="{Parallel NFS (pNFS) Block Disk Protection}",
  howpublished="RFC 6688 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6688",
  pages="1--6",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6688.txt",
  key="RFC 6688",
  abstract={Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server.  This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used.  The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server.  This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server.  This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]},
  keywords="NFS, NFSv4, pNFS, SAN, GPT",
  doi="10.17487/RFC6688",
  }

@misc{rfc6689,
  author="L. Berger",
  title="{Usage of the RSVP ASSOCIATION Object}",
  howpublished="RFC 6689 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6689",
  pages="1--11",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6689.txt",
  key="RFC 6689",
  abstract={The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs).  In this context, the object is used to associate recovery LSPs with the LSP they are protecting.  This document reviews how the association is to be provided in the context of GMPLS recovery.  No new procedures or mechanisms are defined by this document, and it is strictly informative in nature.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Resource Reservation Protocol",
  doi="10.17487/RFC6689",
  }

@misc{rfc6690,
  author="Z. Shelby",
  title="{Constrained RESTful Environments (CoRE) Link Format}",
  howpublished="RFC 6690 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6690",
  pages="1--22",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6690.txt",
  key="RFC 6690",
  abstract={This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. ``RESTful'' refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]},
  keywords="CoRE, Link Format, HTTP Link Header Format, Resource Discovery",
  doi="10.17487/RFC6690",
  }

@misc{rfc6691,
  author="D. Borman",
  title="{TCP Options and Maximum Segment Size (MSS)}",
  howpublished="RFC 6691 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6691",
  pages="1--9",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6691.txt",
  key="RFC 6691",
  abstract={This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6691",
  }

@misc{rfc6692,
  author="R. Clayton and M. Kucherawy",
  title="{Source Ports in Abuse Reporting Format (ARF) Reports}",
  howpublished="RFC 6692 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6692",
  pages="1--5",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6692.txt",
  key="RFC 6692",
  abstract={This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident. This document updates RFC 6591. [STANDARDS-TRACK]},
  keywords="ARF, ports, reporting, feedback",
  doi="10.17487/RFC6692",
  }

@misc{rfc6693,
  author="A. Lindgren and A. Doria and E. Davies and S. Grasic",
  title="{Probabilistic Routing Protocol for Intermittently Connected Networks}",
  howpublished="RFC 6693 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6693",
  pages="1--113",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6693.txt",
  key="RFC 6693",
  abstract={This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the \\%best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.},
  keywords="DTN, Routing, PRoPHET",
  doi="10.17487/RFC6693",
  }

@misc{rfc6694,
  author="S. Moonesamy",
  title="{The ``about'' URI Scheme}",
  howpublished="RFC 6694 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6694",
  pages="1--7",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6694.txt",
  key="RFC 6694",
  abstract={This document describes the ``about'' URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6694",
  }

@misc{rfc6695,
  author="R. Asati",
  title="{Methods to Convey Forward Error Correction (FEC) Framework Configuration Information}",
  howpublished="RFC 6695 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6695",
  pages="1--15",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6695.txt",
  key="RFC 6695",
  abstract={The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s). This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6695",
  }

@misc{rfc6696,
  author="Z. Cao and B. He and Y. Shi and Q. Wu and G. Zorn",
  title="{EAP Extensions for the EAP Re-authentication Protocol (ERP)}",
  howpublished="RFC 6696 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6696",
  pages="1--47",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6696.txt",
  key="RFC 6696",
  abstract={The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.  In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator.  This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator.  The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]},
  keywords="EAP keying, EMSK, inter-authenticator roaming",
  doi="10.17487/RFC6696",
  }

@misc{rfc6697,
  author="G. Zorn and Q. Wu and T. Taylor and Y. Nir and K. Hoeper and S. Decugis",
  title="{Handover Keying (HOKEY) Architecture Design}",
  howpublished="RFC 6697 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6697",
  pages="1--20",
  year=2012,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6697.txt",
  key="RFC 6697",
  abstract={The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or ``peer'' is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748. This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Handover Keying Architecture, Re-authentication, Early authentication",
  doi="10.17487/RFC6697",
  }

@misc{rfc6698,
  author="P. Hoffman and J. Schlyter",
  title="{The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA}",
  howpublished="RFC 6698 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6698",
  pages="1--37",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7218, 7671",
url="https://www.rfc-editor.org/rfc/rfc6698.txt",
  key="RFC 6698",
  abstract={Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]},
  keywords="DNSSEC, certificates, public keys, PKI",
  doi="10.17487/RFC6698",
  }

@misc{rfc6701,
  author="A. Farrel and P. Resnick",
  title="{Sanctions Available for Application to Violators of IETF IPR Policy}",
  howpublished="RFC 6701 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6701",
  pages="1--12",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6701.txt",
  key="RFC 6701",
  abstract={The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6701",
  }

@misc{rfc6702,
  author="T. Polk and P. Saint-Andre",
  title="{Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules}",
  howpublished="RFC 6702 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6702",
  pages="1--16",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6702.txt",
  key="RFC 6702",
  abstract={The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus.  However, this process is not always followed by IETF participants.  Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications.  This document describes some strategies for promoting compliance with the IPR disclosure rules.  These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6702",
  }

@misc{rfc6703,
  author="A. Morton and G. Ramachandran and G. Maguluri",
  title="{Reporting IP Network Performance Metrics: Different Points of View}",
  howpublished="RFC 6703 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6703",
  pages="1--27",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6703.txt",
  key="RFC 6703",
  abstract={Consumers of IP network performance metrics have many different uses in mind.  This memo provides ``long-term'' reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences.  It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Loss, Delay, Delay Variation, Capacity, TCP",
  doi="10.17487/RFC6703",
  }

@misc{rfc6704,
  author="D. Miles and W. Dec and J. Bristow and R. Maglione",
  title="{Forcerenew Nonce Authentication}",
  howpublished="RFC 6704 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6704",
  pages="1--12",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6704.txt",
  key="RFC 6704",
  abstract={Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server.  In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message.  This document updates RFC 3203. [STANDARDS-TRACK]},
  keywords="DHCP",
  doi="10.17487/RFC6704",
  }

@misc{rfc6705,
  author="S. Krishnan and R. Koodli and P. Loureiro and Q. Wu and A. Dutta",
  title="{Localized Routing for Proxy Mobile IPv6}",
  howpublished="RFC 6705 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6705",
  pages="1--20",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6705.txt",
  key="RFC 6705",
  abstract={Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling.  PMIPv6 requires all communications to go through the local mobility anchor.  As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways.  This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain.  It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]},
  keywords="PMIPv6",
  doi="10.17487/RFC6705",
  }

@misc{rfc6706,
  author="F. Templin",
  title="{Asymmetric Extended Route Optimization (AERO)}",
  howpublished="RFC 6706 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6706",
  pages="1--33",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6706.txt",
  key="RFC 6706",
  abstract={Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection.  Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination.  This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress.  However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.  This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.  This document defines an Experimental Protocol for the Internet community.},
  keywords="route, optimize, optimization, redirect, redirection, protocol, routing, link, multi-access, IPv6",
  doi="10.17487/RFC6706",
  }

@misc{rfc6707,
  author="B. Niven-Jenkins and F. Le Faucheur and N. Bitar",
  title="{Content Distribution Network Interconnection (CDNI) Problem Statement}",
  howpublished="RFC 6707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6707",
  pages="1--32",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6707.txt",
  key="RFC 6707",
  abstract={Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection. The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Delivery, CDN",
  doi="10.17487/RFC6707",
  }

@misc{rfc6708,
  author="S. Kiesel and S. Previdi and M. Stiemerling and R. Woundy and Y. Yang",
  title="{Application-Layer Traffic Optimization (ALTO) Requirements}",
  howpublished="RFC 6708 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6708",
  pages="1--20",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6708.txt",
  key="RFC 6708",
  abstract={Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure. This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6708",
  }

@misc{rfc6709,
  author="B. Carpenter and B. Aboba and S. Cheshire",
  title="{Design Considerations for Protocol Extensions}",
  howpublished="RFC 6709 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6709",
  pages="1--42",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6709.txt",
  key="RFC 6709",
  abstract={This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations.  It is intended to assist designers of both base protocols and extensions.  Case studies are included.  A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6709",
  }

@misc{rfc6710,
  author="A. Melnikov and K. Carlberg",
  title="{Simple Mail Transfer Protocol Extension for Message Transfer Priorities}",
  howpublished="RFC 6710 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6710",
  pages="1--28",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6710.txt",
  key="RFC 6710",
  abstract={This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]},
  keywords="SMTP, priority, MMHS",
  doi="10.17487/RFC6710",
  }

@misc{rfc6711,
  author="L. Johansson",
  title="{An IANA Registry for Level of Assurance (LoA) Profiles}",
  howpublished="RFC 6711 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6711",
  pages="1--7",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6711.txt",
  key="RFC 6711",
  abstract={This document establishes an IANA registry for Level of Assurance (LoA) Profiles.  The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Identity, Assurance",
  doi="10.17487/RFC6711",
  }

@misc{rfc6712,
  author="T. Kause and M. Peylo",
  title="{Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)}",
  howpublished="RFC 6712 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6712",
  pages="1--10",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6712.txt",
  key="RFC 6712",
  abstract={This document describes how to layer the Certificate Management Protocol (CMP) over HTTP.  It is the ``CMPtrans'' document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]},
  keywords="CMPtrans",
  doi="10.17487/RFC6712",
  }

@misc{rfc6713,
  author="J. Levine",
  title="{The 'application/zlib' and 'application/gzip' Media Types}",
  howpublished="RFC 6713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6713",
  pages="1--4",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6713.txt",
  key="RFC 6713",
  abstract={This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="compress, deflate, stream compression",
  doi="10.17487/RFC6713",
  }

@misc{rfc6714,
  author="C. Holmberg and S. Blau and E. Burger",
  title="{Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)}",
  howpublished="RFC 6714 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6714",
  pages="1--22",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6714.txt",
  key="RFC 6714",
  abstract={This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA).  Support of this extension is OPTIONAL.  The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed.  This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]},
  keywords="Middlebox, IBCF, SBC",
  doi="10.17487/RFC6714",
  }

@misc{rfc6715,
  author="D. Cauchie and B. Leiba and K. Li",
  title="{vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group}",
  howpublished="RFC 6715 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6715",
  pages="1--11",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6715.txt",
  key="RFC 6715",
  abstract={This document defines extensions to the vCard data format for representing and exchanging certain contact information.  The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]},
  keywords="expertise, hobby, interest",
  doi="10.17487/RFC6715",
  }

@misc{rfc6716,
  author="JM. Valin and K. Vos and T. Terriberry",
  title="{Definition of the Opus Audio Codec}",
  howpublished="RFC 6716 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6716",
  pages="1--326",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6716.txt",
  key="RFC 6716",
  abstract={This document defines the Opus interactive speech and audio codec.  Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances.  It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s.  Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]},
  keywords="voice, music, lossy compression, VOIP",
  doi="10.17487/RFC6716",
  }

@misc{rfc6717,
  author="H. Hotz and R. Allbery",
  title="{kx509 Kerberized Certificate Issuance Protocol in Use in 2012}",
  howpublished="RFC 6717 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6717",
  pages="1--13",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6717.txt",
  key="RFC 6717",
  abstract={This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less. While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Kerberos, X.509, kx509, KCA, kca-service, kca\_service",
  doi="10.17487/RFC6717",
  }

@misc{rfc6718,
  author="P. Muley and M. Aissaoui and M. Bocci",
  title="{Pseudowire Redundancy}",
  howpublished="RFC 6718 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6718",
  pages="1--18",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6718.txt",
  key="RFC 6718",
  abstract={This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy.  A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications.  In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Active, standby, protection, dual-homing, vpls, vpws",
  doi="10.17487/RFC6718",
  }

@misc{rfc6719,
  author="O. Gnawali and P. Levis",
  title="{The Minimum Rank with Hysteresis Objective Function}",
  howpublished="RFC 6719 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6719",
  pages="1--13",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6719.txt",
  key="RFC 6719",
  abstract={The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses.  This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes.  MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]},
  keywords="Routing Protocol for Low Power and Lossy Networks, RPL, Low Power and Lossy Networks, LLN",
  doi="10.17487/RFC6719",
  }

@misc{rfc6720,
  author="C. Pignataro and R. Asati",
  title="{The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)}",
  howpublished="RFC 6720 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6720",
  pages="1--8",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7552",
url="https://www.rfc-editor.org/rfc/rfc6720.txt",
  key="RFC 6720",
  abstract={The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]},
  keywords="GTSM, LDP",
  doi="10.17487/RFC6720",
  }

@misc{rfc6721,
  author="J. Snell",
  title="{The Atom ``deleted-entry'' Element}",
  howpublished="RFC 6721 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6721",
  pages="1--10",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6721.txt",
  key="RFC 6721",
  abstract={This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]},
  keywords="Atom Feed, Entry Documents",
  doi="10.17487/RFC6721",
  }

@misc{rfc6722,
  author="P. Hoffman",
  title="{Publishing the ``Tao of the IETF'' as a Web Page}",
  howpublished="RFC 6722 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6722",
  pages="1--3",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6722.txt",
  key="RFC 6722",
  abstract={This document describes how the ``Tao of the IETF'', which has been published as a series of RFCs in the past, is instead being published as a web page.  It also contains the procedure for publishing and editing that web page.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6722",
  }

@misc{rfc6723,
  author="L. Jin and R. Key and S. Delord and T. Nadeau and S. Boutros",
  title="{Update of the Pseudowire Control-Word Negotiation Mechanism}",
  howpublished="RFC 6723 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6723",
  pages="1--9",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8077",
url="https://www.rfc-editor.org/rfc/rfc6723.txt",
  key="RFC 6723",
  abstract={The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED.  This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]},
  keywords="control word, control word negotiation, control word renegotiation, control word negotiation mechanism, control word renegotiation mechanism",
  doi="10.17487/RFC6723",
  }

@misc{rfc6724,
  author="D. Thaler and R. Draves and A. Matsumoto and T. Chown",
  title="{Default Address Selection for Internet Protocol Version 6 (IPv6)}",
  howpublished="RFC 6724 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6724",
  pages="1--32",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6724.txt",
  key="RFC 6724",
  abstract={This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]},
  keywords="source, destination, sort, sorting",
  doi="10.17487/RFC6724",
  }

@misc{rfc6725,
  author="S. Rose",
  title="{DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates}",
  howpublished="RFC 6725 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6725",
  pages="1--5",
  year=2012,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6725.txt",
  key="RFC 6725",
  abstract={The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.  The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry.  This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6725",
  }

@misc{rfc6726,
  author="T. Paila and R. Walsh and M. Luby and V. Roca and R. Lehtonen",
  title="{FLUTE - File Delivery over Unidirectional Transport}",
  howpublished="RFC 6726 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6726",
  pages="1--46",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6726.txt",
  key="RFC 6726",
  abstract={This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks.  The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.  This document obsoletes RFC 3926. [STANDARDS-TRACK]},
  keywords="Multicast",
  doi="10.17487/RFC6726",
  }

@misc{rfc6727,
  author="T. Dietz and B. Claise and J. Quittek",
  title="{Definitions of Managed Objects for Packet Sampling}",
  howpublished="RFC 6727 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6727",
  pages="1--28",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6727.txt",
  key="RFC 6727",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes extensions to the IPFIX-SELECTOR-MIB module.  For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]},
  keywords="PSAMP, IPFIX, MIB, Sampling, Filtering, Selection",
  doi="10.17487/RFC6727",
  }

@misc{rfc6728,
  author="G. Muenz and B. Claise and P. Aitken",
  title="{Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols}",
  howpublished="RFC 6728 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6728",
  pages="1--129",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6728.txt",
  key="RFC 6728",
  abstract={This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols.  It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF).  The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG.  The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6728",
  }

@misc{rfc6729,
  author="D. Crocker and M. Kucherawy",
  title="{Indicating Email Handling States in Trace Fields}",
  howpublished="RFC 6729 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6729",
  pages="1--12",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6729.txt",
  key="RFC 6729",
  abstract={This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions.  This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]},
  keywords="Quarantine, Moderation",
  doi="10.17487/RFC6729",
  }

@misc{rfc6730,
  author="S. Krishnan and J. Halpern",
  title="{Requirements for IETF Nominations Committee Tools}",
  howpublished="RFC 6730 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6730",
  pages="1--10",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6730.txt",
  key="RFC 6730",
  abstract={This document defines the requirements for a set of tools for use by the IETF Nominations Committee.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6730",
  }

@misc{rfc6731,
  author="T. Savolainen and J. Kato and T. Lemon",
  title="{Improved Recursive DNS Server Selection for Multi-Interfaced Nodes}",
  howpublished="RFC 6731 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6731",
  pages="1--29",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6731.txt",
  key="RFC 6731",
  abstract={A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces.  A node commonly receives recursive DNS server configuration information from all connected networks.  Some of the recursive DNS servers might have information about namespaces other servers do not have.  When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use.  This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK]},
  keywords="DNS, RDNSS, interface, FQDN, selection",
  doi="10.17487/RFC6731",
  }

@misc{rfc6732,
  author="V. Kuarsingh and Y. Lee and O. Vautrin",
  title="{6to4 Provider Managed Tunnels}",
  howpublished="RFC 6732 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6732",
  pages="1--12",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7526",
url="https://www.rfc-editor.org/rfc/rfc6732.txt",
  key="RFC 6732",
  abstract={6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration.  The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation.  6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation.  This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation.  6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="6to4-PMT",
  doi="10.17487/RFC6732",
  }

@misc{rfc6733,
  author="V. Fajardo and J. Arkko and J. Loughney and G. Zorn",
  title="{Diameter Base Protocol}",
  howpublished="RFC 6733 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6733",
  pages="1--152",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7075",
url="https://www.rfc-editor.org/rfc/rfc6733.txt",
  key="RFC 6733",
  abstract={The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations.  This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications.  The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]},
  keywords="Diameter, AAA",
  doi="10.17487/RFC6733",
  }

@misc{rfc6734,
  author="G. Zorn and Q. Wu and V. Cakulev",
  title="{Diameter Attribute-Value Pairs for Cryptographic Key Transport}",
  howpublished="RFC 6734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6734",
  pages="1--7",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6734.txt",
  key="RFC 6734",
  abstract={Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material.  This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK]},
  keywords="AAA,ERP,MSK",
  doi="10.17487/RFC6734",
  }

@misc{rfc6735,
  author="K. Carlberg and T. Taylor",
  title="{Diameter Priority Attribute-Value Pairs}",
  howpublished="RFC 6735 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6735",
  pages="1--10",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6735.txt",
  key="RFC 6735",
  abstract={This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework.  The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]},
  keywords="AVP",
  doi="10.17487/RFC6735",
  }

@misc{rfc6736,
  author="F. Brockners and S. Bhandari and V. Singh and V. Fajardo",
  title="{Diameter Network Address and Port Translation Control Application}",
  howpublished="RFC 6736 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6736",
  pages="1--58",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6736.txt",
  key="RFC 6736",
  abstract={This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application.  This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion.  This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component.  These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers.  This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device.  This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint.  In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]},
  keywords="NAT control, NAT44, NAT66, CGN, BNG",
  doi="10.17487/RFC6736",
  }

@misc{rfc6737,
  author="K. Jiao and G. Zorn",
  title="{The Diameter Capabilities Update Application}",
  howpublished="RFC 6737 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6737",
  pages="1--6",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6737.txt",
  key="RFC 6737",
  abstract={This document defines a new Diameter application and associated Command Codes.  The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]},
  doi="10.17487/RFC6737",
  }

@misc{rfc6738,
  author="V. Cakulev and A. Lior and S. Mizikovsky",
  title="{Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers}",
  howpublished="RFC 6738 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6738",
  pages="1--17",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6738.txt",
  key="RFC 6738",
  abstract={The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK). Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]},
  keywords="Internet Key Exchange Protocol version 2",
  doi="10.17487/RFC6738",
  }

@misc{rfc6739,
  author="H. Schulzrinne and H. Tschofenig",
  title="{Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol}",
  howpublished="RFC 6739 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6739",
  pages="1--25",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6739.txt",
  key="RFC 6739",
  abstract={The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.},
  keywords="Location",
  doi="10.17487/RFC6739",
  }

@misc{rfc6740,
  author="RJ Atkinson and SN Bhatti",
  title="{Identifier-Locator Network Protocol (ILNP) Architectural Description}",
  howpublished="RFC 6740 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6740",
  pages="1--53",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6740.txt",
  key="RFC 6740",
  abstract={This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6740",
  }

@misc{rfc6741,
  author="RJ Atkinson and SN Bhatti",
  title="{Identifier-Locator Network Protocol (ILNP) Engineering Considerations}",
  howpublished="RFC 6741 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6741",
  pages="1--38",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6741.txt",
  key="RFC 6741",
  abstract={This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6741",
  }

@misc{rfc6742,
  author="RJ Atkinson and SN Bhatti and S. Rose",
  title="{DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)}",
  howpublished="RFC 6742 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6742",
  pages="1--20",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6742.txt",
  key="RFC 6742",
  abstract={This note describes additional optional resource records for use with the Domain Name System (DNS).  These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP).  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6742",
  }

@misc{rfc6743,
  author="RJ Atkinson and SN Bhatti",
  title="{ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)}",
  howpublished="RFC 6743 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6743",
  pages="1--12",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6743.txt",
  key="RFC 6743",
  abstract={This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP).  The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP.  This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6743",
  }

@misc{rfc6744,
  author="RJ Atkinson and SN Bhatti",
  title="{IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)}",
  howpublished="RFC 6744 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6744",
  pages="1--14",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6744.txt",
  key="RFC 6744",
  abstract={The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP.  ILNP has multiple instantiations.  This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6).  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6744",
  }

@misc{rfc6745,
  author="RJ Atkinson and SN Bhatti",
  title="{ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)}",
  howpublished="RFC 6745 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6745",
  pages="1--12",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6745.txt",
  key="RFC 6745",
  abstract={This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP).  ILNP is an experimental, evolutionary enhancement to IP.  The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6745",
  }

@misc{rfc6746,
  author="RJ Atkinson and SN Bhatti",
  title="{IPv4 Options for the Identifier-Locator Network Protocol (ILNP)}",
  howpublished="RFC 6746 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6746",
  pages="1--11",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6746.txt",
  key="RFC 6746",
  abstract={This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4).  ILNP is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6746",
  }

@misc{rfc6747,
  author="RJ Atkinson and SN Bhatti",
  title="{Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)}",
  howpublished="RFC 6747 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6747",
  pages="1--12",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6747.txt",
  key="RFC 6747",
  abstract={This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).  ILNP is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6747",
  }

@misc{rfc6748,
  author="RJ Atkinson and SN Bhatti",
  title="{Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)}",
  howpublished="RFC 6748 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6748",
  pages="1--37",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6748.txt",
  key="RFC 6748",
  abstract={This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP.  None of the functions described here is required for the use or deployment of ILNP.  Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6748",
  }

@misc{rfc6749,
  author="D. Hardt",
  title="{The OAuth 2.0 Authorization Framework}",
  howpublished="RFC 6749 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6749",
  pages="1--76",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6749.txt",
  key="RFC 6749",
  abstract={The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]},
  keywords="Client, Resource Owner, Authorization Server, Resource Server, Token Endpoint, Authorization Endpoint, Authorization Request, Authorization Grant, Protected Resource, Access Token, Refresh Token, Authorization Code, Implicit Grant, Client Identifier, Access Token Scope, Delegation",
  doi="10.17487/RFC6749",
  }

@misc{rfc6750,
  author="M. Jones and D. Hardt",
  title="{The OAuth 2.0 Authorization Framework: Bearer Token Usage}",
  howpublished="RFC 6750 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6750",
  pages="1--18",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6750.txt",
  key="RFC 6750",
  abstract={This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources.  Any party in possession of a bearer token (a ``bearer'') can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]},
  keywords="Client, Resource Owner, Authorization Server, Resource Server, Token Endpoint, Authorization Endpoint, Authorization Request, Authorization Grant, Protected Resource, Access Token, Refresh Token, Authorization Code, Implicit Grant, Client Identifier, Access Token Scope, Bearer Authorization Header, Bearer Access Token Type",
  doi="10.17487/RFC6750",
  }

@misc{rfc6751,
  author="R. Despres and B. Carpenter and D. Wing and S. Jiang",
  title="{Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)}",
  howpublished="RFC 6751 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6751",
  pages="1--33",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6751.txt",
  key="RFC 6751",
  abstract={In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity.  However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types).  6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations.  At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)).  The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Coexistence, Transition, Interworking, Tunneling, Encapsulation, Mapping, map-and-encap, Global Addressing",
  doi="10.17487/RFC6751",
  }

@misc{rfc6752,
  author="A. Kirkham",
  title="{Issues with Private IP Addressing in the Internet}",
  howpublished="RFC 6752 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6752",
  pages="1--14",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6752.txt",
  key="RFC 6752",
  abstract={The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network.  The discussion focuses on link addresses and, to a small extent, loopback addresses.  While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6752",
  }

@misc{rfc6753,
  author="J. Winterbottom and H. Tschofenig and H. Schulzrinne and M. Thomson",
  title="{A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)}",
  howpublished="RFC 6753 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6753",
  pages="1--25",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6753.txt",
  key="RFC 6753",
  abstract={This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO).  This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]},
  keywords="HELD, Dereference, lbyr, HTTP, Location, GEOPRIV",
  doi="10.17487/RFC6753",
  }

@misc{rfc6754,
  author="Y. Cai and L. Wei and H. Ou and V. Arya and S. Jethwani",
  title="{Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect}",
  howpublished="RFC 6754 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6754",
  pages="1--12",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6754.txt",
  key="RFC 6754",
  abstract={A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state.  When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path.  Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics.  This usually leads to inefficient or ineffective use of network resources.  This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs.  It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6754",
  }

@misc{rfc6755,
  author="B. Campbell and H. Tschofenig",
  title="{An IETF URN Sub-Namespace for OAuth}",
  howpublished="RFC 6755 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6755",
  pages="1--5",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6755.txt",
  key="RFC 6755",
  abstract={This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="OAuth, URN, sub-namespace, urn:ietf:params:oauth",
  doi="10.17487/RFC6755",
  }

@misc{rfc6756,
  author="S. Trowbridge and E. Lear and G. Fishman and S. Bradner",
  title="{Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines}",
  howpublished="RFC 6756 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6756",
  pages="1--16",
  year=2012,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6756.txt",
  key="RFC 6756",
  abstract={This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012). Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6756",
  }

@misc{rfc6757,
  author="S. Gundavelli and J. Korhonen and M. Grayson and K. Leung and R. Pazhyannur",
  title="{Access Network Identifier (ANI) Option for Proxy Mobile IPv6}",
  howpublished="RFC 6757 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6757",
  pages="1--19",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7563",
url="https://www.rfc-editor.org/rfc/rfc6757.txt",
  key="RFC 6757",
  abstract={The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached.  This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]},
  keywords="ANI, ANI option, Access Network Identifier option, PMIPv6 ANI option",
  doi="10.17487/RFC6757",
  }

@misc{rfc6758,
  author="A. Melnikov and K. Carlberg",
  title="{Tunneling of SMTP Message Transfer Priorities}",
  howpublished="RFC 6758 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6758",
  pages="1--11",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6758.txt",
  key="RFC 6758",
  abstract={This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Priority, MMHS",
  doi="10.17487/RFC6758",
  }

@misc{rfc6759,
  author="B. Claise and P. Aitken and N. Ben-Dvora",
  title="{Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)}",
  howpublished="RFC 6759 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6759",
  pages="1--43",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6759.txt",
  key="RFC 6759",
  abstract={This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6759",
  }

@misc{rfc6760,
  author="S. Cheshire and M. Krochmal",
  title="{Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)}",
  howpublished="RFC 6760 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6760",
  pages="1--16",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6760.txt",
  key="RFC 6760",
  abstract={One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution.  This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.},
  doi="10.17487/RFC6760",
  }

@misc{rfc6761,
  author="S. Cheshire and M. Krochmal",
  title="{Special-Use Domain Names}",
  howpublished="RFC 6761 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6761",
  pages="1--13",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6761.txt",
  key="RFC 6761",
  abstract={This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so.  It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.},
  doi="10.17487/RFC6761",
  }

@misc{rfc6762,
  author="S. Cheshire and M. Krochmal",
  title="{Multicast DNS}",
  howpublished="RFC 6762 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6762",
  pages="1--70",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6762.txt",
  key="RFC 6762",
  abstract={As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.},
  doi="10.17487/RFC6762",
  }

@misc{rfc6763,
  author="S. Cheshire and M. Krochmal",
  title="{DNS-Based Service Discovery}",
  howpublished="RFC 6763 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6763",
  pages="1--49",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6763.txt",
  key="RFC 6763",
  abstract={This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries.  This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.},
  doi="10.17487/RFC6763",
  }

@misc{rfc6764,
  author="C. Daboo",
  title="{Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)}",
  howpublished="RFC 6764 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6764",
  pages="1--14",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6764.txt",
  key="RFC 6764",
  abstract={This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.},
  keywords="SRV, iCalendar",
  doi="10.17487/RFC6764",
  }

@misc{rfc6765,
  author="E. Beili and M. Morgenstern",
  title="{xDSL Multi-Pair Bonding (G.Bond) MIB}",
  howpublished="RFC 6765 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6765",
  pages="1--73",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6765.txt",
  key="RFC 6765",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3.  The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA).  The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, aggregation, G.998, G.998.1, G.998.2, G.998.3, TDIM, IMA, EFM",
  doi="10.17487/RFC6765",
  }

@misc{rfc6766,
  author="E. Beili",
  title="{xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB}",
  howpublished="RFC 6766 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6766",
  pages="1--55",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6766.txt",
  key="RFC 6766",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, aggregation, G.998.3",
  doi="10.17487/RFC6766",
  }

@misc{rfc6767,
  author="E. Beili and M. Morgenstern",
  title="{Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB}",
  howpublished="RFC 6767 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6767",
  pages="1--53",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6767.txt",
  key="RFC 6767",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, Ethernet bonding, aggregation, 802.3ah, G.998.2",
  doi="10.17487/RFC6767",
  }

@misc{rfc6768,
  author="E. Beili",
  title="{ATM-Based xDSL Bonded Interfaces MIB}",
  howpublished="RFC 6768 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6768",
  pages="1--34",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6768.txt",
  key="RFC 6768",
  abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.},
  keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, bonding, xDSL bonding, aggregation, G.Bond, G.Bond/ATM, G.998.1, IMA, IMA+",
  doi="10.17487/RFC6768",
  }

@misc{rfc6769,
  author="R. Raszuk and J. Heitz and A. Lo and L. Zhang and X. Xu",
  title="{Simple Virtual Aggregation (S-VA)}",
  howpublished="RFC 6769 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6769",
  pages="1--8",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6769.txt",
  key="RFC 6769",
  abstract={All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB). Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix. The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="BGP, aggregation",
  doi="10.17487/RFC6769",
  }

@misc{rfc6770,
  author="G. Bertrand and E. Stephan and T. Burbridge and P. Eardley and K. Ma and G. Watson",
  title="{Use Cases for Content Delivery Network Interconnection}",
  howpublished="RFC 6770 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6770",
  pages="1--16",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6770.txt",
  key="RFC 6770",
  abstract={Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level.  This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented.  This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces.  It obsoletes RFC 3570.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="CDN, CDNI",
  doi="10.17487/RFC6770",
  }

@misc{rfc6771,
  author="L. Eggert and G. Camarillo",
  title="{Considerations for Having a Successful ``Bar BOF'' Side Meeting}",
  howpublished="RFC 6771 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6771",
  pages="1--10",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6771.txt",
  key="RFC 6771",
  abstract={New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as ``bar BOF'' sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF (``birds of a feather'' session) on a given topic. During recent IETF meetings, many such ``bar BOF'' get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings. This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term ``bar BOF'' and instead use other terms such as ``side meeting'', in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6771",
  }

@misc{rfc6772,
  author="H. Schulzrinne and H. Tschofenig and J. Cuellar and J. Polk and J. Morris and M. Thomson",
  title="{Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information}",
  howpublished="RFC 6772 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6772",
  pages="1--44",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6772.txt",
  key="RFC 6772",
  abstract={This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]},
  keywords="Authorization Policy, Location Privacy",
  doi="10.17487/RFC6772",
  }

@misc{rfc6773,
  author="T. Phelan and G. Fairhurst and C. Perkins",
  title="{DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal}",
  howpublished="RFC 6773 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6773",
  pages="1--20",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6773.txt",
  key="RFC 6773",
  abstract={This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP.  This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes.  This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]},
  keywords="DCCP, NAPT, NAT, UDP",
  doi="10.17487/RFC6773",
  }

@misc{rfc6774,
  author="R. Raszuk and R. Fernando and K. Patel and D. McPherson and K. Kumaki",
  title="{Distribution of Diverse BGP Paths}",
  howpublished="RFC 6774 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6774",
  pages="1--22",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6774.txt",
  key="RFC 6774",
  abstract={The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services. The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6774",
  }

@misc{rfc6775,
  author="Z. Shelby and S. Chakrabarti and E. Nordmark and C. Bormann",
  title="{Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}",
  howpublished="RFC 6775 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6775",
  pages="1--55",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6775.txt",
  key="RFC 6775",
  abstract={The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks.  The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6775",
  }

@misc{rfc6776,
  author="A. Clark and Q. Wu",
  title="{Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block}",
  howpublished="RFC 6776 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6776",
  pages="1--9",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6776.txt",
  key="RFC 6776",
  abstract={This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]},
  keywords="RTP Control Protocol",
  doi="10.17487/RFC6776",
  }

@misc{rfc6777,
  author="W. Sun and G. Zhang and J. Gao and G. Xie and R. Papneja",
  title="{Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks}",
  howpublished="RFC 6777 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6777",
  pages="1--29",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6777.txt",
  key="RFC 6777",
  abstract={When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner.  Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable.  The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure.  Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust.  This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]},
  keywords="Provisioning performance, Performance measurement, UNI, Bandwidth on Demand, performance evaluation, Measurement methodologies",
  doi="10.17487/RFC6777",
  }

@misc{rfc6778,
  author="R. Sparks",
  title="{Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching}",
  howpublished="RFC 6778 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6778",
  pages="1--8",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6778.txt",
  key="RFC 6778",
  abstract={The IETF makes heavy use of email lists to conduct its work.  Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities.  The current archive mechanism could also be made more efficient.  This memo captures the requirements for improved email list archiving and searching systems.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="tool",
  doi="10.17487/RFC6778",
  }

@misc{rfc6779,
  author="U. Herberg and R. Cole and I. Chakeres",
  title="{Definition of Managed Objects for the Neighborhood Discovery Protocol}",
  howpublished="RFC 6779 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6779",
  pages="1--67",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7939",
url="https://www.rfc-editor.org/rfc/rfc6779.txt",
  key="RFC 6779",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router.  The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP.  This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]},
  keywords="Network Management, Management Information base, MIB, SMIv2, Routing, Neighbor Discovery, MANET",
  doi="10.17487/RFC6779",
  }

@misc{rfc6780,
  author="L. Berger and F. Le Faucheur and A. Narayanan",
  title="{RSVP ASSOCIATION Object Extensions}",
  howpublished="RFC 6780 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6780",
  pages="1--17",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6780.txt",
  key="RFC 6780",
  abstract={The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs).  In this context, the object is used to associate recovery LSPs with the LSP they are protecting.  This object also has broader applicability as a mechanism to associate RSVP state.  This document defines how the ASSOCIATION object can be more generally applied.  This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP).  This document updates RFC 2205, RFC 3209, and RFC 3473.  It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6780",
  }

@misc{rfc6781,
  author="O. Kolkman and W. Mekking and R. Gieben",
  title="{DNSSEC Operational Practices, Version 2}",
  howpublished="RFC 6781 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6781",
  pages="1--71",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6781.txt",
  key="RFC 6781",
  abstract={This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.},
  keywords="DNSSEC, operational, key rollover",
  doi="10.17487/RFC6781",
  }

@misc{rfc6782,
  author="V. Kuarsingh and L. Howard",
  title="{Wireline Incremental IPv6}",
  howpublished="RFC 6782 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6782",
  pages="1--29",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6782.txt",
  key="RFC 6782",
  abstract={Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks.  These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out.  Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses.  The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator.  This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="transition, IPv6 transition, operator",
  doi="10.17487/RFC6782",
  }

@misc{rfc6783,
  author="J. Levine and R. Gellens",
  title="{Mailing Lists and Non-ASCII Addresses}",
  howpublished="RFC 6783 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6783",
  pages="1--9",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6783.txt",
  key="RFC 6783",
  abstract={This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses.  It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice.  This document is a product of the Internet Engineering Task Force (IETF).},
  keywords="Mail, internationalization, mailing lists",
  doi="10.17487/RFC6783",
  }

@misc{rfc6784,
  author="S. Sakane and M. Ishiyama",
  title="{Kerberos Options for DHCPv6}",
  howpublished="RFC 6784 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6784",
  pages="1--12",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6784.txt",
  key="RFC 6784",
  abstract={This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]},
  keywords="security, dhcpv6",
  doi="10.17487/RFC6784",
  }

@misc{rfc6785,
  author="B. Leiba",
  title="{Support for Internet Message Access Protocol (IMAP) Events in Sieve}",
  howpublished="RFC 6785 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6785",
  pages="1--20",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6785.txt",
  key="RFC 6785",
  abstract={Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message.  As defined in the base specification, it plugs into mail delivery.  This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).  Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]},
  keywords="email, filtering",
  doi="10.17487/RFC6785",
  }

@misc{rfc6786,
  author="A. Yegin and R. Cragie",
  title="{Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs}",
  howpublished="RFC 6786 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6786",
  pages="1--11",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6786.txt",
  key="RFC 6786",
  abstract={This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6786",
  }

@misc{rfc6787,
  author="D. Burnett and S. Shanmugham",
  title="{Media Resource Control Protocol Version 2 (MRCPv2)}",
  howpublished="RFC 6787 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6787",
  pages="1--224",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6787.txt",
  key="RFC 6787",
  abstract={The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network.  MRCPv2 is not a ``stand-alone'' protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities.  It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server.  Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]},
  keywords="mrcp, speechsc, asr, tts, speech services, speech recognition, speech synthesis, nlsml, speaker authentication, speaker verification, speaker identification",
  doi="10.17487/RFC6787",
  }

@misc{rfc6788,
  author="S. Krishnan and A. Kavanagh and B. Varga and S. Ooghe and E. Nordmark",
  title="{The Line-Identification Option}",
  howpublished="RFC 6788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6788",
  pages="1--17",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6788.txt",
  key="RFC 6788",
  abstract={In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.  This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages.  The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6788",
  }

@misc{rfc6789,
  author="B. Briscoe and R. Woundy and A. Cooper",
  title="{Congestion Exposure (ConEx) Concepts and Use Cases}",
  howpublished="RFC 6789 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6789",
  pages="1--17",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6789.txt",
  key="RFC 6789",
  abstract={This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol.  It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes.  Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Congestion Signaling, Traffic Management",
  doi="10.17487/RFC6789",
  }

@misc{rfc6790,
  author="K. Kompella and J. Drake and S. Amante and W. Henderickx and L. Yong",
  title="{The Use of Entropy Labels in MPLS Forwarding}",
  howpublished="RFC 6790 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6790",
  pages="1--25",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7274, 7447, 8012",
url="https://www.rfc-editor.org/rfc/rfc6790.txt",
  key="RFC 6790",
  abstract={Load balancing is a powerful tool for engineering traffic across a network.  This memo suggests ways of improving load balancing across MPLS networks using the concept of ``entropy labels''.  It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications.  This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]},
  keywords="entropy, hash, ecmp, load balancing",
  doi="10.17487/RFC6790",
  }

@misc{rfc6791,
  author="X. Li and C. Bao and D. Wing and R. Vaithianathan and G. Huston",
  title="{Stateless Source Address Mapping for ICMPv6 Packets}",
  howpublished="RFC 6791 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6791",
  pages="1--6",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6791.txt",
  key="RFC 6791",
  abstract={A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source.  These packets should be passed across the translator as ICMP packets directed to the IPv4 destination.  This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]},
  keywords="IP/ICMP Translation Algorithm, IPv4-translatable IPv6 addresses, ICMPv6, traceroute",
  doi="10.17487/RFC6791",
  }

@misc{rfc6792,
  author="Q. Wu and G. Hunt and P. Arden",
  title="{Guidelines for Use of the RTP Monitoring Framework}",
  howpublished="RFC 6792 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6792",
  pages="1--17",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6792.txt",
  key="RFC 6792",
  abstract={This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality.  In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application.  Applications may then ``mix and match'' to create a set of blocks that cover their set of concerns.  Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Real Time Control Protocol",
  doi="10.17487/RFC6792",
  }

@misc{rfc6793,
  author="Q. Vohra and E. Chen",
  title="{BGP Support for Four-Octet Autonomous System (AS) Number Space}",
  howpublished="RFC 6793 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6793",
  pages="1--12",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6793.txt",
  key="RFC 6793",
  abstract={The Autonomous System number is encoded as a two-octet entity in the base BGP specification.  This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities.  This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]},
  keywords="autonomous system, border gateway protocol",
  doi="10.17487/RFC6793",
  }

@misc{rfc6794,
  author="V. Hilt and G. Camarillo and J. Rosenberg",
  title="{A Framework for Session Initiation Protocol (SIP) Session Policies}",
  howpublished="RFC 6794 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6794",
  pages="1--36",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6794.txt",
  key="RFC 6794",
  abstract={Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features.  This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used.  It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6794",
  }

@misc{rfc6795,
  author="V. Hilt and G. Camarillo",
  title="{A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies}",
  howpublished="RFC 6795 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6795",
  pages="1--18",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6795.txt",
  key="RFC 6795",
  abstract={This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies.  This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6795",
  }

@misc{rfc6796,
  author="V. Hilt and G. Camarillo and J. Rosenberg and D. Worley",
  title="{A User Agent Profile Data Set for Media Policy}",
  howpublished="RFC 6796 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6796",
  pages="1--43",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6796.txt",
  key="RFC 6796",
  abstract={This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions.  Examples for media properties are the codecs or media types used in the session.  This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]},
  keywords="SIP, Session Policy, Data Set",
  doi="10.17487/RFC6796",
  }

@misc{rfc6797,
  author="J. Hodges and C. Jackson and A. Barth",
  title="{HTTP Strict Transport Security (HSTS)}",
  howpublished="RFC 6797 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6797",
  pages="1--46",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6797.txt",
  key="RFC 6797",
  abstract={This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.  This overall policy is referred to as HTTP Strict Transport Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]},
  keywords="HTTPS, TLS, SSL, ForceHTTPS, man-in-the-middle, MITM, certificate error, certificate verification, security policy, secure transport, IDNA-Canonicalization",
  doi="10.17487/RFC6797",
  }

@misc{rfc6798,
  author="A. Clark and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting}",
  howpublished="RFC 6798 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6798",
  pages="1--13",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6798.txt",
  key="RFC 6798",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6798",
  }

@misc{rfc6801,
  author="U. Kozat and A. Begen",
  title="{Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework}",
  howpublished="RFC 6801 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6801",
  pages="1--11",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6801.txt",
  key="RFC 6801",
  abstract={This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework.  The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6801",
  }

@misc{rfc6802,
  author="S. Baillargeon and C. Flinta and A. Johnsson",
  title="{Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets}",
  howpublished="RFC 6802 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6802",
  pages="1--15",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6802.txt",
  key="RFC 6802",
  abstract={This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP).  Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="available capacity, rate, train, interval, padding, buffer, test session",
  doi="10.17487/RFC6802",
  }

@misc{rfc6803,
  author="G. Hudson",
  title="{Camellia Encryption for Kerberos 5}",
  howpublished="RFC 6803 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6803",
  pages="1--13",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6803.txt",
  key="RFC 6803",
  abstract={This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961.  The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Camellia, Kerberos",
  doi="10.17487/RFC6803",
  }

@misc{rfc6804,
  author="B. Manning",
  title="{DISCOVER: Supporting Multicast DNS Queries}",
  howpublished="RFC 6804 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6804",
  pages="1--9",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6804.txt",
  key="RFC 6804",
  abstract={This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery.  This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project.  This project is no longer active and there are no current plans to restart it.  TBDS was the first known use of multicast transport for DNS.  A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.  This document defines a Historic Document for the Internet community.},
  doi="10.17487/RFC6804",
  }

@misc{rfc6805,
  author="D. King and A. Farrel",
  title="{The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS}",
  howpublished="RFC 6805 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6805",
  pages="1--33",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6805.txt",
  key="RFC 6805",
  abstract={Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6805",
  }

@misc{rfc6806,
  author="S. Hartman and K. Raeburn and L. Zhu",
  title="{Kerberos Principal Name Canonicalization and Cross-Realm Referrals}",
  howpublished="RFC 6806 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6806",
  pages="1--19",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6806.txt",
  key="RFC 6806",
  abstract={This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services.  The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path.  The clients will use this referral information to reach the realm of the target principal and then receive the ticket.  This memo also provides a mechanism for verifying that a request has not been tampered with in transit.  This memo updates RFC 4120. [STANDARDS-TRACK]},
  keywords="authentication, security protocols, identity",
  doi="10.17487/RFC6806",
  }

@misc{rfc6807,
  author="D. Farinacci and G. Shepherd and S. Venaas and Y. Cai",
  title="{Population Count Extensions to Protocol Independent Multicast (PIM)}",
  howpublished="RFC 6807 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6807",
  pages="1--15",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6807.txt",
  key="RFC 6807",
  abstract={This specification defines a method for providing multicast distribution-tree accounting data.  Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6807",
  }

@misc{rfc6808,
  author="L. Ciavattone and R. Geib and A. Morton and M. Wieser",
  title="{Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track}",
  howpublished="RFC 6808 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6808",
  pages="1--29",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6808.txt",
  key="RFC 6808",
  abstract={This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576.  Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended.  Two completely independent implementations have been tested against the key specifications of RFC 2679.  This memo also provides direct input for development of a revision of RFC 2679.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="One-way Delay, IP Performance Metrics, IPPM",
  doi="10.17487/RFC6808",
  }

@misc{rfc6809,
  author="C. Holmberg and I. Sedlacek and H. Kaplan",
  title="{Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6809 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6809",
  pages="1--19",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6809.txt",
  key="RFC 6809",
  abstract={This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. This specification also defines feature-capability indicators and creates a new IANA registry, ``Proxy-Feature Feature-Capability Indicator Trees'', for registering feature-capability indicators. [STANDARDS-TRACK]},
  keywords="proxy, feature, feature tag, feature-capability indicator, Feature-Caps, capability",
  doi="10.17487/RFC6809",
  }

@misc{rfc6810,
  author="R. Bush and R. Austein",
  title="{The Resource Public Key Infrastructure (RPKI) to Router Protocol}",
  howpublished="RFC 6810 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6810",
  pages="1--27",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6810.txt",
  key="RFC 6810",
  abstract={In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache.  This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6810",
  }

@misc{rfc6811,
  author="P. Mohapatra and J. Scudder and D. Ward and R. Bush and R. Austein",
  title="{BGP Prefix Origin Validation}",
  howpublished="RFC 6811 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6811",
  pages="1--10",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6811.txt",
  key="RFC 6811",
  abstract={To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes.  More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS\_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so.  This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]},
  keywords="SIDR, security",
  doi="10.17487/RFC6811",
  }

@misc{rfc6812,
  author="M. Chiba and A. Clemm and S. Medley and J. Salowey and S. Thombare and E. Yedavalli",
  title="{Cisco Service-Level Assurance Protocol}",
  howpublished="RFC 6812 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6812",
  pages="1--27",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6812.txt",
  key="RFC 6812",
  abstract={Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed.  The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss.  This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Cisco's SLA Protocol",
  doi="10.17487/RFC6812",
  }

@misc{rfc6813,
  author="J. Salowey and S. Hanna",
  title="{The Network Endpoint Assessment (NEA) Asokan Attack Analysis}",
  howpublished="RFC 6813 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6813",
  pages="1--8",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6813.txt",
  key="RFC 6813",
  abstract={The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack.  This document describes the attack and countermeasures that may be mounted.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="Man-in-the-Middle, MITM, Security, Endpoint, Posture, Protocol, Forwarding, TNC, Channel, Binding, Cryptographic, Countermeasure",
  doi="10.17487/RFC6813",
  }

@misc{rfc6814,
  author="C. Pignataro and F. Gont",
  title="{Formally Deprecating Some IPv4 Options}",
  howpublished="RFC 6814 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6814",
  pages="1--6",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6814.txt",
  key="RFC 6814",
  abstract={A number of IPv4 options have become obsolete in practice, but have never been formally deprecated.  This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry.  Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6814",
  }

@misc{rfc6815,
  author="S. Bradner and K. Dubray and J. McQuaid and A. Morton",
  title="{Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful}",
  howpublished="RFC 6815 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6815",
  pages="1--11",
  year=2012,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6815.txt",
  key="RFC 6815",
  abstract={The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present.  The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity.  Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods.  This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="testing, performance",
  doi="10.17487/RFC6815",
  }

@misc{rfc6816,
  author="V. Roca and M. Cunche and J. Lacan",
  title="{Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME}",
  howpublished="RFC 6816 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6816",
  pages="1--24",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6816.txt",
  key="RFC 6816",
  abstract={This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME.  These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs.  LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance.  They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.},
  keywords="Forward Error Correction, LDPC-Staircase",
  doi="10.17487/RFC6816",
  }

@misc{rfc6817,
  author="S. Shalunov and G. Hazel and J. Iyengar and M. Kuehlewind",
  title="{Low Extra Delay Background Transport (LEDBAT)}",
  howpublished="RFC 6817 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6817",
  pages="1--25",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6817.txt",
  key="RFC 6817",
  abstract={Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path.  LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network.  LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows.  This document defines an Experimental Protocol for the Internet community.},
  keywords="Congestion control, delay-based, scavenger, P2P",
  doi="10.17487/RFC6817",
  }

@misc{rfc6818,
  author="P. Yee",
  title="{Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 6818 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6818",
  pages="1--8",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6818.txt",
  key="RFC 6818",
  abstract={This document updates RFC 5280, the ``Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile''.  This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII.  This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6818",
  }

@misc{rfc6819,
  author="T. Lodderstedt and M. McGloin and P. Hunt",
  title="{OAuth 2.0 Threat Model and Security Considerations}",
  howpublished="RFC 6819 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6819",
  pages="1--71",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6819.txt",
  key="RFC 6819",
  abstract={This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="authorization, authentication, token, counter-measures, HTTP, REST",
  doi="10.17487/RFC6819",
  }

@misc{rfc6820,
  author="T. Narten and M. Karir and I. Foo",
  title="{Address Resolution Problems in Large Data Center Networks}",
  howpublished="RFC 6820 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6820",
  pages="1--17",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6820.txt",
  key="RFC 6820",
  abstract={This document examines address resolution issues related to the scaling of data centers with a very large number of hosts.  The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center.  This document is a product of the Internet Engineering Task Force (IETF).},
  keywords="ARMD, data center, ARP, ND, Neighbor Discovery",
  doi="10.17487/RFC6820",
  }

@misc{rfc6821,
  author="E. Marocco and A. Fusco and I. Rimac and V. Gurbani",
  title="{Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality}",
  howpublished="RFC 6821 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6821",
  pages="1--16",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6821.txt",
  key="RFC 6821",
  abstract={Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth. This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).},
  keywords="cross-domain traffic, bandwidth, transit traffic, peer-to-peer caching, peer-to-peer swarm",
  doi="10.17487/RFC6821",
  }

@misc{rfc6822,
  author="S. Previdi and L. Ginsberg and M. Shand and A. Roy and D. Ward",
  title="{IS-IS Multi-Instance}",
  howpublished="RFC 6822 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6822",
  pages="1--14",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6822.txt",
  key="RFC 6822",
  abstract={This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.},
  keywords="intermediate system to intermediate system",
  doi="10.17487/RFC6822",
  }

@misc{rfc6823,
  author="L. Ginsberg and S. Previdi and M. Shand",
  title="{Advertising Generic Information in IS-IS}",
  howpublished="RFC 6823 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6823",
  pages="1--11",
  year=2012,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6823.txt",
  key="RFC 6823",
  abstract={This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.},
  keywords="intermediate system to intermediate system",
  doi="10.17487/RFC6823",
  }

@misc{rfc6824,
  author="A. Ford and C. Raiciu and M. Handley and O. Bonaventure",
  title="{TCP Extensions for Multipath Operation with Multiple Addresses}",
  howpublished="RFC 6824 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6824",
  pages="1--64",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6824.txt",
  key="RFC 6824",
  abstract={TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6824",
  }

@misc{rfc6825,
  author="M. Miyazawa and T. Otani and K. Kumaki and T. Nadeau",
  title="{Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS}",
  howpublished="RFC 6825 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6825",
  pages="1--40",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6825.txt",
  key="RFC 6825",
  abstract={This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]},
  keywords="TED-MIB, ted, mib",
  doi="10.17487/RFC6825",
  }

@misc{rfc6826,
  author="IJ. Wijnands and T. Eckert and N. Leymann and M. Napierala",
  title="{Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths}",
  howpublished="RFC 6826 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6826",
  pages="1--12",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7438",
url="https://www.rfc-editor.org/rfc/rfc6826.txt",
  key="RFC 6826",
  abstract={Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created.  The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP.  When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages.  When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain.  The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP.  This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6826",
  }

@misc{rfc6827,
  author="A. Malis and A. Lindem and D. Papadimitriou",
  title="{Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols}",
  howpublished="RFC 6827 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6827",
  pages="1--30",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6827.txt",
  key="RFC 6827",
  abstract={The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6827",
  }

@misc{rfc6828,
  author="J. Xia",
  title="{Content Splicing for RTP Sessions}",
  howpublished="RFC 6828 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6828",
  pages="1--17",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6828.txt",
  key="RFC 6828",
  abstract={Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement. This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6828",
  }

@misc{rfc6829,
  author="M. Chen and P. Pan and C. Pignataro and R. Asati",
  title="{Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6}",
  howpublished="RFC 6829 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6829",
  pages="1--8",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8029",
url="https://www.rfc-editor.org/rfc/rfc6829.txt",
  key="RFC 6829",
  abstract={The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6829",
  }

@misc{rfc6830,
  author="D. Farinacci and V. Fuller and D. Meyer and D. Lewis",
  title="{The Locator/ID Separation Protocol (LISP)}",
  howpublished="RFC 6830 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6830",
  pages="1--75",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8113",
url="https://www.rfc-editor.org/rfc/rfc6830.txt",
  key="RFC 6830",
  abstract={This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the ``core'' of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a ``flag day'', and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6830",
  }

@misc{rfc6831,
  author="D. Farinacci and D. Meyer and J. Zwiebel and S. Venaas",
  title="{The Locator/ID Separation Protocol (LISP) for Multicast Environments}",
  howpublished="RFC 6831 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6831",
  pages="1--28",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6831.txt",
  key="RFC 6831",
  abstract={This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6831",
  }

@misc{rfc6832,
  author="D. Lewis and D. Meyer and D. Farinacci and V. Fuller",
  title="{Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites}",
  howpublished="RFC 6832 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6832",
  pages="1--19",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6832.txt",
  key="RFC 6832",
  abstract={This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP.  A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive.  While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites.  This document introduces three such mechanisms.  The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts.  Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs.  Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6832",
  }

@misc{rfc6833,
  author="V. Fuller and D. Farinacci",
  title="{Locator/ID Separation Protocol (LISP) Map-Server Interface}",
  howpublished="RFC 6833 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6833",
  pages="1--13",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6833.txt",
  key="RFC 6833",
  abstract={This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified ``front end'' for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the ``edge'' of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6833",
  }

@misc{rfc6834,
  author="L. Iannone and D. Saucez and O. Bonaventure",
  title="{Locator/ID Separation Protocol (LISP) Map-Versioning}",
  howpublished="RFC 6834 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6834",
  pages="1--21",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6834.txt",
  key="RFC 6834",
  abstract={This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets.  The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets.  LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets.  The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6834",
  }

@misc{rfc6835,
  author="D. Farinacci and D. Meyer",
  title="{The Locator/ID Separation Protocol Internet Groper (LIG)}",
  howpublished="RFC 6835 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6835",
  pages="1--12",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6835.txt",
  key="RFC 6835",
  abstract={A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database.  This document describes how it works.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6835",
  }

@misc{rfc6836,
  author="V. Fuller and D. Farinacci and D. Meyer and D. Lewis",
  title="{Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)}",
  howpublished="RFC 6836 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6836",
  pages="1--25",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6836.txt",
  key="RFC 6836",
  abstract={This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID).  The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID.  Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE).  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6836",
  }

@misc{rfc6837,
  author="E. Lear",
  title="{NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database}",
  howpublished="RFC 6837 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6837",
  pages="1--31",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6837.txt",
  key="RFC 6837",
  abstract={The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another.  This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner.  Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6837",
  }

@misc{rfc6838,
  author="N. Freed and J. Klensin and T. Hansen",
  title="{Media Type Specifications and Registration Procedures}",
  howpublished="RFC 6838 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6838",
  pages="1--32",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6838.txt",
  key="RFC 6838",
  abstract={This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.},
  doi="10.17487/RFC6838",
  }

@misc{rfc6839,
  author="T. Hansen and A. Melnikov",
  title="{Additional Media Type Structured Syntax Suffixes}",
  howpublished="RFC 6839 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6839",
  pages="1--14",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7303",
url="https://www.rfc-editor.org/rfc/rfc6839.txt",
  key="RFC 6839",
  abstract={A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name.  This document defines several structured syntax suffixes for use with media type registrations.  In particular, it defines and registers the ``+json'', ``+ber'', ``+der'', ``+fastinfoset'', ``+wbxml'' and ``+zip'' structured syntax suffixes, and provides a media type structured syntax suffix registration form for the ``+xml'' structured syntax suffix.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="structured syntax suffix, media type",
  doi="10.17487/RFC6839",
  }

@misc{rfc6840,
  author="S. Weiler and D. Blacka",
  title="{Clarifications and Implementation Notes for DNS Security (DNSSEC)}",
  howpublished="RFC 6840 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6840",
  pages="1--21",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6840.txt",
  key="RFC 6840",
  abstract={This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.},
  keywords="EAP, AAA, reconnect",
  doi="10.17487/RFC6840",
  }

@misc{rfc6841,
  author="F. Ljunggren and AM. Eklund Lowinder and T. Okubo",
  title="{A Framework for DNSSEC Policies and DNSSEC Practice Statements}",
  howpublished="RFC 6841 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6841",
  pages="1--27",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6841.txt",
  key="RFC 6841",
  abstract={This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="DNS, DNSSEC, DP, DPS",
  doi="10.17487/RFC6841",
  }

@misc{rfc6842,
  author="N. Swamy and G. Halwasia and P. Jhingran",
  title="{Client Identifier Option in DHCP Server Replies}",
  howpublished="RFC 6842 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6842",
  pages="1--5",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6842.txt",
  key="RFC 6842",
  abstract={This document updates RFC 2131 ``Dynamic Host Configuration Protocol'' by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6842",
  }

@misc{rfc6843,
  author="A. Clark and K. Gross and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting}",
  howpublished="RFC 6843 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6843",
  pages="1--9",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6843.txt",
  key="RFC 6843",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]},
  keywords="Round Trip Delay, End System Delay",
  doi="10.17487/RFC6843",
  }

@misc{rfc6844,
  author="P. Hallam-Baker and R. Stradling",
  title="{DNS Certification Authority Authorization (CAA) Resource Record}",
  howpublished="RFC 6844 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6844",
  pages="1--18",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6844.txt",
  key="RFC 6844",
  abstract={The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain.  CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.  This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]},
  keywords="DNS, DNSSEC, PKIX",
  doi="10.17487/RFC6844",
  }

@misc{rfc6845,
  author="N. Sheth and L. Wang and J. Zhang",
  title="{OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type}",
  howpublished="RFC 6845 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6845",
  pages="1--9",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6845.txt",
  key="RFC 6845",
  abstract={This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]},
  keywords="OSPF, P2MP, Broadcast, Interface",
  doi="10.17487/RFC6845",
  }

@misc{rfc6846,
  author="G. Pelletier and K. Sandlund and L-E. Jonsson and M. West",
  title="{RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)}",
  howpublished="RFC 6846 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6846",
  pages="1--96",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6846.txt",
  key="RFC 6846",
  abstract={This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6846",
  }

@misc{rfc6847,
  author="D. Melman and T. Mizrahi and D. {Eastlake 3rd}",
  title="{Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)}",
  howpublished="RFC 6847 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6847",
  pages="1--13",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6847.txt",
  key="RFC 6847",
  abstract={Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment.  While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop.  This document describes an architecture for the integrated deployment of these two protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="FCoE, FCRB, TRILL, RBridge",
  doi="10.17487/RFC6847",
  }

@misc{rfc6848,
  author="J. Winterbottom and M. Thomson and R. Barnes and B. Rosen and R. George",
  title="{Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)}",
  howpublished="RFC 6848 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6848",
  pages="1--21",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6848.txt",
  key="RFC 6848",
  abstract={New fields are occasionally added to civic addresses.  A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described.  A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation.  Initial extensions for some new elements are also defined.  The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]},
  keywords="Extension, Local, Civic, Location, GEOPRIV",
  doi="10.17487/RFC6848",
  }

@misc{rfc6849,
  author="H. Kaplan and K. Hedayat and N. Venna and P. Jones and N. Stratton",
  title="{An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback}",
  howpublished="RFC 6849 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6849",
  pages="1--33",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6849.txt",
  key="RFC 6849",
  abstract={The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance.  In particular, media delivery is an area that needs attention.  One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter.  This is typically referred to as ``active monitoring'' of services.  Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service.  Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service.  The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter.  Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.},
  keywords="multimedia, audio, video, RTCP, diagnostic, voip",
  doi="10.17487/RFC6849",
  }

@misc{rfc6850,
  author="A. Rijhsinghani and K. Zebrose",
  title="{Definitions of Managed Objects for Routing Bridges (RBridges)}",
  howpublished="RFC 6850 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6850",
  pages="1--59",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6850.txt",
  key="RFC 6850",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6850",
  }

@misc{rfc6851,
  author="A. Gulbrandsen and N. Freed",
  title="{Internet Message Access Protocol (IMAP) - MOVE Extension}",
  howpublished="RFC 6851 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6851",
  pages="1--8",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6851.txt",
  key="RFC 6851",
  abstract={This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]},
  keywords="IMAP",
  doi="10.17487/RFC6851",
  }

@misc{rfc6852,
  author="R. Housley and S. Mills and J. Jaffe and B. Aboba and L. St.Amour",
  title="{Affirmation of the Modern Paradigm for Standards}",
  howpublished="RFC 6852 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6852",
  pages="1--5",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6852.txt",
  key="RFC 6852",
  abstract={On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards.  These principles have become known as the ``OpenStand'' principles.  This document contains the text of the affirmation that was signed.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6852",
  }

@misc{rfc6853,
  author="J. Brzozowski and J. Tremblay and J. Chen and T. Mrugalski",
  title="{DHCPv6 Redundancy Deployment Considerations}",
  howpublished="RFC 6853 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6853",
  pages="1--16",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6853.txt",
  key="RFC 6853",
  abstract={This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6.  In particular, it discusses the provision of semi-redundant DHCPv6 services.},
  keywords="DHCPv6, Redundancy, Deployment Considerations",
  doi="10.17487/RFC6853",
  }

@misc{rfc6854,
  author="B. Leiba",
  title="{Update to Internet Message Format to Allow Group Syntax in the ``From:'' and ``Sender:'' Header Fields}",
  howpublished="RFC 6854 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6854",
  pages="1--9",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6854.txt",
  key="RFC 6854",
  abstract={The Internet Message Format (RFC 5322) allows ``group'' syntax in some email header fields, such as ``To:'' and ``CC:'', but not in ``From:'' or ``Sender:''.  This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in ``Resent-From:'' and ``Resent-Sender:'', in certain situations.},
  doi="10.17487/RFC6854",
  }

@misc{rfc6855,
  author="P. Resnick and C. Newman and S. Shen",
  title="{IMAP Support for UTF-8}",
  howpublished="RFC 6855 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6855",
  pages="1--12",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6855.txt",
  key="RFC 6855",
  abstract={This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.  This specification replaces RFC 5738.},
  keywords="IMAP, IDNA",
  doi="10.17487/RFC6855",
  }

@misc{rfc6856,
  author="R. Gellens and C. Newman and J. Yao and K. Fujiwara",
  title="{Post Office Protocol Version 3 (POP3) Support for UTF-8}",
  howpublished="RFC 6856 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6856",
  pages="1--14",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6856.txt",
  key="RFC 6856",
  abstract={This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.},
  keywords="internationalized",
  doi="10.17487/RFC6856",
  }

@misc{rfc6857,
  author="K. Fujiwara",
  title="{Post-Delivery Message Downgrading for Internationalized Email Messages}",
  howpublished="RFC 6857 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6857",
  pages="1--20",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6857.txt",
  key="RFC 6857",
  abstract={The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields.  Upgraded POP and IMAP servers support internationalized messages.  If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message.  To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format.  As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.},
  keywords="EAI, Email Address Internationalization, Downgrade, MAIL",
  doi="10.17487/RFC6857",
  }

@misc{rfc6858,
  author="A. Gulbrandsen",
  title="{Simplified POP and IMAP Downgrading for Internationalized Email}",
  howpublished="RFC 6858 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6858",
  pages="1--6",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6858.txt",
  key="RFC 6858",
  abstract={This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients.  The specification is simple, easy to implement, and provides only rudimentary results.},
  doi="10.17487/RFC6858",
  }

@misc{rfc6859,
  author="B. Leiba",
  title="{Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership}",
  howpublished="RFC 6859 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6859",
  pages="1--3",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7437",
url="https://www.rfc-editor.org/rfc/rfc6859.txt",
  key="RFC 6859",
  abstract={RFC 3777 specifies that ``sitting members'' of the IAB and IESG ``may not volunteer to serve on the nominating committee''.  Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777.  There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as ``sitting members''.  This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC.  This memo documents an Internet Best Current Practice.},
  keywords="nomcom, IAOC",
  doi="10.17487/RFC6859",
  }

@misc{rfc6860,
  author="Y. Yang and A. Retana and A. Roy",
  title="{Hiding Transit-Only Networks in OSPF}",
  howpublished="RFC 6860 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6860",
  pages="1--13",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6860.txt",
  key="RFC 6860",
  abstract={A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks. In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2. This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6860",
  }

@misc{rfc6861,
  author="I. Dzmanashvili",
  title="{The ``create-form'' and ``edit-form'' Link Relations}",
  howpublished="RFC 6861 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6861",
  pages="1--6",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6861.txt",
  key="RFC 6861",
  abstract={RFC 5988 standardized a means of indicating the relationships between resources on the Web.  This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6861",
  }

@misc{rfc6862,
  author="G. Lebovitz and M. Bhatia and B. Weis",
  title="{Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements}",
  howpublished="RFC 6862 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6862",
  pages="1--26",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6862.txt",
  key="RFC 6862",
  abstract={Different routing protocols employ different mechanisms for securing protocol packets on the wire.  While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated.  The ``Keying and Authentication for Routing Protocols'' (KARP) effort aims to overhaul and improve these mechanisms.  This document does not contain protocol specifications.  Instead, it defines the areas where protocol specification work is needed.  This document is a companion document to RFC 6518, ``Keying and Authentication for Routing Protocols (KARP) Design Guidelines''; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.},
  doi="10.17487/RFC6862",
  }

@misc{rfc6863,
  author="S. Hartman and D. Zhang",
  title="{Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide}",
  howpublished="RFC 6863 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6863",
  pages="1--11",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6863.txt",
  key="RFC 6863",
  abstract={This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the ``Keying and Authentication for Routing Protocols (KARP) Design Guidelines'' (RFC 6518).  Key components of solutions to gaps identified in this document are already underway.},
  doi="10.17487/RFC6863",
  }

@misc{rfc6864,
  author="J. Touch",
  title="{Updated Specification of the IPv4 ID Field}",
  howpublished="RFC 6864 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6864",
  pages="1--19",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6864.txt",
  key="RFC 6864",
  abstract={The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple.  If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes.  Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification.  This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented.  It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]},
  doi="10.17487/RFC6864",
  }

@misc{rfc6865,
  author="V. Roca and M. Cunche and J. Lacan and A. Bouabdallah and K. Matsuzono",
  title="{Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME}",
  howpublished="RFC 6865 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6865",
  pages="1--23",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6865.txt",
  key="RFC 6865",
  abstract={This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME.  The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding.  However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.},
  keywords="Forward Error Correction, Reed-Solomon",
  doi="10.17487/RFC6865",
  }

@misc{rfc6866,
  author="B. Carpenter and S. Jiang",
  title="{Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks}",
  howpublished="RFC 6866 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6866",
  pages="1--11",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6866.txt",
  key="RFC 6866",
  abstract={This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.},
  doi="10.17487/RFC6866",
  }

@misc{rfc6867,
  author="Y. Nir and Q. Wu",
  title="{An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)}",
  howpublished="RFC 6867 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6867",
  pages="1--9",
  year=2013,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6867.txt",
  key="RFC 6867",
  abstract={This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996.  This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.  This document defines an Experimental Protocol for the Internet community.},
  doi="10.17487/RFC6867",
  }

@misc{rfc6868,
  author="C. Daboo",
  title="{Parameter Value Encoding in iCalendar and vCard}",
  howpublished="RFC 6868 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6868",
  pages="1--7",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6868.txt",
  key="RFC 6868",
  abstract={This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.},
  keywords="calendar, contact",
  doi="10.17487/RFC6868",
  }

@misc{rfc6869,
  author="G. Salgueiro and J. Clarke and P. Saint-Andre",
  title="{vCard KIND:device}",
  howpublished="RFC 6869 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6869",
  pages="1--9",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6869.txt",
  key="RFC 6869",
  abstract={This document defines a value of ``device'' for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]},
  keywords="vCard",
  doi="10.17487/RFC6869",
  }

@misc{rfc6870,
  author="P. Muley and M. Aissaoui",
  title="{Pseudowire Preferential Forwarding Status Bit}",
  howpublished="RFC 6870 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6870",
  pages="1--35",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7771",
url="https://www.rfc-editor.org/rfc/rfc6870.txt",
  key="RFC 6870",
  abstract={This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.},
  keywords="PW redundancy, active PW, standby PW, primary PW, secondary PW, PW precedence",
  doi="10.17487/RFC6870",
  }

@misc{rfc6871,
  author="R. Gilman and R. Even and F. Andreasen",
  title="{Session Description Protocol (SDP) Media Capabilities Negotiation}",
  howpublished="RFC 6871 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6871",
  pages="1--55",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6871.txt",
  key="RFC 6871",
  abstract={Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939.},
  keywords="Session Capabilities, Latent Configurations, Media Format Capability",
  doi="10.17487/RFC6871",
  }

@misc{rfc6872,
  author="V. Gurbani and E. Burger and T. Anjali and H. Abdelnur and O. Festor",
  title="{The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model}",
  howpublished="RFC 6872 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6872",
  pages="1--39",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6872.txt",
  key="RFC 6872",
  abstract={Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format.  The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends.  Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system.  The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection.  This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.},
  keywords="logging, analytics, information model",
  doi="10.17487/RFC6872",
  }

@misc{rfc6873,
  author="G. Salgueiro and V. Gurbani and A. B. Roach",
  title="{Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)}",
  howpublished="RFC 6873 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6873",
  pages="1--28",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7355",
url="https://www.rfc-editor.org/rfc/rfc6873.txt",
  key="RFC 6873",
  abstract={The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers.  This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid.  This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation.  This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.},
  keywords="SIPCLF",
  doi="10.17487/RFC6873",
  }

@misc{rfc6874,
  author="B. Carpenter and S. Cheshire and R. Hinden",
  title="{Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers}",
  howpublished="RFC 6874 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6874",
  pages="1--10",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6874.txt",
  key="RFC 6874",
  abstract={This document describes how the zone identifier of an IPv6 scoped address, defined as <zone\_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address.  It updates the URI Generic Syntax specification (RFC 3986) accordingly.},
  doi="10.17487/RFC6874",
  }

@misc{rfc6875,
  author="S. Kamei and T. Momose and T. Inoue and T. Nishitani",
  title="{The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan}",
  howpublished="RFC 6875 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6875",
  pages="1--18",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6875.txt",
  key="RFC 6875",
  abstract={This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic.  These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure.  Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.},
  keywords="overlay network, content delivery network, peer-to-peer, traffic engineering, experiments in Japan",
  doi="10.17487/RFC6875",
  }

@misc{rfc6876,
  author="P. Sangster and N. Cam-Winget and J. Salowey",
  title="{A Posture Transport Protocol over TLS (PT-TLS)}",
  howpublished="RFC 6876 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6876",
  pages="1--44",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6876.txt",
  key="RFC 6876",
  abstract={This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol.  The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.},
  keywords="Network Endpoint Assessment, NEA",
  doi="10.17487/RFC6876",
  }

@misc{rfc6877,
  author="M. Mawatari and M. Kawashima and C. Byrne",
  title="{464XLAT: Combination of Stateful and Stateless Translation}",
  howpublished="RFC 6877 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6877",
  pages="1--14",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6877.txt",
  key="RFC 6877",
  abstract={This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge.  464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.},
  keywords="XLAT, Stateful Translation, Stateless Translation",
  doi="10.17487/RFC6877",
  }

@misc{rfc6878,
  author="A.B. Roach",
  title="{IANA Registry for the Session Initiation Protocol (SIP) ``Priority'' Header Field}",
  howpublished="RFC 6878 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6878",
  pages="1--3",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6878.txt",
  key="RFC 6878",
  abstract={This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) ``Priority'' header field.  It updates RFC 3261.},
  doi="10.17487/RFC6878",
  }

@misc{rfc6879,
  author="S. Jiang and B. Liu and B. Carpenter",
  title="{IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods}",
  howpublished="RFC 6879 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6879",
  pages="1--17",
  year=2013,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6879.txt",
  key="RFC 6879",
  abstract={This document analyzes events that cause renumbering and describes the current renumbering methods.  These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.},
  doi="10.17487/RFC6879",
  }

@misc{rfc6880,
  author="L. Johansson",
  title="{An Information Model for Kerberos Version 5}",
  howpublished="RFC 6880 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6880",
  pages="1--14",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6880.txt",
  key="RFC 6880",
  abstract={This document describes an information model for Kerberos version 5 from the point of view of an administrative service.  There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC).  This document describes the services exposed by an administrative interface to a KDC.},
  keywords="kerberos, kdc, LDAP, schema",
  doi="10.17487/RFC6880",
  }

@misc{rfc6881,
  author="B. Rosen and J. Polk",
  title="{Best Current Practice for Communications Services in Support of Emergency Calling}",
  howpublished="RFC 6881 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6881",
  pages="1--28",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7840, 7852",
url="https://www.rfc-editor.org/rfc/rfc6881.txt",
  key="RFC 6881",
  abstract={The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks.  This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.},
  keywords="SIP, emergency, emergency calls, emergency call, emergency calling, 9-1-1, 1-1-2, ecrit",
  doi="10.17487/RFC6881",
  }

@misc{rfc6882,
  author="K. Kumaki and T. Murai and D. Cheng and S. Matsushima and P. Jiang",
  title="{Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)}",
  howpublished="RFC 6882 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6882",
  pages="1--15",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6882.txt",
  key="RFC 6882",
  abstract={IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs. The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.},
  doi="10.17487/RFC6882",
  }

@misc{rfc6883,
  author="B. Carpenter and S. Jiang",
  title="{IPv6 Guidance for Internet Content Providers and Application Service Providers}",
  howpublished="RFC 6883 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6883",
  pages="1--24",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6883.txt",
  key="RFC 6883",
  abstract={This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers.  Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.},
  doi="10.17487/RFC6883",
  }

@misc{rfc6884,
  author="Z. Fang",
  title="{RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)}",
  howpublished="RFC 6884 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6884",
  pages="1--21",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6884.txt",
  key="RFC 6884",
  abstract={This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW).  Three media type registrations are included for EVRC-NW RTP payload formats.  In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.},
  keywords="EVRC-WB, EVRC-B",
  doi="10.17487/RFC6884",
  }

@misc{rfc6885,
  author="M. Blanchet and A. Sullivan",
  title="{Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)}",
  howpublished="RFC 6885 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6885",
  pages="1--34",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6885.txt",
  key="RFC 6885",
  abstract={If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow.  Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep.  Other protocols subsequently defined Stringprep profiles.  A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008).  Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed.  This document outlines the issues to be faced by those designing a Stringprep replacement.},
  doi="10.17487/RFC6885",
  }

@misc{rfc6886,
  author="S. Cheshire and M. Krochmal",
  title="{NAT Port Mapping Protocol (NAT-PMP)}",
  howpublished="RFC 6886 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6886",
  pages="1--33",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6886.txt",
  key="RFC 6886",
  abstract={This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings.  Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it.  From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations.  In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC ``Port Control Protocol (PCP)'', which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.},
  doi="10.17487/RFC6886",
  }

@misc{rfc6887,
  author="D. Wing and S. Cheshire and M. Boucadair and R. Penno and P. Selkirk",
  title="{Port Control Protocol (PCP)}",
  howpublished="RFC 6887 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6887",
  pages="1--88",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7488, 7652, 7843",
url="https://www.rfc-editor.org/rfc/rfc6887.txt",
  key="RFC 6887",
  abstract={The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.},
  keywords="NAT, Firewall",
  doi="10.17487/RFC6887",
  }

@misc{rfc6888,
  author="S. Perreault and I. Yamagata and S. Miyakawa and A. Nakagawa and H. Ashida",
  title="{Common Requirements for Carrier-Grade NATs (CGNs)}",
  howpublished="RFC 6888 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6888",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6888.txt",
  key="RFC 6888",
  abstract={This document defines common requirements for Carrier-Grade NATs (CGNs).  It updates RFC 4787.},
  keywords="CGN, NAT",
  doi="10.17487/RFC6888",
  }

@misc{rfc6889,
  author="R. Penno and T. Saxena and M. Boucadair and S. Sivakumar",
  title="{Analysis of Stateful 64 Translation}",
  howpublished="RFC 6889 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6889",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6889.txt",
  key="RFC 6889",
  abstract={Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation.  Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation.  This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.},
  keywords="NAT64, DNS64, NAT-PT, ALG (Application Layer Gateway), NAT traversal, IPv4-IPv6 interconnection, IPv4-IPv6 translation",
  doi="10.17487/RFC6889",
  }

@misc{rfc6890,
  author="M. Cotton and L. Vegoda and R. Bonica and B. Haberman",
  title="{Special-Purpose IP Address Registries}",
  howpublished="RFC 6890 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6890",
  pages="1--23",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6890.txt",
  key="RFC 6890",
  abstract={This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA.  It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries.  Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.},
  keywords="Internet Protocol, space assignments",
  doi="10.17487/RFC6890",
  }

@misc{rfc6891,
  author="J. Damas and M. Graff and P. Vixie",
  title="{Extension Mechanisms for DNS (EDNS(0))}",
  howpublished="RFC 6891 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6891",
  pages="1--16",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6891.txt",
  key="RFC 6891",
  abstract={The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 (``Binary Labels in the Domain Name System'') and adds considerations on the use of extended labels in the DNS.},
  keywords="DNS extensions, domain name system, resource records, opt",
  doi="10.17487/RFC6891",
  }

@misc{rfc6892,
  author="E. Wilde",
  title="{The 'describes' Link Relation Type}",
  howpublished="RFC 6892 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6892",
  pages="1--5",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6892.txt",
  key="RFC 6892",
  abstract={This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource.  In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.},
  doi="10.17487/RFC6892",
  }

@misc{rfc6893,
  author="P. Higgs and P. Szucs",
  title="{A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)}",
  howpublished="RFC 6893 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6893",
  pages="1--8",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6893.txt",
  key="RFC 6893",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications.  Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.},
  doi="10.17487/RFC6893",
  }

@misc{rfc6894,
  author="R. Papneja and S. Vapiwala and J. Karthik and S. Poretsky and S. Rao and JL. Le Roux",
  title="{Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection}",
  howpublished="RFC 6894 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6894",
  pages="1--35",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6894.txt",
  key="RFC 6894",
  abstract={This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection.  This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.},
  doi="10.17487/RFC6894",
  }

@misc{rfc6895,
  author="D. {Eastlake 3rd}",
  title="{Domain Name System (DNS) IANA Considerations}",
  howpublished="RFC 6895 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6895",
  pages="1--19",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6895.txt",
  key="RFC 6895",
  abstract={This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.},
  keywords="RRTYPE, RCODE, AFSDB",
  doi="10.17487/RFC6895",
  }

@misc{rfc6896,
  author="S. Barbato and S. Dorigotti and T. Fossati",
  title="{SCS: KoanLogic's Secure Cookie Sessions for HTTP}",
  howpublished="RFC 6896 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6896",
  pages="1--23",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6896.txt",
  key="RFC 6896",
  abstract={This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies. Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.},
  keywords="HTTP Secure Cookies",
  doi="10.17487/RFC6896",
  }

@misc{rfc6897,
  author="M. Scharf and A. Ford",
  title="{Multipath TCP (MPTCP) Application Interface Considerations}",
  howpublished="RFC 6897 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6897",
  pages="1--31",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6897.txt",
  key="RFC 6897",
  abstract={Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session.  Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit.  This document summarizes the impact that MPTCP may have on applications, such as changes in performance.  Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications.  Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.},
  doi="10.17487/RFC6897",
  }

@misc{rfc6898,
  author="D. Li and D. Ceccarelli and L. Berger",
  title="{Link Management Protocol Behavior Negotiation and Configuration Modifications}",
  howpublished="RFC 6898 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6898",
  pages="1--11",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6898.txt",
  key="RFC 6898",
  abstract={The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.},
  keywords="LMP",
  doi="10.17487/RFC6898",
  }

@misc{rfc6901,
  author="P. Bryan and K. Zyp and M. Nottingham",
  title="{JavaScript Object Notation (JSON) Pointer}",
  howpublished="RFC 6901 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6901",
  pages="1--8",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6901.txt",
  key="RFC 6901",
  abstract={JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.},
  doi="10.17487/RFC6901",
  }

@misc{rfc6902,
  author="P. Bryan and M. Nottingham",
  title="{JavaScript Object Notation (JSON) Patch}",
  howpublished="RFC 6902 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6902",
  pages="1--18",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6902.txt",
  key="RFC 6902",
  abstract={JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method.  The ``application/json-patch+json'' media type is used to identify such patch documents.},
  doi="10.17487/RFC6902",
  }

@misc{rfc6903,
  author="J. Snell",
  title="{Additional Link Relation Types}",
  howpublished="RFC 6903 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6903",
  pages="1--6",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6903.txt",
  key="RFC 6903",
  abstract={This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.},
  keywords="http, link, rel",
  doi="10.17487/RFC6903",
  }

@misc{rfc6904,
  author="J. Lennox",
  title="{Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 6904 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6904",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6904.txt",
  key="RFC 6904",
  abstract={The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.},
  keywords="real-time transport protocol, rtp, header extensions, security",
  doi="10.17487/RFC6904",
  }

@misc{rfc6905,
  author="T. Senevirathne and D. Bond and S. Aldrin and Y. Li and R. Watve",
  title="{Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)}",
  howpublished="RFC 6905 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6905",
  pages="1--13",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6905.txt",
  key="RFC 6905",
  abstract={Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks.  This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).},
  doi="10.17487/RFC6905",
  }

@misc{rfc6906,
  author="E. Wilde",
  title="{The 'profile' Link Relation Type}",
  howpublished="RFC 6906 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6906",
  pages="1--8",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6906.txt",
  key="RFC 6906",
  abstract={This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles.  A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.},
  keywords="application profile, profile identifier",
  doi="10.17487/RFC6906",
  }

@misc{rfc6907,
  author="T. Manderson and K. Sriram and R. White",
  title="{Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties}",
  howpublished="RFC 6907 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6907",
  pages="1--31",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6907.txt",
  key="RFC 6907",
  abstract={This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI.  All of these items are discussed here in relation to the Internet routing system.},
  keywords="Prefix origin validation, Routing security, BGP security",
  doi="10.17487/RFC6907",
  }

@misc{rfc6908,
  author="Y. Lee and R. Maglione and C. Williams and C. Jacquenet and M. Boucadair",
  title="{Deployment Considerations for Dual-Stack Lite}",
  howpublished="RFC 6908 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6908",
  pages="1--14",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6908.txt",
  key="RFC 6908",
  abstract={This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite).  This document describes the various deployment considerations and applicability of the DS-Lite architecture.},
  doi="10.17487/RFC6908",
  }

@misc{rfc6909,
  author="S. Gundavelli and X. Zhou and J. Korhonen and G. Feige and R. Koodli",
  title="{IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6}",
  howpublished="RFC 6909 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6909",
  pages="1--14",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6909.txt",
  key="RFC 6909",
  abstract={This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6.  This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session.  Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.},
  doi="10.17487/RFC6909",
  }

@misc{rfc6910,
  author="D. Worley and M. Huelsemann and R. Jesske and D. Alexeitsev",
  title="{Completion of Calls for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6910 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6910",
  pages="1--37",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6910.txt",
  key="RFC 6910",
  abstract={The ``completion of calls'' feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in ``Session Initiation Protocol Service Examples'' (RFC 5359). For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where ``completion of calls'' implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made. The architecture is designed to interoperate well with existing completion of calls solutions in other networks.},
  keywords="call completion, CC, SS7, Signaling System 7, purpose header parameter, m URI parameter, m header parameter, call-completion event package, CCBS, CCNR, CCNL, Call-Info header field, Presence Information Data Format, PIDF, P-Asserted-Identity header field",
  doi="10.17487/RFC6910",
  }

@misc{rfc6911,
  author="W. Dec and B. Sarikaya and G. Zorn and D. Miles and B. Lourdelet",
  title="{RADIUS Attributes for IPv6 Access Networks}",
  howpublished="RFC 6911 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6911",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6911.txt",
  key="RFC 6911",
  abstract={This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments.  The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.},
  keywords="AAA, RADIUS, IPv6",
  doi="10.17487/RFC6911",
  }

@misc{rfc6912,
  author="A. Sullivan and D. Thaler and J. Klensin and O. Kolkman",
  title="{Principles for Unicode Code Point Inclusion in Labels in the DNS}",
  howpublished="RFC 6912 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6912",
  pages="1--12",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6912.txt",
  key="RFC 6912",
  abstract={Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points.  Most operators of zones should probably not permit registration of U-labels using the entire range.  This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root.  It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk.  This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.},
  doi="10.17487/RFC6912",
  }

@misc{rfc6913,
  author="D. Hanes and G. Salgueiro and K. Fleming",
  title="{Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6913 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6913",
  pages="1--9",
  year=2013,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6913.txt",
  key="RFC 6913",
  abstract={This document defines and registers with IANA the new ``fax'' media feature tag for use with the Session Initiation Protocol (SIP).  Currently, fax calls are indistinguishable from voice calls at call initiation.  Consequently, fax calls can be routed to SIP user agents that are not fax capable.  A ``fax'' media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.},
  keywords="media feature tag",
  doi="10.17487/RFC6913",
  }

@misc{rfc6914,
  author="J. Rosenberg",
  title="{SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6914 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6914",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6914.txt",
  key="RFC 6914",
  abstract={The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP).  Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE).  This document serves as a guide to the SIMPLE suite of specifications.  It categorizes the specifications, explains what each is for, and how they relate to each other.},
  keywords="SIP, SIMPLE, presence, IM",
  doi="10.17487/RFC6914",
  }

@misc{rfc6915,
  author="R. Bellis",
  title="{Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)}",
  howpublished="RFC 6915 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6915",
  pages="1--9",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6915.txt",
  key="RFC 6915",
  abstract={RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow. However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request. This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement. This document updates RFC 6155 by deprecating the port number elements specified therein.},
  keywords="HELD, Flow",
  doi="10.17487/RFC6915",
  }

@misc{rfc6916,
  author="R. Gagliano and S. Kent and S. Turner",
  title="{Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 6916 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6916",
  pages="1--20",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6916.txt",
  key="RFC 6916",
  abstract={This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set.  The process is expected to be completed over a timescale of several years.  Consequently, no emergency transition is specified.  The transition procedure defined in this document supports only a top-down migration (parent migrates before children).},
  keywords="Resource Public Key Infrastructure, RPKI, Algorithm Transition, SIDR, routing security, BGP security",
  doi="10.17487/RFC6916",
  }

@misc{rfc6917,
  author="C. Boulton and L. Miniero and G. Munson",
  title="{Media Resource Brokering}",
  howpublished="RFC 6917 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6917",
  pages="1--136",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6917.txt",
  key="RFC 6917",
  abstract={The MediaCtrl working group in the IETF has proposed an architecture for controlling media services.  The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing.  In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties.  This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers.  This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers.  The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.},
  doi="10.17487/RFC6917",
  }

@misc{rfc6918,
  author="F. Gont and C. Pignataro",
  title="{Formally Deprecating Some ICMPv4 Message Types}",
  howpublished="RFC 6918 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6918",
  pages="1--8",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6918.txt",
  key="RFC 6918",
  abstract={A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated.  This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry.  Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.},
  keywords="IANA, IPv4 Options",
  doi="10.17487/RFC6918",
  }

@misc{rfc6919,
  author="R. Barnes and S. Kent and E. Rescorla",
  title="{Further Key Words for Use in RFCs to Indicate Requirement Levels}",
  howpublished="RFC 6919 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6919",
  pages="1--6",
  year=2013,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6919.txt",
  key="RFC 6919",
  abstract={RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words ``MUST (BUT WE KNOW YOU WON\'T)'', ``SHOULD CONSIDER'', ``REALLY SHOULD NOT'', ``OUGHT TO'', ``WOULD PROBABLY'', ``MAY WISH TO'', ``COULD'', ``POSSIBLE'', and ``MIGHT'' in this document are to be interpreted as described in RFC 6919.},
  doi="10.17487/RFC6919",
  }

@misc{rfc6920,
  author="S. Farrell and D. Kutscher and C. Dannewitz and B. Ohlman and A. Keranen and P. Hallam-Baker",
  title="{Naming Things with Hashes}",
  howpublished="RFC 6920 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6920",
  pages="1--23",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6920.txt",
  key="RFC 6920",
  abstract={This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function.  It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names.  The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it.  The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.},
  keywords="Cryptography, URI, Information Centric Networking",
  doi="10.17487/RFC6920",
  }

@misc{rfc6921,
  author="R. Hinden",
  title="{Design Considerations for Faster-Than-Light (FTL) Communication}",
  howpublished="RFC 6921 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6921",
  pages="1--7",
  year=2013,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6921.txt",
  key="RFC 6921",
  abstract={We are approaching the time when we will be able to communicate faster than the speed of light.  It is well known that as we approach the speed of light, time slows down.  Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse.  The major consequence of this for Internet protocols is that packets will arrive before they are sent.  This will have a major impact on the way we design Internet protocols.  This paper outlines some of the issues and suggests some directions for additional analysis of these issues.},
  doi="10.17487/RFC6921",
  }

@misc{rfc6922,
  author="Y. Shafranovich",
  title="{The application/sql Media Type}",
  howpublished="RFC 6922 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6922",
  pages="1--5",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6922.txt",
  key="RFC 6922",
  abstract={This document registers the application/sql media type to be used for the Structured Query Language (SQL).},
  keywords="SQL, MIME",
  doi="10.17487/RFC6922",
  }

@misc{rfc6923,
  author="R. Winter and E. Gray and H. van Helvoort and M. Betts",
  title="{MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions}",
  howpublished="RFC 6923 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6923",
  pages="1--12",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6923.txt",
  key="RFC 6923",
  abstract={This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).  Identifiers that follow IP/MPLS conventions have already been defined.  This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).},
  doi="10.17487/RFC6923",
  }

@misc{rfc6924,
  author="B. Leiba",
  title="{Registration of Second-Level URN Namespaces under ``ietf''}",
  howpublished="RFC 6924 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6924",
  pages="1--4",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6924.txt",
  key="RFC 6924",
  abstract={RFC 2648 defines the ``ietf'' URN namespace and a number of sub- namespaces.  RFC 3553 defines an additional sub-namespace, ``params'', and creates a registry to document allocations under that.  But there is no registry that lists, in one place, all sub-namespaces of ``ietf''.  This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of ``ietf''.},
  doi="10.17487/RFC6924",
  }

@misc{rfc6925,
  author="B. Joshi and R. Desetti and M. Stapp",
  title="{The DHCPv4 Relay Agent Identifier Sub-Option}",
  howpublished="RFC 6925 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6925",
  pages="1--8",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6925.txt",
  key="RFC 6925",
  abstract={This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option.  The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain.  The value is normally administratively configured in the relay agent.  The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.},
  keywords="DHCP, relay",
  doi="10.17487/RFC6925",
  }

@misc{rfc6926,
  author="K. Kinnear and M. Stapp and R. Desetti and B. Joshi and N. Russell and P. Kurapati and B. Volz",
  title="{DHCPv4 Bulk Leasequery}",
  howpublished="RFC 6926 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6926",
  pages="1--41",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7724",
url="https://www.rfc-editor.org/rfc/rfc6926.txt",
  key="RFC 6926",
  abstract={The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings.  This protocol is limited to queries for individual bindings.  In some situations, individual binding queries may not be efficient or even possible.  This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.},
  doi="10.17487/RFC6926",
  }

@misc{rfc6927,
  author="J. Levine and P. Hoffman",
  title="{Variants in Second-Level Names Registered in Top-Level Domains}",
  howpublished="RFC 6927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6927",
  pages="1--18",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6927.txt",
  key="RFC 6927",
  abstract={Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS.  Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called ``variants''. (The authors note that there are many conflicting definitions for the term ``variant'' in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants.  This document is not a product of the IETF, does not propose any method to make variants work ``correctly'', and is not an introduction to internationalization or IDNA.},
  keywords="DNS, variant, TLDs",
  doi="10.17487/RFC6927",
  }

@misc{rfc6928,
  author="J. Chu and N. Dukkipati and Y. Cheng and M. Mathis",
  title="{Increasing TCP's Initial Window}",
  howpublished="RFC 6928 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6928",
  pages="1--24",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6928.txt",
  key="RFC 6928",
  abstract={This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected.  It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse.  The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.},
  doi="10.17487/RFC6928",
  }

@misc{rfc6929,
  author="A. DeKok and A. Lior",
  title="{Remote Authentication Dial In User Service (RADIUS) Protocol Extensions}",
  howpublished="RFC 6929 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6929",
  pages="1--68",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6929.txt",
  key="RFC 6929",
  abstract={The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space.  In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data.  This document defines changes to RADIUS that address all of the above problems.},
  doi="10.17487/RFC6929",
  }

@misc{rfc6930,
  author="D. Guo and S. Jiang and R. Despres and R. Maglione",
  title="{RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)}",
  howpublished="RFC 6930 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6930",
  pages="1--12",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6930.txt",
  key="RFC 6930",
  abstract={The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period.  The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE).  However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol.  This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.},
  doi="10.17487/RFC6930",
  }

@misc{rfc6931,
  author="D. {Eastlake 3rd}",
  title="{Additional XML Security Uniform Resource Identifiers (URIs)}",
  howpublished="RFC 6931 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6931",
  pages="1--36",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6931.txt",
  key="RFC 6931",
  abstract={This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management.  These URIs identify algorithms and types of information.  This document obsoletes RFC 4051.},
  doi="10.17487/RFC6931",
  }

@misc{rfc6932,
  author="D. Harkins",
  title="{Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry}",
  howpublished="RFC 6932 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6932",
  pages="1--12",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6932.txt",
  key="RFC 6932",
  abstract={This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.},
  keywords="elliptic curve, Diffie-Hellman",
  doi="10.17487/RFC6932",
  }

@misc{rfc6933,
  author="A. Bierman and D. Romascanu and J. Quittek and M. Chandramouli",
  title="{Entity MIB (Version 4)}",
  howpublished="RFC 6933 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6933",
  pages="1--76",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6933.txt",
  key="RFC 6933",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent.  This document specifies version 4 of the Entity MIB.  This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.},
  keywords="management information base, snmp, simple network management protocol",
  doi="10.17487/RFC6933",
  }

@misc{rfc6934,
  author="N. Bitar and S. Wadhwa and T. Haag and H. Li",
  title="{Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)}",
  howpublished="RFC 6934 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6934",
  pages="1--39",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6934.txt",
  key="RFC 6934",
  abstract={The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs).  The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations.  The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT).  The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net.  This allows for performing access-link-related operations within those network elements to meet performance objectives.},
  doi="10.17487/RFC6934",
  }

@misc{rfc6935,
  author="M. Eubanks and P. Chimento and M. Westerlund",
  title="{IPv6 and UDP Checksums for Tunneled Packets}",
  howpublished="RFC 6935 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6935",
  pages="1--12",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6935.txt",
  key="RFC 6935",
  abstract={This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets.  The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the ``inner'' packet being carried.  Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets.  This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum.  It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.},
  keywords="Tunnel, Encapsulation, Integrity, Packet Corruption, Middlebox",
  doi="10.17487/RFC6935",
  }

@misc{rfc6936,
  author="G. Fairhurst and M. Westerlund",
  title="{Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums}",
  howpublished="RFC 6936 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6936",
  pages="1--40",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6936.txt",
  key="RFC 6936",
  abstract={This document provides an applicability statement for the use of UDP transport checksums with IPv6.  It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum.  It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum.  The document also identifies issues and constraints for deployment on network paths that include middleboxes.  An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.},
  doi="10.17487/RFC6936",
  }

@misc{rfc6937,
  author="M. Mathis and N. Dukkipati and Y. Cheng",
  title="{Proportional Rate Reduction for TCP}",
  howpublished="RFC 6937 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6937",
  pages="1--16",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6937.txt",
  key="RFC 6937",
  abstract={This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms.  These algorithms determine the amount of data sent by TCP during loss recovery.  PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.},
  keywords="TCP loss recovery, packet conservation, self clock",
  doi="10.17487/RFC6937",
  }

@misc{rfc6938,
  author="J. Scudder",
  title="{Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID\_PATH / CLUSTER\_ID}",
  howpublished="RFC 6938 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6938",
  pages="1--3",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6938.txt",
  key="RFC 6938",
  abstract={This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID\_PATH / CLUSTER\_ID, associated with an abandoned Internet-Draft and a Historic RFC.},
  keywords="BGP",
  doi="10.17487/RFC6938",
  }

@misc{rfc6939,
  author="G. Halwasia and S. Bhandari and W. Dec",
  title="{Client Link-Layer Address Option in DHCPv6}",
  howpublished="RFC 6939 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6939",
  pages="1--7",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6939.txt",
  key="RFC 6939",
  abstract={This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.},
  doi="10.17487/RFC6939",
  }

@misc{rfc6940,
  author="C. Jennings and B. Lowekamp and E. Rescorla and S. Baset and H. Schulzrinne",
  title="{REsource LOcation And Discovery (RELOAD) Base Protocol}",
  howpublished="RFC 6940 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6940",
  pages="1--176",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6940.txt",
  key="RFC 6940",
  abstract={This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network.  RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application.  RELOAD defines a security model based on a certificate enrollment service that provides unique identities.  NAT traversal is a fundamental service of the protocol.  RELOAD also allows access from ``client'' nodes that do not need to route traffic or store data for others.},
  keywords="p2p, dht, p2psip, chord, peer to peer",
  doi="10.17487/RFC6940",
  }

@misc{rfc6941,
  author="L. Fang and B. Niven-Jenkins and S. Mansfield and R. Graveman",
  title="{MPLS Transport Profile (MPLS-TP) Security Framework}",
  howpublished="RFC 6941 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6941",
  pages="1--15",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6941.txt",
  key="RFC 6941",
  abstract={This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 (``Security Framework for MPLS and GMPLS Networks'') by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.},
  keywords="threats, mitigation, defensive techniques",
  doi="10.17487/RFC6941",
  }

@misc{rfc6942,
  author="J. Bournelle and L. Morand and S. Decugis and Q. Wu and G. Zorn",
  title="{Diameter Support for the EAP Re-authentication Protocol (ERP)}",
  howpublished="RFC 6942 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6942",
  pages="1--18",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6942.txt",
  key="RFC 6942",
  abstract={The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator.  This document specifies Diameter support for ERP.  It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.},
  doi="10.17487/RFC6942",
  }

@misc{rfc6943,
  author="D. Thaler",
  title="{Issues in Identifier Comparison for Security Purposes}",
  howpublished="RFC 6943 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6943",
  pages="1--26",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6943.txt",
  key="RFC 6943",
  abstract={Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources.  In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc.  If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result.  This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.},
  keywords="Canonicalization, Normalization, Hostname, URI, IRI",
  doi="10.17487/RFC6943",
  }

@misc{rfc6944,
  author="S. Rose",
  title="{Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status}",
  howpublished="RFC 6944 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6944",
  pages="1--7",
  year=2013,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6944.txt",
  key="RFC 6944",
  abstract={The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data.  There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm.  This document provides an applicability statement on algorithm implementation status for DNSSEC component software.  This document lists each algorithm's status based on the current reference.  In the case that an algorithm is specified without an implementation status, this document assigns one.  This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.},
  doi="10.17487/RFC6944",
  }

@misc{rfc6945,
  author="R. Bush and B. Wijnen and K. Patel and M. Baer",
  title="{Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol}",
  howpublished="RFC 6945 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6945",
  pages="1--25",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6945.txt",
  key="RFC 6945",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.},
  doi="10.17487/RFC6945",
  }

@misc{rfc6946,
  author="F. Gont",
  title="{Processing of IPv6 ``Atomic'' Fragments}",
  howpublished="RFC 6946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6946",
  pages="1--9",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6946.txt",
  key="RFC 6946",
  abstract={The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as ``atomic fragments'').  Such packets are typically sent by hosts that have received an ICMPv6 ``Packet Too Big'' error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal ``fragmented traffic'' (i.e., they are ``reassembled'' with any other queued fragments that supposedly correspond to the same original packet).  Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 ``Packet Too Big'' error messages, and then launch any fragmentation-based attacks against such traffic.  This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications.  Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.},
  keywords="fragmentation, attacks, vulnerabilities, atomic fragments",
  doi="10.17487/RFC6946",
  }

@misc{rfc6947,
  author="M. Boucadair and H. Kaplan and R. Gilman and S. Veikkolainen",
  title="{The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute}",
  howpublished="RFC 6947 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6947",
  pages="1--24",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6947.txt",
  key="RFC 6947",
  abstract={This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the ``altc'' attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax. The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.},
  doi="10.17487/RFC6947",
  }

@misc{rfc6948,
  author="A. Keranen and J. Arkko",
  title="{Some Measurements on World IPv6 Day from an End-User Perspective}",
  howpublished="RFC 6948 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6948",
  pages="1--11",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6948.txt",
  key="RFC 6948",
  abstract={During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services.  Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event.  The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected.  For the Internet, however, there was a major change on a short timescale.  This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity.  Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.},
  doi="10.17487/RFC6948",
  }

@misc{rfc6949,
  author="H. Flanagan and N. Brownlee",
  title="{RFC Series Format Requirements and Future Development}",
  howpublished="RFC 6949 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6949",
  pages="1--14",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6949.txt",
  key="RFC 6949",
  abstract={This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs.  Terms are defined to help clarify exactly which stages of document production are under discussion for format changes.  The requirements described in this document will determine what changes will be made to RFC format.  This document updates RFC 2223.},
  doi="10.17487/RFC6949",
  }

@misc{rfc6950,
  author="J. Peterson and O. Kolkman and H. Tschofenig and B. Aboba",
  title="{Architectural Considerations on Application Features in the DNS}",
  howpublished="RFC 6950 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6950",
  pages="1--31",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6950.txt",
  key="RFC 6950",
  abstract={A number of Internet applications rely on the Domain Name System (DNS) to support their operations.  Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS.  Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform.  This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.},
  doi="10.17487/RFC6950",
  }

@misc{rfc6951,
  author="M. Tuexen and R. Stewart",
  title="{UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication}",
  howpublished="RFC 6951 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6951",
  pages="1--12",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6951.txt",
  key="RFC 6951",
  abstract={This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints.},
  doi="10.17487/RFC6951",
  }

@misc{rfc6952,
  author="M. Jethanandani and K. Patel and L. Zheng",
  title="{Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide}",
  howpublished="RFC 6952 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6952",
  pages="1--17",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6952.txt",
  key="RFC 6952",
  abstract={This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of ``Keying and Authentication for Routing Protocols Design Guidelines'', RFC 6518.},
  keywords="key, authentication, routing, DoS",
  doi="10.17487/RFC6952",
  }

@misc{rfc6953,
  author="A. Mancuso and S. Probasco and B. Patil",
  title="{Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements}",
  howpublished="RFC 6953 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6953",
  pages="1--23",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6953.txt",
  key="RFC 6953",
  abstract={Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as ``white space''.  The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to ``unlock'' existing spectrum for new use.  This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol.  Finally, requirements associated with the protocol are presented.},
  doi="10.17487/RFC6953",
  }

@misc{rfc6954,
  author="J. Merkle and M. Lochter",
  title="{Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 6954 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6954",
  pages="1--11",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6954.txt",
  key="RFC 6954",
  abstract={This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).},
  keywords="IKE, Elliptic Curve",
  doi="10.17487/RFC6954",
  }

@misc{rfc6955,
  author="J. Schaad and H. Prafullchandra",
  title="{Diffie-Hellman Proof-of-Possession Algorithms}",
  howpublished="RFC 6955 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6955",
  pages="1--43",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6955.txt",
  key="RFC 6955",
  abstract={This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) \#10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm. This document obsoletes RFC 2875.},
  keywords="POP, ECDH, DH",
  doi="10.17487/RFC6955",
  }

@misc{rfc6956,
  author="W. Wang and E. Haleplidis and K. Ogawa and C. Li and J. Halpern",
  title="{Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library}",
  howpublished="RFC 6956 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6956",
  pages="1--111",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6956.txt",
  key="RFC 6956",
  abstract={This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES).  The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES.  The library includes the descriptions of the LFBs and the XML definitions.},
  keywords="ForCES, LFB, Library",
  doi="10.17487/RFC6956",
  }

@misc{rfc6957,
  author="F. Costa and J-M. Combes and X. Pougnard and H. Li",
  title="{Duplicate Address Detection Proxy}",
  howpublished="RFC 6957 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6957",
  pages="1--16",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6957.txt",
  key="RFC 6957",
  abstract={The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a ``split-horizon'' forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures.  Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN).  When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.},
  keywords="IPv6, SLAAC, DAD, SAVI",
  doi="10.17487/RFC6957",
  }

@misc{rfc6958,
  author="A. Clark and S. Zhang and J. Zhao and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting}",
  howpublished="RFC 6958 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6958",
  pages="1--16",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6958.txt",
  key="RFC 6958",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.},
  keywords="Real Time Control Protocol",
  doi="10.17487/RFC6958",
  }

@misc{rfc6959,
  author="D. McPherson and F. Baker and J. Halpern",
  title="{Source Address Validation Improvement (SAVI) Threat Scope}",
  howpublished="RFC 6959 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6959",
  pages="1--25",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6959.txt",
  key="RFC 6959",
  abstract={The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation.  This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.},
  doi="10.17487/RFC6959",
  }

@misc{rfc6960,
  author="S. Santesson and M. Myers and R. Ankney and A. Malpani and S. Galperin and C. Adams",
  title="{X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP}",
  howpublished="RFC 6960 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6960",
  pages="1--41",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6960.txt",
  key="RFC 6960",
  abstract={This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs).  Additional mechanisms addressing PKIX operational requirements are specified in separate documents.  This document obsoletes RFCs 2560 and 6277.  It also updates RFC 5912.},
  keywords="PKIX, digital security, ocsp",
  doi="10.17487/RFC6960",
  }

@misc{rfc6961,
  author="Y. Pettersen",
  title="{The Transport Layer Security (TLS) Multiple Certificate Status Request Extension}",
  howpublished="RFC 6961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6961",
  pages="1--10",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6961.txt",
  key="RFC 6961",
  abstract={This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as ``OCSP stapling''.) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.},
  keywords="RFC 6066, RFC 2560, RFC 6960, RFC 5246, OCSP, OCSP stapling, multi-stapling, certificate status checking, revocation information, status\_request, status\_request\_v2",
  doi="10.17487/RFC6961",
  }

@misc{rfc6962,
  author="B. Laurie and A. Langley and E. Kasper",
  title="{Certificate Transparency}",
  howpublished="RFC 6962 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6962",
  pages="1--27",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6962.txt",
  key="RFC 6962",
  abstract={This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.},
  keywords="TLS certificates",
  doi="10.17487/RFC6962",
  }

@misc{rfc6963,
  author="P. Saint-Andre",
  title="{A Uniform Resource Name (URN) Namespace for Examples}",
  howpublished="RFC 6963 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6963",
  pages="1--7",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6963.txt",
  key="RFC 6963",
  abstract={This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.},
  keywords="URN, examples, documentation",
  doi="10.17487/RFC6963",
  }

@misc{rfc6964,
  author="F. Templin",
  title="{Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}",
  howpublished="RFC 6964 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6964",
  pages="1--20",
  year=2013,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6964.txt",
  key="RFC 6964",
  abstract={Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures.  These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications.  As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality.  This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).},
  keywords="IPv6, IPv4, IPv6/IPv4, IPv6-in-IPv4, tunnel, automatic, isatap, enterprise, site",
  doi="10.17487/RFC6964",
  }

@misc{rfc6965,
  author="L. Fang and N. Bitar and R. Zhang and M. Daikoku and P. Pan",
  title="{MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design}",
  howpublished="RFC 6965 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6965",
  pages="1--16",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6965.txt",
  key="RFC 6965",
  abstract={This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations.  The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.},
  doi="10.17487/RFC6965",
  }

@misc{rfc6967,
  author="M. Boucadair and J. Touch and P. Levis and R. Penno",
  title="{Analysis of Potential Solutions for Revealing a Host Identifier (HOST\_ID) in Shared Address Deployments}",
  howpublished="RFC 6967 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6967",
  pages="1--24",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6967.txt",
  key="RFC 6967",
  abstract={This document is a collection of potential solutions for revealing a host identifier (denoted as HOST\_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.},
  keywords="NAT, Host Identifier",
  doi="10.17487/RFC6967",
  }

@misc{rfc6968,
  author="V. Roca and B. Adamson",
  title="{FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}",
  howpublished="RFC 6968 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6968",
  pages="1--40",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6968.txt",
  key="RFC 6968",
  abstract={This document introduces the FCAST reliable object (e.g., file) delivery application.  It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.},
  doi="10.17487/RFC6968",
  }

@misc{rfc6969,
  author="A. Retana and D. Cheng",
  title="{OSPFv3 Instance ID Registry Update}",
  howpublished="RFC 6969 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6969",
  pages="1--4",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6969.txt",
  key="RFC 6969",
  abstract={This document modifies the ``Unassigned'' number space in the IANA ``OSPFv3 Instance ID Address Family Values'' registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use.  It updates RFC 5838.},
  doi="10.17487/RFC6969",
  }

@misc{rfc6970,
  author="M. Boucadair and R. Penno and D. Wing",
  title="{Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)}",
  howpublished="RFC 6970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6970",
  pages="1--23",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6970.txt",
  key="RFC 6970",
  abstract={This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF).  A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.},
  keywords="UPnP, pinhole, PCP, mapping, NAT control, interworking",
  doi="10.17487/RFC6970",
  }

@misc{rfc6971,
  author="U. Herberg and A. Cardenas and T. Iwao and M. Dow and S. Cespedes",
  title="{Depth-First Forwarding (DFF) in Unreliable Networks}",
  howpublished="RFC 6971 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6971",
  pages="1--41",
  year=2013,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6971.txt",
  key="RFC 6971",
  abstract={This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links.  The protocol operates entirely on the forwarding plane but may interact with the routing plane.  DFF forwards data packets using a mechanism similar to a ``depth-first search'' for the destination of a packet.  The routing plane may be informed of failures to deliver a packet or loops.  This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for ``mesh-under'' Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944.  The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not.  It is applicable for networks with little traffic and is used for unicast transmissions only.},
  keywords="DFF, Depth first forwarding, IPv6, Forwarding plane, Lossy networks, Reliability",
  doi="10.17487/RFC6971",
  }

@misc{rfc6972,
  author="Y. Zhang and N. Zong",
  title="{Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)}",
  howpublished="RFC 6972 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6972",
  pages="1--22",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6972.txt",
  key="RFC 6972",
  abstract={Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols.  This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.},
  keywords="P2P",
  doi="10.17487/RFC6972",
  }

@misc{rfc6973,
  author="A. Cooper and H. Tschofenig and B. Aboba and J. Peterson and J. Morris and M. Hansen and R. Smith",
  title="{Privacy Considerations for Internet Protocols}",
  howpublished="RFC 6973 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6973",
  pages="1--36",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6973.txt",
  key="RFC 6973",
  abstract={This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.},
  keywords="Disclosure, Anonymity, Pseudonymity, Confidentiality, Identity",
  doi="10.17487/RFC6973",
  }

@misc{rfc6974,
  author="Y. Weingarten and S. Bryant and D. Ceccarelli and D. Caviglia and F. Fondelli and M. Corsi and B. Wu and X. Dai",
  title="{Applicability of MPLS Transport Profile for Ring Topologies}",
  howpublished="RFC 6974 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6974",
  pages="1--30",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6974.txt",
  key="RFC 6974",
  abstract={This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies.  This document does not propose any new mechanisms or protocols.  Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in ``Requirements of an MPLS Transport Profile'' (RFC 5654) and ``MPLS Transport Profile (MPLS-TP) Survivability Framework'' (RFC 6372).  This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.},
  doi="10.17487/RFC6974",
  }

@misc{rfc6975,
  author="S. Crocker and S. Rose",
  title="{Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)}",
  howpublished="RFC 6975 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6975",
  pages="1--9",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6975.txt",
  key="RFC 6975",
  abstract={The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be generated using different algorithms.  This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support.  The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.},
  keywords="DNS, DNSSEC, EDNS",
  doi="10.17487/RFC6975",
  }

@misc{rfc6976,
  author="M. Shand and S. Bryant and S. Previdi and C. Filsfils and P. Francois and O. Bonaventure",
  title="{Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach}",
  howpublished="RFC 6976 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6976",
  pages="1--28",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6976.txt",
  key="RFC 6976",
  abstract={This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.},
  doi="10.17487/RFC6976",
  }

@misc{rfc6977,
  author="M. Boucadair and X. Pougnard",
  title="{Triggering DHCPv6 Reconfiguration from Relay Agents}",
  howpublished="RFC 6977 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6977",
  pages="1--13",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6977.txt",
  key="RFC 6977",
  abstract={This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply.  The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly.  The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.},
  keywords="Reconfigure-Request, Reconfigure-Reply, Link Address Option",
  doi="10.17487/RFC6977",
  }

@misc{rfc6978,
  author="J. Touch",
  title="{A TCP Authentication Option Extension for NAT Traversal}",
  howpublished="RFC 6978 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6978",
  pages="1--6",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6978.txt",
  key="RFC 6978",
  abstract={This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs).  This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.},
  keywords="TCP-AO",
  doi="10.17487/RFC6978",
  }

@misc{rfc6979,
  author="T. Pornin",
  title="{Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)}",
  howpublished="RFC 6979 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6979",
  pages="1--79",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6979.txt",
  key="RFC 6979",
  abstract={This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.},
  keywords="dsa, ecdsa, digital signature, deterministic",
  doi="10.17487/RFC6979",
  }

@misc{rfc6980,
  author="F. Gont",
  title="{Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery}",
  howpublished="RFC 6980 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6980",
  pages="1--10",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6980.txt",
  key="RFC 6980",
  abstract={This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages.  It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks.  Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.},
  keywords="vulnerabilities, evasion, monitoring",
  doi="10.17487/RFC6980",
  }

@misc{rfc6981,
  author="S. Bryant and S. Previdi and M. Shand",
  title="{A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses}",
  howpublished="RFC 6981 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6981",
  pages="1--34",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6981.txt",
  key="RFC 6981",
  abstract={This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to ``not-via'' addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.},
  keywords="not-via",
  doi="10.17487/RFC6981",
  }

@misc{rfc6982,
  author="Y. Sheffer and A. Farrel",
  title="{Improving Awareness of Running Code: The Implementation Status Section}",
  howpublished="RFC 6982 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6982",
  pages="1--9",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7942",
url="https://www.rfc-editor.org/rfc/rfc6982.txt",
  key="RFC 6982",
  abstract={This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.},
  doi="10.17487/RFC6982",
  }

@misc{rfc6983,
  author="R. van Brandenburg and O. van Deventer and F. Le Faucheur and K. Leung",
  title="{Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)}",
  howpublished="RFC 6983 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6983",
  pages="1--45",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6983.txt",
  key="RFC 6983",
  abstract={This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios.  The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI.  This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.},
  keywords="video, caching, HTTP, content delivery",
  doi="10.17487/RFC6983",
  }

@misc{rfc6984,
  author="W. Wang and K. Ogawa and E. Haleplidis and M. Gao and J. Hadi Salim",
  title="{Interoperability Report for Forwarding and Control Element Separation (ForCES)}",
  howpublished="RFC 6984 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6984",
  pages="1--29",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6984.txt",
  key="RFC 6984",
  abstract={This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China.  The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.},
  doi="10.17487/RFC6984",
  }

@misc{rfc6985,
  author="A. Morton",
  title="{IMIX Genome: Specification of Variable Packet Sizes for Additional Testing}",
  howpublished="RFC 6985 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6985",
  pages="1--10",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6985.txt",
  key="RFC 6985",
  abstract={Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested.  Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or ``IMIX'' (``Internet Mix'').  The mixture of sizes a networking device will encounter is highly variable and depends on many factors.  An IMIX suited for one networking device and deployment will not be appropriate for another.  However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests.  To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.},
  keywords="Traffic, Pattern, Benchmarking",
  doi="10.17487/RFC6985",
  }

@misc{rfc6986,
  author="V. Dolmatov and A. Degtyarev",
  title="{GOST R 34.11-2012: Hash Function}",
  howpublished="RFC 6986 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6986",
  pages="1--40",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6986.txt",
  key="RFC 6986",
  abstract={This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  This document updates RFC 5831.},
  doi="10.17487/RFC6986",
  }

@misc{rfc6987,
  author="A. Retana and L. Nguyen and A. Zinin and R. White and D. McPherson",
  title="{OSPF Stub Router Advertisement}",
  howpublished="RFC 6987 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6987",
  pages="1--7",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6987.txt",
  key="RFC 6987",
  abstract={This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document obsoletes RFC 3137.},
  keywords="ospf stub",
  doi="10.17487/RFC6987",
  }

@misc{rfc6988,
  author="J. Quittek and M. Chandramouli and R. Winter and T. Dietz and B. Claise",
  title="{Requirements for Energy Management}",
  howpublished="RFC 6988 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6988",
  pages="1--28",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6988.txt",
  key="RFC 6988",
  abstract={This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.},
  keywords="monitoring functions, control functions",
  doi="10.17487/RFC6988",
  }

@misc{rfc6989,
  author="Y. Sheffer and S. Fluhrer",
  title="{Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 6989 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6989",
  pages="1--10",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6989.txt",
  key="RFC 6989",
  abstract={This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups.  No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups.  This document updates the IKEv2 protocol, RFC 5996.},
  keywords="Elliptic Curve cryptography, secret key reuse, recipient tests",
  doi="10.17487/RFC6989",
  }

@misc{rfc6990,
  author="R. Huang and Q. Wu and H. Asaeda and G. Zorn",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting}",
  howpublished="RFC 6990 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6990",
  pages="1--11",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6990.txt",
  key="RFC 6990",
  abstract={An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data.  Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.  This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP.  The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.},
  keywords="RTCP, XR, MPEG2, PSI, Decodability",
  doi="10.17487/RFC6990",
  }

@misc{rfc6991,
  author="J. Schoenwaelder",
  title="{Common YANG Data Types}",
  howpublished="RFC 6991 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6991",
  pages="1--30",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6991.txt",
  key="RFC 6991",
  abstract={This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.},
  keywords="YANG, data model, netconf",
  doi="10.17487/RFC6991",
  }

@misc{rfc6992,
  author="D. Cheng and M. Boucadair and A. Retana",
  title="{Routing for IPv4-Embedded IPv6 Packets}",
  howpublished="RFC 6992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6992",
  pages="1--15",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6992.txt",
  key="RFC 6992",
  abstract={This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.},
  doi="10.17487/RFC6992",
  }

@misc{rfc6993,
  author="P. Saint-Andre",
  title="{Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 6993 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6993",
  pages="1--5",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6993.txt",
  key="RFC 6993",
  abstract={This document defines and registers a value of ``impp'' (``instant messaging and presence protocol'') for the ``purpose'' header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).},
  keywords="SIP, Call-Info, header field, Instant Messaging, Presence",
  doi="10.17487/RFC6993",
  }

@misc{rfc6994,
  author="J. Touch",
  title="{Shared Use of Experimental TCP Options}",
  howpublished="RFC 6994 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6994",
  pages="1--11",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6994.txt",
  key="RFC 6994",
  abstract={This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier.  This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism.  It is recommended for all new TCP options that use these codepoints.},
  doi="10.17487/RFC6994",
  }

@misc{rfc6996,
  author="J. Mitchell",
  title="{Autonomous System (AS) Reservation for Private Use}",
  howpublished="RFC 6996 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="6996",
  pages="1--4",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6996.txt",
  key="RFC 6996",
  abstract={This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use.  This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.},
  keywords="asn",
  doi="10.17487/RFC6996",
  }

@misc{rfc6997,
  author="M. Goyal and E. Baccelli and M. Philipp and A. Brandt and J. Martocci",
  title="{Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks}",
  howpublished="RFC 6997 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6997",
  pages="1--40",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6997.txt",
  key="RFC 6997",
  abstract={This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality.  This mechanism allows an IPv6 router to discover ``on demand'' routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.},
  keywords="P2P Routing, RPL, ROLL",
  doi="10.17487/RFC6997",
  }

@misc{rfc6998,
  author="M. Goyal and E. Baccelli and A. Brandt and J. Martocci",
  title="{A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network}",
  howpublished="RFC 6998 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6998",
  pages="1--29",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6998.txt",
  key="RFC 6998",
  abstract={This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.},
  keywords="Measurement, Route Quality, P2P Routes, RPL, ROLL",
  doi="10.17487/RFC6998",
  }

@misc{rfc7001,
  author="M. Kucherawy",
  title="{Message Header Field for Indicating Message Authentication Status}",
  howpublished="RFC 7001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7001",
  pages="1--43",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7601, updated by RFC 7410",
url="https://www.rfc-editor.org/rfc/rfc7001.txt",
  key="RFC 7001",
  abstract={This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.},
  keywords="DKIM, DomainKeys, SenderID, SPF, ADSP, ATPS, VBR, Authentication, Reputation",
  doi="10.17487/RFC7001",
  }

@misc{rfc7002,
  author="A. Clark and G. Zorn and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting}",
  howpublished="RFC 7002 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7002",
  pages="1--12",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7002.txt",
  key="RFC 7002",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.},
  doi="10.17487/RFC7002",
  }

@misc{rfc7003,
  author="A. Clark and R. Huang and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting}",
  howpublished="RFC 7003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7003",
  pages="1--14",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7003.txt",
  key="RFC 7003",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.},
  keywords="Real Time Control Protocol",
  doi="10.17487/RFC7003",
  }

@misc{rfc7004,
  author="G. Zorn and R. Schott and Q. Wu and R. Huang",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting}",
  howpublished="RFC 7004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7004",
  pages="1--21",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7004.txt",
  key="RFC 7004",
  abstract={This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.},
  keywords="RTCP XR, Summary Statistics, Burst/Gap Loss, Burst/Gap Discard, Frame Impairment",
  doi="10.17487/RFC7004",
  }

@misc{rfc7005,
  author="A. Clark and V. Singh and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting}",
  howpublished="RFC 7005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7005",
  pages="1--14",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7005.txt",
  key="RFC 7005",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.},
  doi="10.17487/RFC7005",
  }

@misc{rfc7006,
  author="M. Garcia-Martin and S. Veikkolainen and R. Gilman",
  title="{Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)}",
  howpublished="RFC 7006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7006",
  pages="1--22",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7006.txt",
  key="RFC 7006",
  abstract={The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth (``b='' line), connection data (``c='' line), and session or media titles (``i='' line for each session or media).},
  keywords="title capability, connection data capability, bandwidth capability",
  doi="10.17487/RFC7006",
  }

@misc{rfc7007,
  author="T. Terriberry",
  title="{Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)}",
  howpublished="RFC 7007 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7007",
  pages="1--4",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7007.txt",
  key="RFC 7007",
  abstract={The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF).  This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.},
  doi="10.17487/RFC7007",
  }

@misc{rfc7008,
  author="S. Kiyomoto and W. Shin",
  title="{A Description of the KCipher-2 Encryption Algorithm}",
  howpublished="RFC 7008 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7008",
  pages="1--37",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7008.txt",
  key="RFC 7008",
  abstract={This document describes the KCipher-2 encryption algorithm.  KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector.  Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies.  As of the publication of this document, no security vulnerabilities have been found.  KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation.  KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.},
  keywords="encryption, stream cipher, cipher",
  doi="10.17487/RFC7008",
  }

@misc{rfc7009,
  author="T. Lodderstedt and S. Dronia and M. Scurtescu",
  title="{OAuth 2.0 Token Revocation}",
  howpublished="RFC 7009 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7009",
  pages="1--11",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7009.txt",
  key="RFC 7009",
  abstract={This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed.  This allows the authorization server to clean up security credentials.  A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.},
  doi="10.17487/RFC7009",
  }

@misc{rfc7010,
  author="B. Liu and S. Jiang and B. Carpenter and S. Venaas and W. George",
  title="{IPv6 Site Renumbering Gap Analysis}",
  howpublished="RFC 7010 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7010",
  pages="1--26",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7010.txt",
  key="RFC 7010",
  abstract={This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.  The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate.  The gap analysis is organized by the main steps of a renumbering process.},
  doi="10.17487/RFC7010",
  }

@misc{rfc7011,
  author="B. Claise and B. Trammell and P. Aitken",
  title="{Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information}",
  howpublished="RFC 7011 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7011",
  pages="1--76",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7011.txt",
  key="RFC 7011",
  abstract={This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.},
  doi="10.17487/RFC7011",
  }

@misc{rfc7012,
  author="B. Claise and B. Trammell",
  title="{Information Model for IP Flow Information Export (IPFIX)}",
  howpublished="RFC 7012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7012",
  pages="1--24",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7012.txt",
  key="RFC 7012",
  abstract={This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol.  This information model is maintained as the IANA ``IPFIX Information Elements'' registry, the initial contents of which were defined by RFC 5102.  This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications.  This document obsoletes RFC 5102.},
  doi="10.17487/RFC7012",
  }

@misc{rfc7013,
  author="B. Trammell and B. Claise",
  title="{Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements}",
  howpublished="RFC 7013 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7013",
  pages="1--32",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7013.txt",
  key="RFC 7013",
  abstract={This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol.  It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.},
  keywords="IE-DOCTORS, IANA",
  doi="10.17487/RFC7013",
  }

@misc{rfc7014,
  author="S. D'Antonio and T. Zseby and C. Henke and L. Peluso",
  title="{Flow Selection Techniques}",
  howpublished="RFC 7014 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7014",
  pages="1--33",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7014.txt",
  key="RFC 7014",
  abstract={The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows.  The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator.  It reduces the effort of post-processing Flow data and transferring Flow Records.  This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques.  It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.},
  doi="10.17487/RFC7014",
  }

@misc{rfc7015,
  author="B. Trammell and A. Wagner and B. Claise",
  title="{Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol}",
  howpublished="RFC 7015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7015",
  pages="1--49",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7015.txt",
  key="RFC 7015",
  abstract={This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties.  It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.},
  keywords="Flow metering, Flow measurement, IPFIX mediator",
  doi="10.17487/RFC7015",
  }

@misc{rfc7016,
  author="M. Thornburgh",
  title="{Adobe's Secure Real-Time Media Flow Protocol}",
  howpublished="RFC 7016 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7016",
  pages="1--113",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7016.txt",
  key="RFC 7016",
  abstract={This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks.  RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.},
  keywords="RTMFP",
  doi="10.17487/RFC7016",
  }

@misc{rfc7017,
  author="R. Sparks",
  title="{IMAP Access to IETF Email List Archives}",
  howpublished="RFC 7017 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7017",
  pages="1--5",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7017.txt",
  key="RFC 7017",
  abstract={The IETF makes heavy use of email lists to conduct its work.  This often involves accessing the archived history of those email lists.  Participants would like to have the ability to browse and search those archives using standard IMAP clients.  This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.},
  doi="10.17487/RFC7017",
  }

@misc{rfc7018,
  author="V. Manral and S. Hanna",
  title="{Auto-Discovery VPN Problem Statement and Requirements}",
  howpublished="RFC 7018 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7018",
  pages="1--12",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7018.txt",
  key="RFC 7018",
  abstract={This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.},
  keywords="IPsec, Overlay, SDN, IKE",
  doi="10.17487/RFC7018",
  }

@misc{rfc7019,
  author="J. Buford and M. Kolberg",
  title="{Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7019 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7019",
  pages="1--41",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7019.txt",
  key="RFC 7019",
  abstract={We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast. This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).},
  keywords="application-layer multicast",
  doi="10.17487/RFC7019",
  }

@misc{rfc7020,
  author="R. Housley and J. Curran and G. Huston and D. Conrad",
  title="{The Internet Numbers Registry System}",
  howpublished="RFC 7020 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7020",
  pages="1--9",
  year=2013,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7020.txt",
  key="RFC 7020",
  abstract={This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.},
  doi="10.17487/RFC7020",
  }

@misc{rfc7021,
  author="C. Donley and L. Howard and V. Kuarsingh and J. Berg and J. Doshi",
  title="{Assessing the Impact of Carrier-Grade NAT on Network Applications}",
  howpublished="RFC 7021 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7021",
  pages="1--29",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7021.txt",
  key="RFC 7021",
  abstract={NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6.  This technology adds an extra Carrier- Grade NAT (CGN) in the Service Provider network, often resulting in two NATs.  CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment.  This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications.  This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.},
  keywords="CGN, NAT444, DS-Lite, Dual-Stack Lite, IPv4, NAT, IPv6, LSN transition",
  doi="10.17487/RFC7021",
  }

@misc{rfc7022,
  author="A. Begen and C. Perkins and D. Wing and E. Rescorla",
  title="{Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)}",
  howpublished="RFC 7022 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7022",
  pages="1--10",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7022.txt",
  key="RFC 7022",
  abstract={The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.},
  doi="10.17487/RFC7022",
  }

@misc{rfc7023,
  author="D. Mohan and N. Bitar and A. Sajassi and S. DeLord and P. Niger and R. Qiu",
  title="{MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking}",
  howpublished="RFC 7023 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7023",
  pages="1--23",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7023.txt",
  key="RFC 7023",
  abstract={This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service.  It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.},
  doi="10.17487/RFC7023",
  }

@misc{rfc7024,
  author="H. Jeng and J. Uttaro and L. Jalil and B. Decraene and Y. Rekhter and R. Aggarwal",
  title="{Virtual Hub-and-Spoke in BGP/MPLS VPNs}",
  howpublished="RFC 7024 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7024",
  pages="1--25",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7024.txt",
  key="RFC 7024",
  abstract={With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.},
  doi="10.17487/RFC7024",
  }

@misc{rfc7025,
  author="T. Otani and K. Ogaki and D. Caviglia and F. Zhang and C. Margaria",
  title="{Requirements for GMPLS Applications of PCE}",
  howpublished="RFC 7025 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7025",
  pages="1--12",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7025.txt",
  key="RFC 7025",
  abstract={The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS.  As a next step, this document describes functional requirements for GMPLS applications of PCE.},
  keywords="Path Computation, CSPF, PCC, Traffic Engineering, TE",
  doi="10.17487/RFC7025",
  }

@misc{rfc7026,
  author="A. Farrel and S. Bryant",
  title="{Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel}",
  howpublished="RFC 7026 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7026",
  pages="1--5",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7026.txt",
  key="RFC 7026",
  abstract={The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.},
  keywords="ACH, G-ACh, Pseudowire, PW, MPLS-TP",
  doi="10.17487/RFC7026",
  }

@misc{rfc7027,
  author="J. Merkle and M. Lochter",
  title="{Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)}",
  howpublished="RFC 7027 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7027",
  pages="1--10",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7027.txt",
  key="RFC 7027",
  abstract={This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.},
  keywords="TLS, Elliptic Curve Cryptography",
  doi="10.17487/RFC7027",
  }

@misc{rfc7028,
  author="JC. Zuniga and LM. Contreras and CJ. Bernardos and S. Jeon and Y. Kim",
  title="{Multicast Mobility Routing Optimizations for Proxy Mobile IPv6}",
  howpublished="RFC 7028 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7028",
  pages="1--29",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7028.txt",
  key="RFC 7028",
  abstract={This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain.  These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network.  The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.},
  keywords="multimob, PMIPv6, MTMA, selector, MLD, IGMP",
  doi="10.17487/RFC7028",
  }

@misc{rfc7029,
  author="S. Hartman and M. Wasserman and D. Zhang",
  title="{Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding}",
  howpublished="RFC 7029 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7029",
  pages="1--19",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7029.txt",
  key="RFC 7029",
  abstract={As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server.  EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information.  Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks.  However, cryptographic binding focuses on protecting the server rather than the peer.  This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.},
  keywords="MITM, man-in-the-middle, EMSK crypto binding, Extended Master Session Key, tunnel",
  doi="10.17487/RFC7029",
  }

@misc{rfc7030,
  author="M. Pritikin and P. Yee and D. Harkins",
  title="{Enrollment over Secure Transport}",
  howpublished="RFC 7030 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7030",
  pages="1--53",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7030.txt",
  key="RFC 7030",
  abstract={This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.},
  keywords="pki, est",
  doi="10.17487/RFC7030",
  }

@misc{rfc7031,
  author="T. Mrugalski and K. Kinnear",
  title="{DHCPv6 Failover Requirements}",
  howpublished="RFC 7031 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7031",
  pages="1--17",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7031.txt",
  key="RFC 7031",
  abstract={The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases.  Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure.  In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information.  RFC 3315 allows for, but does not define, any redundancy or failover mechanisms.  This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted.  This document does not define a DHCPv6 failover protocol.},
  keywords="DHCPv6, Failover",
  doi="10.17487/RFC7031",
  }

@misc{rfc7032,
  author="T. Beckhaus and B. Decraene and K. Tiruveedhula and M. Konstantynowicz and L. Martini",
  title="{LDP Downstream-on-Demand in Seamless MPLS}",
  howpublished="RFC 7032 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7032",
  pages="1--35",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7032.txt",
  key="RFC 7032",
  abstract={Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.},
  doi="10.17487/RFC7032",
  }

@misc{rfc7033,
  author="P. Jones and G. Salgueiro and M. Jones and J. Smarr",
  title="{WebFinger}",
  howpublished="RFC 7033 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7033",
  pages="1--28",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7033.txt",
  key="RFC 7033",
  abstract={This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods.  WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.},
  keywords="WebFinger, JRD,  JSON Resource Descriptor, service discovery, service discovery protocol, information discovery, information discovery protocol",
  doi="10.17487/RFC7033",
  }

@misc{rfc7034,
  author="D. Ross and T. Gondrom",
  title="{HTTP Header Field X-Frame-Options}",
  howpublished="RFC 7034 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7034",
  pages="1--14",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7034.txt",
  key="RFC 7034",
  abstract={To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.},
  keywords="frame-options, HTTP header, websec",
  doi="10.17487/RFC7034",
  }

@misc{rfc7035,
  author="M. Thomson and B. Rosen and D. Stanley and G. Bajko and A. Thomson",
  title="{Relative Location Representation}",
  howpublished="RFC 7035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7035",
  pages="1--39",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7035.txt",
  key="RFC 7035",
  abstract={This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.},
  keywords="Relative, location",
  doi="10.17487/RFC7035",
  }

@misc{rfc7036,
  author="R. Housley",
  title="{Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group}",
  howpublished="RFC 7036 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7036",
  pages="1--7",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7036.txt",
  key="RFC 7036",
  abstract={When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group.  This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.},
  doi="10.17487/RFC7036",
  }

@misc{rfc7037,
  author="L. Yeh and M. Boucadair",
  title="{RADIUS Option for the DHCPv6 Relay Agent}",
  howpublished="RFC 7037 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7037",
  pages="1--10",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7037.txt",
  key="RFC 7037",
  abstract={The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server.  This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client.  When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server.  The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.},
  keywords="DHCPv6, RADIUS",
  doi="10.17487/RFC7037",
  }

@misc{rfc7038,
  author="R. Ogier",
  title="{Use of OSPF-MDR in Single-Hop Broadcast Networks}",
  howpublished="RFC 7038 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7038",
  pages="1--7",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7038.txt",
  key="RFC 7038",
  abstract={RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET.  This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router.  Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.  The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.},
  keywords="routing, mobile ad hoc network, MANET designated router, wireless, point-to-multipoint interface",
  doi="10.17487/RFC7038",
  }

@misc{rfc7039,
  author="J. Wu and J. Bi and M. Bagnulo and F. Baker and C. Vogt",
  title="{Source Address Validation Improvement (SAVI) Framework}",
  howpublished="RFC 7039 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7039",
  pages="1--14",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7039.txt",
  key="RFC 7039",
  abstract={Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation.  This document is a framework document that describes and motivates the design of the SAVI methods.  Particular SAVI methods are described in other documents.},
  keywords="anti-spoofing, BCP38, ingress filtering",
  doi="10.17487/RFC7039",
  }

@misc{rfc7040,
  author="Y. Cui and J. Wu and P. Wu and O. Vautrin and Y. Lee",
  title="{Public IPv4-over-IPv6 Access Network}",
  howpublished="RFC 7040 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7040",
  pages="1--13",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7040.txt",
  key="RFC 7040",
  abstract={This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses.  Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments.  Future deployments of similar scenarios should use Lightweight 4over6.  Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network.  The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay.  Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.},
  keywords="Public 4over6, IPv4 over IPv6, Access Network, DHCPv4 over IPv6, IPv6 Tunnel, IPv6 Transition",
  doi="10.17487/RFC7040",
  }

@misc{rfc7041,
  author="F. Balus and A. Sajassi and N. Bitar",
  title="{Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging}",
  howpublished="RFC 7041 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7041",
  pages="1--15",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7041.txt",
  key="RFC 7041",
  abstract={The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported. The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.},
  doi="10.17487/RFC7041",
  }

@misc{rfc7042,
  author="D. {Eastlake 3rd} and J. Abley",
  title="{IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters}",
  howpublished="RFC 7042 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7042",
  pages="1--27",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7042.txt",
  key="RFC 7042",
  abstract={Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation.  This document obsoletes RFC 5342.},
  keywords="Ethernet, Ethertype, 802, OUI, EUI, LSAP",
  doi="10.17487/RFC7042",
  }

@misc{rfc7043,
  author="J. Abley",
  title="{Resource Records for EUI-48 and EUI-64 Addresses in the DNS}",
  howpublished="RFC 7043 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7043",
  pages="1--8",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7043.txt",
  key="RFC 7043",
  abstract={48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet. This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS. This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.},
  keywords="IEEE, ethernet",
  doi="10.17487/RFC7043",
  }

@misc{rfc7044,
  author="M. Barnes and F. Audet and S. Schubert and J. van Elburg and C. Holmberg",
  title="{An Extension to the Session Initiation Protocol (SIP) for Request History Information}",
  howpublished="RFC 7044 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7044",
  pages="1--36",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7044.txt",
  key="RFC 7044",
  abstract={This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request.  This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user.  This document defines an optional SIP header field, History-Info, for capturing the history information in requests.  The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined.  In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field.  This document obsoletes RFC 4244.},
  keywords="history-info, retarget, enhanced services, voicemail, automatic call distribution",
  doi="10.17487/RFC7044",
  }

@misc{rfc7045,
  author="B. Carpenter and S. Jiang",
  title="{Transmission and Processing of IPv6 Extension Headers}",
  howpublished="RFC 7045 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7045",
  pages="1--10",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7045.txt",
  key="RFC 7045",
  abstract={Various IPv6 extension headers have been standardised since the IPv6 standard was first published.  This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.  It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.},
  doi="10.17487/RFC7045",
  }

@misc{rfc7046,
  author="M. Waehlisch and T. Schmidt and S. Venaas",
  title="{A Common API for Transparent Hybrid Multicast}",
  howpublished="RFC 7046 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7046",
  pages="1--41",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7046.txt",
  key="RFC 7046",
  abstract={Group communication services exist in a large variety of flavors and technical implementations at different protocol layers.  Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime.  Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network.  Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself.  This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast.  It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies.  Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet.  It reports on an implementation of the programming Interface, including service middleware.  This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.},
  keywords="Peer-to-Peer (P2P), adaptive multicast, multicast  naming, multicast addressing",
  doi="10.17487/RFC7046",
  }

@misc{rfc7047,
  author="B. Pfaff and B. Davie",
  title="{The Open vSwitch Database Management Protocol}",
  howpublished="RFC 7047 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7047",
  pages="1--35",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7047.txt",
  key="RFC 7047",
  abstract={Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments.  A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network.  Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol.  This document defines the OVSDB management protocol.  The Open vSwitch project includes open-source OVSDB client and server implementations.},
  keywords="vswitch, virtualization, overlay, OVS",
  doi="10.17487/RFC7047",
  }

@misc{rfc7048,
  author="E. Nordmark and I. Gashinsky",
  title="{Neighbor Unreachability Detection Is Too Impatient}",
  howpublished="RFC 7048 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7048",
  pages="1--8",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7048.txt",
  key="RFC 7048",
  abstract={IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.  That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time.  By default, this time is 3 seconds after the node starts probing.  However, if there are no alternative neighbors, this timeout behavior is far too impatient.  This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors.  This document updates RFC 4861.},
  keywords="6MAN, IPv6, Neighbor Discovery",
  doi="10.17487/RFC7048",
  }

@misc{rfc7049,
  author="C. Bormann and P. Hoffman",
  title="{Concise Binary Object Representation (CBOR)}",
  howpublished="RFC 7049 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7049",
  pages="1--54",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7049.txt",
  key="RFC 7049",
  abstract={The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.  These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.},
  keywords="parser, encoder, binary format, data interchange format, JSON",
  doi="10.17487/RFC7049",
  }

@misc{rfc7050,
  author="T. Savolainen and J. Korhonen and D. Wing",
  title="{Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis}",
  howpublished="RFC 7050 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7050",
  pages="1--22",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7050.txt",
  key="RFC 7050",
  abstract={This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network.  The method depends on the existence of a well-known IPv4-only fully qualified domain name ``ipv4only.arpa.''.  The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.},
  keywords="NAT64, DNS64, 464XLAT, Pref64::/n",
  doi="10.17487/RFC7050",
  }

@misc{rfc7051,
  author="J. Korhonen and T. Savolainen",
  title="{Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix}",
  howpublished="RFC 7051 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7051",
  pages="1--25",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7051.txt",
  key="RFC 7051",
  abstract={Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network.  This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64.  These solutions enable both NAT64 avoidance and local IPv6 address synthesis.  The document concludes by recommending the standardization of the approach based on heuristic discovery.},
  keywords="NAT64, DNS64, 464XLAT, Pref64::/n",
  doi="10.17487/RFC7051",
  }

@misc{rfc7052,
  author="G. Schudel and A. Jain and V. Moreno",
  title="{Locator/ID Separation Protocol (LISP) MIB}",
  howpublished="RFC 7052 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7052",
  pages="1--66",
  year=2013,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7052.txt",
  key="RFC 7052",
  abstract={This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP).  These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.},
  doi="10.17487/RFC7052",
  }

@misc{rfc7053,
  author="M. Tuexen and I. Ruengeler and R. Stewart",
  title="{SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol}",
  howpublished="RFC 7053 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7053",
  pages="1--8",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7053.txt",
  key="RFC 7053",
  abstract={This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed.  It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack.  Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.},
  doi="10.17487/RFC7053",
  }

@misc{rfc7054,
  author="A. Farrel and H. Endo and R. Winter and Y. Koike and M. Paul",
  title="{Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)}",
  howpublished="RFC 7054 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7054",
  pages="1--11",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7054.txt",
  key="RFC 7054",
  abstract={The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.},
  doi="10.17487/RFC7054",
  }

@misc{rfc7055,
  author="S. Hartman and J. Howlett",
  title="{A GSS-API Mechanism for the Extensible Authentication Protocol}",
  howpublished="RFC 7055 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7055",
  pages="1--35",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7055.txt",
  key="RFC 7055",
  abstract={This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism.  Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.},
  doi="10.17487/RFC7055",
  }

@misc{rfc7056,
  author="S. Hartman and J. Howlett",
  title="{Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism}",
  howpublished="RFC 7056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7056",
  pages="1--11",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7056.txt",
  key="RFC 7056",
  abstract={The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names.  The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response.  It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response.  This document describes how to use the Naming Extensions API to access that information.},
  doi="10.17487/RFC7056",
  }

@misc{rfc7057,
  author="S. Winter and J. Salowey",
  title="{Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)}",
  howpublished="RFC 7057 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7057",
  pages="1--7",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7057.txt",
  key="RFC 7057",
  abstract={This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.},
  keywords="EAP, AAA",
  doi="10.17487/RFC7057",
  }

@misc{rfc7058,
  author="A. Amirante and T. Castaldi and L. Miniero and S P. Romano",
  title="{Media Control Channel Framework (CFW) Call Flow Examples}",
  howpublished="RFC 7058 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7058",
  pages="1--182",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7058.txt",
  key="RFC 7058",
  abstract={This document provides a list of typical Media Control Channel Framework call flows.  It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.},
  keywords="MediaCtrl, Media Server Control, Media Control Channel Framework",
  doi="10.17487/RFC7058",
  }

@misc{rfc7059,
  author="S. Steffann and I. van Beijnum and R. van Rein",
  title="{A Comparison of IPv6-over-IPv4 Tunnel Mechanisms}",
  howpublished="RFC 7059 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7059",
  pages="1--41",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7059.txt",
  key="RFC 7059",
  abstract={This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks.  It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication.  The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.},
  doi="10.17487/RFC7059",
  }

@misc{rfc7060,
  author="M. Napierala and E. Rosen and IJ. Wijnands",
  title="{Using LDP Multipoint Extensions on Targeted LDP Sessions}",
  howpublished="RFC 7060 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7060",
  pages="1--9",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7060.txt",
  key="RFC 7060",
  abstract={Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths.  However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected.  The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a ``Targeted LDP'' session.  This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.},
  doi="10.17487/RFC7060",
  }

@misc{rfc7061,
  author="R. Sinnema and E. Wilde",
  title="{eXtensible Access Control Markup Language (XACML) XML Media Type}",
  howpublished="RFC 7061 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7061",
  pages="1--8",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7061.txt",
  key="RFC 7061",
  abstract={This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).},
  doi="10.17487/RFC7061",
  }

@misc{rfc7062,
  author="F. Zhang and D. Li and H. Li and S. Belotti and D. Ceccarelli",
  title="{Framework for GMPLS and PCE Control of G.709 Optical Transport Networks}",
  howpublished="RFC 7062 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7062",
  pages="1--26",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7062.txt",
  key="RFC 7062",
  abstract={This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.},
  doi="10.17487/RFC7062",
  }

@misc{rfc7063,
  author="L. Zheng and J. Zhang and R. Parekh",
  title="{Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments}",
  howpublished="RFC 7063 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7063",
  pages="1--12",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7063.txt",
  key="RFC 7063",
  abstract={This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.},
  doi="10.17487/RFC7063",
  }

@misc{rfc7064,
  author="S. Nandakumar and G. Salgueiro and P. Jones and M. Petit-Huguenin",
  title="{URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol}",
  howpublished="RFC 7064 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7064",
  pages="1--9",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7064.txt",
  key="RFC 7064",
  abstract={This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.},
  doi="10.17487/RFC7064",
  }

@misc{rfc7065,
  author="M. Petit-Huguenin and S. Nandakumar and G. Salgueiro and P. Jones",
  title="{Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers}",
  howpublished="RFC 7065 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7065",
  pages="1--9",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7065.txt",
  key="RFC 7065",
  abstract={This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol.  It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).},
  doi="10.17487/RFC7065",
  }

@misc{rfc7066,
  author="J. Korhonen and J. Arkko and T. Savolainen and S. Krishnan",
  title="{IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts}",
  howpublished="RFC 7066 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7066",
  pages="1--20",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7066.txt",
  key="RFC 7066",
  abstract={As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet.  Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications.  However, the concept of IPv6 covers many aspects and numerous specifications.  In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used.  This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks).  This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434).  It also discusses some issues related to the use of these components when operating in these networks.  This document obsoletes RFC 3316.},
  doi="10.17487/RFC7066",
  }

@misc{rfc7067,
  author="L. Dunbar and D. {Eastlake 3rd} and R. Perlman and I. Gashinsky",
  title="{Directory Assistance Problem and High-Level Design Proposal}",
  howpublished="RFC 7067 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7067",
  pages="1--15",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7067.txt",
  key="RFC 7067",
  abstract={Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC\&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus. This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.},
  keywords="TRILL, Orchestration, Directory, Push, Pull, RBridge, ARP",
  doi="10.17487/RFC7067",
  }

@misc{rfc7068,
  author="E. McMurry and B. Campbell",
  title="{Diameter Overload Control Requirements}",
  howpublished="RFC 7068 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7068",
  pages="1--29",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7068.txt",
  key="RFC 7068",
  abstract={When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time.  Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition.  The existing Diameter mechanisms are not sufficient for managing overload conditions.  This document describes the limitations of the existing mechanisms.  Requirements for new overload management mechanisms are also provided.},
  doi="10.17487/RFC7068",
  }

@misc{rfc7069,
  author="R. Alimi and A. Rahman and D. Kutscher and Y. Yang and H. Song and K. Pentikousis",
  title="{DECoupled Application Data Enroute (DECADE)}",
  howpublished="RFC 7069 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7069",
  pages="1--35",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7069.txt",
  key="RFC 7069",
  abstract={Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks.  Often, however, content distribution applications use network resources inefficiently.  One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms.  This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document.  DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources.  This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.},
  keywords="decade",
  doi="10.17487/RFC7069",
  }

@misc{rfc7070,
  author="N. Borenstein and M. Kucherawy",
  title="{An Architecture for Reputation Reporting}",
  howpublished="RFC 7070 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7070",
  pages="1--14",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7070.txt",
  key="RFC 7070",
  abstract={This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where ``reputation'' refers to predictions or expectations about an entity or an identifier such as a domain name.  The document roughly follows the recommendations of RFC 4101 for describing a protocol model.},
  keywords="domain, security, messaging, dkim, spf, authentication, reputation",
  doi="10.17487/RFC7070",
  }

@misc{rfc7071,
  author="N. Borenstein and M. Kucherawy",
  title="{A Media Type for Reputation Interchange}",
  howpublished="RFC 7071 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7071",
  pages="1--17",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7071.txt",
  key="RFC 7071",
  abstract={This document defines the format of reputation response data (``reputons''), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.},
  keywords="reputation, domain, security, messaging, dkim, spf, authentication",
  doi="10.17487/RFC7071",
  }

@misc{rfc7072,
  author="N. Borenstein and M. Kucherawy",
  title="{A Reputation Query Protocol}",
  howpublished="RFC 7072 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7072",
  pages="1--9",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7072.txt",
  key="RFC 7072",
  abstract={This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.},
  keywords="reputation, domain, security, messaging, dkim, spf, authentication",
  doi="10.17487/RFC7072",
  }

@misc{rfc7073,
  author="N. Borenstein and M. Kucherawy",
  title="{A Reputation Response Set for Email Identifiers}",
  howpublished="RFC 7073 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7073",
  pages="1--8",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7073.txt",
  key="RFC 7073",
  abstract={This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.},
  keywords="reputation, domain, security, messaging, dkim, spf, authentication",
  doi="10.17487/RFC7073",
  }

@misc{rfc7074,
  author="L. Berger and J. Meuric",
  title="{Revised Definition of the GMPLS Switching Capability and Type Fields}",
  howpublished="RFC 7074 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7074",
  pages="1--9",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7074.txt",
  key="RFC 7074",
  abstract={GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology.  GMPLS routing and signaling use common values to indicate the type of switching technology.  These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field.  While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS.  This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields.  This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.},
  doi="10.17487/RFC7074",
  }

@misc{rfc7075,
  author="T. Tsou and R. Hao and T. Taylor",
  title="{Realm-Based Redirection In Diameter}",
  howpublished="RFC 7075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7075",
  pages="1--10",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7075.txt",
  key="RFC 7075",
  abstract={The Diameter protocol includes a capability for message redirection, controlled by an application-independent ``redirect agent''. In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a ``Realm-based Redirect Server''. This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).},
  keywords="Diameter, routing",
  doi="10.17487/RFC7075",
  }

@misc{rfc7076,
  author="M. Joseph and J. Susoy",
  title="{P6R's Secure Shell Public Key Subsystem}",
  howpublished="RFC 7076 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7076",
  pages="1--11",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7076.txt",
  key="RFC 7076",
  abstract={The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport. The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)). The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace). Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.},
  keywords="key management, certificate management, security",
  doi="10.17487/RFC7076",
  }

@misc{rfc7077,
  author="S. Krishnan and S. Gundavelli and M. Liebsch and H. Yokota and J. Korhonen",
  title="{Update Notifications for Proxy Mobile IPv6}",
  howpublished="RFC 7077 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7077",
  pages="1--21",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7077.txt",
  key="RFC 7077",
  abstract={This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session.  These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.},
  keywords="MIPv6",
  doi="10.17487/RFC7077",
  }

@misc{rfc7078,
  author="A. Matsumoto and T. Fujisaki and T. Chown",
  title="{Distributing Address Selection Policy Using DHCPv6}",
  howpublished="RFC 7078 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7078",
  pages="1--12",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7078.txt",
  key="RFC 7078",
  abstract={RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between.  RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information.  This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.},
  doi="10.17487/RFC7078",
  }

@misc{rfc7079,
  author="N. Del Regno and A. Malis",
  title="{The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results}",
  howpublished="RFC 7079 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7079",
  pages="1--41",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7079.txt",
  key="RFC 7079",
  abstract={The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data.  In most of these encapsulations, use of the Pseudowire (PW) Control Word is required.  However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations.  This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.},
  keywords="Control Word (CW), Control Channel (CC)",
  doi="10.17487/RFC7079",
  }

@misc{rfc7080,
  author="A. Sajassi and S. Salam and N. Bitar and F. Balus",
  title="{Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges}",
  howpublished="RFC 7080 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7080",
  pages="1--26",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7080.txt",
  key="RFC 7080",
  abstract={The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access.  Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008.  It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks.  This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances.  The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them.  Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.},
  keywords="h-vpls",
  doi="10.17487/RFC7080",
  }

@misc{rfc7081,
  author="E. Ivov and P. Saint-Andre and E. Marocco",
  title="{CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 7081 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7081",
  pages="1--19",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7081.txt",
  key="RFC 7081",
  abstract={This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers.  Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP.  Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP.  This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize ``best current practices''.  Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.},
  keywords="real-time communication, unified communication, voice, video, instant messaging, chat, presence, telephony",
  doi="10.17487/RFC7081",
  }

@misc{rfc7082,
  author="R. Shekh-Yusef and M. Barnes",
  title="{Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)}",
  howpublished="RFC 7082 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7082",
  pages="1--10",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7082.txt",
  key="RFC 7082",
  abstract={The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference. This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the ``purpose'' header field parameter in the <service-uris> element in the SIP conferencing event package.},
  doi="10.17487/RFC7082",
  }

@misc{rfc7083,
  author="R. Droms",
  title="{Modification to Default Values of SOL\_MAX\_RT and INF\_MAX\_RT}",
  howpublished="RFC 7083 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7083",
  pages="1--7",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7083.txt",
  key="RFC 7083",
  abstract={This document updates RFC 3315 by redefining the default values for SOL\_MAX\_RT and INF\_MAX\_RT and defining options through which a DHCPv6 server can override the client's default value for SOL\_MAX\_RT and INF\_MAX\_RT with new values.},
  doi="10.17487/RFC7083",
  }

@misc{rfc7084,
  author="H. Singh and W. Beebee and C. Donley and B. Stark",
  title="{Basic Requirements for IPv6 Customer Edge Routers}",
  howpublished="RFC 7084 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7084",
  pages="1--21",
  year=2013,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7084.txt",
  key="RFC 7084",
  abstract={This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  The document also covers IP transition technologies.  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document.  The document obsoletes RFC 6204.},
  keywords="6rd, DS-Lite",
  doi="10.17487/RFC7084",
  }

@misc{rfc7085,
  author="J. Levine and P. Hoffman",
  title="{Top-Level Domains That Are Already Dotless}",
  howpublished="RFC 7085 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7085",
  pages="1--6",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7085.txt",
  key="RFC 7085",
  abstract={Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called ``dotless domains'').  In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them.  This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.},
  keywords="DNS",
  doi="10.17487/RFC7085",
  }

@misc{rfc7086,
  author="A. Keranen and G. Camarillo and J. Maenpaa",
  title="{Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7086 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7086",
  pages="1--10",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7086.txt",
  key="RFC 7086",
  abstract={This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol.  The document provides the details needed to build a RELOAD-based overlay that uses HIP.},
  keywords="HIP, overlay, P2P",
  doi="10.17487/RFC7086",
  }

@misc{rfc7087,
  author="H. van Helvoort and L. Andersson and N. Sprecher",
  title="{A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations}",
  howpublished="RFC 7087 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7087",
  pages="1--21",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7087.txt",
  key="RFC 7087",
  abstract={The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.},
  doi="10.17487/RFC7087",
  }

@misc{rfc7088,
  author="D. Worley",
  title="{Session Initiation Protocol Service Example -- Music on Hold}",
  howpublished="RFC 7088 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7088",
  pages="1--36",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7088.txt",
  key="RFC 7088",
  abstract={``Music on hold'' is one of the features of telephone systems that is most desired by buyers of business telephone systems.  Music on hold means that when one party to a call has the call ``on hold'', that party's telephone provides an audio stream (often music) to be heard by the other party.  Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant.  The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented.  In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.},
  keywords="Music on hold",
  doi="10.17487/RFC7088",
  }

@misc{rfc7089,
  author="H. Van de Sompel and M. Nelson and R. Sanderson",
  title="{HTTP Framework for Time-Based Access to Resource States -- Memento}",
  howpublished="RFC 7089 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7089",
  pages="1--50",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7089.txt",
  key="RFC 7089",
  abstract={The HTTP-based Memento framework bridges the present and past Web.  It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps.  Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime.  TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource.  The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.},
  keywords="HTTP, content negotiation, datetime negotiation, resource versions, archival resources, Memento",
  doi="10.17487/RFC7089",
  }

@misc{rfc7090,
  author="H. Schulzrinne and H. Tschofenig and C. Holmberg and M. Patel",
  title="{Public Safety Answering Point (PSAP) Callback}",
  howpublished="RFC 7090 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7090",
  pages="1--18",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7090.txt",
  key="RFC 7090",
  abstract={After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called ``psap-callback'', to mark PSAP callbacks.},
  keywords="PSAP, callback, SIP, emergency, VoIP",
  doi="10.17487/RFC7090",
  }

@misc{rfc7091,
  author="V. Dolmatov and A. Degtyarev",
  title="{GOST R 34.10-2012: Digital Signature Algorithm}",
  howpublished="RFC 7091 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7091",
  pages="1--21",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7091.txt",
  key="RFC 7091",
  abstract={This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification.  This document updates RFC 5832.},
  doi="10.17487/RFC7091",
  }

@misc{rfc7092,
  author="H. Kaplan and V. Pascual",
  title="{A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents}",
  howpublished="RFC 7092 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7092",
  pages="1--10",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7092.txt",
  key="RFC 7092",
  abstract={In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC). There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.},
  keywords="SIP, B2BUA, taxonomy",
  doi="10.17487/RFC7092",
  }

@misc{rfc7093,
  author="S. Turner and S. Kent and J. Manger",
  title="{Additional Methods for Generating Key Identifiers Values}",
  howpublished="RFC 7093 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7093",
  pages="1--5",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7093.txt",
  key="RFC 7093",
  abstract={This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.},
  doi="10.17487/RFC7093",
  }

@misc{rfc7094,
  author="D. McPherson and D. Oran and D. Thaler and E. Osterweil",
  title="{Architectural Considerations of IP Anycast}",
  howpublished="RFC 7094 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7094",
  pages="1--22",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7094.txt",
  key="RFC 7094",
  abstract={This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.},
  keywords="anycast, architecture",
  doi="10.17487/RFC7094",
  }

@misc{rfc7095,
  author="P. Kewisch",
  title="{jCard: The JSON Format for vCard}",
  howpublished="RFC 7095 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7095",
  pages="1--29",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7095.txt",
  key="RFC 7095",
  abstract={This specification defines ``jCard'', a JSON format for vCard data.  The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.},
  keywords="jCard, JSON, vCard, addressbook, contacts, CardDAV, PIM",
  doi="10.17487/RFC7095",
  }

@misc{rfc7096,
  author="S. Belotti and P. Grandi and D. Ceccarelli and D. Caviglia and F. Zhang and D. Li",
  title="{Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)}",
  howpublished="RFC 7096 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7096",
  pages="1--23",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7096.txt",
  key="RFC 7096",
  abstract={ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.},
  keywords="Routing, CCAMP Working Group, OSPF, GMPLS, G709, OTN",
  doi="10.17487/RFC7096",
  }

@misc{rfc7097,
  author="J. Ott and V. Singh and I. Curcio",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets}",
  howpublished="RFC 7097 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7097",
  pages="1--11",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7097.txt",
  key="RFC 7097",
  abstract={The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics.  The available reporting may include aggregate information across longer periods of time as well as individual packet reporting.  This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.},
  keywords="RTP, RTCP, discard metrics",
  doi="10.17487/RFC7097",
  }

@misc{rfc7098,
  author="B. Carpenter and S. Jiang and W. Tarreau",
  title="{Using the IPv6 Flow Label for Load Balancing in Server Farms}",
  howpublished="RFC 7098 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7098",
  pages="1--13",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7098.txt",
  key="RFC 7098",
  abstract={This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.},
  keywords="ECMP",
  doi="10.17487/RFC7098",
  }

@misc{rfc7100,
  author="P. Resnick",
  title="{Retirement of the ``Internet Official Protocol Standards'' Summary Document}",
  howpublished="RFC 7100 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7100",
  pages="1--3",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7100.txt",
  key="RFC 7100",
  abstract={This document updates RFC 2026 to no longer use STD 1 as a summary of ``Internet Official Protocol Standards''.  It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.},
  doi="10.17487/RFC7100",
  }

@misc{rfc7101,
  author="S. Ginoza",
  title="{List of Internet Official Protocol Standards: Replaced by a Web Page}",
  howpublished="RFC 7101 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7101",
  pages="1--4",
  year=2013,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7101.txt",
  key="RFC 7101",
  abstract={At one time, the RFC Editor published snapshots of the ``Internet Official Protocol Standards''.  These documents were known as xx00 documents, the last of which was published in May 2008.  These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs.  As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued.  Starting with the RFC number 7100, xx00 numbers will be available for assignment.},
  doi="10.17487/RFC7101",
  }

@misc{rfc7102,
  author="JP. Vasseur",
  title="{Terms Used in Routing for Low-Power and Lossy Networks}",
  howpublished="RFC 7102 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7102",
  pages="1--8",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7102.txt",
  key="RFC 7102",
  abstract={This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.},
  doi="10.17487/RFC7102",
  }

@misc{rfc7103,
  author="M. Kucherawy and G. Shapiro and N. Freed",
  title="{Advice for Safe Handling of Malformed Messages}",
  howpublished="RFC 7103 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7103",
  pages="1--24",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7103.txt",
  key="RFC 7103",
  abstract={Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications.  The malformed messages that result are non-standard.  Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant.  This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.},
  keywords="MTA, SMTP",
  doi="10.17487/RFC7103",
  }

@misc{rfc7104,
  author="A. Begen and Y. Cai and H. Ou",
  title="{Duplication Grouping Semantics in the Session Description Protocol}",
  howpublished="RFC 7104 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7104",
  pages="1--10",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7104.txt",
  key="RFC 7104",
  abstract={Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages.  This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers.  One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams.  This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP).  The semantics defined in this document are to be used with the SDP Grouping Framework.  Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.},
  keywords="SDP, ssrc, synchronization source, grouping framework",
  doi="10.17487/RFC7104",
  }

@misc{rfc7105,
  author="M. Thomson and J. Winterbottom",
  title="{Using Device-Provided Location-Related Measurements in Location Configuration Protocols}",
  howpublished="RFC 7105 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7105",
  pages="1--74",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7105.txt",
  key="RFC 7105",
  abstract={This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information.  Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment.  A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device.  A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.},
  keywords="HELD, Location, Measurements, Device-based",
  doi="10.17487/RFC7105",
  }

@misc{rfc7106,
  author="E. Ivov",
  title="{A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State}",
  howpublished="RFC 7106 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7106",
  pages="1--6",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7106.txt",
  key="RFC 7106",
  abstract={This document defines and registers a value of ``grouptextchat'' (``Group Text Chat'') for the URI <purpose> element of SIP's Conference Event Package.},
  keywords="SIP, Conference Event Package, service-uris, conference-uris, URI purpose",
  doi="10.17487/RFC7106",
  }

@misc{rfc7107,
  author="R. Housley",
  title="{Object Identifier Registry for the S/MIME Mail Security Working Group}",
  howpublished="RFC 7107 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7107",
  pages="1--18",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7107.txt",
  key="RFC 7107",
  abstract={When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group.  This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.},
  doi="10.17487/RFC7107",
  }

@misc{rfc7108,
  author="J. Abley and T. Manderson",
  title="{A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes}",
  howpublished="RFC 7108 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7108",
  pages="1--11",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7108.txt",
  key="RFC 7108",
  abstract={Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion. Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency. This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.},
  doi="10.17487/RFC7108",
  }

@misc{rfc7109,
  author="H. Yokota and D. Kim and B. Sarikaya and F. Xia",
  title="{Flow Bindings Initiated by Home Agents for Mobile IPv6}",
  howpublished="RFC 7109 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7109",
  pages="1--18",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7109.txt",
  key="RFC 7109",
  abstract={There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability.  In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6.  Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.},
  keywords="MIPv6, Flow mobility",
  doi="10.17487/RFC7109",
  }

@misc{rfc7110,
  author="M. Chen and W. Cao and S. Ning and F. Jounay and S. Delord",
  title="{Return Path Specified Label Switched Path (LSP) Ping}",
  howpublished="RFC 7110 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7110",
  pages="1--21",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7737",
url="https://www.rfc-editor.org/rfc/rfc7110.txt",
  key="RFC 7110",
  abstract={This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as ``LSP ping''.  These extensions allow a selection of the LSP to be used for the echo reply return path.  Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.},
  keywords="Tunnel Stack, Reply TC",
  doi="10.17487/RFC7110",
  }

@misc{rfc7111,
  author="M. Hausenblas and E. Wilde and J. Tennison",
  title="{URI Fragment Identifiers for the text/csv Media Type}",
  howpublished="RFC 7111 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7111",
  pages="1--13",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7111.txt",
  key="RFC 7111",
  abstract={This memo defines URI fragment identifiers for text/csv MIME entities.  These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell.  Fragment identification can use single items or ranges.},
  keywords="mime",
  doi="10.17487/RFC7111",
  }

@misc{rfc7112,
  author="F. Gont and V. Manral and R. Bonica",
  title="{Implications of Oversized IPv6 Header Chains}",
  howpublished="RFC 7112 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7112",
  pages="1--8",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7112.txt",
  key="RFC 7112",
  abstract={The IPv6 specification allows IPv6 Header Chains of an arbitrary size.  The specification also allows options that can, in turn, extend each of the headers.  In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain.  This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.},
  doi="10.17487/RFC7112",
  }

@misc{rfc7113,
  author="F. Gont",
  title="{Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)}",
  howpublished="RFC 7113 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7113",
  pages="1--13",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7113.txt",
  key="RFC 7113",
  abstract={The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages.  Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors.  However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers.  This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.},
  doi="10.17487/RFC7113",
  }

@misc{rfc7114,
  author="B. Leiba",
  title="{Creation of a Registry for smime-type Parameter Values}",
  howpublished="RFC 7114 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7114",
  pages="1--4",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7114.txt",
  key="RFC 7114",
  abstract={Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter ``smime-type''.  As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values.  This document creates the registry, registers the current values, and specifies the policies for registration of new values.},
  doi="10.17487/RFC7114",
  }

@misc{rfc7115,
  author="R. Bush",
  title="{Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)}",
  howpublished="RFC 7115 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7115",
  pages="1--11",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7115.txt",
  key="RFC 7115",
  abstract={Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations.  This document attempts to collect and present those that are most critical.  It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.},
  doi="10.17487/RFC7115",
  }

@misc{rfc7116,
  author="K. Scott and M. Blanchet",
  title="{Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries}",
  howpublished="RFC 7116 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7116",
  pages="1--10",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7116.txt",
  key="RFC 7116",
  abstract={The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).  Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type.  All of these fields are subject to a registry.  For the purpose of its research work, the group has created ad hoc registries.  As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management.  This document describes the necessary IANA actions.},
  doi="10.17487/RFC7116",
  }

@misc{rfc7117,
  author="R. Aggarwal and Y. Kamite and L. Fang and Y. Rekhter and C. Kodeboniya",
  title="{Multicast in Virtual Private LAN Service (VPLS)}",
  howpublished="RFC 7117 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7117",
  pages="1--50",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7117.txt",
  key="RFC 7117",
  abstract={RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported. This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.},
  doi="10.17487/RFC7117",
  }

@misc{rfc7118,
  author="I. Baz Castillo and J. Millan Villegas and V. Pascual",
  title="{The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 7118 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7118",
  pages="1--25",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7118.txt",
  key="RFC 7118",
  abstract={The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications.  This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.},
  keywords="SIP, WebSocket",
  doi="10.17487/RFC7118",
  }

@misc{rfc7119,
  author="B. Claise and A. Kobayashi and B. Trammell",
  title="{Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators}",
  howpublished="RFC 7119 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7119",
  pages="1--32",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7119.txt",
  key="RFC 7119",
  abstract={This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.},
  doi="10.17487/RFC7119",
  }

@misc{rfc7120,
  author="M. Cotton",
  title="{Early IANA Allocation of Standards Track Code Points}",
  howpublished="RFC 7120 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7120",
  pages="1--9",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7120.txt",
  key="RFC 7120",
  abstract={This memo describes the process for early allocation of code points by IANA from registries for which ``Specification Required'', ``RFC Required'', ``IETF Review'', or ``Standards Action'' policies apply.  This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation.  The procedures in this document are intended to apply only to IETF Stream documents.},
  keywords="early allocation, policy, protocol",
  doi="10.17487/RFC7120",
  }

@misc{rfc7121,
  author="K. Ogawa and W. Wang and E. Haleplidis and J. Hadi Salim",
  title="{High Availability within a Forwarding and Control Element Separation (ForCES) Network Element}",
  howpublished="RFC 7121 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7121",
  pages="1--31",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7391",
url="https://www.rfc-editor.org/rfc/rfc7121.txt",
  key="RFC 7121",
  abstract={This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE).  Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.},
  keywords="ForCES, HA",
  doi="10.17487/RFC7121",
  }

@misc{rfc7122,
  author="H. Kruse and S. Jero and S. Ostermann",
  title="{Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)}",
  howpublished="RFC 7122 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7122",
  pages="1--11",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7122.txt",
  key="RFC 7122",
  abstract={This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams.  It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326).  UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed.  UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control.  DCCP addresses the congestion control problem, and its use is recommended whenever possible.  This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.},
  doi="10.17487/RFC7122",
  }

@misc{rfc7123,
  author="F. Gont and W. Liu",
  title="{Security Implications of IPv6 on IPv4 Networks}",
  howpublished="RFC 7123 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7123",
  pages="1--19",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7123.txt",
  key="RFC 7123",
  abstract={This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on ``IPv4-only'' networks and describes possible mitigations for the aforementioned issues.},
  doi="10.17487/RFC7123",
  }

@misc{rfc7124,
  author="E. Beili",
  title="{Ethernet in the First Mile Copper (EFMCu) Interfaces MIB}",
  howpublished="RFC 7124 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7124",
  pages="1--6",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7124.txt",
  key="RFC 7124",
  abstract={This document updates RFC 5066.  It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.},
  keywords="EFM-CU-MIB, ieee",
  doi="10.17487/RFC7124",
  }

@misc{rfc7125,
  author="B. Trammell and P. Aitken",
  title="{Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element}",
  howpublished="RFC 7125 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7125",
  pages="1--6",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7125.txt",
  key="RFC 7125",
  abstract={This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.},
  doi="10.17487/RFC7125",
  }

@misc{rfc7126,
  author="F. Gont and R. Atkinson and C. Pignataro",
  title="{Recommendations on Filtering of IPv4 Packets Containing IPv4 Options}",
  howpublished="RFC 7126 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7126",
  pages="1--36",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7126.txt",
  key="RFC 7126",
  abstract={This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain.  Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.},
  doi="10.17487/RFC7126",
  }

@misc{rfc7127,
  author="O. Kolkman and S. Bradner and S. Turner",
  title="{Characterization of Proposed Standards}",
  howpublished="RFC 7127 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7127",
  pages="1--5",
  year=2014,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7127.txt",
  key="RFC 7127",
  abstract={RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents.  This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.},
  keywords="Guidance, Standards, Standards Process, Advancement, Proposed Standard",
  doi="10.17487/RFC7127",
  }

@misc{rfc7128,
  author="R. Bush and R. Austein and K. Patel and H. Gredler and M. Waehlisch",
  title="{Resource Public Key Infrastructure (RPKI) Router Implementation Report}",
  howpublished="RFC 7128 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7128",
  pages="1--11",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7128.txt",
  key="RFC 7128",
  abstract={This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810.  The authors did not verify the accuracy of the information provided by respondents.  The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent.  The respondents were asked to only use the ``YES'' answer if the feature had at least been tested in the lab.},
  keywords="routing, security",
  doi="10.17487/RFC7128",
  }

@misc{rfc7129,
  author="R. Gieben and W. Mekking",
  title="{Authenticated Denial of Existence in the DNS}",
  howpublished="RFC 7129 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7129",
  pages="1--30",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7129.txt",
  key="RFC 7129",
  abstract={Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.},
  keywords="Internet, DNSSEC, Denial of Existence, NSEC, NSEC3",
  doi="10.17487/RFC7129",
  }

@misc{rfc7130,
  author="M. Bhatia and M. Chen and S. Boutros and M. Binderberger and J. Haas",
  title="{Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces}",
  howpublished="RFC 7130 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7130",
  pages="1--11",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7130.txt",
  key="RFC 7130",
  abstract={This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.},
  doi="10.17487/RFC7130",
  }

@misc{rfc7131,
  author="M. Barnes and F. Audet and S. Schubert and H. van Elburg and C. Holmberg",
  title="{Session Initiation Protocol (SIP) History-Info Header Call Flow Examples}",
  howpublished="RFC 7131 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7131",
  pages="1--52",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7131.txt",
  key="RFC 7131",
  abstract={This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted.  The use cases are described along with the corresponding call flow diagrams and messaging details.},
  keywords="SIP, History-Info, RFC4244bis, Example, Call Flow",
  doi="10.17487/RFC7131",
  }

@misc{rfc7132,
  author="S. Kent and A. Chi",
  title="{Threat Model for BGP Path Security}",
  howpublished="RFC 7132 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7132",
  pages="1--20",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7132.txt",
  key="RFC 7132",
  abstract={This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term ``PATHSEC'' to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI. The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.},
  keywords="BGPSEC, RPKI, SIDR",
  doi="10.17487/RFC7132",
  }

@misc{rfc7133,
  author="S. Kashima and A. Kobayashi and P. Aitken",
  title="{Information Elements for Data Link Layer Traffic Measurement}",
  howpublished="RFC 7133 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7133",
  pages="1--41",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7133.txt",
  key="RFC 7133",
  abstract={This document describes Information Elements related to the data link layer.  They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.},
  keywords="IPFIX, PSAMP, Provider Bridge, Provider Backbone Bridge, ipfix",
  doi="10.17487/RFC7133",
  }

@misc{rfc7134,
  author="B. Rosen",
  title="{The Management Policy of the Resource Priority Header (RPH) Registry Changed to ``IETF Review''}",
  howpublished="RFC 7134 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7134",
  pages="1--2",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7134.txt",
  key="RFC 7134",
  abstract={RFC 4412 defines the ``Resource-Priority Namespaces'' and ``Resource-Priority Priority-values'' registries.  The management policy of these registries is ``Standards Action''.  This document normatively updates RFC 4412 to change the management policy of these registries to ``IETF Review''.},
  keywords="Resource-Priority Namespaces, Resource-Priority Priority-values",
  doi="10.17487/RFC7134",
  }

@misc{rfc7135,
  author="J. Polk",
  title="{Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications}",
  howpublished="RFC 7135 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7135",
  pages="1--9",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7135.txt",
  key="RFC 7135",
  abstract={This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA.  The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.},
  doi="10.17487/RFC7135",
  }

@misc{rfc7136,
  author="B. Carpenter and S. Jiang",
  title="{Significance of IPv6 Interface Identifiers}",
  howpublished="RFC 7136 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7136",
  pages="1--10",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7136.txt",
  key="RFC 7136",
  abstract={The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses.  Interface identifiers are formed by a variety of methods.  This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value.  In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier.  This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.},
  doi="10.17487/RFC7136",
  }

@misc{rfc7137,
  author="A. Retana and S. Ratliff",
  title="{Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks}",
  howpublished="RFC 7137 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7137",
  pages="1--8",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7137.txt",
  key="RFC 7137",
  abstract={This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature. This document updates RFC 5820.},
  doi="10.17487/RFC7137",
  }

@misc{rfc7138,
  author="D. Ceccarelli and F. Zhang and S. Belotti and R. Rao and J. Drake",
  title="{Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks}",
  howpublished="RFC 7138 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7138",
  pages="1--36",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7138.txt",
  key="RFC 7138",
  abstract={This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012.  It extends mechanisms defined in RFC 4203.},
  keywords="OSPF, GMPLS, G709, OTN",
  doi="10.17487/RFC7138",
  }

@misc{rfc7139,
  author="F. Zhang and G. Zhang and S. Belotti and D. Ceccarelli and K. Pithewan",
  title="{GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks}",
  howpublished="RFC 7139 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7139",
  pages="1--27",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7892",
url="https://www.rfc-editor.org/rfc/rfc7139.txt",
  key="RFC 7139",
  abstract={ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.},
  doi="10.17487/RFC7139",
  }

@misc{rfc7140,
  author="L. Jin and F. Jounay and IJ. Wijnands and N. Leymann",
  title="{LDP Extensions for Hub and Spoke Multipoint Label Switched Path}",
  howpublished="RFC 7140 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7140",
  pages="1--15",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7358",
url="https://www.rfc-editor.org/rfc/rfc7140.txt",
  key="RFC 7140",
  abstract={This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path.  That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node.  Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root.  Direct communication among the leaf nodes is not allowed.},
  keywords="P2MP LSP, MP2MP LSP",
  doi="10.17487/RFC7140",
  }

@misc{rfc7141,
  author="B. Briscoe and J. Manner",
  title="{Byte and Packet Congestion Notification}",
  howpublished="RFC 7141 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7141",
  pages="1--41",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7141.txt",
  key="RFC 7141",
  abstract={This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced).  We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used.  This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.},
  keywords="active queue management, aqm, availability, denial of service, dos, quality of service, qos, congestion control, fairness, incentives, architecture layering, protocol",
  doi="10.17487/RFC7141",
  }

@misc{rfc7142,
  author="M. Shand and L. Ginsberg",
  title="{Reclassification of RFC 1142 to Historic}",
  howpublished="RFC 7142 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7142",
  pages="1--3",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7142.txt",
  key="RFC 7142",
  abstract={This memo reclassifies RFC 1142, ``OSI IS-IS Intra-domain Routing Protocol'', to Historic status.  This memo also obsoletes RFC 1142.},
  doi="10.17487/RFC7142",
  }

@misc{rfc7143,
  author="M. Chadalapaka and J. Satran and K. Meth and D. Black",
  title="{Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)}",
  howpublished="RFC 7143 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7143",
  pages="1--295",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7143.txt",
  key="RFC 7143",
  abstract={This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.},
  keywords="iSCSI, SCSI, storage, SAN, block storage, SCSI object storage devices, OSD, SAM, disk, T10",
  doi="10.17487/RFC7143",
  }

@misc{rfc7144,
  author="F. Knight and M. Chadalapaka",
  title="{Internet Small Computer System Interface (iSCSI) SCSI Features Update}",
  howpublished="RFC 7144 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7144",
  pages="1--25",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7144.txt",
  key="RFC 7144",
  abstract={Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP.  The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols.  This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5.},
  doi="10.17487/RFC7144",
  }

@misc{rfc7145,
  author="M. Ko and A. Nezhinsky",
  title="{Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification}",
  howpublished="RFC 7145 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7145",
  pages="1--91",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7145.txt",
  key="RFC 7145",
  abstract={Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol. This document obsoletes RFC 5046.},
  doi="10.17487/RFC7145",
  }

@misc{rfc7146,
  author="D. Black and P. Koning",
  title="{Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3}",
  howpublished="RFC 7146 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7146",
  pages="1--18",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7146.txt",
  key="RFC 7146",
  abstract={RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP).  This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.},
  keywords="IPsec",
  doi="10.17487/RFC7146",
  }

@misc{rfc7147,
  author="M. Bakke and P. Venkatesen",
  title="{Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)}",
  howpublished="RFC 7147 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7147",
  pages="1--92",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7147.txt",
  key="RFC 7147",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC 4544.},
  keywords="ISCSI-MIB",
  doi="10.17487/RFC7147",
  }

@misc{rfc7148,
  author="X. Zhou and J. Korhonen and C. Williams and S. Gundavelli and CJ. Bernardos",
  title="{Prefix Delegation Support for Proxy Mobile IPv6}",
  howpublished="RFC 7148 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7148",
  pages="1--27",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7148.txt",
  key="RFC 7148",
  abstract={This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation.  Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address.  Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.},
  keywords="Prefix Delegation, Proxy Mobile IPv6, PMIPv6, Mobile Router",
  doi="10.17487/RFC7148",
  }

@misc{rfc7149,
  author="M. Boucadair and C. Jacquenet",
  title="{Software-Defined Networking: A Perspective from within a Service Provider Environment}",
  howpublished="RFC 7149 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7149",
  pages="1--20",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7149.txt",
  key="RFC 7149",
  abstract={Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.},
  keywords="Network Automation, Policy Management, Connectivity Provisioning, Service Parameter Exposure, Dynamic Negotiation, Dynamic Service Provisioning, Autonomic, Programmable Networks",
  doi="10.17487/RFC7149",
  }

@misc{rfc7150,
  author="F. Zhang and A. Farrel",
  title="{Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol}",
  howpublished="RFC 7150 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7150",
  pages="1--12",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7470",
url="https://www.rfc-editor.org/rfc/rfc7150.txt",
  key="RFC 7150",
  abstract={The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.},
  doi="10.17487/RFC7150",
  }

@misc{rfc7151,
  author="P. Hethmon and R. McMurray",
  title="{File Transfer Protocol HOST Command for Virtual Hosts}",
  howpublished="RFC 7151 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7151",
  pages="1--24",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7151.txt",
  key="RFC 7151",
  abstract={The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address.  This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.},
  keywords="FTP, HOST",
  doi="10.17487/RFC7151",
  }

@misc{rfc7152,
  author="R. Key and S. DeLord and F. Jounay and L. Huang and Z. Liu and M. Paul",
  title="{Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)}",
  howpublished="RFC 7152 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7152",
  pages="1--12",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7152.txt",
  key="RFC 7152",
  abstract={This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply ``L2VPN'').  It is intended that potential solutions will use these requirements as guidelines.},
  keywords="RMP, Rooted-Multipoint, VPLS, Virtual Private LAN Service, E-VPN, Ethernet Virtual Private Network, MPLS, Multi-Protocol Label Switching, CE, Carrier Ethernet",
  doi="10.17487/RFC7152",
  }

@misc{rfc7153,
  author="E. Rosen and Y. Rekhter",
  title="{IANA Registries for BGP Extended Communities}",
  howpublished="RFC 7153 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7153",
  pages="1--16",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7153.txt",
  key="RFC 7153",
  abstract={This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute.  This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries.  This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries.  These changes are compatible with the existing allocations and thus do not affect protocol implementations.  The changes will, however, impact the ``IANA Considerations'' sections of future protocol specifications.  This document updates RFC 4360 and RFC 5701.},
  keywords="Border Gateway Protocol",
  doi="10.17487/RFC7153",
  }

@misc{rfc7154,
  author="S. Moonesamy",
  title="{IETF Guidelines for Conduct}",
  howpublished="RFC 7154 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7154",
  pages="1--7",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7154.txt",
  key="RFC 7154",
  abstract={This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. This document is an updated version of the guidelines for conduct originally published in RFC 3184.},
  doi="10.17487/RFC7154",
  }

@misc{rfc7155,
  author="G. Zorn",
  title="{Diameter Network Access Server Application}",
  howpublished="RFC 7155 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7155",
  pages="1--70",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7155.txt",
  key="RFC 7155",
  abstract={This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005.  When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.},
  keywords="AAA, Authentication, Authorization, Accounting, Remote Access",
  doi="10.17487/RFC7155",
  }

@misc{rfc7156,
  author="G. Zorn and Q. Wu and J. Korhonen",
  title="{Diameter Support for Proxy Mobile IPv6 Localized Routing}",
  howpublished="RFC 7156 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7156",
  pages="1--11",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7156.txt",
  key="RFC 7156",
  abstract={In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing.  The term ``localized routing'' refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA.  In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized.  This document specifies how to accomplish this using the Diameter protocol.},
  doi="10.17487/RFC7156",
  }

@misc{rfc7157,
  author="O. Troan and D. Miles and S. Matsushima and T. Okimoto and D. Wing",
  title="{IPv6 Multihoming without Network Address Translation}",
  howpublished="RFC 7157 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7157",
  pages="1--22",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7157.txt",
  key="RFC 7157",
  abstract={Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution.  For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6).  However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity.  In this document, we analyze the use cases of multihoming.  We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria.  We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.},
  keywords="NPTv6",
  doi="10.17487/RFC7157",
  }

@misc{rfc7158,
  author="T. Bray",
  title="{The JavaScript Object Notation (JSON) Data Interchange Format}",
  howpublished="RFC 7158 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7158",
  pages="1--16",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7159",
url="https://www.rfc-editor.org/rfc/rfc7158.txt",
  key="RFC 7158",
  abstract={JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.},
  doi="10.17487/RFC7158",
  }

@misc{rfc7159,
  author="T. Bray",
  title="{The JavaScript Object Notation (JSON) Data Interchange Format}",
  howpublished="RFC 7159 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7159",
  pages="1--16",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7159.txt",
  key="RFC 7159",
  abstract={JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.},
  doi="10.17487/RFC7159",
  }

@misc{rfc7160,
  author="M. Petit-Huguenin and G. Zorn",
  title="{Support for Multiple Clock Rates in an RTP Session}",
  howpublished="RFC 7160 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7160",
  pages="1--13",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7160.txt",
  key="RFC 7160",
  abstract={This document clarifies the RTP specification regarding the use of different clock rates in an RTP session.  It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document.  It updates RFC 3550.},
  doi="10.17487/RFC7160",
  }

@misc{rfc7161,
  author="LM. Contreras and CJ. Bernardos and I. Soto",
  title="{Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)}",
  howpublished="RFC 7161 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7161",
  pages="1--37",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7161.txt",
  key="RFC 7161",
  abstract={This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.  The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways.  To do that, extensions to the current PMIPv6 protocol are proposed.  These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.  Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).},
  keywords="PMIPv6, Proxy Mobile IPv6, multicast, handover, SIAL",
  doi="10.17487/RFC7161",
  }

@misc{rfc7162,
  author="A. Melnikov and D. Cridland",
  title="{IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)}",
  howpublished="RFC 7162 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7162",
  pages="1--52",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7162.txt",
  key="RFC 7162",
  abstract={Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162. Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.},
  keywords="IMAP, CONDSTORE, QRESYNC, VANISHED, EXPUNGE, quick resynchronization",
  doi="10.17487/RFC7162",
  }

@misc{rfc7163,
  author="C. Holmberg and I. Sedlacek",
  title="{URN for Country-Specific Emergency Services}",
  howpublished="RFC 7163 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7163",
  pages="1--4",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7163.txt",
  key="RFC 7163",
  abstract={This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services ``that are offered widely and in different countries''.  This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.},
  keywords="sip, emergency, urn, country, 5031, sos",
  doi="10.17487/RFC7163",
  }

@misc{rfc7164,
  author="K. Gross and R. Brandenburg",
  title="{RTP and Leap Seconds}",
  howpublished="RFC 7164 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7164",
  pages="1--9",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7164.txt",
  key="RFC 7164",
  abstract={This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds.  It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.},
  keywords="Leap second, rtp, Real-time Transport Protocol, ntp, Network Time Protocol, UTC, Universal Coordinated Time, tai, International Atomic Time, Unix time",
  doi="10.17487/RFC7164",
  }

@misc{rfc7165,
  author="R. Barnes",
  title="{Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)}",
  howpublished="RFC 7165 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7165",
  pages="1--25",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7165.txt",
  key="RFC 7165",
  abstract={Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer.  For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1.  Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON).  This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.},
  keywords="JWS, JWE, JWK, JWA, JWT, CMS, S/MIME, JOSE, XMPP, ALTO, OAuth",
  doi="10.17487/RFC7165",
  }

@misc{rfc7166,
  author="M. Bhatia and V. Manral and A. Lindem",
  title="{Supporting Authentication Trailer for OSPFv3}",
  howpublished="RFC 7166 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7166",
  pages="1--23",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7166.txt",
  key="RFC 7166",
  abstract={Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication. The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.},
  doi="10.17487/RFC7166",
  }

@misc{rfc7167,
  author="D. Frost and S. Bryant and M. Bocci and L. Berger",
  title="{A Framework for Point-to-Multipoint MPLS in Transport Networks}",
  howpublished="RFC 7167 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7167",
  pages="1--12",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7167.txt",
  key="RFC 7167",
  abstract={The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks.  The MPLS-TP supports both point-to-point and point-to-multipoint transport paths.  This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.},
  keywords="mpls-tp, mpls",
  doi="10.17487/RFC7167",
  }

@misc{rfc7168,
  author="I. Nazar",
  title="{The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)}",
  howpublished="RFC 7168 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7168",
  pages="1--7",
  year=2014,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7168.txt",
  key="RFC 7168",
  abstract={The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity.  This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.},
  doi="10.17487/RFC7168",
  }

@misc{rfc7169,
  author="S. Turner",
  title="{The NSA (No Secrecy Afforded) Certificate Extension}",
  howpublished="RFC 7169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7169",
  pages="1--3",
  year=2014,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7169.txt",
  key="RFC 7169",
  abstract={This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates.  Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained.  In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party.  Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.},
  doi="10.17487/RFC7169",
  }

@misc{rfc7170,
  author="H. Zhou and N. Cam-Winget and J. Salowey and S. Hanna",
  title="{Tunnel Extensible Authentication Protocol (TEAP) Version 1}",
  howpublished="RFC 7170 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7170",
  pages="1--101",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7170.txt",
  key="RFC 7170",
  abstract={This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel.  Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.},
  keywords="EAP, Tunnel",
  doi="10.17487/RFC7170",
  }

@misc{rfc7171,
  author="N. Cam-Winget and P. Sangster",
  title="{PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods}",
  howpublished="RFC 7171 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7171",
  pages="1--19",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7171.txt",
  key="RFC 7171",
  abstract={This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS).  The document also describes the intended applicability of PT-EAP.},
  keywords="NEA EAP",
  doi="10.17487/RFC7171",
  }

@misc{rfc7172,
  author="D. {Eastlake 3rd} and M. Zhang and P. Agarwal and R. Perlman and D. Dutt",
  title="{Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling}",
  howpublished="RFC 7172 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7172",
  pages="1--27",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7172.txt",
  key="RFC 7172",
  abstract={The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count.  The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs.  However, there are applications that require a larger number of labels providing configurable isolation of data.  This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this.  These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.},
  keywords="TRILL, VLAN, Fine-Grained, Label",
  doi="10.17487/RFC7172",
  }

@misc{rfc7173,
  author="L. Yong and D. {Eastlake 3rd} and S. Aldrin and J. Hudson",
  title="{Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires}",
  howpublished="RFC 7173 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7173",
  pages="1--11",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7173.txt",
  key="RFC 7173",
  abstract={This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.},
  keywords="TRILL, pseudowires, MPLS, RBridge",
  doi="10.17487/RFC7173",
  }

@misc{rfc7174,
  author="S. Salam and T. Senevirathne and S. Aldrin and D. {Eastlake 3rd}",
  title="{Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework}",
  howpublished="RFC 7174 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7174",
  pages="1--33",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7174.txt",
  key="RFC 7174",
  abstract={This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks.  The focus of the document is on the fault and performance management aspects of TRILL OAM.},
  keywords="RBridge, CFM, BFD, MEP, MIP, MA, Fault, Performance, Maintenance, Continuity, Connectivity, Delay, Operations, Administration",
  doi="10.17487/RFC7174",
  }

@misc{rfc7175,
  author="V. Manral and D. {Eastlake 3rd} and D. Ward and A. Banerjee",
  title="{Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support}",
  howpublished="RFC 7175 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7175",
  pages="1--12",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7175.txt",
  key="RFC 7175",
  abstract={This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol. BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.},
  keywords="RBridge, Echo, one-hop",
  doi="10.17487/RFC7175",
  }

@misc{rfc7176,
  author="D. {Eastlake 3rd} and T. Senevirathne and A. Ghanwani and D. Dutt and A. Banerjee",
  title="{Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS}",
  howpublished="RFC 7176 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7176",
  pages="1--45",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7176.txt",
  key="RFC 7176",
  abstract={The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic.  This document specifies the data formats and code points for the IS-IS extensions to support TRILL.  These data formats and code points may also be used by technologies other than TRILL.  This document obsoletes RFC 6326.},
  keywords="Affinity, multicast, multi-topology, fine-grained, VLAN",
  doi="10.17487/RFC7176",
  }

@misc{rfc7177,
  author="D. {Eastlake 3rd} and R. Perlman and A. Ghanwani and H. Yang and V. Manral",
  title="{Transparent Interconnection of Lots of Links (TRILL): Adjacency}",
  howpublished="RFC 7177 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7177",
  pages="1--35",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7780",
url="https://www.rfc-editor.org/rfc/rfc7177.txt",
  key="RFC 7177",
  abstract={The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached.  TRILL uses Intermediate System to Intermediate System (IS-IS) routing.  This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges).  It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency.  State diagrams are included where appropriate.  This document obsoletes RFC 6327 and updates RFC 6325.},
  keywords="RBridge, TRILL, Adjacency, BFD, p2p, point-to-point",
  doi="10.17487/RFC7177",
  }

@misc{rfc7178,
  author="D. {Eastlake 3rd} and V. Manral and Y. Li and S. Aldrin and D. Ward",
  title="{Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support}",
  howpublished="RFC 7178 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7178",
  pages="1--21",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7978",
url="https://www.rfc-editor.org/rfc/rfc7178.txt",
  key="RFC 7178",
  abstract={This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.},
  keywords="TRILL, native",
  doi="10.17487/RFC7178",
  }

@misc{rfc7179,
  author="D. {Eastlake 3rd} and A. Ghanwani and V. Manral and Y. Li and C. Bestler",
  title="{Transparent Interconnection of Lots of Links (TRILL): Header Extension}",
  howpublished="RFC 7179 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7179",
  pages="1--12",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7780",
url="https://www.rfc-editor.org/rfc/rfc7179.txt",
  key="RFC 7179",
  abstract={The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions.  This document specifies an initial extension providing additional flag bits and specifies some of those bits.  It updates RFC 6325.},
  keywords="RBridge, extension, option",
  doi="10.17487/RFC7179",
  }

@misc{rfc7180,
  author="D. {Eastlake 3rd} and M. Zhang and A. Ghanwani and V. Manral and A. Banerjee",
  title="{Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates}",
  howpublished="RFC 7180 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7180",
  pages="1--24",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7780",
url="https://www.rfc-editor.org/rfc/rfc7180.txt",
  key="RFC 7180",
  abstract={The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates. RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.},
  keywords="TRILL, RBridge, IS-IS, reachability, overload, MTU, DEI, multicast",
  doi="10.17487/RFC7180",
  }

@misc{rfc7181,
  author="T. Clausen and C. Dearlove and P. Jacquet and U. Herberg",
  title="{The Optimized Link State Routing Protocol Version 2}",
  howpublished="RFC 7181 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7181",
  pages="1--115",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7183, 7187, 7188, 7466",
url="https://www.rfc-editor.org/rfc/rfc7181.txt",
  key="RFC 7181",
  abstract={This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).},
  keywords="MANET, ad hoc network, NHDP",
  doi="10.17487/RFC7181",
  }

@misc{rfc7182,
  author="U. Herberg and T. Clausen and C. Dearlove",
  title="{Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)}",
  howpublished="RFC 7182 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7182",
  pages="1--31",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7182.txt",
  key="RFC 7182",
  abstract={This document revises, extends, and replaces RFC 6622.  It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444.  It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.},
  keywords="NHDP, OLSRv2, security, integrity, routing",
  doi="10.17487/RFC7182",
  }

@misc{rfc7183,
  author="U. Herberg and C. Dearlove and T. Clausen",
  title="{Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)}",
  howpublished="RFC 7183 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7183",
  pages="1--15",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7183.txt",
  key="RFC 7183",
  abstract={This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.},
  keywords="MANET, OLSRv2, Security, Integrity protection, ICV",
  doi="10.17487/RFC7183",
  }

@misc{rfc7184,
  author="U. Herberg and R. Cole and T. Clausen",
  title="{Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2}",
  howpublished="RFC 7184 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7184",
  pages="1--86",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7184.txt",
  key="RFC 7184",
  abstract={This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications.  This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol.  Two levels of compliance allow this MIB module to be deployed on constrained routers.},
  keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, MANET, Optimized Link STate Routing Protocol version 2",
  doi="10.17487/RFC7184",
  }

@misc{rfc7185,
  author="C. Dearlove and T. Clausen and P. Jacquet",
  title="{Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale}",
  howpublished="RFC 7185 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7185",
  pages="1--25",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7185.txt",
  key="RFC 7185",
  abstract={The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes.  This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.},
  keywords="MANET, ad hoc network, proactive, NHDP, neighborhood discovery, OLSR, OLSRv2, routing protocol, metrics",
  doi="10.17487/RFC7185",
  }

@misc{rfc7186,
  author="J. Yi and U. Herberg and T. Clausen",
  title="{Security Threats for the Neighborhood Discovery Protocol (NHDP)}",
  howpublished="RFC 7186 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7186",
  pages="1--20",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7985",
url="https://www.rfc-editor.org/rfc/rfc7186.txt",
  key="RFC 7186",
  abstract={This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP.  This document is not intended to propose solutions to the threats described.},
  doi="10.17487/RFC7186",
  }

@misc{rfc7187,
  author="C. Dearlove and T. Clausen",
  title="{Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)}",
  howpublished="RFC 7187 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7187",
  pages="1--5",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7187.txt",
  key="RFC 7187",
  abstract={This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays.  The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.},
  doi="10.17487/RFC7187",
  }

@misc{rfc7188,
  author="C. Dearlove and T. Clausen",
  title="{Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs}",
  howpublished="RFC 7188 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7188",
  pages="1--16",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7722",
url="https://www.rfc-editor.org/rfc/rfc7188.txt",
  key="RFC 7188",
  abstract={This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions.  This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).},
  keywords="MANET, OLSRv2, NHDP, TLV",
  doi="10.17487/RFC7188",
  }

@misc{rfc7189,
  author="G. Mirsky",
  title="{Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)}",
  howpublished="RFC 7189 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7189",
  pages="1--7",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7189.txt",
  key="RFC 7189",
  abstract={This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs.  This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.},
  keywords="PW VCCV, MPLS-TP CC/CV/RDI",
  doi="10.17487/RFC7189",
  }

@misc{rfc7190,
  author="C. Villamizar",
  title="{Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)}",
  howpublished="RFC 7190 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7190",
  pages="1--15",
  year=2014,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7190.txt",
  key="RFC 7190",
  abstract={Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.},
  keywords="MPLS, composite link, link aggregation, ECMP, link bundling, multipath, MPLS-TP",
  doi="10.17487/RFC7190",
  }

@misc{rfc7191,
  author="R. Housley",
  title="{Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types}",
  howpublished="RFC 7191 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7191",
  pages="1--25",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7191.txt",
  key="RFC 7191",
  abstract={This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors.  The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages.  The key package error content type is used to indicate an error occurred during the processing of a key package.  CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.},
  doi="10.17487/RFC7191",
  }

@misc{rfc7192,
  author="S. Turner",
  title="{Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types}",
  howpublished="RFC 7192 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7192",
  pages="1--6",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7192.txt",
  key="RFC 7192",
  abstract={This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.},
  keywords="Key Package, Key Package Receipt, Key Package Error",
  doi="10.17487/RFC7192",
  }

@misc{rfc7193,
  author="S. Turner and R. Housley and J. Schaad",
  title="{The application/cms Media Type}",
  howpublished="RFC 7193 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7193",
  pages="1--12",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7193.txt",
  key="RFC 7193",
  abstract={This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.},
  keywords="Cryptographic Message Syntax",
  doi="10.17487/RFC7193",
  }

@misc{rfc7194,
  author="R. Hartmann",
  title="{Default Port for Internet Relay Chat (IRC) via TLS/SSL}",
  howpublished="RFC 7194 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7194",
  pages="1--6",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7194.txt",
  key="RFC 7194",
  abstract={This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.},
  doi="10.17487/RFC7194",
  }

@misc{rfc7195,
  author="M. Garcia-Martin and S. Veikkolainen",
  title="{Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)}",
  howpublished="RFC 7195 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7195",
  pages="1--39",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7195.txt",
  key="RFC 7195",
  abstract={This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).},
  keywords="PSTN",
  doi="10.17487/RFC7195",
  }

@misc{rfc7196,
  author="C. Pelsser and R. Bush and K. Patel and P. Mohapatra and O. Maennel",
  title="{Making Route Flap Damping Usable}",
  howpublished="RFC 7196 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7196",
  pages="1--8",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7196.txt",
  key="RFC 7196",
  abstract={Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers.  Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged.  Many operators have turned RFD off.  Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD.  The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.},
  keywords="rfd",
  doi="10.17487/RFC7196",
  }

@misc{rfc7197,
  author="A. Begen and Y. Cai and H. Ou",
  title="{Duplication Delay Attribute in the Session Description Protocol}",
  howpublished="RFC 7197 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7197",
  pages="1--11",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7197.txt",
  key="RFC 7197",
  abstract={A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units.  This approach is commonly referred to as ``time-shifted redundancy'', ``temporal redundancy'', or simply ``delayed duplication''.  This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.},
  keywords="Interleaving, temporal diversity, temporal redundancy, time shifted, delayed duplication",
  doi="10.17487/RFC7197",
  }

@misc{rfc7198,
  author="A. Begen and C. Perkins",
  title="{Duplicating RTP Streams}",
  howpublished="RFC 7198 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7198",
  pages="1--13",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7198.txt",
  key="RFC 7198",
  abstract={Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages.  In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets.  In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage.  For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements.  This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.},
  keywords="RTP duplication, live/live, redundancy",
  doi="10.17487/RFC7198",
  }

@misc{rfc7199,
  author="R. Barnes and M. Thomson and J. Winterbottom and H. Tschofenig",
  title="{Location Configuration Extensions for Policy Management}",
  howpublished="RFC 7199 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7199",
  pages="1--20",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7199.txt",
  key="RFC 7199",
  abstract={Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location.  These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute.  This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.},
  keywords="geopriv, geolocation, privacy, policy",
  doi="10.17487/RFC7199",
  }

@misc{rfc7200,
  author="C. Shen and H. Schulzrinne and A. Koike",
  title="{A Session Initiation Protocol (SIP) Load-Control Event Package}",
  howpublished="RFC 7200 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7200",
  pages="1--44",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7200.txt",
  key="RFC 7200",
  abstract={This specification defines a load-control event package for the Session Initiation Protocol (SIP).  It allows SIP entities to distribute load-filtering policies to other SIP entities in the network.  The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix.  The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.},
  keywords="SIP, Overload Control, Server, Performance",
  doi="10.17487/RFC7200",
  }

@misc{rfc7201,
  author="M. Westerlund and C. Perkins",
  title="{Options for Securing RTP Sessions}",
  howpublished="RFC 7201 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7201",
  pages="1--37",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7201.txt",
  key="RFC 7201",
  abstract={The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments.  This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments.  The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism.  This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.},
  keywords="Secure RTP, SRTP, key management, real-time, media",
  doi="10.17487/RFC7201",
  }

@misc{rfc7202,
  author="C. Perkins and M. Westerlund",
  title="{Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution}",
  howpublished="RFC 7202 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7202",
  pages="1--10",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7202.txt",
  key="RFC 7202",
  abstract={This memo discusses the problem of securing real-time multimedia sessions.  It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism.  This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.},
  keywords="SRTP, RTP Profile, Payload Format",
  doi="10.17487/RFC7202",
  }

@misc{rfc7203,
  author="T. Takahashi and K. Landfield and Y. Kadobayashi",
  title="{An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information}",
  howpublished="RFC 7203 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7203",
  pages="1--28",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7203.txt",
  key="RFC 7203",
  abstract={This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations.  It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.},
  keywords="data structure, information architecture, incident response, response team, security incident, information exchange, knowledge sharing, security operation, automation, vulnerability, CERT, CSIRT",
  doi="10.17487/RFC7203",
  }

@misc{rfc7204,
  author="T. Haynes",
  title="{Requirements for Labeled NFS}",
  howpublished="RFC 7204 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7204",
  pages="1--18",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7204.txt",
  key="RFC 7204",
  abstract={This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2).  It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system.  The intent here is not to present the protocol changes but to describe the environment in which they reside.},
  keywords="NFSv4",
  doi="10.17487/RFC7204",
  }

@misc{rfc7205,
  author="A. Romanow and S. Botzko and M. Duckworth and R. Even",
  title="{Use Cases for Telepresence Multistreams}",
  howpublished="RFC 7205 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7205",
  pages="1--17",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7205.txt",
  key="RFC 7205",
  abstract={Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity.  A number of techniques for handling audio and video streams are used to create this experience.  When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible.  Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork.  This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.},
  doi="10.17487/RFC7205",
  }

@misc{rfc7206,
  author="P. Jones and G. Salgueiro and J. Polk and L. Liess and H. Kaplan",
  title="{Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks}",
  howpublished="RFC 7206 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7206",
  pages="1--15",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7206.txt",
  key="RFC 7206",
  abstract={This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks.  This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.},
  doi="10.17487/RFC7206",
  }

@misc{rfc7207,
  author="M. Ortseifen and G. Dickfeld",
  title="{A Uniform Resource Name (URN) Namespace for Eurosystem Messaging}",
  howpublished="RFC 7207 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7207",
  pages="1--8",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7207.txt",
  key="RFC 7207",
  abstract={This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem.  The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).},
  keywords="URN Namespace, Eurosystem, TARGET2, TARGET2-Securities, ESCB",
  doi="10.17487/RFC7207",
  }

@misc{rfc7208,
  author="S. Kitterman",
  title="{Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1}",
  howpublished="RFC 7208 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7208",
  pages="1--64",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7372",
url="https://www.rfc-editor.org/rfc/rfc7208.txt",
  key="RFC 7208",
  abstract={Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the ``MAIL FROM'' of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408.},
  keywords="spoofing, spf, anti-forgery, authentication",
  doi="10.17487/RFC7208",
  }

@misc{rfc7209,
  author="A. Sajassi and R. Aggarwal and J. Uttaro and N. Bitar and W. Henderickx and A. Isaac",
  title="{Requirements for Ethernet VPN (EVPN)}",
  howpublished="RFC 7209 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7209",
  pages="1--15",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7209.txt",
  key="RFC 7209",
  abstract={The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution.  In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames.  Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration.  This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.},
  keywords="ethernet l2vpn",
  doi="10.17487/RFC7209",
  }

@misc{rfc7210,
  author="R. Housley and T. Polk and S. Hartman and D. Zhang",
  title="{Database of Long-Lived Symmetric Cryptographic Keys}",
  howpublished="RFC 7210 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7210",
  pages="1--14",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7210.txt",
  key="RFC 7210",
  abstract={This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security.  The database is designed to support both manual and automated key management.  In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database.  In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.},
  doi="10.17487/RFC7210",
  }

@misc{rfc7211,
  author="S. Hartman and D. Zhang",
  title="{Operations Model for Router Keying}",
  howpublished="RFC 7211 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7211",
  pages="1--18",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7211.txt",
  key="RFC 7211",
  abstract={The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, ``Keying and Authentication for Routing Protocols (KARP) Design Guidelines''.  Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts.  This document gives recommendations to operators and implementors regarding management and operation of router authentication.  These recommendations will also assist protocol designers in understanding management issues they will face.},
  doi="10.17487/RFC7211",
  }

@misc{rfc7212,
  author="D. Frost and S. Bryant and M. Bocci",
  title="{MPLS Generic Associated Channel (G-ACh) Advertisement Protocol}",
  howpublished="RFC 7212 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7212",
  pages="1--23",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7212.txt",
  key="RFC 7212",
  abstract={The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow.  These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel.  This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information.  This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.},
  doi="10.17487/RFC7212",
  }

@misc{rfc7213,
  author="D. Frost and S. Bryant and M. Bocci",
  title="{MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing}",
  howpublished="RFC 7213 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7213",
  pages="1--9",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7213.txt",
  key="RFC 7213",
  abstract={The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.  This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.},
  keywords="MPLS",
  doi="10.17487/RFC7213",
  }

@misc{rfc7214,
  author="L. Andersson and C. Pignataro",
  title="{Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry}",
  howpublished="RFC 7214 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7214",
  pages="1--7",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7214.txt",
  key="RFC 7214",
  abstract={RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new ``Generic Associated Channel (G-ACh) Parameters'' registry under the ``Multiprotocol Label Switching Architecture (MPLS)'' heading. This document updates RFC 5586. This document also updates RFCs 6374, 6378, 6427, and 6428.},
  doi="10.17487/RFC7214",
  }

@misc{rfc7215,
  author="L. Jakab and A. Cabellos-Aparicio and F. Coras and J. Domingo-Pascual and D. Lewis",
  title="{Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations}",
  howpublished="RFC 7215 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7215",
  pages="1--30",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7215.txt",
  key="RFC 7215",
  abstract={This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios.  It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013.  LISP deployment scenarios may have evolved since then.  This memo represents one stable point in that evolution of understanding.},
  keywords="LISP, deployment",
  doi="10.17487/RFC7215",
  }

@misc{rfc7216,
  author="M. Thomson and R. Bellis",
  title="{Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS}",
  howpublished="RFC 7216 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7216",
  pages="1--18",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7216.txt",
  key="RFC 7216",
  abstract={The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.},
  keywords="HELD, LIS, Discovery, NAT, Residential Gateway",
  doi="10.17487/RFC7216",
  }

@misc{rfc7217,
  author="F. Gont",
  title="{A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)}",
  howpublished="RFC 7217 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7217",
  pages="1--19",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7217.txt",
  key="RFC 7217",
  abstract={This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another.  This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users.  The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).},
  doi="10.17487/RFC7217",
  }

@misc{rfc7218,
  author="O. Gudmundsson",
  title="{Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)}",
  howpublished="RFC 7218 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7218",
  pages="1--5",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7218.txt",
  key="RFC 7218",
  abstract={Experience has shown that people get confused when discussing the three numeric fields of the TLSA record.  This document specifies descriptive acronyms for the three numeric fields in TLSA records.  This document updates the format of the IANA registry created by RFC 6698.},
  keywords="DNSSEC, DANE, Applications",
  doi="10.17487/RFC7218",
  }

@misc{rfc7219,
  author="M. Bagnulo and A. Garcia-Martinez",
  title="{SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)}",
  howpublished="RFC 7219 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7219",
  pages="1--38",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7219.txt",
  key="RFC 7219",
  abstract={This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol.  The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.},
  keywords="IPv6, ingress filtering, packet filtering, Neighbor Discovery",
  doi="10.17487/RFC7219",
  }

@misc{rfc7220,
  author="M. Boucadair and R. Penno and D. Wing",
  title="{Description Option for the Port Control Protocol (PCP)}",
  howpublished="RFC 7220 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7220",
  pages="1--6",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7220.txt",
  key="RFC 7220",
  abstract={This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping.  It does this by defining a new DESCRIPTION option.},
  doi="10.17487/RFC7220",
  }

@misc{rfc7221,
  author="A. Farrel and D. Crocker",
  title="{Handling of Internet-Drafts by IETF Working Groups}",
  howpublished="RFC 7221 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7221",
  pages="1--14",
  year=2014,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7221.txt",
  key="RFC 7221",
  abstract={The productive output of an IETF working group is documents, as mandated by the working group's charter.  When a working group is ready to develop a particular document, the most common mechanism is for it to ``adopt'' an existing document as a starting point.  The document that a working group adopts and then develops further is based on initial input at varying levels of maturity.  An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between.  This document discusses how a working group typically handles the formal documents that it targets for publication.},
  keywords="IETF, process, working group, Internet-Draft, adoption, handling, creation",
  doi="10.17487/RFC7221",
  }

@misc{rfc7222,
  author="M. Liebsch and P. Seite and H. Yokota and J. Korhonen and S. Gundavelli",
  title="{Quality-of-Service Option for Proxy Mobile IPv6}",
  howpublished="RFC 7222 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7222",
  pages="1--58",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7222.txt",
  key="RFC 7222",
  abstract={This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6.  This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows.  The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway.  Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.},
  keywords="QoS, Quality of Service, PMIP-QoS, PMIPv6-QoS, WiFi-QoS, 3GPP-QoS",
  doi="10.17487/RFC7222",
  }

@misc{rfc7223,
  author="M. Bjorklund",
  title="{A YANG Data Model for Interface Management}",
  howpublished="RFC 7223 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7223",
  pages="1--39",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7223.txt",
  key="RFC 7223",
  abstract={This document defines a YANG data model for the management of network interfaces.  It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.  The data model includes configuration data and state data (status information and counters for the collection of statistics).},
  keywords="NETCONF, ietf-interfaces",
  doi="10.17487/RFC7223",
  }

@misc{rfc7224,
  author="M. Bjorklund",
  title="{IANA Interface Type YANG Module}",
  howpublished="RFC 7224 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7224",
  pages="1--37",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7224.txt",
  key="RFC 7224",
  abstract={This document defines the initial version of the iana-if-type YANG module.},
  keywords="yang, netconf, iana-if-type",
  doi="10.17487/RFC7224",
  }

@misc{rfc7225,
  author="M. Boucadair",
  title="{Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)}",
  howpublished="RFC 7225 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7225",
  pages="1--17",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7225.txt",
  key="RFC 7225",
  abstract={This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses.  This option is needed for successful communications when IPv4 addresses are used in referrals.},
  doi="10.17487/RFC7225",
  }

@misc{rfc7226,
  author="C. Villamizar and D. McDysan and S. Ning and A. Malis and L. Yong",
  title="{Requirements for Advanced Multipath in MPLS Networks}",
  howpublished="RFC 7226 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7226",
  pages="1--17",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7226.txt",
  key="RFC 7226",
  abstract={This document provides a set of requirements for Advanced Multipath in MPLS networks. Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.},
  keywords="MPLS, Advanced Multipath, composite link, link aggregation, ECMP, link bundling, delay metric",
  doi="10.17487/RFC7226",
  }

@misc{rfc7227,
  author="D. Hankins and T. Mrugalski and M. Siodelski and S. Jiang and S. Krishnan",
  title="{Guidelines for Creating New DHCPv6 Options}",
  howpublished="RFC 7227 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7227",
  pages="1--35",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7227.txt",
  key="RFC 7227",
  abstract={This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software.  It also provides guidelines for expert reviewers to evaluate new registrations.  This document updates RFC 3315.},
  keywords="DHCPv6, option guidelines, option guidance, option format",
  doi="10.17487/RFC7227",
  }

@misc{rfc7228,
  author="C. Bormann and M. Ersue and A. Keranen",
  title="{Terminology for Constrained-Node Networks}",
  howpublished="RFC 7228 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7228",
  pages="1--17",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7228.txt",
  key="RFC 7228",
  abstract={The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.},
  keywords="IoT, Internet of Things, Embedded Internet, Smart Object, Sensor Network, WSN, Constrained node, Constrained network, LLN, LoWPAN, 6LoWPAN, Always-on, Low-power, Energy efficient",
  doi="10.17487/RFC7228",
  }

@misc{rfc7229,
  author="R. Housley",
  title="{Object Identifiers for Test Certificate Policies}",
  howpublished="RFC 7229 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7229",
  pages="1--4",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7229.txt",
  key="RFC 7229",
  abstract={This document provides several certificate policy identifiers for testing certificate handling software.},
  doi="10.17487/RFC7229",
  }

@misc{rfc7230,
  author="R. Fielding and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing}",
  howpublished="RFC 7230 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7230",
  pages="1--89",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7230.txt",
  key="RFC 7230",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the ``http'' and ``https'' Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.},
  keywords="Hyptertext Transfer Protocol, HTTP, HTTP message format",
  doi="10.17487/RFC7230",
  }

@misc{rfc7231,
  author="R. Fielding and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content}",
  howpublished="RFC 7231 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7231",
  pages="1--101",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7231.txt",
  key="RFC 7231",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless \\%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.},
  keywords="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code",
  doi="10.17487/RFC7231",
  }

@misc{rfc7232,
  author="R. Fielding and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests}",
  howpublished="RFC 7232 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7232",
  pages="1--28",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7232.txt",
  key="RFC 7232",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.},
  keywords="HyperText Transfer Protocol, HTTP, HTTP conditional requests",
  doi="10.17487/RFC7232",
  }

@misc{rfc7233,
  author="R. Fielding and Y. Lafon and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Range Requests}",
  howpublished="RFC 7233 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7233",
  pages="1--25",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7233.txt",
  key="RFC 7233",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems.  This document defines range requests and the rules for constructing and combining responses to those requests.},
  doi="10.17487/RFC7233",
  }

@misc{rfc7234,
  author="R. Fielding and M. Nottingham and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Caching}",
  howpublished="RFC 7234 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7234",
  pages="1--43",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7234.txt",
  key="RFC 7234",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless \\%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.},
  keywords="HTTP caching, HyperText Transfer Protocol, HTTP",
  doi="10.17487/RFC7234",
  }

@misc{rfc7235,
  author="R. Fielding and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Authentication}",
  howpublished="RFC 7235 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7235",
  pages="1--19",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7235.txt",
  key="RFC 7235",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems.  This document defines the HTTP Authentication framework.},
  keywords="HTTP authentication, HyperText Transfer Protocol, HTTP",
  doi="10.17487/RFC7235",
  }

@misc{rfc7236,
  author="J. Reschke",
  title="{Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations}",
  howpublished="RFC 7236 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7236",
  pages="1--3",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7236.txt",
  key="RFC 7236",
  abstract={This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.},
  keywords="HyperText Transfer Protocol, HTTP, Authentication, Authentication Scheme",
  doi="10.17487/RFC7236",
  }

@misc{rfc7237,
  author="J. Reschke",
  title="{Initial Hypertext Transfer Protocol (HTTP) Method Registrations}",
  howpublished="RFC 7237 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7237",
  pages="1--5",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7237.txt",
  key="RFC 7237",
  abstract={This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.},
  keywords="HyperText Transfer Protocol, HTTP, Request Method",
  doi="10.17487/RFC7237",
  }

@misc{rfc7238,
  author="J. Reschke",
  title="{The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)}",
  howpublished="RFC 7238 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7238",
  pages="1--6",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7538",
url="https://www.rfc-editor.org/rfc/rfc7238.txt",
  key="RFC 7238",
  abstract={This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).},
  keywords="HTTP, redirect, status code",
  doi="10.17487/RFC7238",
  }

@misc{rfc7239,
  author="A. Petersson and M. Nilsson",
  title="{Forwarded HTTP Extension}",
  howpublished="RFC 7239 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7239",
  pages="1--16",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7239.txt",
  key="RFC 7239",
  abstract={This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.},
  keywords="proxy, x-forwarded-for, x-forwarded-by, x-forwarded-host, x-forwarded-proto, via",
  doi="10.17487/RFC7239",
  }

@misc{rfc7240,
  author="J. Snell",
  title="{Prefer Header for HTTP}",
  howpublished="RFC 7240 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7240",
  pages="1--17",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8144",
url="https://www.rfc-editor.org/rfc/rfc7240.txt",
  key="RFC 7240",
  abstract={This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.},
  keywords="http, prefer",
  doi="10.17487/RFC7240",
  }

@misc{rfc7241,
  author="S. Dawkins and P. Thaler and D. Romascanu and B. Aboba",
  title="{The IEEE 802/IETF Relationship}",
  howpublished="RFC 7241 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7241",
  pages="1--35",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7241.txt",
  key="RFC 7241",
  abstract={This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441. Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.},
  keywords="snmp, aaa, simple network management protocol, authentication, authorization, accounting",
  doi="10.17487/RFC7241",
  }

@misc{rfc7242,
  author="M. Demmer and J. Ott and S. Perreault",
  title="{Delay-Tolerant Networking TCP Convergence-Layer Protocol}",
  howpublished="RFC 7242 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7242",
  pages="1--22",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7242.txt",
  key="RFC 7242",
  abstract={This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN).  It is the product of the IRTF's DTN Research Group (DTNRG).},
  doi="10.17487/RFC7242",
  }

@misc{rfc7243,
  author="V. Singh and J. Ott and I. Curcio",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric}",
  howpublished="RFC 7243 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7243",
  pages="1--12",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7243.txt",
  key="RFC 7243",
  abstract={The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics.  The available reporting may include aggregate information across longer periods of time as well as individual packet reporting.  This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.},
  keywords="rtp, reception statistics, de-jitter buffer",
  doi="10.17487/RFC7243",
  }

@misc{rfc7244,
  author="H. Asaeda and Q. Wu and R. Huang",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting}",
  howpublished="RFC 7244 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7244",
  pages="1--13",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7244.txt",
  key="RFC 7244",
  abstract={This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.},
  doi="10.17487/RFC7244",
  }

@misc{rfc7245,
  author="A. Hutton and L. Portman and R. Jain and K. Rehor",
  title="{An Architecture for Media Recording Using the Session Initiation Protocol}",
  howpublished="RFC 7245 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7245",
  pages="1--16",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7245.txt",
  key="RFC 7245",
  abstract={Session recording is a critical requirement in many communications environments such as call centers and financial trading.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.  Recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).},
  keywords="sip",
  doi="10.17487/RFC7245",
  }

@misc{rfc7246,
  author="IJ. Wijnands and P. Hitchen and N. Leymann and W. Henderickx and A. Gulko and J. Tantsura",
  title="{Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context}",
  howpublished="RFC 7246 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7246",
  pages="1--13",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7438",
url="https://www.rfc-editor.org/rfc/rfc7246.txt",
  key="RFC 7246",
  abstract={An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network.  Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region.  In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region.  Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region.  This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the ``BGP IP/MPLS VPN'' specification.  However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.},
  doi="10.17487/RFC7246",
  }

@misc{rfc7247,
  author="P. Saint-Andre and A. Houri and J. Hildebrand",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling}",
  howpublished="RFC 7247 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7247",
  pages="1--24",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7247.txt",
  key="RFC 7247",
  abstract={As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.},
  keywords="XMPP, SIP",
  doi="10.17487/RFC7247",
  }

@misc{rfc7248,
  author="P. Saint-Andre and A. Houri and J. Hildebrand",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence}",
  howpublished="RFC 7248 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7248",
  pages="1--30",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8048",
url="https://www.rfc-editor.org/rfc/rfc7248.txt",
  key="RFC 7248",
  abstract={This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).},
  keywords="XMPP, Jabber, SIP, SIMPLE, IM, Instant Messaging, Presence",
  doi="10.17487/RFC7248",
  }

@misc{rfc7249,
  author="R. Housley",
  title="{Internet Numbers Registries}",
  howpublished="RFC 7249 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7249",
  pages="1--6",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7249.txt",
  key="RFC 7249",
  abstract={RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space. This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.},
  doi="10.17487/RFC7249",
  }

@misc{rfc7250,
  author="P. Wouters and H. Tschofenig and J. Gilmore and S. Weiler and T. Kivinen",
  title="{Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 7250 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7250",
  pages="1--18",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7250.txt",
  key="RFC 7250",
  abstract={This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.},
  keywords="TLS, DNSSEC, DANE, Raw Public Key",
  doi="10.17487/RFC7250",
  }

@misc{rfc7251,
  author="D. McGrew and D. Bailey and M. Campagna and R. Dugal",
  title="{AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS}",
  howpublished="RFC 7251 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7251",
  pages="1--10",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7251.txt",
  key="RFC 7251",
  abstract={This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security.  The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.},
  doi="10.17487/RFC7251",
  }

@misc{rfc7252,
  author="Z. Shelby and K. Hartke and C. Bormann",
  title="{The Constrained Application Protocol (CoAP)}",
  howpublished="RFC 7252 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7252",
  pages="1--112",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7959",
url="https://www.rfc-editor.org/rfc/rfc7252.txt",
  key="RFC 7252",
  abstract={The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.},
  doi="10.17487/RFC7252",
  }

@misc{rfc7253,
  author="T. Krovetz and P. Rogaway",
  title="{The OCB Authenticated-Encryption Algorithm}",
  howpublished="RFC 7253 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7253",
  pages="1--19",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7253.txt",
  key="RFC 7253",
  abstract={This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data.  This document is a product of the Crypto Forum Research Group (CFRG).},
  keywords="OCB, AEAD, authenticated-encryption",
  doi="10.17487/RFC7253",
  }

@misc{rfc7254,
  author="M. Montemurro and A. Allen and D. McDonald and P. Gosden",
  title="{A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)}",
  howpublished="RFC 7254 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7254",
  pages="1--16",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7254.txt",
  key="RFC 7254",
  abstract={This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV).  The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks.  The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA.  URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.},
  keywords="GSM, UMTS, LTE, 3GPP, Mobile, identifier, instance ID",
  doi="10.17487/RFC7254",
  }

@misc{rfc7255,
  author="A. Allen",
  title="{Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID}",
  howpublished="RFC 7255 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7255",
  pages="1--9",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7255.txt",
  key="RFC 7255",
  abstract={This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id.  Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.},
  keywords="GSM, UMTS, LTE, 3GPP, IMS, SIP, GRUU, Mobile, identifier, instance ID",
  doi="10.17487/RFC7255",
  }

@misc{rfc7256,
  author="F. Le Faucheur and R. Maglione and T. Taylor",
  title="{Multicast Control Extensions for the Access Node Control Protocol (ANCP)}",
  howpublished="RFC 7256 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7256",
  pages="1--99",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7256.txt",
  key="RFC 7256",
  abstract={This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o multicast replication initiated by the Network Access Server (NAS); o conditional access and admission control with white and black lists; o conditional access and admission control with grey lists; o bandwidth delegation; and o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.},
  doi="10.17487/RFC7256",
  }

@misc{rfc7257,
  author="T. Nadeau and A. Kiran Koushik and R. Mediratta",
  title="{Virtual Private LAN Service (VPLS) Management Information Base}",
  howpublished="RFC 7257 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7257",
  pages="1--48",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7257.txt",
  key="RFC 7257",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects to configure and/or monitor Virtual Private LAN services.  It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).},
  doi="10.17487/RFC7257",
  }

@misc{rfc7258,
  author="S. Farrell and H. Tschofenig",
  title="{Pervasive Monitoring Is an Attack}",
  howpublished="RFC 7258 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7258",
  pages="1--6",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7258.txt",
  key="RFC 7258",
  abstract={Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.},
  keywords="pervasive monitoring",
  doi="10.17487/RFC7258",
  }

@misc{rfc7259,
  author="P. Saint-Andre",
  title="{The Jabber-ID Header Field}",
  howpublished="RFC 7259 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7259",
  pages="1--7",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7259.txt",
  key="RFC 7259",
  abstract={This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.},
  keywords="Jabber, XMPP, Extensible Messaging and Presence Protocol, email, netnews, message header field, IM, instant messaging",
  doi="10.17487/RFC7259",
  }

@misc{rfc7260,
  author="A. Takacs and D. Fedyk and J. He",
  title="{GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration}",
  howpublished="RFC 7260 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7260",
  pages="1--24",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7260.txt",
  key="RFC 7260",
  abstract={Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation.  In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities.  This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.},
  keywords="MPLS-TP, Transport Profile, GELS, Ethernet Label Switching, PBB-TE, connectivity monitoring, OAM configuration",
  doi="10.17487/RFC7260",
  }

@misc{rfc7261,
  author="M. Perumal and P. Ravindran",
  title="{Offer/Answer Considerations for G723 Annex A and G729 Annex B}",
  howpublished="RFC 7261 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7261",
  pages="1--8",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7261.txt",
  key="RFC 7261",
  abstract={This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.},
  keywords="offer, answer",
  doi="10.17487/RFC7261",
  }

@misc{rfc7262,
  author="A. Romanow and S. Botzko and M. Barnes",
  title="{Requirements for Telepresence Multistreams}",
  howpublished="RFC 7262 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7262",
  pages="1--12",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7262.txt",
  key="RFC 7262",
  abstract={This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE).  In addition, the problem statement and related definitions are also covered herein.},
  doi="10.17487/RFC7262",
  }

@misc{rfc7263,
  author="N. Zong and X. Jiang and R. Even and Y. Zhang",
  title="{An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing}",
  howpublished="RFC 7263 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7263",
  pages="1--20",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7263.txt",
  key="RFC 7263",
  abstract={This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode.  RELOAD recommends symmetric recursive routing for routing messages.  The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.  This document also describes potential cases where this extension can be used.},
  keywords="P2P",
  doi="10.17487/RFC7263",
  }

@misc{rfc7264,
  author="N. Zong and X. Jiang and R. Even and Y. Zhang",
  title="{An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing}",
  howpublished="RFC 7264 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7264",
  pages="1--15",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7264.txt",
  key="RFC 7264",
  abstract={This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode.  RELOAD recommends symmetric recursive routing for routing messages.  The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.  This document also describes potential cases where this extension can be used.},
  keywords="P2P",
  doi="10.17487/RFC7264",
  }

@misc{rfc7265,
  author="P. Kewisch and C. Daboo and M. Douglass",
  title="{jCal: The JSON Format for iCalendar}",
  howpublished="RFC 7265 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7265",
  pages="1--31",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7529",
url="https://www.rfc-editor.org/rfc/rfc7265.txt",
  key="RFC 7265",
  abstract={This specification defines ``jCal'', a JSON format for iCalendar data.  The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events.  JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.},
  doi="10.17487/RFC7265",
  }

@misc{rfc7266,
  author="A. Clark and Q. Wu and R. Schott and G. Zorn",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting}",
  howpublished="RFC 7266 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7266",
  pages="1--23",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7266.txt",
  key="RFC 7266",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.},
  doi="10.17487/RFC7266",
  }

@misc{rfc7267,
  author="L. Martini and M. Bocci and F. Balus",
  title="{Dynamic Placement of Multi-Segment Pseudowires}",
  howpublished="RFC 7267 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7267",
  pages="1--24",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7267.txt",
  key="RFC 7267",
  abstract={RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains.  A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW.  This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers.  This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.},
  keywords="pw, pw switching point pe sub-tlv",
  doi="10.17487/RFC7267",
  }

@misc{rfc7268,
  author="B. Aboba and J. Malinen and P. Congdon and J. Salowey and M. Jones",
  title="{RADIUS Attributes for IEEE 802 Networks}",
  howpublished="RFC 7268 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7268",
  pages="1--29",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8044",
url="https://www.rfc-editor.org/rfc/rfc7268.txt",
  key="RFC 7268",
  abstract={RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs).  This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute.  This document updates RFCs 3580 and 4072.},
  doi="10.17487/RFC7268",
  }

@misc{rfc7269,
  author="G. Chen and Z. Cao and C. Xie and D. Binet",
  title="{NAT64 Deployment Options and Experience}",
  howpublished="RFC 7269 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7269",
  pages="1--22",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7269.txt",
  key="RFC 7269",
  abstract={This document summarizes NAT64 function deployment scenarios and operational experience.  Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.},
  doi="10.17487/RFC7269",
  }

@misc{rfc7270,
  author="A. Yourtchenko and P. Aitken and B. Claise",
  title="{Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)}",
  howpublished="RFC 7270 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7270",
  pages="1--21",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7270.txt",
  key="RFC 7270",
  abstract={This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.},
  keywords="IPFIX",
  doi="10.17487/RFC7270",
  }

@misc{rfc7271,
  author="J. Ryoo and E. Gray and H. van Helvoort and A. D'Alessandro and T. Cheung and E. Osborne",
  title="{MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators}",
  howpublished="RFC 7271 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7271",
  pages="1--40",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7271.txt",
  key="RFC 7271",
  abstract={This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.},
  keywords="PSC mode, APS mode, capabilities, priority, non-revertive, MS-W support, SD support, EXER support",
  doi="10.17487/RFC7271",
  }

@misc{rfc7272,
  author="R. van Brandenburg and H. Stokking and O. van Deventer and F. Boronat and M. Montagud and K. Gross",
  title="{Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)}",
  howpublished="RFC 7272 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7272",
  pages="1--23",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7272.txt",
  key="RFC 7272",
  abstract={This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.},
  keywords="Inter-Destination Media Synchronization, RTP Control Protocol, RTCP",
  doi="10.17487/RFC7272",
  }

@misc{rfc7273,
  author="A. Williams and K. Gross and R. van Brandenburg and H. Stokking",
  title="{RTP Clock Source Signalling}",
  howpublished="RFC 7273 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7273",
  pages="1--30",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7273.txt",
  key="RFC 7273",
  abstract={NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements.  This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.},
  keywords="clock, source",
  doi="10.17487/RFC7273",
  }

@misc{rfc7274,
  author="K. Kompella and L. Andersson and A. Farrel",
  title="{Allocating and Retiring Special-Purpose MPLS Labels}",
  howpublished="RFC 7274 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7274",
  pages="1--11",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7274.txt",
  key="RFC 7274",
  abstract={Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called ``reserved labels''. They will be called ``special-purpose labels'' in this document. As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for. This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to ``Special-Purpose MPLS Label Values'' and creates a new registry called the ``Extended Special-Purpose MPLS Label Values'' registry. This document updates a number of previous RFCs that use the term ``reserved label''. Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.},
  doi="10.17487/RFC7274",
  }

@misc{rfc7275,
  author="L. Martini and S. Salam and A. Sajassi and M. Bocci and S. Matsushima and T. Nadeau",
  title="{Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy}",
  howpublished="RFC 7275 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7275",
  pages="1--83",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7275.txt",
  key="RFC 7275",
  abstract={This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications.  The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems.  It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.},
  keywords="iccp",
  doi="10.17487/RFC7275",
  }

@misc{rfc7276,
  author="T. Mizrahi and N. Sprecher and E. Bellagamba and Y. Weingarten",
  title="{An Overview of Operations, Administration, and Maintenance (OAM) Tools}",
  howpublished="RFC 7276 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7276",
  pages="1--53",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7276.txt",
  key="RFC 7276",
  abstract={Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.},
  doi="10.17487/RFC7276",
  }

@misc{rfc7277,
  author="M. Bjorklund",
  title="{A YANG Data Model for IP Management}",
  howpublished="RFC 7277 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7277",
  pages="1--30",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7277.txt",
  key="RFC 7277",
  abstract={This document defines a YANG data model for management of IP implementations.  The data model includes configuration data and state data.},
  keywords="netmod",
  doi="10.17487/RFC7277",
  }

@misc{rfc7278,
  author="C. Byrne and D. Drown and A. Vizdal",
  title="{Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link}",
  howpublished="RFC 7278 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7278",
  pages="1--10",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7278.txt",
  key="RFC 7278",
  abstract={This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.},
  doi="10.17487/RFC7278",
  }

@misc{rfc7279,
  author="M. Shore and C. Pignataro",
  title="{An Acceptable Use Policy for New ICMP Types and Codes}",
  howpublished="RFC 7279 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7279",
  pages="1--10",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7279.txt",
  key="RFC 7279",
  abstract={In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use. This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.},
  keywords="icmp, icmpv4, icmpv6",
  doi="10.17487/RFC7279",
  }

@misc{rfc7280,
  author="G. Fairhurst",
  title="{IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry}",
  howpublished="RFC 7280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7280",
  pages="1--7",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7280.txt",
  key="RFC 7280",
  abstract={This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry.  This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.},
  keywords="ULE, IANA",
  doi="10.17487/RFC7280",
  }

@misc{rfc7281,
  author="A. Melnikov",
  title="{Authentication-Results Registration for S/MIME Signature Verification}",
  howpublished="RFC 7281 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7281",
  pages="1--11",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7281.txt",
  key="RFC 7281",
  abstract={RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks.  This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.},
  keywords="Authentication-Results, S/MIME",
  doi="10.17487/RFC7281",
  }

@misc{rfc7282,
  author="P. Resnick",
  title="{On Consensus and Humming in the IETF}",
  howpublished="RFC 7282 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7282",
  pages="1--19",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7282.txt",
  key="RFC 7282",
  abstract={The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a ``majority rule'' philosophy. This is why we engage in rituals like ``humming'' instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus. Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.},
  keywords="accommodate, agree, agreement, appease, argue, argument, balloting, capitulated, capitulation, chair, choice, choose, coin, compromise, count, decide, decision, disagree, disagreement, hands, horse-trade, horse-trading, hum, issue, judge, judging, king, majority, member, minority, object, objection, objector, president, rough, unaddressed, vote, voting, working group",
  doi="10.17487/RFC7282",
  }

@misc{rfc7283,
  author="Y. Cui and Q. Sun and T. Lemon",
  title="{Handling Unknown DHCPv6 Messages}",
  howpublished="RFC 7283 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7283",
  pages="1--7",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7283.txt",
  key="RFC 7283",
  abstract={DHCPv6 is not specific about handling messages with unknown types.  This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages.  This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents.  This document updates RFC 3315.},
  keywords="DHCPv6, Unknown Messages",
  doi="10.17487/RFC7283",
  }

@misc{rfc7284,
  author="M. Lanthaler",
  title="{The Profile URI Registry}",
  howpublished="RFC 7284 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7284",
  pages="1--5",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7284.txt",
  key="RFC 7284",
  abstract={This document defines a registry for profile URIs to be used in specifications standardizing profiles.},
  keywords="profile, profiles, URI, registry",
  doi="10.17487/RFC7284",
  }

@misc{rfc7285,
  author="R. Alimi and R. Penno and Y. Yang and S. Kiesel and S. Previdi and W. Roome and S. Shalunov and R. Woundy",
  title="{Application-Layer Traffic Optimization (ALTO) Protocol}",
  howpublished="RFC 7285 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7285",
  pages="1--91",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7285.txt",
  key="RFC 7285",
  abstract={Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.},
  keywords="ALTO Information Resources, Network Map, PID, Filtered Network Map, Cost Map, Endpoint Property Service, Endpoint Cost Service",
  doi="10.17487/RFC7285",
  }

@misc{rfc7286,
  author="S. Kiesel and M. Stiemerling and N. Schwan and M. Scharf and H. Song",
  title="{Application-Layer Traffic Optimization (ALTO) Server Discovery}",
  howpublished="RFC 7286 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7286",
  pages="1--15",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7286.txt",
  key="RFC 7286",
  abstract={The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers. This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.},
  doi="10.17487/RFC7286",
  }

@misc{rfc7287,
  author="T. Schmidt and S. Gao and H. Zhang and M. Waehlisch",
  title="{Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains}",
  howpublished="RFC 7287 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7287",
  pages="1--28",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7287.txt",
  key="RFC 7287",
  abstract={Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes.  This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios.  Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined.  Mobile sources always remain agnostic of multicast mobility operations.},
  doi="10.17487/RFC7287",
  }

@misc{rfc7288,
  author="D. Thaler",
  title="{Reflections on Host Firewalls}",
  howpublished="RFC 7288 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7288",
  pages="1--13",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7288.txt",
  key="RFC 7288",
  abstract={In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice.  Unlike traditional firewalls that protect network links, host firewalls run in end-user systems.  Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall.  It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication.  In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.},
  keywords="Filter, Filtering",
  doi="10.17487/RFC7288",
  }

@misc{rfc7289,
  author="V. Kuarsingh and J. Cianfarani",
  title="{Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs}",
  howpublished="RFC 7289 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7289",
  pages="1--20",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7289.txt",
  key="RFC 7289",
  abstract={This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT).  The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function.  Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN.  Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone.  This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings.  The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network.  This document does not intend to defend the merits of CGN.},
  keywords="NAT444, LSN, Large-Scale NAT",
  doi="10.17487/RFC7289",
  }

@misc{rfc7290,
  author="L. Ciavattone and R. Geib and A. Morton and M. Wieser",
  title="{Test Plan and Results for Advancing RFC 2680 on the Standards Track}",
  howpublished="RFC 7290 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7290",
  pages="1--31",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7290.txt",
  key="RFC 7290",
  abstract={This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track.  Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended.  Two completely independent implementations have been tested against the key specifications of RFC 2680.},
  keywords="packet loss, IPPM implementation comparison, perfas+, netem, IPPM comparison, metric test, WIPM, NetProbe",
  doi="10.17487/RFC7290",
  }

@misc{rfc7291,
  author="M. Boucadair and R. Penno and D. Wing",
  title="{DHCP Options for the Port Control Protocol (PCP)}",
  howpublished="RFC 7291 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7291",
  pages="1--11",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7291.txt",
  key="RFC 7291",
  abstract={This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses.  The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios.  The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.},
  keywords="PCP Server discovery, Port Mapping, Shared Address",
  doi="10.17487/RFC7291",
  }

@misc{rfc7292,
  author="K. Moriarty and M. Nystrom and S. Parkinson and A. Rusch and M. Scott",
  title="{PKCS \#12: Personal Information Exchange Syntax v1.1}",
  howpublished="RFC 7292 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7292",
  pages="1--29",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7292.txt",
  key="RFC 7292",
  abstract={PKCS \#12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes. This document represents a republication of PKCS \#12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.},
  keywords="PKCS\#12, PKCS12v1.1, PKCS\#12v1.1",
  doi="10.17487/RFC7292",
  }

@misc{rfc7293,
  author="W. Mills and M. Kucherawy",
  title="{The Require-Recipient-Valid-Since Header Field and SMTP Service Extension}",
  howpublished="RFC 7293 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7293",
  pages="1--24",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7293.txt",
  key="RFC 7293",
  abstract={This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called ``RRVS'' to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called ``Require-Recipient-Valid-Since'' that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.},
  keywords="Security, Privacy, Email, Account Expiration",
  doi="10.17487/RFC7293",
  }

@misc{rfc7294,
  author="A. Clark and G. Zorn and C. Bi and Q. Wu",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications}",
  howpublished="RFC 7294 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7294",
  pages="1--22",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7294.txt",
  key="RFC 7294",
  abstract={This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.},
  keywords="Real Time Control Protocol",
  doi="10.17487/RFC7294",
  }

@misc{rfc7295,
  author="H. Tschofenig and L. Eggert and Z. Sarker",
  title="{Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication}",
  howpublished="RFC 7295 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7295",
  pages="1--26",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7295.txt",
  key="RFC 7295",
  abstract={This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).},
  keywords="Congestion Control, RTCWEB, Workshop, Real-Time Communication",
  doi="10.17487/RFC7295",
  }

@misc{rfc7296,
  author="C. Kaufman and P. Hoffman and Y. Nir and P. Eronen and T. Kivinen",
  title="{Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 7296 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7296",
  pages="1--142",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7427, 7670",
url="https://www.rfc-editor.org/rfc/rfc7296.txt",
  key="RFC 7296",
  abstract={This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document obsoletes RFC 5996, and includes all of the errata for it.  It advances IKEv2 to be an Internet Standard.},
  keywords="IKE, IPsec",
  doi="10.17487/RFC7296",
  }

@misc{rfc7297,
  author="M. Boucadair and C. Jacquenet and N. Wang",
  title="{IP Connectivity Provisioning Profile (CPP)}",
  howpublished="RFC 7297 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7297",
  pages="1--22",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7297.txt",
  key="RFC 7297",
  abstract={This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.},
  doi="10.17487/RFC7297",
  }

@misc{rfc7298,
  author="D. Ovsienko",
  title="{Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication}",
  howpublished="RFC 7298 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7298",
  pages="1--55",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7298.txt",
  key="RFC 7298",
  abstract={This document describes a cryptographic authentication mechanism for the Babel routing protocol.  This document updates RFC 6126.  The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.},
  keywords="routing protocol, authentication, applied cryptography",
  doi="10.17487/RFC7298",
  }

@misc{rfc7299,
  author="R. Housley",
  title="{Object Identifier Registry for the PKIX Working Group}",
  howpublished="RFC 7299 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7299",
  pages="1--30",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7299.txt",
  key="RFC 7299",
  abstract={When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group.  This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.},
  keywords="Public-Key Infrastructure using X.509",
  doi="10.17487/RFC7299",
  }

@misc{rfc7300,
  author="J. Haas and J. Mitchell",
  title="{Reservation of Last Autonomous System (AS) Numbers}",
  howpublished="RFC 7300 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7300",
  pages="1--5",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7300.txt",
  key="RFC 7300",
  abstract={This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as ``Last ASNs'', and provides guidance to implementers and operators on their use.  This document updates Section 10 of RFC 1930.},
  keywords="asn, last asns",
  doi="10.17487/RFC7300",
  }

@misc{rfc7301,
  author="S. Friedl and A. Popov and A. Langley and E. Stephan",
  title="{Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension}",
  howpublished="RFC 7301 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7301",
  pages="1--9",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7301.txt",
  key="RFC 7301",
  abstract={This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.  For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.},
  keywords="ALPN",
  doi="10.17487/RFC7301",
  }

@misc{rfc7302,
  author="P. Lemieux",
  title="{Entertainment Identifier Registry (EIDR) URN Namespace Definition}",
  howpublished="RFC 7302 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7302",
  pages="1--8",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7972",
url="https://www.rfc-editor.org/rfc/rfc7302.txt",
  key="RFC 7302",
  abstract={Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content.  This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.},
  keywords="EIDR, Entertainment Identifier Registry, URN",
  doi="10.17487/RFC7302",
  }

@misc{rfc7303,
  author="H. Thompson and C. Lilley",
  title="{XML Media Types}",
  howpublished="RFC 7303 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7303",
  pages="1--35",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7303.txt",
  key="RFC 7303",
  abstract={This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types.  This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.},
  keywords="application/xml, application/xml-external-parsed-entity, application/xml-dtd, text/xml, text/xml-external-parsed-entity, +xml",
  doi="10.17487/RFC7303",
  }

@misc{rfc7304,
  author="W. Kumari",
  title="{A Method for Mitigating Namespace Collisions}",
  howpublished="RFC 7304 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7304",
  pages="1--4",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7304.txt",
  key="RFC 7304",
  abstract={This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.},
  doi="10.17487/RFC7304",
  }

@misc{rfc7305,
  author="E. Lear",
  title="{Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)}",
  howpublished="RFC 7305 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7305",
  pages="1--17",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7305.txt",
  key="RFC 7305",
  abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.},
  doi="10.17487/RFC7305",
  }

@misc{rfc7306,
  author="H. Shah and F. Marti and W. Noureddine and A. Eiriksson and R. Sharp",
  title="{Remote Direct Memory Access (RDMA) Protocol Extensions}",
  howpublished="RFC 7306 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7306",
  pages="1--34",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7306.txt",
  key="RFC 7306",
  abstract={This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040.  RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies.  The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.},
  keywords="iWARP, RDMAP, DDP, RDMA, DMA",
  doi="10.17487/RFC7306",
  }

@misc{rfc7307,
  author="Q. Zhao and K. Raza and C. Zhou and L. Fang and L. Li and D. King",
  title="{LDP Extensions for Multi-Topology}",
  howpublished="RFC 7307 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7307",
  pages="1--20",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7307.txt",
  key="RFC 7307",
  abstract={Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.},
  keywords="MT, Label Distribution Protocol",
  doi="10.17487/RFC7307",
  }

@misc{rfc7308,
  author="E. Osborne",
  title="{Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)}",
  howpublished="RFC 7308 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7308",
  pages="1--7",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7308.txt",
  key="RFC 7308",
  abstract={MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as ``colors'' or ``link colors'') using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305). This document adds a sub-TLV to the IGP TE extensions, ``Extended Administrative Group''. This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.},
  keywords="colors, link colors, igp te extensions",
  doi="10.17487/RFC7308",
  }

@misc{rfc7309,
  author="Z. Liu and L. Jin and R. Chen and D. Cai and S. Salam",
  title="{Redundancy Mechanism for Inter-domain VPLS Service}",
  howpublished="RFC 7309 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7309",
  pages="1--12",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7309.txt",
  key="RFC 7309",
  abstract={In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain.  This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy.  This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.},
  keywords="ICCP, PW",
  doi="10.17487/RFC7309",
  }

@misc{rfc7310,
  author="J. Lindsay and H. Foerster",
  title="{RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs}",
  howpublished="RFC 7310 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7310",
  pages="1--16",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7310.txt",
  key="RFC 7310",
  abstract={This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets.  The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).},
  doi="10.17487/RFC7310",
  }

@misc{rfc7311,
  author="P. Mohapatra and R. Fernando and E. Rosen and J. Uttaro",
  title="{The Accumulated IGP Metric Attribute for BGP}",
  howpublished="RFC 7311 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7311",
  pages="1--15",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7311.txt",
  key="RFC 7311",
  abstract={Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized.  BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric.  It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems.  However, there are deployments in which a single administration runs several contiguous BGP networks.  In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do.  The purpose of this document is to provide a specification for doing so.},
  doi="10.17487/RFC7311",
  }

@misc{rfc7312,
  author="J. Fabini and A. Morton",
  title="{Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)}",
  howpublished="RFC 7312 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7312",
  pages="1--17",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7312.txt",
  key="RFC 7312",
  abstract={To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets.  This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing.  The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows.  Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance.  This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.},
  keywords="Measurement, Wireless, Reactive, Repeatability, Continuity, Actionable, Conservative, Spatial Composition, Temporal Composition",
  doi="10.17487/RFC7312",
  }

@misc{rfc7313,
  author="K. Patel and E. Chen and B. Venkatachalapathy",
  title="{Enhanced Route Refresh Capability for BGP-4}",
  howpublished="RFC 7313 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7313",
  pages="1--8",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7313.txt",
  key="RFC 7313",
  abstract={In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh.  The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner.  This document updates RFC 2918.},
  keywords="Border Gateway Protocol, bgp rib, BGP Routing Information Base",
  doi="10.17487/RFC7313",
  }

@misc{rfc7314,
  author="M. Andrews",
  title="{Extension Mechanisms for DNS (EDNS) EXPIRE Option}",
  howpublished="RFC 7314 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7314",
  pages="1--4",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7314.txt",
  key="RFC 7314",
  abstract={This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.},
  keywords="IXFR, AXFR, zone, transfer, DNS, SOA",
  doi="10.17487/RFC7314",
  }

@misc{rfc7315,
  author="R. Jesske and K. Drage and C. Holmberg",
  title="{Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP}",
  howpublished="RFC 7315 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7315",
  pages="1--43",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 7913, 7976",
url="https://www.rfc-editor.org/rfc/rfc7315.txt",
  key="RFC 7315",
  abstract={This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments.  The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses.  This document obsoletes RFC 3455.},
  doi="10.17487/RFC7315",
  }

@misc{rfc7316,
  author="J. van Elburg and K. Drage and M. Ohsugi and S. Schubert and K. Arai",
  title="{The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)}",
  howpublished="RFC 7316 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7316",
  pages="1--15",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7316.txt",
  key="RFC 7316",
  abstract={This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP.  The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network.  A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.},
  doi="10.17487/RFC7316",
  }

@misc{rfc7317,
  author="A. Bierman and M. Bjorklund",
  title="{A YANG Data Model for System Management}",
  howpublished="RFC 7317 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7317",
  pages="1--35",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7317.txt",
  key="RFC 7317",
  abstract={This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server.  This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.},
  keywords="NETCONF",
  doi="10.17487/RFC7317",
  }

@misc{rfc7318,
  author="A. Newton and G. Huston",
  title="{Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates}",
  howpublished="RFC 7318 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7318",
  pages="1--5",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7318.txt",
  key="RFC 7318",
  abstract={This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.},
  doi="10.17487/RFC7318",
  }

@misc{rfc7319,
  author="D. {Eastlake 3rd}",
  title="{IANA Considerations for Connectivity Fault Management (CFM) Code Points}",
  howpublished="RFC 7319 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7319",
  pages="1--5",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7319.txt",
  key="RFC 7319",
  abstract={IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities.  CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information.  IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF.  This document specifies the IANA considerations for the assignment of values from these blocks.},
  keywords="CFM, OAM, Connectivity, Continuity, Fault, IANA, TRILL",
  doi="10.17487/RFC7319",
  }

@misc{rfc7320,
  author="M. Nottingham",
  title="{URI Design and Ownership}",
  howpublished="RFC 7320 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7320",
  pages="1--9",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7320.txt",
  key="RFC 7320",
  abstract={Section 1.1.1 of RFC 3986 defines URI syntax as ``a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.'' In other words, the structure of a URI is defined by its scheme.  While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership.  This document further describes this problematic practice and provides some acceptable alternatives for use in standards.},
  keywords="URI structure",
  doi="10.17487/RFC7320",
  }

@misc{rfc7321,
  author="D. McGrew and P. Hoffman",
  title="{Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)}",
  howpublished="RFC 7321 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7321",
  pages="1--11",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7321.txt",
  key="RFC 7321",
  abstract={This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms. ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.},
  doi="10.17487/RFC7321",
  }

@misc{rfc7322,
  author="H. Flanagan and S. Ginoza",
  title="{RFC Style Guide}",
  howpublished="RFC 7322 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7322",
  pages="1--24",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7997",
url="https://www.rfc-editor.org/rfc/rfc7322.txt",
  key="RFC 7322",
  abstract={This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.  It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC.  Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.  This document obsoletes RFC 2223, ``Instructions to RFC Authors''.},
  keywords="editorial guidance, format, style manual, house style",
  doi="10.17487/RFC7322",
  }

@misc{rfc7323,
  author="D. Borman and B. Braden and V. Jacobson and R. Scheffenegger",
  title="{TCP Extensions for High Performance}",
  howpublished="RFC 7323 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7323",
  pages="1--49",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7323.txt",
  key="RFC 7323",
  abstract={This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it.},
  keywords="Timestamps, Timestamp, RTT, RTTM, Window Scale, PAWS, TCP options",
  doi="10.17487/RFC7323",
  }

@misc{rfc7324,
  author="E. Osborne",
  title="{Updates to MPLS Transport Profile Linear Protection}",
  howpublished="RFC 7324 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7324",
  pages="1--11",
  year=2014,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7324.txt",
  key="RFC 7324",
  abstract={This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, ``MPLS Transport Profile (MPLS-TP) Linear Protection''.  These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.},
  keywords="multiprotocol label switching, mpls-tp, psc, protection state coordination",
  doi="10.17487/RFC7324",
  }

@misc{rfc7325,
  author="C. Villamizar and K. Kompella and S. Amante and A. Malis and C. Pignataro",
  title="{MPLS Forwarding Compliance and Performance Requirements}",
  howpublished="RFC 7325 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7325",
  pages="1--59",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7325.txt",
  key="RFC 7325",
  abstract={This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations.  Guidelines cover many aspects of MPLS forwarding.  Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.},
  keywords="MPLS, ECMP, link bundling, multipath, MPLS-TP, forwarding",
  doi="10.17487/RFC7325",
  }

@misc{rfc7326,
  author="J. Parello and B. Claise and B. Schoening and J. Quittek",
  title="{Energy Management Framework}",
  howpublished="RFC 7326 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7326",
  pages="1--54",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7326.txt",
  key="RFC 7326",
  abstract={This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks.  The framework presents a physical reference model and information model.  The information model consists of an Energy Management Domain as a set of Energy Objects.  Each Energy Object can be attributed with identity, classification, and context.  Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery.  Additionally, the framework models relationships and capabilities between Energy Objects.},
  doi="10.17487/RFC7326",
  }

@misc{rfc7328,
  author="R. Gieben",
  title="{Writing I-Ds and RFCs Using Pandoc and a Bit of XML}",
  howpublished="RFC 7328 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7328",
  pages="1--10",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7328.txt",
  key="RFC 7328",
  abstract={This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs. The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.},
  doi="10.17487/RFC7328",
  }

@misc{rfc7329,
  author="H. Kaplan",
  title="{A Session Identifier for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 7329 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7329",
  pages="1--17",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7989",
url="https://www.rfc-editor.org/rfc/rfc7329.txt",
  key="RFC 7329",
  abstract={There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID. The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.},
  doi="10.17487/RFC7329",
  }

@misc{rfc7330,
  author="T. Nadeau and Z. Ali and N. Akiya",
  title="{Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management}",
  howpublished="RFC 7330 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7330",
  pages="1--11",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7330.txt",
  key="RFC 7330",
  abstract={This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information.  The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.},
  keywords="Network Management, management Information Base, MIB, SMIv2, BFD",
  doi="10.17487/RFC7330",
  }

@misc{rfc7331,
  author="T. Nadeau and Z. Ali and N. Akiya",
  title="{Bidirectional Forwarding Detection (BFD) Management Information Base}",
  howpublished="RFC 7331 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7331",
  pages="1--39",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7331.txt",
  key="RFC 7331",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.},
  keywords="Network Management, Management Information Base, MIB, SMIv2, BFD",
  doi="10.17487/RFC7331",
  }

@misc{rfc7332,
  author="H. Kaplan and V. Pascual",
  title="{Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)}",
  howpublished="RFC 7332 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7332",
  pages="1--5",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7332.txt",
  key="RFC 7332",
  abstract={SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values.  This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.},
  doi="10.17487/RFC7332",
  }

@misc{rfc7333,
  author="H. Chan and D. Liu and P. Seite and H. Yokota and J. Korhonen",
  title="{Requirements for Distributed Mobility Management}",
  howpublished="RFC 7333 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7333",
  pages="1--24",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7333.txt",
  key="RFC 7333",
  abstract={This document defines the requirements for Distributed Mobility Management (DMM) at the network layer.  The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors.  As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route.  The motivation and the problems addressed by each requirement are also described.},
  keywords="Distributed Mobility Management, Network function distribution, Flat mobile network, Mobile network operation and management, Control and data plane separation",
  doi="10.17487/RFC7333",
  }

@misc{rfc7334,
  author="Q. Zhao and D. Dhody and D. King and Z. Ali and R. Casellas",
  title="{PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths}",
  howpublished="RFC 7334 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7334",
  pages="1--25",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7334.txt",
  key="RFC 7334",
  abstract={The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.},
  keywords="Core-tree",
  doi="10.17487/RFC7334",
  }

@misc{rfc7335,
  author="C. Byrne",
  title="{IPv4 Service Continuity Prefix}",
  howpublished="RFC 7335 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7335",
  pages="1--4",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7335.txt",
  key="RFC 7335",
  abstract={Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element.  Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.},
  doi="10.17487/RFC7335",
  }

@misc{rfc7336,
  author="L. Peterson and B. Davie and R. van Brandenburg",
  title="{Framework for Content Distribution Network Interconnection (CDNI)}",
  howpublished="RFC 7336 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7336",
  pages="1--58",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7336.txt",
  key="RFC 7336",
  abstract={This document presents a framework for Content Distribution Network Interconnection (CDNI).  The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs.  CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs.  The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents.  This document, in combination with RFC 6707, obsoletes RFC 3466.},
  keywords="CDNI, content delivery network, federation, cdni request routing, cdni logging, cdmi metadata, cdni control",
  doi="10.17487/RFC7336",
  }

@misc{rfc7337,
  author="K. Leung and Y. Lee",
  title="{Content Distribution Network Interconnection (CDNI) Requirements}",
  howpublished="RFC 7337 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7337",
  pages="1--23",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7337.txt",
  key="RFC 7337",
  abstract={Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.},
  doi="10.17487/RFC7337",
  }

@misc{rfc7338,
  author="F. Jounay and Y. Kamite and G. Heron and M. Bocci",
  title="{Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks}",
  howpublished="RFC 7338 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7338",
  pages="1--18",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7338.txt",
  key="RFC 7338",
  abstract={This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks.  The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation.  They are proposed as guidelines for the standardization of such mechanisms.  Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).},
  doi="10.17487/RFC7338",
  }

@misc{rfc7339,
  author="V. Gurbani and V. Hilt and H. Schulzrinne",
  title="{Session Initiation Protocol (SIP) Overload Control}",
  howpublished="RFC 7339 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7339",
  pages="1--38",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7339.txt",
  key="RFC 7339",
  abstract={Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive.  Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload.  This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.},
  keywords="SIP, Overload Control",
  doi="10.17487/RFC7339",
  }

@misc{rfc7340,
  author="J. Peterson and H. Schulzrinne and H. Tschofenig",
  title="{Secure Telephone Identity Problem Statement and Requirements}",
  howpublished="RFC 7340 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7340",
  pages="1--25",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7340.txt",
  key="RFC 7340",
  abstract={Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.},
  keywords="SIP, XMPP, Secure Origin Identification, Communication Security, RTCWeb, Problem Statement, Real-Time Communication",
  doi="10.17487/RFC7340",
  }

@misc{rfc7341,
  author="Q. Sun and Y. Cui and M. Siodelski and S. Krishnan and I. Farrer",
  title="{DHCPv4-over-DHCPv6 (DHCP 4o6) Transport}",
  howpublished="RFC 7341 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7341",
  pages="1--16",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7341.txt",
  key="RFC 7341",
  abstract={IPv4 connectivity is still needed as networks migrate towards IPv6.  Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only.  This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport.  Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.},
  keywords="ipv6, transition, softwire, migration, tunnel, residual, ipv4, dhcpv6, relay, ipv6-only",
  doi="10.17487/RFC7341",
  }

@misc{rfc7342,
  author="L. Dunbar and W. Kumari and I. Gashinsky",
  title="{Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers}",
  howpublished="RFC 7342 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7342",
  pages="1--14",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7342.txt",
  key="RFC 7342",
  abstract={This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.},
  doi="10.17487/RFC7342",
  }

@misc{rfc7343,
  author="J. Laganier and F. Dupont",
  title="{An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)}",
  howpublished="RFC 7343 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7343",
  pages="1--14",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7343.txt",
  key="RFC 7343",
  abstract={This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.},
  keywords="HIP, HIPv2, ORCHID, CGA, API",
  doi="10.17487/RFC7343",
  }

@misc{rfc7344,
  author="W. Kumari and O. Gudmundsson and G. Barwood",
  title="{Automating DNSSEC Delegation Trust Maintenance}",
  howpublished="RFC 7344 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7344",
  pages="1--18",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8078",
url="https://www.rfc-editor.org/rfc/rfc7344.txt",
  key="RFC 7344",
  abstract={This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel.  The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.},
  keywords="key roll, trust anchor, CDS, CDNSKEY, DNSSEC, DNS",
  doi="10.17487/RFC7344",
  }

@misc{rfc7345,
  author="C. Holmberg and I. Sedlacek and G. Salgueiro",
  title="{UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 7345 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7345",
  pages="1--23",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7345.txt",
  key="RFC 7345",
  abstract={This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).},
  keywords="SDP, SIP, DTLS, UDPTL, fax, transport",
  doi="10.17487/RFC7345",
  }

@misc{rfc7346,
  author="R. Droms",
  title="{IPv6 Multicast Address Scopes}",
  howpublished="RFC 7346 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7346",
  pages="1--6",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7346.txt",
  key="RFC 7346",
  abstract={This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.},
  keywords="IPv6 multicast address scopes",
  doi="10.17487/RFC7346",
  }

@misc{rfc7347,
  author="H. van Helvoort and J. Ryoo and H. Zhang and F. Huang and H. Li and A. D'Alessandro",
  title="{Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)}",
  howpublished="RFC 7347 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7347",
  pages="1--32",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7347.txt",
  key="RFC 7347",
  abstract={The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324. This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic. The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.},
  doi="10.17487/RFC7347",
  }

@misc{rfc7348,
  author="M. Mahalingam and D. Dutt and K. Duda and P. Agarwal and L. Kreeger and T. Sridhar and M. Bursell and C. Wright",
  title="{Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks}",
  howpublished="RFC 7348 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7348",
  pages="1--22",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7348.txt",
  key="RFC 7348",
  abstract={This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants.  The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers.  This memo documents the deployed VXLAN protocol for the benefit of the Internet community.},
  doi="10.17487/RFC7348",
  }

@misc{rfc7349,
  author="L. Zheng and M. Chen and M. Bhatia",
  title="{LDP Hello Cryptographic Authentication}",
  howpublished="RFC 7349 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7349",
  pages="1--14",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7349.txt",
  key="RFC 7349",
  abstract={This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages.  It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header.  This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.},
  doi="10.17487/RFC7349",
  }

@misc{rfc7350,
  author="M. Petit-Huguenin and G. Salgueiro",
  title="{Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 7350 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7350",
  pages="1--16",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7350.txt",
  key="RFC 7350",
  abstract={This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN).  It provides guidance on when and how to use DTLS with the currently standardized STUN usages.  It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol.  This document updates RFCs 5389 and 5928.},
  keywords="Security, Encryption",
  doi="10.17487/RFC7350",
  }

@misc{rfc7351,
  author="E. Wilde",
  title="{A Media Type for XML Patch Operations}",
  howpublished="RFC 7351 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7351",
  pages="1--14",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7351.txt",
  key="RFC 7351",
  abstract={The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document.  The XML patch document format builds on the foundations defined in RFC 5261.  This specification also provides the media type registration ``application/xml-patch+xml'', to allow the use of XML patch documents in, for example, HTTP conversations.},
  keywords="Media Type, XML Patch Operations",
  doi="10.17487/RFC7351",
  }

@misc{rfc7352,
  author="S. Bosch",
  title="{Sieve Email Filtering: Detecting Duplicate Deliveries}",
  howpublished="RFC 7352 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7352",
  pages="1--15",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7352.txt",
  key="RFC 7352",
  abstract={This document defines a new test command, ``duplicate'', for the Sieve email filtering language.  This test adds the ability to detect duplications.  The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses.  The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages.  For more complex applications, the ``duplicate'' test can also use the content of a specific header field or other parts of the message.},
  keywords="sieve, duplicate deliveries",
  doi="10.17487/RFC7352",
  }

@misc{rfc7353,
  author="S. Bellovin and R. Bush and D. Ward",
  title="{Security Requirements for BGP Path Validation}",
  howpublished="RFC 7353 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7353",
  pages="1--9",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7353.txt",
  key="RFC 7353",
  abstract={This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.},
  keywords="Routing, BGP, Security, AS\_PATH, and RPKI",
  doi="10.17487/RFC7353",
  }

@misc{rfc7354,
  author="A. Adolf and P. Siebert",
  title="{Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace}",
  howpublished="RFC 7354 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7354",
  pages="1--3",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7354.txt",
  key="RFC 7354",
  abstract={RFC 5328 registered the Uniform Resource Name (URN) namespace ``dvb'' for the Digital Video Broadcasting Project.  This document updates RFC 5328 with new registrant information.},
  doi="10.17487/RFC7354",
  }

@misc{rfc7355,
  author="G. Salgueiro and V. Pascual and A. Roman and S. Garcia",
  title="{Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)}",
  howpublished="RFC 7355 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7355",
  pages="1--9",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7355.txt",
  key="RFC 7355",
  abstract={RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments.  This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new ``Transport Flag'' for such SIP WebSocket transport.},
  doi="10.17487/RFC7355",
  }

@misc{rfc7356,
  author="L. Ginsberg and S. Previdi and Y. Yang",
  title="{IS-IS Flooding Scope Link State PDUs (LSPs)}",
  howpublished="RFC 7356 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7356",
  pages="1--23",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7356.txt",
  key="RFC 7356",
  abstract={Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.},
  doi="10.17487/RFC7356",
  }

@misc{rfc7357,
  author="H. Zhai and F. Hu and R. Perlman and D. {Eastlake 3rd} and O. Stokes",
  title="{Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol}",
  howpublished="RFC 7357 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7357",
  pages="1--31",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7357.txt",
  key="RFC 7357",
  abstract={The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges). ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.},
  keywords="ESADI, TRILL, RBridge, Address Learning, Reachability, MAC Addresses",
  doi="10.17487/RFC7357",
  }

@misc{rfc7358,
  author="K. Raza and S. Boutros and L. Martini and N. Leymann",
  title="{Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)}",
  howpublished="RFC 7358 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7358",
  pages="1--8",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7358.txt",
  key="RFC 7358",
  abstract={The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode.  This document updates RFC 5036 to make that fact clear.  It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.},
  doi="10.17487/RFC7358",
  }

@misc{rfc7359,
  author="F. Gont",
  title="{Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks}",
  howpublished="RFC 7359 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7359",
  pages="1--12",
  year=2014,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7359.txt",
  key="RFC 7359",
  abstract={The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages.  That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination.  This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software.  Additionally, this document offers possible mitigations for this issue.},
  doi="10.17487/RFC7359",
  }

@misc{rfc7360,
  author="A. DeKok",
  title="{Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS}",
  howpublished="RFC 7360 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7360",
  pages="1--27",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7360.txt",
  key="RFC 7360",
  abstract={The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets.  The protocol transports data in the clear, although some parts of the packets can have obfuscated content.  Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets.  This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems.  It also describes how implementations of this proposal can coexist with current RADIUS systems.},
  doi="10.17487/RFC7360",
  }

@misc{rfc7361,
  author="P. Dutta and F. Balus and O. Stokes and G. Calvignac and D. Fedyk",
  title="{LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)}",
  howpublished="RFC 7361 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7361",
  pages="1--27",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7361.txt",
  key="RFC 7361",
  abstract={RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes.  The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes.  This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned.  Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.},
  keywords="MAC flush message, MAC Flush TLV, MAC flushing",
  doi="10.17487/RFC7361",
  }

@misc{rfc7362,
  author="E. Ivov and H. Kaplan and D. Wing",
  title="{Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication}",
  howpublished="RFC 7362 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7362",
  pages="1--16",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7362.txt",
  key="RFC 7362",
  abstract={This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users. Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.},
  keywords="VoIP, firewall traversal",
  doi="10.17487/RFC7362",
  }

@misc{rfc7363,
  author="J. Maenpaa and G. Camarillo",
  title="{Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7363 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7363",
  pages="1--22",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7363.txt",
  key="RFC 7363",
  abstract={REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service.  Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data.  This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.},
  keywords="P2PSIP, P2P, Chord",
  doi="10.17487/RFC7363",
  }

@misc{rfc7364,
  author="T. Narten and E. Gray and D. Black and L. Fang and L. Kreeger and M. Napierala",
  title="{Problem Statement: Overlays for Network Virtualization}",
  howpublished="RFC 7364 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7364",
  pages="1--23",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7364.txt",
  key="RFC 7364",
  abstract={This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach.  A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant.  Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks.  Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway).  Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated.  Use of an overlay-based approach enables scalable deployment on large network infrastructures.},
  doi="10.17487/RFC7364",
  }

@misc{rfc7365,
  author="M. Lasserre and F. Balus and T. Morin and N. Bitar and Y. Rekhter",
  title="{Framework for Data Center (DC) Network Virtualization}",
  howpublished="RFC 7365 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7365",
  pages="1--26",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7365.txt",
  key="RFC 7365",
  abstract={This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.},
  keywords="nvo3, network virtualization over layer 3",
  doi="10.17487/RFC7365",
  }

@misc{rfc7366,
  author="P. Gutmann",
  title="{Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 7366 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7366",
  pages="1--7",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7366.txt",
  key="RFC 7366",
  abstract={This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.},
  doi="10.17487/RFC7366",
  }

@misc{rfc7367,
  author="R. Cole and J. Macker and B. Adamson",
  title="{Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process}",
  howpublished="RFC 7367 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7367",
  pages="1--65",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7367.txt",
  key="RFC 7367",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs).  The SMF-MIB module also reports state information, performance information, and notifications.  In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.},
  keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, MANET, Multicast",
  doi="10.17487/RFC7367",
  }

@misc{rfc7368,
  author="T. Chown and J. Arkko and A. Brandt and O. Troan and J. Weil",
  title="{IPv6 Home Networking Architecture Principles}",
  howpublished="RFC 7368 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7368",
  pages="1--49",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7368.txt",
  key="RFC 7368",
  abstract={This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing.  The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements.  The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking.  The architecture describes the need for specific protocol extensions for certain additional functionality.  It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network.  There are no recommendations in this text for the IPv4 part of the network.},
  keywords="IPv6",
  doi="10.17487/RFC7368",
  }

@misc{rfc7369,
  author="A. Takacs and B. Gero and H. Long",
  title="{GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration}",
  howpublished="RFC 7369 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7369",
  pages="1--18",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7369.txt",
  key="RFC 7369",
  abstract={The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs).  IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks.  CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms.  The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks.  This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework.  This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.},
  keywords="GELS, Ethernet Label Switching, PBB-TE, connectivity monitoring, OAM configuration",
  doi="10.17487/RFC7369",
  }

@misc{rfc7370,
  author="L. Ginsberg",
  title="{Updates to the IS-IS TLV Codepoints Registry}",
  howpublished="RFC 7370 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7370",
  pages="1--7",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7370.txt",
  key="RFC 7370",
  abstract={This document recommends some editorial changes to the IANA ``IS-IS TLV Codepoints'' registry to more accurately document the state of the protocol.  It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.},
  keywords="Codepoint",
  doi="10.17487/RFC7370",
  }

@misc{rfc7371,
  author="M. Boucadair and S. Venaas",
  title="{Updates to the IPv6 Multicast Addressing Architecture}",
  howpublished="RFC 7371 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7371",
  pages="1--10",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7371.txt",
  key="RFC 7371",
  abstract={This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits. This document updates RFCs 3956, 3306, and 4291.},
  keywords="IPv6 Multicast Flag Bits, updated unicast-prefix-based address, updated Embedded-RP",
  doi="10.17487/RFC7371",
  }

@misc{rfc7372,
  author="M. Kucherawy",
  title="{Email Authentication Status Codes}",
  howpublished="RFC 7372 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7372",
  pages="1--8",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7372.txt",
  key="RFC 7372",
  abstract={This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.},
  doi="10.17487/RFC7372",
  }

@misc{rfc7373,
  author="B. Trammell",
  title="{Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types}",
  howpublished="RFC 7373 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7373",
  pages="1--14",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7373.txt",
  key="RFC 7373",
  abstract={This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.},
  keywords="information element, unicode",
  doi="10.17487/RFC7373",
  }

@misc{rfc7374,
  author="J. Maenpaa and G. Camarillo",
  title="{Service Discovery Usage for REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7374 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7374",
  pages="1--20",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7374.txt",
  key="RFC 7374",
  abstract={REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940).  This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.},
  keywords="P2PSIP, ReDiR, P2P, DHT",
  doi="10.17487/RFC7374",
  }

@misc{rfc7375,
  author="J. Peterson",
  title="{Secure Telephone Identity Threat Model}",
  howpublished="RFC 7375 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7375",
  pages="1--13",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7375.txt",
  key="RFC 7375",
  abstract={As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.},
  keywords="SIP, Secure Origin Identification, Communication Security, RTCWeb, Threat, Real-Time Communication",
  doi="10.17487/RFC7375",
  }

@misc{rfc7376,
  author="T. Reddy and R. Ravindranath and M. Perumal and A. Yegin",
  title="{Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)}",
  howpublished="RFC 7376 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7376",
  pages="1--8",
  year=2014,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7376.txt",
  key="RFC 7376",
  abstract={This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.},
  doi="10.17487/RFC7376",
  }

@misc{rfc7377,
  author="B. Leiba and A. Melnikov",
  title="{IMAP4 Multimailbox SEARCH Extension}",
  howpublished="RFC 7377 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7377",
  pages="1--11",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7377.txt",
  key="RFC 7377",
  abstract={The IMAP4 specification allows the searching of only the selected mailbox.  A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next.  This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox.  This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.  This document updates RFC 4466 and obsoletes RFC 6237.},
  keywords="IMAP, email, search, multiple mailboxes, imapext",
  doi="10.17487/RFC7377",
  }

@misc{rfc7378,
  author="H. Tschofenig and H. Schulzrinne and B. Aboba",
  title="{Trustworthy Location}",
  howpublished="RFC 7378 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7378",
  pages="1--31",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7378.txt",
  key="RFC 7378",
  abstract={The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.},
  doi="10.17487/RFC7378",
  }

@misc{rfc7379,
  author="Y. Li and W. Hao and R. Perlman and J. Hudson and H. Zhai",
  title="{Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge}",
  howpublished="RFC 7379 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7379",
  pages="1--13",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7379.txt",
  key="RFC 7379",
  abstract={The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology.  Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus.  This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.},
  doi="10.17487/RFC7379",
  }

@misc{rfc7380,
  author="J. Tong and C. Bi and R. Even and Q. Wu and R. Huang",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting}",
  howpublished="RFC 7380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7380",
  pages="1--11",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7380.txt",
  key="RFC 7380",
  abstract={An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data.  Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems.  This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP.  The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.},
  keywords="TR 101 290",
  doi="10.17487/RFC7380",
  }

@misc{rfc7381,
  author="K. Chittimaneni and T. Chown and L. Howard and V. Kuarsingh and Y. Pouffary and E. Vyncke",
  title="{Enterprise IPv6 Deployment Guidelines}",
  howpublished="RFC 7381 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7381",
  pages="1--34",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7381.txt",
  key="RFC 7381",
  abstract={Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks.  The administrators face different challenges than operators of Internet access providers and have reasons for different priorities.  The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network.  The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode.  This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.},
  keywords="IPV6 migration transition enterprise",
  doi="10.17487/RFC7381",
  }

@misc{rfc7382,
  author="S. Kent and D. Kong and K. Seo",
  title="{Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)}",
  howpublished="RFC 7382 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7382",
  pages="1--38",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7382.txt",
  key="RFC 7382",
  abstract={This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.},
  doi="10.17487/RFC7382",
  }

@misc{rfc7383,
  author="V. Smyslov",
  title="{Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation}",
  howpublished="RFC 7383 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7383",
  pages="1--20",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7383.txt",
  key="RFC 7383",
  abstract={This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages.  This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.},
  keywords="IP fragmentation, NAT, firewall, PMTU discovery",
  doi="10.17487/RFC7383",
  }

@misc{rfc7384,
  author="T. Mizrahi",
  title="{Security Requirements of Time Protocols in Packet Switched Networks}",
  howpublished="RFC 7384 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7384",
  pages="1--36",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7384.txt",
  key="RFC 7384",
  abstract={As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing.  This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP).  This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.},
  keywords="ptp, precision time protocol, ntp, network time protocol",
  doi="10.17487/RFC7384",
  }

@misc{rfc7385,
  author="L. Andersson and G. Swallow",
  title="{IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points}",
  howpublished="RFC 7385 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7385",
  pages="1--4",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7385.txt",
  key="RFC 7385",
  abstract={RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the ``P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute''. However, the RFC did not create a corresponding IANA registry. There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.},
  doi="10.17487/RFC7385",
  }

@misc{rfc7386,
  author="P. Hoffman and J. Snell",
  title="{JSON Merge Patch}",
  howpublished="RFC 7386 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7386",
  pages="1--9",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7396",
url="https://www.rfc-editor.org/rfc/rfc7386.txt",
  key="RFC 7386",
  abstract={This specification defines the JSON merge patch format and processing rules.  The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.},
  keywords="http, json, patch, merge",
  doi="10.17487/RFC7386",
  }

@misc{rfc7387,
  author="R. Key and L. Yong and S. Delord and F. Jounay and L. Jin",
  title="{A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network}",
  howpublished="RFC 7387 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7387",
  pages="1--13",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7387.txt",
  key="RFC 7387",
  abstract={This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network.  The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.},
  keywords="mef, etherhet lan, e-lan, metro ethernet forum",
  doi="10.17487/RFC7387",
  }

@misc{rfc7388,
  author="J. Schoenwaelder and A. Sehgal and T. Tsou and C. Zhou",
  title="{Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}",
  howpublished="RFC 7388 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7388",
  pages="1--27",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7388.txt",
  key="RFC 7388",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).},
  keywords="Network Management, Management Information Base, MIB, SMIv2",
  doi="10.17487/RFC7388",
  }

@misc{rfc7389,
  author="R. Wakikawa and R. Pazhyannur and S. Gundavelli and C. Perkins",
  title="{Separation of Control and User Plane for Proxy Mobile IPv6}",
  howpublished="RFC 7389 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7389",
  pages="1--12",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7389.txt",
  key="RFC 7389",
  abstract={This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6).  Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4.  However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split.  To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA.  With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.},
  keywords="Control and User Plane Split, Control and User Plane Separation, LMA User-Plane Address Mobility Option",
  doi="10.17487/RFC7389",
  }

@misc{rfc7390,
  author="A. Rahman and E. Dijk",
  title="{Group Communication for the Constrained Application Protocol (CoAP)}",
  howpublished="RFC 7390 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7390",
  pages="1--46",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7390.txt",
  key="RFC 7390",
  abstract={The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks.  It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group).  This specification defines how CoAP should be used in a group communication context.  An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification.  Also, various use cases and corresponding protocol flows are provided to illustrate important concepts.  Finally, guidance is provided for deployment in various network topologies.},
  keywords="multicast, IP multicast, RESTful, Internet of Things (IoT)",
  doi="10.17487/RFC7390",
  }

@misc{rfc7391,
  author="J. Hadi Salim",
  title="{Forwarding and Control Element Separation (ForCES) Protocol Extensions}",
  howpublished="RFC 7391 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7391",
  pages="1--23",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7391.txt",
  key="RFC 7391",
  abstract={Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions.  The ForCES protocol is extended with a table range operation and a new extension for error handling.  This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.},
  keywords="ForCES, Protocol, Extension",
  doi="10.17487/RFC7391",
  }

@misc{rfc7392,
  author="P. Dutta and M. Bocci and L. Martini",
  title="{Explicit Path Routing for Dynamic Multi-Segment Pseudowires}",
  howpublished="RFC 7392 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7392",
  pages="1--10",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7392.txt",
  key="RFC 7392",
  abstract={When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs.  This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.},
  keywords="Pseudowire, MS-PW, explicit route",
  doi="10.17487/RFC7392",
  }

@misc{rfc7393,
  author="X. Deng and M. Boucadair and Q. Zhao and J. Huang and C. Zhou",
  title="{Using the Port Control Protocol (PCP) to Update Dynamic DNS}",
  howpublished="RFC 7393 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7393",
  pages="1--14",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7393.txt",
  key="RFC 7393",
  abstract={This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition.  Both issues and possible solutions are documented in this memo.},
  keywords="address sharing, CGN, service continuity, service availability, user-generated content, address-sharing issues, DS-Lite, service delivery in CGN contexts",
  doi="10.17487/RFC7393",
  }

@misc{rfc7394,
  author="S. Boutros and S. Sivabalan and G. Swallow and S. Saxena and V. Manral and S. Aldrin",
  title="{Definition of Time to Live TLV for LSP-Ping Mechanisms}",
  howpublished="RFC 7394 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7394",
  pages="1--8",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7394.txt",
  key="RFC 7394",
  abstract={LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks.  However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP.  This document defines a TLV to address this shortcoming.},
  doi="10.17487/RFC7394",
  }

@misc{rfc7395,
  author="L. Stout and J. Moffitt and E. Cestari",
  title="{An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket}",
  howpublished="RFC 7395 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7395",
  pages="1--18",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7395.txt",
  key="RFC 7395",
  abstract={This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer.  A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.},
  keywords="WebSocket, XMPP",
  doi="10.17487/RFC7395",
  }

@misc{rfc7396,
  author="P. Hoffman and J. Snell",
  title="{JSON Merge Patch}",
  howpublished="RFC 7396 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7396",
  pages="1--9",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7396.txt",
  key="RFC 7396",
  abstract={This specification defines the JSON merge patch format and processing rules.  The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.},
  keywords="http, json, patch, merge",
  doi="10.17487/RFC7396",
  }

@misc{rfc7397,
  author="J. Gilger and H. Tschofenig",
  title="{Report from the Smart Object Security Workshop}",
  howpublished="RFC 7397 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7397",
  pages="1--23",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7397.txt",
  key="RFC 7397",
  abstract={This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.},
  keywords="Smart Objects, Internet of Things, Workshop, Security",
  doi="10.17487/RFC7397",
  }

@misc{rfc7398,
  author="M. Bagnulo and T. Burbridge and S. Crawford and P. Eardley and A. Morton",
  title="{A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance}",
  howpublished="RFC 7398 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7398",
  pages="1--17",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7398.txt",
  key="RFC 7398",
  abstract={This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics.  Other similar measurement projects may also be able to use the extensions described here for measurement point location.  The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.},
  keywords="LMAP, performance metrics",
  doi="10.17487/RFC7398",
  }

@misc{rfc7399,
  author="A. Farrel and D. King",
  title="{Unanswered Questions in the Path Computation Element Architecture}",
  howpublished="RFC 7399 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7399",
  pages="1--29",
  year=2014,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7399.txt",
  key="RFC 7399",
  abstract={The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.},
  keywords="SDN, Software Defined Networking, H-PCE, Hierarchical PCE, VNTM, Virtual Network Topology Manager, ABNO, Application-Based Network Operation, TE, Traffic Engineering",
  doi="10.17487/RFC7399",
  }

@misc{rfc7400,
  author="C. Bormann",
  title="{6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}",
  howpublished="RFC 7400 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7400",
  pages="1--24",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7400.txt",
  key="RFC 7400",
  abstract={RFC 6282 defines header compression in 6LoWPAN packets (where ``6LoWPAN'' refers to ``IPv6 over Low-Power Wireless Personal Area Network'').  The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.},
  keywords="IoT, Internet of Things, Embedded Internet, Sensor Network, WSN, Constrained node, Constrained network, Constrained-node network, LLN, LoWPAN, packet encoding, capability indication, 6CIO, LZ77, RFC 6282, RFC 4944, adaptation layer, IEEE 802.15.4",
  doi="10.17487/RFC7400",
  }

@misc{rfc7401,
  author="R. Moskowitz and T. Heer and P. Jokela and T. Henderson",
  title="{Host Identity Protocol Version 2 (HIPv2)}",
  howpublished="RFC 7401 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7401",
  pages="1--128",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 8002",
url="https://www.rfc-editor.org/rfc/rfc7401.txt",
  key="RFC 7401",
  abstract={This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.},
  keywords="HIP, IP-layer state, integrity protection, optional encryption",
  doi="10.17487/RFC7401",
  }

@misc{rfc7402,
  author="P. Jokela and R. Moskowitz and J. Melen",
  title="{Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)}",
  howpublished="RFC 7402 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7402",
  pages="1--40",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7402.txt",
  key="RFC 7402",
  abstract={This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).  This document obsoletes RFC 5202.},
  keywords="encryption, user data packets",
  doi="10.17487/RFC7402",
  }

@misc{rfc7403,
  author="H. Kaplan",
  title="{A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)}",
  howpublished="RFC 7403 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7403",
  pages="1--7",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7403.txt",
  key="RFC 7403",
  abstract={SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target.  A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator.  This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).},
  doi="10.17487/RFC7403",
  }

@misc{rfc7404,
  author="M. Behringer and E. Vyncke",
  title="{Using Only Link-Local Addressing inside an IPv6 Network}",
  howpublished="RFC 7404 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7404",
  pages="1--10",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7404.txt",
  key="RFC 7404",
  abstract={In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers.  This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.},
  keywords="IPv6 security routing, Link-Local, Routing Protocol, Security",
  doi="10.17487/RFC7404",
  }

@misc{rfc7405,
  author="P. Kyzivat",
  title="{Case-Sensitive String Support in ABNF}",
  howpublished="RFC 7405 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7405",
  pages="1--4",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7405.txt",
  key="RFC 7405",
  abstract={This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.},
  keywords="BNF, ABNF Syntax",
  doi="10.17487/RFC7405",
  }

@misc{rfc7406,
  author="H. Schulzrinne and S. McCann and G. Bajko and H. Tschofenig and D. Kroeselberg",
  title="{Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices}",
  howpublished="RFC 7406 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7406",
  pages="1--25",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7406.txt",
  key="RFC 7406",
  abstract={This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.},
  doi="10.17487/RFC7406",
  }

@misc{rfc7407,
  author="M. Bjorklund and J. Schoenwaelder",
  title="{A YANG Data Model for SNMP Configuration}",
  howpublished="RFC 7407 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7407",
  pages="1--88",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7407.txt",
  key="RFC 7407",
  abstract={This document defines a collection of YANG definitions for configuring SNMP engines.},
  doi="10.17487/RFC7407",
  }

@misc{rfc7408,
  author="E. Haleplidis",
  title="{Forwarding and Control Element Separation (ForCES) Model Extension}",
  howpublished="RFC 7408 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7408",
  pages="1--31",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7408.txt",
  key="RFC 7408",
  abstract={This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures.  It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties.  The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.},
  keywords="ForCES, Model, Extension",
  doi="10.17487/RFC7408",
  }

@misc{rfc7409,
  author="E. Haleplidis and J. Halpern",
  title="{Forwarding and Control Element Separation (ForCES) Packet Parallelization}",
  howpublished="RFC 7409 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7409",
  pages="1--27",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7409.txt",
  key="RFC 7409",
  abstract={Many network devices support parallel packet processing.  This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).},
  keywords="ForCES, Model, Extension",
  doi="10.17487/RFC7409",
  }

@misc{rfc7410,
  author="M. Kucherawy",
  title="{A Property Types Registry for the Authentication-Results Header Field}",
  howpublished="RFC 7410 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7410",
  pages="1--5",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7601",
url="https://www.rfc-editor.org/rfc/rfc7410.txt",
  key="RFC 7410",
  abstract={This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.},
  keywords="Authentication-Results, Reputation",
  doi="10.17487/RFC7410",
  }

@misc{rfc7411,
  author="T. Schmidt and M. Waehlisch and R. Koodli and G. Fairhurst and D. Liu",
  title="{Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers}",
  howpublished="RFC 7411 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7411",
  pages="1--30",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7411.txt",
  key="RFC 7411",
  abstract={Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format. This document updates RFC 5568, ``Mobile IPv6 Fast Handovers''.},
  keywords="Multicast, Mobility, IPv6, PIM, MLD, Group Communication",
  doi="10.17487/RFC7411",
  }

@misc{rfc7412,
  author="Y. Weingarten and S. Aldrin and P. Pan and J. Ryoo and G. Mirsky",
  title="{Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection}",
  howpublished="RFC 7412 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7412",
  pages="1--16",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7412.txt",
  key="RFC 7412",
  abstract={This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support.  This document provides an expansion of the basic requirements presented in RFC 5654 (``Requirements of an MPLS Transport Profile'') and RFC 6372 (``MPLS Transport Profile (MPLS-TP) Survivability Framework'').  This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.},
  doi="10.17487/RFC7412",
  }

@misc{rfc7413,
  author="Y. Cheng and J. Chu and S. Radhakrishnan and A. Jain",
  title="{TCP Fast Open}",
  howpublished="RFC 7413 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7413",
  pages="1--26",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7413.txt",
  key="RFC 7413",
  abstract={This document describes an experimental TCP mechanism called TCP Fast Open (TFO).  TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged.  However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.  Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.},
  doi="10.17487/RFC7413",
  }

@misc{rfc7414,
  author="M. Duke and R. Braden and W. Eddy and E. Blanton and A. Zimmermann",
  title="{A Roadmap for Transmission Control Protocol (TCP) Specification Documents}",
  howpublished="RFC 7414 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7414",
  pages="1--57",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7805",
url="https://www.rfc-editor.org/rfc/rfc7414.txt",
  key="RFC 7414",
  abstract={This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614.},
  keywords="TCP Roadmap",
  doi="10.17487/RFC7414",
  }

@misc{rfc7415,
  author="E. Noel and P. Williams",
  title="{Session Initiation Protocol (SIP) Rate Control}",
  howpublished="RFC 7415 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7415",
  pages="1--15",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7415.txt",
  key="RFC 7415",
  abstract={The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads.  A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed.  Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.},
  doi="10.17487/RFC7415",
  }

@misc{rfc7416,
  author="T. Tsao and R. Alexander and M. Dohler and V. Daza and A. Lozano and M. Richardson",
  title="{A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)}",
  howpublished="RFC 7416 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7416",
  pages="1--40",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7416.txt",
  key="RFC 7416",
  abstract={This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.},
  keywords="LLN, ROLL, security",
  doi="10.17487/RFC7416",
  }

@misc{rfc7417,
  author="G. Karagiannis and A. Bhargava",
  title="{Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains}",
  howpublished="RFC 7417 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7417",
  pages="1--36",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7417.txt",
  key="RFC 7417",
  abstract={This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.},
  keywords="generic aggregate rsvp",
  doi="10.17487/RFC7417",
  }

@misc{rfc7418,
  author="S. Dawkins",
  title="{An IRTF Primer for IETF Participants}",
  howpublished="RFC 7418 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7418",
  pages="1--7",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7418.txt",
  key="RFC 7418",
  abstract={This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF).  This document emphasizes differences in expectations between the two organizations.},
  keywords="Research Group",
  doi="10.17487/RFC7418",
  }

@misc{rfc7419,
  author="N. Akiya and M. Binderberger and G. Mirsky",
  title="{Common Interval Support in Bidirectional Forwarding Detection}",
  howpublished="RFC 7419 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7419",
  pages="1--8",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7419.txt",
  key="RFC 7419",
  abstract={Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions. This document updates RFC 5880 by defining a small set of interval values for BFD that we call ``Common Intervals'' and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.},
  keywords="BFD, hardware, interval, timer",
  doi="10.17487/RFC7419",
  }

@misc{rfc7420,
  author="A. Koushik and E. Stephan and Q. Zhao and D. King and J. Hardwick",
  title="{Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module}",
  howpublished="RFC 7420 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7420",
  pages="1--65",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7420.txt",
  key="RFC 7420",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.},
  keywords="Network Management, Management Information Base, MIB, SMIv2, PCE, PCEP",
  doi="10.17487/RFC7420",
  }

@misc{rfc7421,
  author="B. Carpenter and T. Chown and F. Gont and S. Jiang and A. Petrescu and A. Yourtchenko",
  title="{Analysis of the 64-bit Boundary in IPv6 Addressing}",
  howpublished="RFC 7421 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7421",
  pages="1--24",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7421.txt",
  key="RFC 7421",
  abstract={The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet.  Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix.  This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.},
  doi="10.17487/RFC7421",
  }

@misc{rfc7422,
  author="C. Donley and C. Grundemann and V. Sarawat and K. Sundaresan and O. Vautrin",
  title="{Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments}",
  howpublished="RFC 7422 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7422",
  pages="1--14",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7422.txt",
  key="RFC 7422",
  abstract={In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response).  Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations.  CGN port assignments are often per connection, but they could optionally use port ranges.  Research indicates that per-connection logging is not scalable in many residential broadband services.  This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response.  IPv6 is, of course, the preferred solution.  While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4.  This note addresses the IPv4 part of the network when a CGN solution is in use.},
  doi="10.17487/RFC7422",
  }

@misc{rfc7423,
  author="L. Morand and V. Fajardo and H. Tschofenig",
  title="{Diameter Applications Design Guidelines}",
  howpublished="RFC 7423 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7423",
  pages="1--29",
  year=2014,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7423.txt",
  key="RFC 7423",
  abstract={The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications.  This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter.  Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.},
  keywords="AAA, Authentication, Authorization, Accounting",
  doi="10.17487/RFC7423",
  }

@misc{rfc7424,
  author="R. Krishnan and L. Yong and A. Ghanwani and N. So and B. Khasnabish",
  title="{Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks}",
  howpublished="RFC 7424 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7424",
  pages="1--29",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7424.txt",
  key="RFC 7424",
  abstract={Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications.  In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling.  This document explores some of the mechanisms useful for achieving this.},
  doi="10.17487/RFC7424",
  }

@misc{rfc7425,
  author="M. Thornburgh",
  title="{Adobe's RTMFP Profile for Flash Communication}",
  howpublished="RFC 7425 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7425",
  pages="1--49",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7425.txt",
  key="RFC 7425",
  abstract={This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications.  Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.},
  doi="10.17487/RFC7425",
  }

@misc{rfc7426,
  author="E. Haleplidis and K. Pentikousis and S. Denazis and J. Hadi Salim and D. Meyer and O. Koufopavlou",
  title="{Software-Defined Networking (SDN): Layers and Architecture Terminology}",
  howpublished="RFC 7426 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7426",
  pages="1--35",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7426.txt",
  key="RFC 7426",
  abstract={Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces.  SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane.  This separation allows faster innovation cycles at both planes as experience has already shown.  However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other.  This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.},
  keywords="Software-defined Networking, SDN, Programmable Networks, Architecture, Layer, Terminology",
  doi="10.17487/RFC7426",
  }

@misc{rfc7427,
  author="T. Kivinen and J. Snyder",
  title="{Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)}",
  howpublished="RFC 7427 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7427",
  pages="1--18",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7427.txt",
  key="RFC 7427",
  abstract={The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA).  The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group.  This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation.  This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.},
  keywords="IPsec, IKE, IKEv2, Signature, Authentication, RSA, DSS, DSA, ECDSA, SASSA-PSS, PKIX",
  doi="10.17487/RFC7427",
  }

@misc{rfc7428,
  author="A. Brandt and J. Buron",
  title="{Transmission of IPv6 Packets over ITU-T G.9959 Networks}",
  howpublished="RFC 7428 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7428",
  pages="1--21",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7428.txt",
  key="RFC 7428",
  abstract={This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.},
  doi="10.17487/RFC7428",
  }

@misc{rfc7429,
  author="D. Liu and JC. Zuniga and P. Seite and H. Chan and CJ. Bernardos",
  title="{Distributed Mobility Management: Current Practices and Gap Analysis}",
  howpublished="RFC 7429 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7429",
  pages="1--34",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7429.txt",
  key="RFC 7429",
  abstract={This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment.  It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.},
  keywords="DMM, Distributed Mobility Management, anchor, gap analysis, best practices",
  doi="10.17487/RFC7429",
  }

@misc{rfc7430,
  author="M. Bagnulo and C. Paasch and F. Gont and O. Bonaventure and C. Raiciu",
  title="{Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)}",
  howpublished="RFC 7430 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7430",
  pages="1--19",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7430.txt",
  key="RFC 7430",
  abstract={This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.},
  keywords="MPTCP, security, threat analysis",
  doi="10.17487/RFC7430",
  }

@misc{rfc7431,
  author="A. Karan and C. Filsfils and IJ. Wijnands and B. Decraene",
  title="{Multicast-Only Fast Reroute}",
  howpublished="RFC 7431 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7431",
  pages="1--14",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7431.txt",
  key="RFC 7431",
  abstract={As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services.  This document describes a mechanism for minimizing packet loss in a network when node or link failures occur.  Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).},
  doi="10.17487/RFC7431",
  }

@misc{rfc7432,
  author="A. Sajassi and R. Aggarwal and N. Bitar and A. Isaac and J. Uttaro and J. Drake and W. Henderickx",
  title="{BGP MPLS-Based Ethernet VPN}",
  howpublished="RFC 7432 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7432",
  pages="1--56",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7432.txt",
  key="RFC 7432",
  abstract={This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN).  The procedures described here meet the requirements specified in RFC 7209 -- ``Requirements for Ethernet VPN (EVPN)''.},
  doi="10.17487/RFC7432",
  }

@misc{rfc7433,
  author="A. Johnston and J. Rafferty",
  title="{A Mechanism for Transporting User-to-User Call Control Information in SIP}",
  howpublished="RFC 7433 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7433",
  pages="1--19",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7433.txt",
  key="RFC 7433",
  abstract={There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment.  This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session.  The syntax and semantics for the UUI data used by a specific application are defined by a UUI package.  This UUI data is opaque to SIP and its function is unrelated to any basic SIP function.  This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.},
  keywords="UUI, Package, Content, Encoding, Media",
  doi="10.17487/RFC7433",
  }

@misc{rfc7434,
  author="K. Drage and A. Johnston",
  title="{Interworking ISDN Call Control User Information with SIP}",
  howpublished="RFC 7434 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7434",
  pages="1--17",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7434.txt",
  key="RFC 7434",
  abstract={The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service. This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by the new value ``isdn-uui'' of the ``purpose'' header field parameter.},
  keywords="UUS Supplementary Service",
  doi="10.17487/RFC7434",
  }

@misc{rfc7435,
  author="V. Dukhovni",
  title="{Opportunistic Security: Some Protection Most of the Time}",
  howpublished="RFC 7435 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7435",
  pages="1--11",
  year=2014,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7435.txt",
  key="RFC 7435",
  abstract={This document defines the concept ``Opportunistic Security'' in the context of communications protocols.  Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.},
  keywords="authentication, encryption",
  doi="10.17487/RFC7435",
  }

@misc{rfc7436,
  author="H. Shah and E. Rosen and F. Le Faucheur and G. Heron",
  title="{IP-Only LAN Service (IPLS)}",
  howpublished="RFC 7436 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="7436",
  pages="1--32",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7436.txt",
  key="RFC 7436",
  abstract={A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an ``IP-only LAN Service'' (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's ``Media Access Control (MAC) Bridges''. This document specifies the protocol extensions and procedures for support of the IPLS service. The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.},
  doi="10.17487/RFC7436",
  }

@misc{rfc7437,
  author="M. Kucherawy",
  title="{IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}",
  howpublished="RFC 7437 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7437",
  pages="1--35",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7776",
url="https://www.rfc-editor.org/rfc/rfc7437.txt",
  key="RFC 7437",
  abstract={The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document.  This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.},
  keywords="Internet Architecture Board, Engineering Steering Group, nomcom, IAOC",
  doi="10.17487/RFC7437",
  }

@misc{rfc7438,
  author="IJ. Wijnands and E. Rosen and A. Gulko and U. Joorde and J. Tantsura",
  title="{Multipoint LDP (mLDP) In-Band Signaling with Wildcards}",
  howpublished="RFC 7438 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7438",
  pages="1--16",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7438.txt",
  key="RFC 7438",
  abstract={There are scenarios in which an IP multicast tree traverses an MPLS domain.  In these scenarios, it can be desirable to convert the IP multicast tree ``seamlessly'' into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain.  Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP).  However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP.  This document specifies the procedures to support these functions.  It does so by defining ``wildcard'' encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP.  Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document.  This document updates RFCs 6826 and 7246.},
  keywords="mpls, multicast",
  doi="10.17487/RFC7438",
  }

@misc{rfc7439,
  author="W. George and C. Pignataro",
  title="{Gap Analysis for Operating IPv6-Only MPLS Networks}",
  howpublished="RFC 7439 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7439",
  pages="1--28",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7439.txt",
  key="RFC 7439",
  abstract={This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality. In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.},
  keywords="MPLS, LDP, IPv6, RSVP, L3VPN, L2VPN",
  doi="10.17487/RFC7439",
  }

@misc{rfc7440,
  author="P. Masotta",
  title="{TFTP Windowsize Option}",
  howpublished="RFC 7440 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7440",
  pages="1--9",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7440.txt",
  key="RFC 7440",
  abstract={The ``Trivial File Transfer Protocol'' (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN. This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in ``TFTP Option Extension'' (RFC 2347).},
  doi="10.17487/RFC7440",
  }

@misc{rfc7441,
  author="IJ. Wijnands and E. Rosen and U. Joorde",
  title="{Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes}",
  howpublished="RFC 7441 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7441",
  pages="1--10",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7441.txt",
  key="RFC 7441",
  abstract={Many service providers offer ``BGP/MPLS IP VPN'' service to their customers.  Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs.  It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs.  This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic.  Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances.  This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions.  This document updates RFC 6514.},
  doi="10.17487/RFC7441",
  }

@misc{rfc7442,
  author="Y. Rekhter and R. Aggarwal and N. Leymann and W. Henderickx and Q. Zhao and R. Li",
  title="{Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)}",
  howpublished="RFC 7442 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7442",
  pages="1--11",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7442.txt",
  key="RFC 7442",
  abstract={When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs).  This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).},
  doi="10.17487/RFC7442",
  }

@misc{rfc7443,
  author="P. Patil and T. Reddy and G. Salgueiro and M. Petit-Huguenin",
  title="{Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages}",
  howpublished="RFC 7443 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7443",
  pages="1--5",
  year=2015,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7443.txt",
  key="RFC 7443",
  abstract={Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection.  ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).},
  doi="10.17487/RFC7443",
  }

@misc{rfc7444,
  author="K. Zeilenga and A. Melnikov",
  title="{Security Labels in Internet Email}",
  howpublished="RFC 7444 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7444",
  pages="1--16",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7444.txt",
  key="RFC 7444",
  abstract={This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message.  This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message.  This document also describes a header field, SIO-Label-History, for recording changes in the message's label.},
  keywords="email, header fields, ESS, Security Label, Confidential Label, Message Sensitivity",
  doi="10.17487/RFC7444",
  }

@misc{rfc7445,
  author="G. Chen and H. Deng and D. Michaud and J. Korhonen and M. Boucadair",
  title="{Analysis of Failure Cases in IPv6 Roaming Scenarios}",
  howpublished="RFC 7445 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7445",
  pages="1--19",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7445.txt",
  key="RFC 7445",
  abstract={This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios.  The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.},
  keywords="Mobile Network, Dual Stack, IPv6-only",
  doi="10.17487/RFC7445",
  }

@misc{rfc7446,
  author="Y. Lee and G. Bernstein and D. Li and W. Imajuku",
  title="{Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks}",
  howpublished="RFC 7446 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7446",
  pages="1--23",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7446.txt",
  key="RFC 7446",
  abstract={This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs).  The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs.  This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments.  Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.},
  keywords="WSON, RWA",
  doi="10.17487/RFC7446",
  }

@misc{rfc7447,
  author="J. Scudder and K. Kompella",
  title="{Deprecation of BGP Entropy Label Capability Attribute}",
  howpublished="RFC 7447 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7447",
  pages="1--4",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7447.txt",
  key="RFC 7447",
  abstract={The BGP Entropy Label Capability attribute is defined in RFC 6790.  Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice.  This specification deprecates the attribute.  A forthcoming document will propose a replacement.},
  doi="10.17487/RFC7447",
  }

@misc{rfc7448,
  author="T. Taylor and D. Romascanu",
  title="{MIB Transfer from the IETF to the IEEE 802.3 WG}",
  howpublished="RFC 7448 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7448",
  pages="1--7",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7448.txt",
  key="RFC 7448",
  abstract={This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG).  This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.},
  keywords="Ethernet, IEEE",
  doi="10.17487/RFC7448",
  }

@misc{rfc7449,
  author="Y. Lee and G. Bernstein and J. Martensson and T. Takeda and T. Tsuritani and O. Gonzalez de Dios",
  title="{Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment}",
  howpublished="RFC 7449 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7449",
  pages="1--12",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7449.txt",
  key="RFC 7449",
  abstract={This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs).  Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process.  From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation.  Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.},
  doi="10.17487/RFC7449",
  }

@misc{rfc7450,
  author="G. Bumgardner",
  title="{Automatic Multicast Tunneling}",
  howpublished="RFC 7450 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7450",
  pages="1--82",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7450.txt",
  key="RFC 7450",
  abstract={This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.},
  keywords="AMT, IGMPv2, IGMPv3, MLDv1, MLDv2, ASM, SSM, amt gateway, amt relay, multicast replication, multicast encapsulation",
  doi="10.17487/RFC7450",
  }

@misc{rfc7451,
  author="S. Hollenbeck",
  title="{Extension Registry for the Extensible Provisioning Protocol}",
  howpublished="RFC 7451 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7451",
  pages="1--12",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7451.txt",
  key="RFC 7451",
  abstract={The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol.  It does not, however, describe how those extensions are managed.  This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.},
  keywords="domain, host, contact",
  doi="10.17487/RFC7451",
  }

@misc{rfc7452,
  author="H. Tschofenig and J. Arkko and D. Thaler and D. McPherson",
  title="{Architectural Considerations in Smart Object Networking}",
  howpublished="RFC 7452 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7452",
  pages="1--24",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7452.txt",
  key="RFC 7452",
  abstract={The term ``Internet of Things'' (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called ``smart objects'', are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme ``Everything that can be connected will be connected'', engineers and researchers designing smart object networks need to decide how to achieve this in practice. This document offers guidance to engineers designing Internet- connected smart objects.},
  keywords="IAB Statement, Smart Objects",
  doi="10.17487/RFC7452",
  }

@misc{rfc7453,
  author="V. Mahalingam and K. Sampath and S. Aldrin and T. Nadeau",
  title="{MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)}",
  howpublished="RFC 7453 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7453",
  pages="1--62",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7453.txt",
  key="RFC 7453",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.},
  doi="10.17487/RFC7453",
  }

@misc{rfc7454,
  author="J. Durand and I. Pepelnjak and G. Doering",
  title="{BGP Operations and Security}",
  howpublished="RFC 7454 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7454",
  pages="1--26",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7454.txt",
  key="RFC 7454",
  abstract={The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.},
  doi="10.17487/RFC7454",
  }

@misc{rfc7455,
  author="T. Senevirathne and N. Finn and S. Salam and D. Kumar and D. {Eastlake 3rd} and S. Aldrin and Y. Li",
  title="{Transparent Interconnection of Lots of Links (TRILL): Fault Management}",
  howpublished="RFC 7455 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7455",
  pages="1--63",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7455.txt",
  key="RFC 7455",
  abstract={This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management.  Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible.  Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1.  This document updates RFC 6325.},
  keywords="Fault, Continuity, Connectivity, OAM, CFM, MEP, CCM",
  doi="10.17487/RFC7455",
  }

@misc{rfc7456,
  author="T. Mizrahi and T. Senevirathne and S. Salam and D. Kumar and D. {Eastlake 3rd}",
  title="{Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)}",
  howpublished="RFC 7456 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7456",
  pages="1--32",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7456.txt",
  key="RFC 7456",
  abstract={Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM).  It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies.  This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.},
  doi="10.17487/RFC7456",
  }

@misc{rfc7457,
  author="Y. Sheffer and R. Holz and P. Saint-Andre",
  title="{Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)}",
  howpublished="RFC 7457 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7457",
  pages="1--13",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7457.txt",
  key="RFC 7457",
  abstract={Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation.  This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).},
  keywords="Transport Layer Security, TLS, Datagram TLS, DTLS, Secure Sockets Layer, SSL, security attacks",
  doi="10.17487/RFC7457",
  }

@misc{rfc7458,
  author="R. Valmikam and R. Koodli",
  title="{Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core}",
  howpublished="RFC 7458 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7458",
  pages="1--18",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7458.txt",
  key="RFC 7458",
  abstract={With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.},
  keywords="Mobile Networks, 3GPP, EAP, EPC, Handover, Identity, APN",
  doi="10.17487/RFC7458",
  }

@misc{rfc7459,
  author="M. Thomson and J. Winterbottom",
  title="{Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)}",
  howpublished="RFC 7459 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7459",
  pages="1--39",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7459.txt",
  key="RFC 7459",
  abstract={This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined. This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.},
  doi="10.17487/RFC7459",
  }

@misc{rfc7460,
  author="M. Chandramouli and B. Claise and B. Schoening and J. Quittek and T. Dietz",
  title="{Monitoring and Control MIB for Power and Energy}",
  howpublished="RFC 7460 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7460",
  pages="1--69",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7460.txt",
  key="RFC 7460",
  abstract={This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.},
  keywords="management information base, IANAPowerStateSet-MIB, ENERGY-OBJECT-MIB, POWER-ATTRIBUTES-MIB",
  doi="10.17487/RFC7460",
  }

@misc{rfc7461,
  author="J. Parello and B. Claise and M. Chandramouli",
  title="{Energy Object Context MIB}",
  howpublished="RFC 7461 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7461",
  pages="1--32",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7461.txt",
  key="RFC 7461",
  abstract={This document defines a subset of a Management Information Base (MIB) for energy management of devices.  The module addresses device identification, context information, and the energy relationships between devices.},
  keywords="management information base, ENERGY-OBJECT-CONTEXT-MIB, IANA-ENERGY-RELATION-MIB",
  doi="10.17487/RFC7461",
  }

@misc{rfc7462,
  author="L. Liess and R. Jesske and A. Johnston and D. Worley and P. Kyzivat",
  title="{URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)}",
  howpublished="RFC 7462 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7462",
  pages="1--46",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7462.txt",
  key="RFC 7462",
  abstract={The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification. This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.},
  doi="10.17487/RFC7462",
  }

@misc{rfc7463,
  author="A. Johnston and M. Soroushnejad and V. Venkataramanan",
  title="{Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)}",
  howpublished="RFC 7463 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7463",
  pages="1--72",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7463.txt",
  key="RFC 7463",
  abstract={This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA).  When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines.  This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment.  This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group.  This document discusses use cases, lists requirements, and defines extensions to implement this feature.  This specification updates RFCs 3261 and 4235.},
  doi="10.17487/RFC7463",
  }

@misc{rfc7464,
  author="N. Williams",
  title="{JavaScript Object Notation (JSON) Text Sequences}",
  howpublished="RFC 7464 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7464",
  pages="1--8",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7464.txt",
  key="RFC 7464",
  abstract={This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type ``application/json-seq''.  A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).},
  keywords="JSON, sequence, online, streaming, log file",
  doi="10.17487/RFC7464",
  }

@misc{rfc7465,
  author="A. Popov",
  title="{Prohibiting RC4 Cipher Suites}",
  howpublished="RFC 7465 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7465",
  pages="1--6",
  year=2015,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7465.txt",
  key="RFC 7465",
  abstract={This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.  This applies to all TLS versions.  This document updates RFCs 5246, 4346, and 2246.},
  keywords="TLS, transport layer security",
  doi="10.17487/RFC7465",
  }

@misc{rfc7466,
  author="C. Dearlove and T. Clausen",
  title="{An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)}",
  howpublished="RFC 7466 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7466",
  pages="1--9",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7466.txt",
  key="RFC 7466",
  abstract={The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables ``ignoring'' some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while ``ignored'' (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. This specification updates RFC 6130 ``Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)'' and RFC 7181 ``The Optimized Link State Routing Protocol Version 2 (OLSRv2)'' to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more ``robust''.},
  keywords="MANET, NHDP, OLSRv2, link quality",
  doi="10.17487/RFC7466",
  }

@misc{rfc7467,
  author="A. Murdock",
  title="{URN Namespace for the North Atlantic Treaty Organization (NATO)}",
  howpublished="RFC 7467 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7467",
  pages="1--8",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7467.txt",
  key="RFC 7467",
  abstract={This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406.  At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.},
  doi="10.17487/RFC7467",
  }

@misc{rfc7468,
  author="S. Josefsson and S. Leonard",
  title="{Textual Encodings of PKIX, PKCS, and CMS Structures}",
  howpublished="RFC 7468 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7468",
  pages="1--20",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7468.txt",
  key="RFC 7468",
  abstract={This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS).  The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed.  This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.},
  doi="10.17487/RFC7468",
  }

@misc{rfc7469,
  author="C. Evans and C. Palmer and R. Sleevi",
  title="{Public Key Pinning Extension for HTTP}",
  howpublished="RFC 7469 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7469",
  pages="1--28",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7469.txt",
  key="RFC 7469",
  abstract={This document defines a new HTTP header that allows web host operators to instruct user agents to remember (``pin'') the hosts' cryptographic identities over a period of time.  During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host.  By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.},
  keywords="pin",
  doi="10.17487/RFC7469",
  }

@misc{rfc7470,
  author="F. Zhang and A. Farrel",
  title="{Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol}",
  howpublished="RFC 7470 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7470",
  pages="1--14",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7470.txt",
  key="RFC 7470",
  abstract={The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs. This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.},
  doi="10.17487/RFC7470",
  }

@misc{rfc7471,
  author="S. Giacalone and D. Ward and J. Drake and A. Atlas and S. Previdi",
  title="{OSPF Traffic Engineering (TE) Metric Extensions}",
  howpublished="RFC 7471 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7471",
  pages="1--19",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7471.txt",
  key="RFC 7471",
  abstract={In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 ``Traffic Engineering (TE) Extensions to OSPF Version 2'' and RFC 5329 ``Traffic Engineering Extensions to OSPF Version 3'' to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.},
  doi="10.17487/RFC7471",
  }

@misc{rfc7472,
  author="I. McDonald and M. Sweet",
  title="{Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme}",
  howpublished="RFC 7472 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7472",
  pages="1--19",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7472.txt",
  key="RFC 7472",
  abstract={This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service. This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.},
  doi="10.17487/RFC7472",
  }

@misc{rfc7473,
  author="K. Raza and S. Boutros",
  title="{Controlling State Advertisements of Non-negotiated LDP Applications}",
  howpublished="RFC 7473 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7473",
  pages="1--15",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7473.txt",
  key="RFC 7473",
  abstract={There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs).  When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP).  This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.},
  doi="10.17487/RFC7473",
  }

@misc{rfc7474,
  author="M. Bhatia and S. Hartman and D. Zhang and A. Lindem",
  title="{Security Extension for OSPFv2 When Using Manual Key Management}",
  howpublished="RFC 7474 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7474",
  pages="1--14",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7474.txt",
  key="RFC 7474",
  abstract={The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks. This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.},
  keywords="OSPF, cryptographic authentication, security, replay attacks",
  doi="10.17487/RFC7474",
  }

@misc{rfc7475,
  author="S. Dawkins",
  title="{Increasing the Number of Area Directors in an IETF Area}",
  howpublished="RFC 7475 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7475",
  pages="1--5",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7475.txt",
  key="RFC 7475",
  abstract={This document removes a limit on the number of Area Directors who manage an Area in the definition of ``IETF Area''.  This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).},
  doi="10.17487/RFC7475",
  }

@misc{rfc7476,
  author="K. Pentikousis and B. Ohlman and D. Corujo and G. Boggia and G. Tyson and E. Davies and A. Molinaro and S. Eum",
  title="{Information-Centric Networking: Baseline Scenarios}",
  howpublished="RFC 7476 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7476",
  pages="1--45",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7476.txt",
  key="RFC 7476",
  abstract={This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).},
  doi="10.17487/RFC7476",
  }

@misc{rfc7477,
  author="W. Hardaker",
  title="{Child-to-Parent Synchronization in DNS}",
  howpublished="RFC 7477 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7477",
  pages="1--15",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7477.txt",
  key="RFC 7477",
  abstract={This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone.  The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.},
  doi="10.17487/RFC7477",
  }

@misc{rfc7478,
  author="C. Holmberg and S. Hakansson and G. Eriksson",
  title="{Web Real-Time Communication Use Cases and Requirements}",
  howpublished="RFC 7478 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7478",
  pages="1--28",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7478.txt",
  key="RFC 7478",
  abstract={This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.},
  keywords="webrtc, browser, websocket, real-time",
  doi="10.17487/RFC7478",
  }

@misc{rfc7479,
  author="S. Moonesamy",
  title="{Using Ed25519 in SSHFP Resource Records}",
  howpublished="RFC 7479 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7479",
  pages="1--4",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7479.txt",
  key="RFC 7479",
  abstract={The Ed25519 signature algorithm has been implemented in OpenSSH.  This document updates the IANA ``SSHFP RR Types for public key algorithms'' registry by adding an algorithm number for Ed25519.},
  doi="10.17487/RFC7479",
  }

@misc{rfc7480,
  author="A. Newton and B. Ellacott and N. Kong",
  title="{HTTP Usage in the Registration Data Access Protocol (RDAP)}",
  howpublished="RFC 7480 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7480",
  pages="1--16",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7480.txt",
  key="RFC 7480",
  abstract={This document is one of a collection that together describes the Registration Data Access Protocol (RDAP).  It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP).  RDAP is a successor protocol to the very old WHOIS protocol.  The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.},
  keywords="Registry, WHOIS",
  doi="10.17487/RFC7480",
  }

@misc{rfc7481,
  author="S. Hollenbeck and N. Kong",
  title="{Security Services for the Registration Data Access Protocol (RDAP)}",
  howpublished="RFC 7481 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7481",
  pages="1--13",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7481.txt",
  key="RFC 7481",
  abstract={The Registration Data Access Protocol (RDAP) provides ``RESTful'' web services to retrieve registration metadata from Domain Name and Regional Internet Registries.  This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.},
  keywords="RDAP, Security",
  doi="10.17487/RFC7481",
  }

@misc{rfc7482,
  author="A. Newton and S. Hollenbeck",
  title="{Registration Data Access Protocol (RDAP) Query Format}",
  howpublished="RFC 7482 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7482",
  pages="1--20",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7482.txt",
  key="RFC 7482",
  abstract={This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using ``RESTful'' web access patterns.  These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).},
  keywords="WHOIS",
  doi="10.17487/RFC7482",
  }

@misc{rfc7483,
  author="A. Newton and S. Hollenbeck",
  title="{JSON Responses for the Registration Data Access Protocol (RDAP)}",
  howpublished="RFC 7483 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7483",
  pages="1--78",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7483.txt",
  key="RFC 7483",
  abstract={This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs).  These data structures are used to form Registration Data Access Protocol (RDAP) query responses.},
  keywords="WHOIS",
  doi="10.17487/RFC7483",
  }

@misc{rfc7484,
  author="M. Blanchet",
  title="{Finding the Authoritative Registration Data (RDAP) Service}",
  howpublished="RFC 7484 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7484",
  pages="1--17",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7484.txt",
  key="RFC 7484",
  abstract={This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.},
  keywords="whois, bootstrap, IDN, AS, IPv4, IPv6, JSON",
  doi="10.17487/RFC7484",
  }

@misc{rfc7485,
  author="L. Zhou and N. Kong and S. Shen and S. Sheng and A. Servin",
  title="{Inventory and Analysis of WHOIS Registration Objects}",
  howpublished="RFC 7485 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7485",
  pages="1--33",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7485.txt",
  key="RFC 7485",
  abstract={WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed.  This document describes the process and results of the statistical analysis of existing WHOIS information.  The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.},
  keywords="whois, restful, weirds, response object, inventory",
  doi="10.17487/RFC7485",
  }

@misc{rfc7486,
  author="S. Farrell and P. Hoffman and M. Thomas",
  title="{HTTP Origin-Bound Authentication (HOBA)}",
  howpublished="RFC 7486 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7486",
  pages="1--28",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7486.txt",
  key="RFC 7486",
  abstract={HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method.  The design can also be used in JavaScript-based authentication embedded in HTML.  HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.},
  keywords="Network Working Group, http authentication, origin-bound key",
  doi="10.17487/RFC7486",
  }

@misc{rfc7487,
  author="E. Bellagamba and A. Takacs and G. Mirsky and L. Andersson and P. Skoldstrom and D. Ward",
  title="{Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE}",
  howpublished="RFC 7487 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7487",
  pages="1--32",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7487.txt",
  key="RFC 7487",
  abstract={This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.},
  keywords="RSVP-TE, GMPLS, MPLS, MPLS-TP, OAM",
  doi="10.17487/RFC7487",
  }

@misc{rfc7488,
  author="M. Boucadair and R. Penno and D. Wing and P. Patil and T. Reddy",
  title="{Port Control Protocol (PCP) Server Selection}",
  howpublished="RFC 7488 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7488",
  pages="1--12",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7488.txt",
  key="RFC 7488",
  abstract={This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured. This document updates RFC 6887.},
  keywords="PCP Server discovery, Port Mapping, Shared Address, Multiple PCP Servers",
  doi="10.17487/RFC7488",
  }

@misc{rfc7489,
  author="M. Kucherawy and E. Zwicky",
  title="{Domain-based Message Authentication, Reporting, and Conformance (DMARC)}",
  howpublished="RFC 7489 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7489",
  pages="1--73",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7489.txt",
  key="RFC 7489",
  abstract={Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.},
  keywords="domain, email, security, messaging, dkim, spf, authentication, reporting, conformance",
  doi="10.17487/RFC7489",
  }

@misc{rfc7490,
  author="S. Bryant and C. Filsfils and S. Previdi and M. Shand and N. So",
  title="{Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)}",
  howpublished="RFC 7490 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7490",
  pages="1--29",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7490.txt",
  key="RFC 7490",
  abstract={This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.},
  doi="10.17487/RFC7490",
  }

@misc{rfc7491,
  author="D. King and A. Farrel",
  title="{A PCE-Based Architecture for Application-Based Network Operations}",
  howpublished="RFC 7491 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7491",
  pages="1--71",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7491.txt",
  key="RFC 7491",
  abstract={Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.},
  keywords="Software-Defined Networking (SDN), Path Computation Element (PCE), Network management, Network programming",
  doi="10.17487/RFC7491",
  }

@misc{rfc7492,
  author="M. Bhatia and D. Zhang and M. Jethanandani",
  title="{Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines}",
  howpublished="RFC 7492 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7492",
  pages="1--9",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7492.txt",
  key="RFC 7492",
  abstract={This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, ``Keying and Authentication for Routing Protocols (KARP) Design Guidelines''.},
  keywords="BFD, KARP, replay attacks, cryptographic authentication, security, DoS attacks",
  doi="10.17487/RFC7492",
  }

@misc{rfc7493,
  author="T. Bray",
  title="{The I-JSON Message Format}",
  howpublished="RFC 7493 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7493",
  pages="1--6",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7493.txt",
  key="RFC 7493",
  abstract={I-JSON (short for ``Internet JSON'') is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.},
  keywords="JSON, Internet JSON",
  doi="10.17487/RFC7493",
  }

@misc{rfc7494,
  author="C. Shao and H. Deng and R. Pazhyannur and F. Bari and R. Zhang and S. Matsushima",
  title="{IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)}",
  howpublished="RFC 7494 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7494",
  pages="1--13",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7494.txt",
  key="RFC 7494",
  abstract={The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC.  In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined.  In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located.  This leads to interoperability issues, especially when the AC and WTP come from different vendors.  To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.},
  keywords="CAPWAP, MAC Profile, Encryption, IEEE 802.11",
  doi="10.17487/RFC7494",
  }

@misc{rfc7495,
  author="A. Montville and D. Black",
  title="{Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)}",
  howpublished="RFC 7495 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7495",
  pages="1--10",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7495.txt",
  key="RFC 7495",
  abstract={The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information. This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.},
  keywords="IODEF, Incident, Reference, Enumeration, Format",
  doi="10.17487/RFC7495",
  }

@misc{rfc7496,
  author="M. Tuexen and R. Seggelmann and R. Stewart and S. Loreto",
  title="{Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension}",
  howpublished="RFC 7496 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7496",
  pages="1--11",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7496.txt",
  key="RFC 7496",
  abstract={This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension.  These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.},
  doi="10.17487/RFC7496",
  }

@misc{rfc7497,
  author="A. Morton",
  title="{Rate Measurement Test Protocol Problem Statement and Requirements}",
  howpublished="RFC 7497 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7497",
  pages="1--14",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7497.txt",
  key="RFC 7497",
  abstract={This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM).  Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.},
  keywords="Internet access, Asymmetric Packet Size",
  doi="10.17487/RFC7497",
  }

@misc{rfc7498,
  author="P. Quinn and T. Nadeau",
  title="{Problem Statement for Service Function Chaining}",
  howpublished="RFC 7498 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7498",
  pages="1--13",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7498.txt",
  key="RFC 7498",
  abstract={This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term ``service function chaining'' is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent ``steering'' of traffic flows through those service functions. The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.},
  keywords="service function chaining, steering, sfc",
  doi="10.17487/RFC7498",
  }

@misc{rfc7499,
  author="A. Perez-Mendez and R. Marin-Lopez and F. Pereniguez-Garcia and G. Lopez-Millan and D. Lopez and A. DeKok",
  title="{Support of Fragmentation of RADIUS Packets}",
  howpublished="RFC 7499 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7499",
  pages="1--38",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7499.txt",
  key="RFC 7499",
  abstract={The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes.  Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets.  No similar provisions exist for fragmenting large amounts of authorization data.  This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality.  These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and ``fail-safe'' to legacy RADIUS Clients and Servers.},
  keywords="RADIUS, attribute, extension, fragmentation, chunk",
  doi="10.17487/RFC7499",
  }

@misc{rfc7500,
  author="R. Housley and O. Kolkman",
  title="{Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries}",
  howpublished="RFC 7500 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7500",
  pages="1--7",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7500.txt",
  key="RFC 7500",
  abstract={This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.},
  doi="10.17487/RFC7500",
  }

@misc{rfc7501,
  author="C. Davids and V. Gurbani and S. Poretsky",
  title="{Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration}",
  howpublished="RFC 7501 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7501",
  pages="1--20",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7501.txt",
  key="RFC 7501",
  abstract={This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices.  Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502).  Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers.  The term ``performance'' in this context means the capacity of the Device Under Test (DUT) to process SIP messages.  Media streams are used only to study how they impact the signaling behavior.  The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices.  Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.  A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.},
  doi="10.17487/RFC7501",
  }

@misc{rfc7502,
  author="C. Davids and V. Gurbani and S. Poretsky",
  title="{Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration}",
  howpublished="RFC 7502 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7502",
  pages="1--21",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7502.txt",
  key="RFC 7502",
  abstract={This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices.  Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501).  Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers.  The term ``performance'' in this context means the capacity of the Device Under Test (DUT) to process SIP messages.  Media streams are used only to study how they impact the signaling behavior.  The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices.  Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.},
  doi="10.17487/RFC7502",
  }

@misc{rfc7503,
  author="A. Lindem and J. Arkko",
  title="{OSPFv3 Autoconfiguration}",
  howpublished="RFC 7503 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7503",
  pages="1--15",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7503.txt",
  key="RFC 7503",
  abstract={OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement.  One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing.  This document describes the necessary mechanisms for OSPFv3 to be self-configuring.  This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).},
  doi="10.17487/RFC7503",
  }

@misc{rfc7504,
  author="J. Klensin",
  title="{SMTP 521 and 556 Reply Codes}",
  howpublished="RFC 7504 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7504",
  pages="1--7",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7504.txt",
  key="RFC 7504",
  abstract={This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556.  The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP.  The 556 code was created to support the new tests and actions specified in RFC 7505.  These codes are used to indicate that an Internet host does not accept incoming mail at all.  This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.},
  keywords="Reply code, Email, Server, No Mail",
  doi="10.17487/RFC7504",
  }

@misc{rfc7505,
  author="J. Levine and M. Delany",
  title="{A ``Null MX'' No Service Resource Record for Domains That Accept No Mail}",
  howpublished="RFC 7505 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7505",
  pages="1--6",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7505.txt",
  key="RFC 7505",
  abstract={Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback.  Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail.  The No Service MX RR, informally called ``null MX'', formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.},
  keywords="DNS, e-mail",
  doi="10.17487/RFC7505",
  }

@misc{rfc7506,
  author="K. Raza and N. Akiya and C. Pignataro",
  title="{IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)}",
  howpublished="RFC 7506 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7506",
  pages="1--6",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7506.txt",
  key="RFC 7506",
  abstract={RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic ``Router shall examine packet'' Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379. The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.},
  keywords="IPv6, LSP Ping, MPLS OAM",
  doi="10.17487/RFC7506",
  }

@misc{rfc7507,
  author="B. Moeller and A. Langley",
  title="{TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks}",
  howpublished="RFC 7507 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7507",
  pages="1--8",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7507.txt",
  key="RFC 7507",
  abstract={This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.  It updates RFCs 2246, 4346, 4347, 5246, and 6347.  Server update considerations are included.},
  doi="10.17487/RFC7507",
  }

@misc{rfc7508,
  author="L. Cailleux and C. Bonatti",
  title="{Securing Header Fields with S/MIME}",
  howpublished="RFC 7508 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7508",
  pages="1--19",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7508.txt",
  key="RFC 7508",
  abstract={This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322.  This technology provides security services such as data integrity, non-repudiation, and confidentiality.  This extension is referred to as 'Secure Headers'.},
  keywords="secure headers",
  doi="10.17487/RFC7508",
  }

@misc{rfc7509,
  author="R. Huang and V. Singh",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics}",
  howpublished="RFC 7509 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7509",
  pages="1--11",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7509.txt",
  key="RFC 7509",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications.  In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.},
  doi="10.17487/RFC7509",
  }

@misc{rfc7510,
  author="X. Xu and N. Sheth and L. Yong and R. Callon and D. Black",
  title="{Encapsulating MPLS in UDP}",
  howpublished="RFC 7510 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7510",
  pages="1--19",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7510.txt",
  key="RFC 7510",
  abstract={This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation.  The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required.  Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.},
  keywords="MPLS, UDP, Tunnel, Checksum, encapsulation, multipath, ECMP",
  doi="10.17487/RFC7510",
  }

@misc{rfc7511,
  author="M. Wilhelm",
  title="{Scenic Routing for IPv6}",
  howpublished="RFC 7511 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7511",
  pages="1--8",
  year=2015,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7511.txt",
  key="RFC 7511",
  abstract={This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of ``Green IT'', whereby packets will be routed to get as much fresh-air time as possible.},
  keywords="green it",
  doi="10.17487/RFC7511",
  }

@misc{rfc7512,
  author="J. Pechanec and D. Moffat",
  title="{The PKCS \#11 URI Scheme}",
  howpublished="RFC 7512 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7512",
  pages="1--20",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7512.txt",
  key="RFC 7512",
  abstract={This memo specifies a PKCS \#11 Uniform Resource Identifier (URI) Scheme for identifying PKCS \#11 objects stored in PKCS \#11 tokens and also for identifying PKCS \#11 tokens, slots, or libraries.  The URI scheme is based on how PKCS \#11 objects, tokens, slots, and libraries are identified in ``PKCS \#11 v2.20: Cryptographic Token Interface Standard''.},
  keywords="PKCS11, PKCS-11, PKCS\#11,",
  doi="10.17487/RFC7512",
  }

@misc{rfc7513,
  author="J. Bi and J. Wu and G. Yao and F. Baker",
  title="{Source Address Validation Improvement (SAVI) Solution for DHCP}",
  howpublished="RFC 7513 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7513",
  pages="1--54",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7513.txt",
  key="RFC 7513",
  abstract={This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device.  The bindings set up by this procedure are used to filter packets with forged source IP addresses.  This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.},
  keywords="SAVI-DHCP",
  doi="10.17487/RFC7513",
  }

@misc{rfc7514,
  author="M. Luckie",
  title="{Really Explicit Congestion Notification (RECN)}",
  howpublished="RFC 7514 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7514",
  pages="1--5",
  year=2015,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7514.txt",
  key="RFC 7514",
  abstract={This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).},
  doi="10.17487/RFC7514",
  }

@misc{rfc7515,
  author="M. Jones and J. Bradley and N. Sakimura",
  title="{JSON Web Signature (JWS)}",
  howpublished="RFC 7515 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7515",
  pages="1--59",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7515.txt",
  key="RFC 7515",
  abstract={JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.},
  keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA",
  doi="10.17487/RFC7515",
  }

@misc{rfc7516,
  author="M. Jones and J. Hildebrand",
  title="{JSON Web Encryption (JWE)}",
  howpublished="RFC 7516 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7516",
  pages="1--51",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7516.txt",
  key="RFC 7516",
  abstract={JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification.  Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.},
  keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA",
  doi="10.17487/RFC7516",
  }

@misc{rfc7517,
  author="M. Jones",
  title="{JSON Web Key (JWK)}",
  howpublished="RFC 7517 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7517",
  pages="1--40",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7517.txt",
  key="RFC 7517",
  abstract={A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.},
  keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA",
  doi="10.17487/RFC7517",
  }

@misc{rfc7518,
  author="M. Jones",
  title="{JSON Web Algorithms (JWA)}",
  howpublished="RFC 7518 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7518",
  pages="1--69",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7518.txt",
  key="RFC 7518",
  abstract={This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.},
  doi="10.17487/RFC7518",
  }

@misc{rfc7519,
  author="M. Jones and J. Bradley and N. Sakimura",
  title="{JSON Web Token (JWT)}",
  howpublished="RFC 7519 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7519",
  pages="1--30",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7797",
url="https://www.rfc-editor.org/rfc/rfc7519.txt",
  key="RFC 7519",
  abstract={JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.},
  keywords="Assertion, Claim, Security Token, JavaScript Object Notation, JSON, JSON Web Token, JWT, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA",
  doi="10.17487/RFC7519",
  }

@misc{rfc7520,
  author="M. Miller",
  title="{Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)}",
  howpublished="RFC 7520 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7520",
  pages="1--120",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7520.txt",
  key="RFC 7520",
  abstract={This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data.  These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.},
  keywords="JSON Object Signing and Encryption, JOSE, JavaScript Object Notation, JSON, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA, Cookbook",
  doi="10.17487/RFC7520",
  }

@misc{rfc7521,
  author="B. Campbell and C. Mortimore and M. Jones and Y. Goland",
  title="{Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants}",
  howpublished="RFC 7521 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7521",
  pages="1--20",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7521.txt",
  key="RFC 7521",
  abstract={This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.},
  keywords="OAuth, SAML, JWT, Assertion",
  doi="10.17487/RFC7521",
  }

@misc{rfc7522,
  author="B. Campbell and C. Mortimore and M. Jones",
  title="{Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants}",
  howpublished="RFC 7522 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7522",
  pages="1--15",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7522.txt",
  key="RFC 7522",
  abstract={This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.},
  keywords="OAuth, SAML, Assertion",
  doi="10.17487/RFC7522",
  }

@misc{rfc7523,
  author="M. Jones and B. Campbell and C. Mortimore",
  title="{JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants}",
  howpublished="RFC 7523 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7523",
  pages="1--12",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7523.txt",
  key="RFC 7523",
  abstract={This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.},
  keywords="OAuth, JWT, Assertion, Token, Security Token",
  doi="10.17487/RFC7523",
  }

@misc{rfc7524,
  author="Y. Rekhter and E. Rosen and R. Aggarwal and T. Morin and I. Grosclaude and N. Leymann and S. Saad",
  title="{Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)}",
  howpublished="RFC 7524 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7524",
  pages="1--42",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7524.txt",
  key="RFC 7524",
  abstract={This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP).  Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication.  The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP).  If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area.  The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.},
  doi="10.17487/RFC7524",
  }

@misc{rfc7525,
  author="Y. Sheffer and R. Holz and P. Saint-Andre",
  title="{Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 7525 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7525",
  pages="1--27",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7525.txt",
  key="RFC 7525",
  abstract={Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS.  The recommendations are applicable to the majority of use cases.},
  keywords="Transport Layer Security, TLS, DTLS, Secure Sockets Layer, SSL",
  doi="10.17487/RFC7525",
  }

@misc{rfc7526,
  author="O. Troan and B. Carpenter",
  title="{Deprecating the Anycast Prefix for 6to4 Relay Routers}",
  howpublished="RFC 7526 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7526",
  pages="1--10",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7526.txt",
  key="RFC 7526",
  abstract={Experience with the 6to4 transition mechanism defined in RFC 3056 (``Connection of IPv6 Domains via IPv4 Clouds'') has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode.  Therefore, this document requests that RFC 3068 (``An Anycast Prefix for 6to4 Relay Routers'') and RFC 6732 (``6to4 Provider Managed Tunnels'') be made obsolete and moved to Historic status.  It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed.  This complements the guidelines in RFC 6343.},
  doi="10.17487/RFC7526",
  }

@misc{rfc7527,
  author="R. Asati and H. Singh and W. Beebee and C. Pignataro and E. Dart and W. George",
  title="{Enhanced Duplicate Address Detection}",
  howpublished="RFC 7527 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7527",
  pages="1--11",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7527.txt",
  key="RFC 7527",
  abstract={IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862.  That specification mentions a hardware-assisted mechanism to detect looped back DAD messages.  If hardware cannot suppress looped back DAD messages, a software solution is required.  Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD.  This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD.  For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed.  Further, for certain access networks, this document automates resolving a specific duplicate address conflict.  This document updates RFCs 4429, 4861, and 4862.},
  keywords="Automated DAD, loopback detection",
  doi="10.17487/RFC7527",
  }

@misc{rfc7528,
  author="P. Higgs and J. Piesing",
  title="{A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association}",
  howpublished="RFC 7528 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7528",
  pages="1--7",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7528.txt",
  key="RFC 7528",
  abstract={This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications.  Example resources include technical documents and specifications, Extensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.},
  doi="10.17487/RFC7528",
  }

@misc{rfc7529,
  author="C. Daboo and G. Yakushev",
  title="{Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)}",
  howpublished="RFC 7529 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7529",
  pages="1--21",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7529.txt",
  key="RFC 7529",
  abstract={This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules.  It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.},
  keywords="calendaring, iCalendar, iTIP, CalDAV",
  doi="10.17487/RFC7529",
  }

@misc{rfc7530,
  author="T. Haynes and D. Noveck",
  title="{Network File System (NFS) Version 4 Protocol}",
  howpublished="RFC 7530 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7530",
  pages="1--323",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7931",
url="https://www.rfc-editor.org/rfc/rfc7530.txt",
  key="RFC 7530",
  abstract={The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.},
  doi="10.17487/RFC7530",
  }

@misc{rfc7531,
  author="T. Haynes and D. Noveck",
  title="{Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description}",
  howpublished="RFC 7531 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7531",
  pages="1--39",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7531.txt",
  key="RFC 7531",
  abstract={The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.},
  doi="10.17487/RFC7531",
  }

@misc{rfc7532,
  author="J. Lentini and R. Tewari and C. Lever",
  title="{Namespace Database (NSDB) Protocol for Federated File Systems}",
  howpublished="RFC 7532 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7532",
  pages="1--65",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7532.txt",
  key="RFC 7532",
  abstract={This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers.  The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.},
  keywords="Federated File Systems",
  doi="10.17487/RFC7532",
  }

@misc{rfc7533,
  author="J. Lentini and R. Tewari and C. Lever",
  title="{Administration Protocol for Federated File Systems}",
  howpublished="RFC 7533 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7533",
  pages="1--37",
  year=2015,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7533.txt",
  key="RFC 7533",
  abstract={This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers.  The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.},
  keywords="Federated File Systems",
  doi="10.17487/RFC7533",
  }

@misc{rfc7534,
  author="J. Abley and W. Sotomayor",
  title="{AS112 Nameserver Operations}",
  howpublished="RFC 7534 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7534",
  pages="1--24",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7534.txt",
  key="RFC 7534",
  abstract={Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called ``reverse lookups'') corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document obsoletes RFC 6304.},
  keywords="AS112, DNS, reverse DNS, anycast",
  doi="10.17487/RFC7534",
  }

@misc{rfc7535,
  author="J. Abley and B. Dickson and W. Kumari and G. Michaelson",
  title="{AS112 Redirection Using DNAME}",
  howpublished="RFC 7535 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7535",
  pages="1--16",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7535.txt",
  key="RFC 7535",
  abstract={AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records. This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.},
  keywords="DNS, root server",
  doi="10.17487/RFC7535",
  }

@misc{rfc7536,
  author="M. Linsner and P. Eardley and T. Burbridge and F. Sorensen",
  title="{Large-Scale Broadband Measurement Use Cases}",
  howpublished="RFC 7536 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7536",
  pages="1--17",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7536.txt",
  key="RFC 7536",
  abstract={Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy.  Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol.  This document details two use cases that can assist in developing that framework.  The details of the measurement metrics themselves are beyond the scope of this document.},
  keywords="lmap",
  doi="10.17487/RFC7536",
  }

@misc{rfc7537,
  author="B. Decraene and N. Akiya and C. Pignataro and L. Andersson and S. Aldrin",
  title="{IANA Registries for LSP Ping Code Points}",
  howpublished="RFC 7537 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7537",
  pages="1--7",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 8029",
url="https://www.rfc-editor.org/rfc/rfc7537.txt",
  key="RFC 7537",
  abstract={RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types. There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.},
  keywords="MPLS OAM, lsp ping, LSP-Ping",
  doi="10.17487/RFC7537",
  }

@misc{rfc7538,
  author="J. Reschke",
  title="{The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)}",
  howpublished="RFC 7538 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7538",
  pages="1--6",
  year=2015,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7538.txt",
  key="RFC 7538",
  abstract={This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).},
  keywords="HTTP, redirect, status code",
  doi="10.17487/RFC7538",
  }

@misc{rfc7539,
  author="Y. Nir and A. Langley",
  title="{ChaCha20 and Poly1305 for IETF Protocols}",
  howpublished="RFC 7539 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7539",
  pages="1--45",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7539.txt",
  key="RFC 7539",
  abstract={This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a ``combined mode'', or Authenticated Encryption with Associated Data (AEAD) algorithm. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).},
  keywords="AEAD",
  doi="10.17487/RFC7539",
  }

@misc{rfc7540,
  author="M. Belshe and R. Peon and M. Thomson",
  title="{Hypertext Transfer Protocol Version 2 (HTTP/2)}",
  howpublished="RFC 7540 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7540",
  pages="1--96",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7540.txt",
  key="RFC 7540",
  abstract={This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.},
  keywords="HTTP, SPDY, Web",
  doi="10.17487/RFC7540",
  }

@misc{rfc7541,
  author="R. Peon and H. Ruellan",
  title="{HPACK: Header Compression for HTTP/2}",
  howpublished="RFC 7541 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7541",
  pages="1--55",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7541.txt",
  key="RFC 7541",
  abstract={This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.},
  keywords="HTTP, Header",
  doi="10.17487/RFC7541",
  }

@misc{rfc7542,
  author="A. DeKok",
  title="{The Network Access Identifier}",
  howpublished="RFC 7542 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7542",
  pages="1--30",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7542.txt",
  key="RFC 7542",
  abstract={In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users.  This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources.  This document is a revised version of RFC 4282.  It addresses issues with international character sets and makes a number of other corrections to RFC 4282.},
  doi="10.17487/RFC7542",
  }

@misc{rfc7543,
  author="H. Jeng and L. Jalil and R. Bonica and K. Patel and L. Yong",
  title="{Covering Prefixes Outbound Route Filter for BGP-4}",
  howpublished="RFC 7543 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7543",
  pages="1--21",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7543.txt",
  key="RFC 7543",
  abstract={This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF).  CP-ORF is applicable in Virtual Hub-and-Spoke VPNs.  It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.},
  keywords="ORF, VPN",
  doi="10.17487/RFC7543",
  }

@misc{rfc7544,
  author="M. Mohali",
  title="{Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)}",
  howpublished="RFC 7544 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7544",
  pages="1--30",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7544.txt",
  key="RFC 7544",
  abstract={Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling. RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests. Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations. This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.},
  keywords="Diversion, History-Info",
  doi="10.17487/RFC7544",
  }

@misc{rfc7545,
  author="V. Chen and S. Das and L. Zhu and J. Malyar and P. McCann",
  title="{Protocol to Access White-Space (PAWS) Databases}",
  howpublished="RFC 7545 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7545",
  pages="1--90",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7545.txt",
  key="RFC 7545",
  abstract={Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called ``white space''. Allowing secondary users access to available spectrum ``unlocks'' existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the ``Protocol to Access White-Space (PAWS) Databases''.},
  keywords="dynamic spectrum, radio spectrum, wireless spectrum, spectrum, spectrum database, TV white space, TVWS, TVBD, white space device, WSD",
  doi="10.17487/RFC7545",
  }

@misc{rfc7546,
  author="B. Kaduk",
  title="{Structure of the Generic Security Service (GSS) Negotiation Loop}",
  howpublished="RFC 7546 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7546",
  pages="1--21",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7546.txt",
  key="RFC 7546",
  abstract={This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor.  The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.},
  keywords="GSS-API, security, authentication",
  doi="10.17487/RFC7546",
  }

@misc{rfc7547,
  author="M. Ersue and D. Romascanu and J. Schoenwaelder and U. Herberg",
  title="{Management of Networks with Constrained Devices: Problem Statement and Requirements}",
  howpublished="RFC 7547 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7547",
  pages="1--44",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7547.txt",
  key="RFC 7547",
  abstract={This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.},
  keywords="Constrained, Management, IoT, M2M",
  doi="10.17487/RFC7547",
  }

@misc{rfc7548,
  author="M. Ersue and D. Romascanu and J. Schoenwaelder and A. Sehgal",
  title="{Management of Networks with Constrained Devices: Use Cases}",
  howpublished="RFC 7548 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7548",
  pages="1--26",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7548.txt",
  key="RFC 7548",
  abstract={This document discusses use cases concerning the management of networks in which constrained devices are involved.  A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on ``Management of Networks with Constrained Devices: Problem Statement and Requirements'' (RFC 7547).},
  keywords="Constrained, Management, IoT, M2M",
  doi="10.17487/RFC7548",
  }

@misc{rfc7549,
  author="C. Holmberg and J. Holm and R. Jesske and M. Dolly",
  title="{3GPP SIP URI Inter-Operator Traffic Leg Parameter}",
  howpublished="RFC 7549 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7549",
  pages="1--17",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7549.txt",
  key="RFC 7549",
  abstract={In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).},
  keywords="3GPP, IMS, NNI, IOTL, CSCF, RAVEL, TRF, operator, transit",
  doi="10.17487/RFC7549",
  }

@misc{rfc7550,
  author="O. Troan and B. Volz and M. Siodelski",
  title="{Issues and Recommendations with Multiple Stateful DHCPv6 Options}",
  howpublished="RFC 7550 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7550",
  pages="1--24",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7550.txt",
  key="RFC 7550",
  abstract={The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA\_NA and IA\_TA, but did not anticipate the development of additional stateful options.  DHCPv6 Prefix Delegation added the IA\_PD option, which is stateful.  Applications that use IA\_NA and IA\_PD together have revealed issues that need to be addressed.  This document updates RFCs 3315 and 3633 to address these issues.},
  keywords="CPE, CER, CE, Customer Edge Router, Prefix Delegation, IPv6 Address Option, Session, State Machine, Advertise, Time, Timer T1 T2, Renew, Rebind, Confirm, Decline, Provision",
  doi="10.17487/RFC7550",
  }

@misc{rfc7551,
  author="F. Zhang and R. Jing and R. Gandhi",
  title="{RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)}",
  howpublished="RFC 7551 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7551",
  pages="1--20",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7551.txt",
  key="RFC 7551",
  abstract={This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP.  The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects.  One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning.  The REVERSE\_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.},
  doi="10.17487/RFC7551",
  }

@misc{rfc7552,
  author="R. Asati and C. Pignataro and K. Raza and V. Manral and R. Papneja",
  title="{Updates to LDP for IPv6}",
  howpublished="RFC 7552 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7552",
  pages="1--24",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7552.txt",
  key="RFC 7552",
  abstract={The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both.  This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4).  This document updates RFCs 5036 and 6720.},
  keywords="Label Distribution Protocol",
  doi="10.17487/RFC7552",
  }

@misc{rfc7553,
  author="P. Faltstrom and O. Kolkman",
  title="{The Uniform Resource Identifier (URI) DNS Resource Record}",
  howpublished="RFC 7553 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7553",
  pages="1--14",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7553.txt",
  key="RFC 7553",
  abstract={This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.},
  keywords="Operations, DNS, applications",
  doi="10.17487/RFC7553",
  }

@misc{rfc7554,
  author="T. Watteyne and M. Palattella and L. Grieco",
  title="{Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement}",
  howpublished="RFC 7554 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7554",
  pages="1--23",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7554.txt",
  key="RFC 7554",
  abstract={This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs).  The set of goals enumerated in this document form an initial set only.},
  keywords="6TiSCH",
  doi="10.17487/RFC7554",
  }

@misc{rfc7555,
  author="G. Swallow and V. Lim and S. Aldrin",
  title="{Proxy MPLS Echo Request}",
  howpublished="RFC 7555 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7555",
  pages="1--28",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7555.txt",
  key="RFC 7555",
  abstract={This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths.  An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path.  The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).},
  doi="10.17487/RFC7555",
  }

@misc{rfc7556,
  author="D. Anipko",
  title="{Multiple Provisioning Domain Architecture}",
  howpublished="RFC 7556 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7556",
  pages="1--25",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7556.txt",
  key="RFC 7556",
  abstract={This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.},
  doi="10.17487/RFC7556",
  }

@misc{rfc7557,
  author="J. Chroboczek",
  title="{Extension Mechanism for the Babel Routing Protocol}",
  howpublished="RFC 7557 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7557",
  pages="1--11",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7557.txt",
  key="RFC 7557",
  abstract={This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.},
  keywords="Babel, routing, extension, TLV, sub-TLV",
  doi="10.17487/RFC7557",
  }

@misc{rfc7558,
  author="K. Lynn and S. Cheshire and M. Blanchet and D. Migault",
  title="{Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions}",
  howpublished="RFC 7558 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7558",
  pages="1--14",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7558.txt",
  key="RFC 7558",
  abstract={DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link.  This document provides a problem statement and a list of requirements for scalable DNS-SD.},
  doi="10.17487/RFC7558",
  }

@misc{rfc7559,
  author="S. Krishnan and D. Anipko and D. Thaler",
  title="{Packet-Loss Resiliency for Router Solicitations}",
  howpublished="RFC 7559 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7559",
  pages="1--6",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7559.txt",
  key="RFC 7559",
  abstract={When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received.  In certain scenarios, these Router Solicitations transmitted by the host might be lost.  This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.},
  doi="10.17487/RFC7559",
  }

@misc{rfc7560,
  author="M. Kuehlewind and R. Scheffenegger and B. Briscoe",
  title="{Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback}",
  howpublished="RFC 7560 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7560",
  pages="1--17",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7560.txt",
  key="RFC 7560",
  abstract={Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints.  An ECN-capable receiver will feed this information back to the sender.  ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT).  In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback.  Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT.  This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.},
  keywords="congestion control, TCP",
  doi="10.17487/RFC7560",
  }

@misc{rfc7561,
  author="J. Kaippallimalil and R. Pazhyannur and P. Yegani",
  title="{Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN}",
  howpublished="RFC 7561 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7561",
  pages="1--23",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7561.txt",
  key="RFC 7561",
  abstract={This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11.  RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain.  The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA.  IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point.  This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters.  This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.},
  keywords="PMIPv6, Wi-Fi, QoS",
  doi="10.17487/RFC7561",
  }

@misc{rfc7562,
  author="D. Thakore",
  title="{Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates}",
  howpublished="RFC 7562 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7562",
  pages="1--15",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7562.txt",
  key="RFC 7562",
  abstract={This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol.  This is in accordance with the guidelines for authorization extensions as specified in RFC 5878.  As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types.  If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680.  This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).},
  keywords="Transport Layer Security, TLS, SupplementalData, DTCP",
  doi="10.17487/RFC7562",
  }

@misc{rfc7563,
  author="R. Pazhyannur and S. Speicher and S. Gundavelli and J. Korhonen and J. Kaippallimalil",
  title="{Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option}",
  howpublished="RFC 7563 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7563",
  pages="1--12",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7563.txt",
  key="RFC 7563",
  abstract={The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, ``Access Network Identifier (ANI) Option for Proxy Mobile IPv6''.  This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier.  This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier.  This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.},
  doi="10.17487/RFC7563",
  }

@misc{rfc7564,
  author="P. Saint-Andre and M. Blanchet",
  title="{PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols}",
  howpublished="RFC 7564 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7564",
  pages="1--40",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7564.txt",
  key="RFC 7564",
  abstract={Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization).  This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings (``PRECIS'') in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode.  As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  This document obsoletes RFC 3454.},
  keywords="internationalization, i18n, Stringprep",
  doi="10.17487/RFC7564",
  }

@misc{rfc7565,
  author="P. Saint-Andre",
  title="{The 'acct' URI Scheme}",
  howpublished="RFC 7565 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7565",
  pages="1--8",
  year=2015,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7565.txt",
  key="RFC 7565",
  abstract={This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.},
  keywords="Uniform Resource Identifier, URI",
  doi="10.17487/RFC7565",
  }

@misc{rfc7566,
  author="L. Goix and K. Li",
  title="{Enumservice Registration for 'acct' URI}",
  howpublished="RFC 7566 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7566",
  pages="1--8",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7566.txt",
  key="RFC 7566",
  abstract={This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).},
  keywords="Reverse Phone Lookup, Social Network Web",
  doi="10.17487/RFC7566",
  }

@misc{rfc7567,
  author="F. Baker and G. Fairhurst",
  title="{IETF Recommendations Regarding Active Queue Management}",
  howpublished="RFC 7567 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7567",
  pages="1--31",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7567.txt",
  key="RFC 7567",
  abstract={This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.},
  doi="10.17487/RFC7567",
  }

@misc{rfc7568,
  author="R. Barnes and M. Thomson and A. Pironti and A. Langley",
  title="{Deprecating Secure Sockets Layer Version 3.0}",
  howpublished="RFC 7568 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7568",
  pages="1--7",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7568.txt",
  key="RFC 7568",
  abstract={The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols. This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.},
  keywords="SSL, TLS, insecure, diediedie",
  doi="10.17487/RFC7568",
  }

@misc{rfc7569,
  author="D. Quigley and J. Lu and T. Haynes",
  title="{Registry Specification for Mandatory Access Control (MAC) Security Label Formats}",
  howpublished="RFC 7569 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7569",
  pages="1--10",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7569.txt",
  key="RFC 7569",
  abstract={In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable. To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.},
  keywords="NFSv4",
  doi="10.17487/RFC7569",
  }

@misc{rfc7570,
  author="C. Margaria and G. Martinelli and S. Balls and B. Wright",
  title="{Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)}",
  howpublished="RFC 7570 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7570",
  pages="1--15",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7570.txt",
  key="RFC 7570",
  abstract={RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP).  This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.},
  keywords="RSVP-TE, GMPLS",
  doi="10.17487/RFC7570",
  }

@misc{rfc7571,
  author="J. Dong and M. Chen and Z. Li and D. Ceccarelli",
  title="{GMPLS RSVP-TE Extensions for Lock Instruct and Loopback}",
  howpublished="RFC 7571 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7571",
  pages="1--9",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7571.txt",
  key="RFC 7571",
  abstract={This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.},
  keywords="OAM",
  doi="10.17487/RFC7571",
  }

@misc{rfc7572,
  author="P. Saint-Andre and A. Houri and J. Hildebrand",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging}",
  howpublished="RFC 7572 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7572",
  pages="1--13",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7572.txt",
  key="RFC 7572",
  abstract={This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).},
  keywords="XMPP, Jabber, SIP, SIMPLE, IM, Instant Message",
  doi="10.17487/RFC7572",
  }

@misc{rfc7573,
  author="P. Saint-Andre and S. Loreto",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions}",
  howpublished="RFC 7573 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7573",
  pages="1--20",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7573.txt",
  key="RFC 7573",
  abstract={This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP).  Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).},
  keywords="Text Chat, Instant Messaging, Session Initiation Protocol, SIP, Message Sessions Relay Protocol, MSRP, Extensible Messaging and Presence Protocol, XMPP",
  doi="10.17487/RFC7573",
  }

@misc{rfc7574,
  author="A. Bakker and R. Petrocco and V. Grishchenko",
  title="{Peer-to-Peer Streaming Peer Protocol (PPSPP)}",
  howpublished="RFC 7574 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7574",
  pages="1--85",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7574.txt",
  key="RFC 7574",
  abstract={The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion.  PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content.  It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth.  It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers.  PPSPP has also been designed to be flexible and extensible.  It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables).  It supports multiple methods for content integrity protection and chunk addressing.  Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.},
  keywords="video on demand, live streaming, content integrity protection",
  doi="10.17487/RFC7574",
  }

@misc{rfc7575,
  author="M. Behringer and M. Pritikin and S. Bjarnason and A. Clemm and B. Carpenter and S. Jiang and L. Ciavaglia",
  title="{Autonomic Networking: Definitions and Design Goals}",
  howpublished="RFC 7575 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7575",
  pages="1--16",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7575.txt",
  key="RFC 7575",
  abstract={Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements. This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.},
  keywords="self-management, self-chop, autonomic, secure by default, simplification",
  doi="10.17487/RFC7575",
  }

@misc{rfc7576,
  author="S. Jiang and B. Carpenter and M. Behringer",
  title="{General Gap Analysis for Autonomic Networking}",
  howpublished="RFC 7576 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7576",
  pages="1--17",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7576.txt",
  key="RFC 7576",
  abstract={This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept. This document is a product of the IRTF's Network Management Research Group.},
  doi="10.17487/RFC7576",
  }

@misc{rfc7577,
  author="J. Quittek and R. Winter and T. Dietz",
  title="{Definition of Managed Objects for Battery Monitoring}",
  howpublished="RFC 7577 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7577",
  pages="1--40",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7577.txt",
  key="RFC 7577",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines managed objects that provide information on the status of batteries in managed devices.},
  keywords="Energy Management, Battery Status, Battery MIB, Management Information Base",
  doi="10.17487/RFC7577",
  }

@misc{rfc7578,
  author="L. Masinter",
  title="{Returning Values from Forms: multipart/form-data}",
  howpublished="RFC 7578 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7578",
  pages="1--15",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7578.txt",
  key="RFC 7578",
  abstract={This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form.  This document obsoletes RFC 2388.},
  keywords="media-type, multipurpose, internet, mail, extensions",
  doi="10.17487/RFC7578",
  }

@misc{rfc7579,
  author="G. Bernstein and Y. Lee and D. Li and W. Imajuku and J. Han",
  title="{General Network Element Constraint Encoding for GMPLS-Controlled Networks}",
  howpublished="RFC 7579 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7579",
  pages="1--28",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7579.txt",
  key="RFC 7579",
  abstract={Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.},
  keywords="WSON, Optical Network Control, Protocol-agnostic encoding",
  doi="10.17487/RFC7579",
  }

@misc{rfc7580,
  author="F. Zhang and Y. Lee and J. Han and G. Bernstein and Y. Xu",
  title="{OSPF-TE Extensions for General Network Element Constraints}",
  howpublished="RFC 7580 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7580",
  pages="1--12",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7580.txt",
  key="RFC 7580",
  abstract={Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links.  This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.},
  keywords="WSON, Optical Routing",
  doi="10.17487/RFC7580",
  }

@misc{rfc7581,
  author="G. Bernstein and Y. Lee and D. Li and W. Imajuku and J. Han",
  title="{Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks}",
  howpublished="RFC 7581 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7581",
  pages="1--37",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7581.txt",
  key="RFC 7581",
  abstract={A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in ``Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks'' (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).},
  keywords="Optical Networks, GMPLS control plane, Wavelength Assignment, Optical LSP, Optical Routing",
  doi="10.17487/RFC7581",
  }

@misc{rfc7582,
  author="E. Rosen and IJ. Wijnands and Y. Cai and A. Boers",
  title="{Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels}",
  howpublished="RFC 7582 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7582",
  pages="1--34",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7582.txt",
  key="RFC 7582",
  abstract={A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs.  These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels.  The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the ``Provider Multicast Service Interface (PMSI) Tunnel'' attribute.  Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees.  However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs.  This document updates RFCs 6513, 6514, and 6625 by specifying those procedures.  In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.},
  doi="10.17487/RFC7582",
  }

@misc{rfc7583,
  author="S. Morris and J. Ihren and J. Dickinson and W. Mekking",
  title="{DNSSEC Key Rollover Timing Considerations}",
  howpublished="RFC 7583 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7583",
  pages="1--31",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7583.txt",
  key="RFC 7583",
  abstract={This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone.  It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.},
  doi="10.17487/RFC7583",
  }

@misc{rfc7584,
  author="R. Ravindranath and T. Reddy and G. Salgueiro",
  title="{Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)}",
  howpublished="RFC 7584 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7584",
  pages="1--14",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7584.txt",
  key="RFC 7584",
  abstract={Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing. This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.},
  doi="10.17487/RFC7584",
  }

@misc{rfc7585,
  author="S. Winter and M. McCauley",
  title="{Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)}",
  howpublished="RFC 7585 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7585",
  pages="1--32",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7585.txt",
  key="RFC 7585",
  abstract={This document specifies a means to find authoritative RADIUS servers for a given realm.  It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).},
  keywords="RADIUS, AAA, Security, Reliability, DNS",
  doi="10.17487/RFC7585",
  }

@misc{rfc7586,
  author="Y. Nachum and L. Dunbar and I. Yerushalmi and T. Mizrahi",
  title="{The Scalable Address Resolution Protocol (SARP) for Large Data Centers}",
  howpublished="RFC 7586 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7586",
  pages="1--21",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7586.txt",
  key="RFC 7586",
  abstract={This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks.  SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations.  SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.},
  keywords="ARP, data center, proxy",
  doi="10.17487/RFC7586",
  }

@misc{rfc7587,
  author="J. Spittka and K. Vos and JM. Valin",
  title="{RTP Payload Format for the Opus Speech and Audio Codec}",
  howpublished="RFC 7587 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7587",
  pages="1--18",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7587.txt",
  key="RFC 7587",
  abstract={This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way.  It also provides an applicability statement for the use of Opus over RTP.  Further, it describes media type registrations for the RTP payload format.},
  keywords="audio codec",
  doi="10.17487/RFC7587",
  }

@misc{rfc7588,
  author="R. Bonica and C. Pignataro and J. Touch",
  title="{A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem}",
  howpublished="RFC 7588 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7588",
  pages="1--12",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7588.txt",
  key="RFC 7588",
  abstract={This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem.  The solution described herein is configurable.  It is widely deployed on the Internet in its default configuration.},
  keywords="GRE, MTU, Fragmentation",
  doi="10.17487/RFC7588",
  }

@misc{rfc7589,
  author="M. Badra and A. Luchuk and J. Schoenwaelder",
  title="{Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication}",
  howpublished="RFC 7589 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7589",
  pages="1--11",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7589.txt",
  key="RFC 7589",
  abstract={The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.  This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages.  This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.},
  keywords="NETCONF, TLS",
  doi="10.17487/RFC7589",
  }

@misc{rfc7590,
  author="P. Saint-Andre and T. Alkemade",
  title="{Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 7590 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7590",
  pages="1--9",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7590.txt",
  key="RFC 7590",
  abstract={This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP).  This document updates RFC 6120.},
  keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Secure Sockets Layer, SSL, Transport Layer Security, TLS, instant messaging, presence, encryption, authentication",
  doi="10.17487/RFC7590",
  }

@misc{rfc7591,
  author="J. Richer and M. Jones and J. Bradley and M. Machulak and P. Hunt",
  title="{OAuth 2.0 Dynamic Client Registration Protocol}",
  howpublished="RFC 7591 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7591",
  pages="1--39",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7591.txt",
  key="RFC 7591",
  abstract={This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.  Registration requests send a set of desired client metadata values to the authorization server.  The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client.  The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol.  This specification also defines a set of common client metadata fields and values for clients to use during registration.},
  keywords="OpenID Connect Dynamic Client Registration, OpenID Connect, oidc, openid, user managed access, uma, Dynamic Registration, Dynamic Client Registration",
  doi="10.17487/RFC7591",
  }

@misc{rfc7592,
  author="J. Richer and M. Jones and J. Bradley and M. Machulak",
  title="{OAuth 2.0 Dynamic Client Registration Management Protocol}",
  howpublished="RFC 7592 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7592",
  pages="1--18",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7592.txt",
  key="RFC 7592",
  abstract={This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client.  Not all authorization servers supporting dynamic client registration will support these management methods.},
  doi="10.17487/RFC7592",
  }

@misc{rfc7593,
  author="K. Wierenga and S. Winter and T. Wolniewicz",
  title="{The eduroam Architecture for Network Roaming}",
  howpublished="RFC 7593 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7593",
  pages="1--37",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7593.txt",
  key="RFC 7593",
  abstract={This document describes the architecture of the eduroam service for federated (wireless) network access in academia.  The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access.  The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document.  In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.},
  keywords="Federated Authentication, AAA, RADIUS, IEEE 802.1X, roaming, EAP, eduroam",
  doi="10.17487/RFC7593",
  }

@misc{rfc7594,
  author="P. Eardley and A. Morton and M. Bagnulo and T. Burbridge and P. Aitken and A. Akhter",
  title="{A Framework for Large-Scale Measurement of Broadband Performance (LMAP)}",
  howpublished="RFC 7594 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7594",
  pages="1--55",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7594.txt",
  key="RFC 7594",
  abstract={Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components.  This document presents an overall framework for large-scale measurements.  It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).},
  keywords="Controller, Collector, Measurement Agent, Metric, Measurement Method, Measurement Results, Registry",
  doi="10.17487/RFC7594",
  }

@misc{rfc7595,
  author="D. Thaler and T. Hansen and T. Hardie",
  title="{Guidelines and Registration Procedures for URI Schemes}",
  howpublished="RFC 7595 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7595",
  pages="1--19",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7595.txt",
  key="RFC 7595",
  abstract={This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.  It obsoletes RFC 4395.},
  keywords="URI scheme, IRI, Internationalized Resource Identifier, Uniform Resource Identifier, URI registration",
  doi="10.17487/RFC7595",
  }

@misc{rfc7596,
  author="Y. Cui and Q. Sun and M. Boucadair and T. Tsou and Y. Lee and I. Farrer",
  title="{Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture}",
  howpublished="RFC 7596 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7596",
  pages="1--22",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7596.txt",
  key="RFC 7596",
  abstract={Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network.  This document specifies an extension to DS-Lite called ``Lightweight 4over6'', which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE).  This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level.  In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.},
  keywords="DS-Lite, address sharing, address exhaustion, aplusp, A+P, IPv4 service continuity, IPv4 over IPv6 connectivity",
  doi="10.17487/RFC7596",
  }

@misc{rfc7597,
  author="O. Troan and W. Dec and X. Li and C. Bao and S. Matsushima and T. Murakami and T. Taylor",
  title="{Mapping of Address and Port with Encapsulation (MAP-E)}",
  howpublished="RFC 7597 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7597",
  pages="1--35",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7597.txt",
  key="RFC 7597",
  abstract={This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation.  It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.},
  doi="10.17487/RFC7597",
  }

@misc{rfc7598,
  author="T. Mrugalski and O. Troan and I. Farrer and S. Perreault and W. Dec and C. Bao and L. Yeh and X. Deng",
  title="{DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients}",
  howpublished="RFC 7598 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7598",
  pages="1--18",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7598.txt",
  key="RFC 7598",
  abstract={This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices.  Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.},
  keywords="MAP, DHCPv6",
  doi="10.17487/RFC7598",
  }

@misc{rfc7599,
  author="X. Li and C. Bao and W. Dec and O. Troan and S. Matsushima and T. Murakami",
  title="{Mapping of Address and Port using Translation (MAP-T)}",
  howpublished="RFC 7599 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7599",
  pages="1--27",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7599.txt",
  key="RFC 7599",
  abstract={This document specifies the solution architecture based on ``Mapping of Address and Port'' stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.},
  doi="10.17487/RFC7599",
  }

@misc{rfc7600,
  author="R. Despres and S. Jiang and R. Penno and Y. Lee and G. Chen and M. Chen",
  title="{IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)}",
  howpublished="RFC 7600 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7600",
  pages="1--45",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7600.txt",
  key="RFC 7600",
  abstract={This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers.  The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end.  Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.},
  keywords="Coexistence, Transition, Interworking, Tunneling, Stateless, 4rd, IPv4, IPv6, Mapping, Global Addressing",
  doi="10.17487/RFC7600",
  }

@misc{rfc7601,
  author="M. Kucherawy",
  title="{Message Header Field for Indicating Message Authentication Status}",
  howpublished="RFC 7601 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7601",
  pages="1--53",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7601.txt",
  key="RFC 7601",
  abstract={This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.},
  keywords="DKIM, DomainKeys, SenderID, SPF, ADSP, ATPS, VBR, Authentication, Reputation",
  doi="10.17487/RFC7601",
  }

@misc{rfc7602,
  author="U. Chunduri and W. Lu and A. Tian and N. Shen",
  title="{IS-IS Extended Sequence Number TLV}",
  howpublished="RFC 7602 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7602",
  pages="1--12",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7602.txt",
  key="RFC 7602",
  abstract={This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.},
  doi="10.17487/RFC7602",
  }

@misc{rfc7603,
  author="B. Schoening and M. Chandramouli and B. Nordman",
  title="{Energy Management (EMAN) Applicability Statement}",
  howpublished="RFC 7603 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7603",
  pages="1--28",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7603.txt",
  key="RFC 7603",
  abstract={The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices.  This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices.  These use cases are useful for identifying requirements for the framework and MIBs.  Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.},
  doi="10.17487/RFC7603",
  }

@misc{rfc7604,
  author="M. Westerlund and T. Zeng",
  title="{Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)}",
  howpublished="RFC 7604 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7604",
  pages="1--46",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7604.txt",
  key="RFC 7604",
  abstract={This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol (RTSP).  Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has.  There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases.  These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.},
  keywords="RTP, Real-time Transport Protocol, Real-time, Firewall, UDP",
  doi="10.17487/RFC7604",
  }

@misc{rfc7605,
  author="J. Touch",
  title="{Recommendations on Using Assigned Transport Port Numbers}",
  howpublished="RFC 7605 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7605",
  pages="1--24",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7605.txt",
  key="RFC 7605",
  abstract={This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA.  It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.},
  keywords="tcp, udp, sctp, dccp, service, iana",
  doi="10.17487/RFC7605",
  }

@misc{rfc7606,
  author="E. Chen and J. Scudder and P. Mohapatra and K. Patel",
  title="{Revised Error Handling for BGP UPDATE Messages}",
  howpublished="RFC 7606 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7606",
  pages="1--19",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7606.txt",
  key="RFC 7606",
  abstract={According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.},
  keywords="BGP",
  doi="10.17487/RFC7606",
  }

@misc{rfc7607,
  author="W. Kumari and R. Bush and H. Schiller and K. Patel",
  title="{Codification of AS 0 Processing}",
  howpublished="RFC 7607 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7607",
  pages="1--5",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7607.txt",
  key="RFC 7607",
  abstract={This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS\_PATH, AS4\_PATH, AGGREGATOR, and AS4\_AGGREGATOR attributes in the BGP UPDATE message.},
  keywords="BGP, AS 0, AS\_PATH, AS-PATH",
  doi="10.17487/RFC7607",
  }

@misc{rfc7608,
  author="M. Boucadair and A. Petrescu and F. Baker",
  title="{IPv6 Prefix Length Recommendation for Forwarding}",
  howpublished="RFC 7608 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7608",
  pages="1--6",
  year=2015,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7608.txt",
  key="RFC 7608",
  abstract={IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture.  The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix.  Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.},
  keywords="IPv6 Routing, CIDR, Classless Inter-Domain Routing, IPv6 Addressing Architecture, IPv6 Forwarding Information Base, IPv6 Routing Information Base, FIB, RIB, IPv6 Deployment",
  doi="10.17487/RFC7608",
  }

@misc{rfc7609,
  author="M. Fox and C. Kassimis and J. Stevens",
  title="{IBM's Shared Memory Communications over RDMA (SMC-R) Protocol}",
  howpublished="RFC 7609 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7609",
  pages="1--143",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7609.txt",
  key="RFC 7609",
  abstract={This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol.  This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications.  It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available.  It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.},
  doi="10.17487/RFC7609",
  }

@misc{rfc7610,
  author="F. Gont and W. Liu and G. Van de Velde",
  title="{DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers}",
  howpublished="RFC 7610 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7610",
  pages="1--12",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7610.txt",
  key="RFC 7610",
  abstract={This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers.  It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received.  A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks.  This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.},
  doi="10.17487/RFC7610",
  }

@misc{rfc7611,
  author="J. Uttaro and P. Mohapatra and D. Smith and R. Raszuk and J. Scudder",
  title="{BGP ACCEPT\_OWN Community Attribute}",
  howpublished="RFC 7611 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7611",
  pages="1--8",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7611.txt",
  key="RFC 7611",
  abstract={Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs.  This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route.  However, due to the constraints of BGP, it does not work if the two are on the same PE.  This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.},
  keywords="BGP, VPN, L3VPN, Extranet, Well-known, Reserved",
  doi="10.17487/RFC7611",
  }

@misc{rfc7612,
  author="P. Fleming and I. McDonald",
  title="{Lightweight Directory Access Protocol (LDAP): Schema for Printer Services}",
  howpublished="RFC 7612 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7612",
  pages="1--54",
  year=2015,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7612.txt",
  key="RFC 7612",
  abstract={This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of ``Internet Printing Protocol/1.1: Model and Semantics'' (RFC 2911). Additional Printer attributes are based on definitions in ``Printer MIB v2'' (RFC 3805), ``PWG Command Set Format for IEEE 1284 Device ID v1.0'' (PWG 5107.2), ``IPP Job and Printer Extensions - Set 3 (JPS3)'' (PWG 5100.13), and ``IPP Everywhere'' (PWG 5100.14). This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG ``IPP Everywhere'' (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software. This document obsoletes RFC 3712.},
  doi="10.17487/RFC7612",
  }

@misc{rfc7613,
  author="P. Saint-Andre and A. Melnikov",
  title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords}",
  howpublished="RFC 7613 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7613",
  pages="1--27",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7613.txt",
  key="RFC 7613",
  abstract={This document describes updated methods for handling Unicode strings representing usernames and passwords.  The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).  The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords.  The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.},
  keywords="Username, Password, Unicode, Internationalization, i18n, Authentication, SASLprep, strings, stringprep",
  doi="10.17487/RFC7613",
  }

@misc{rfc7614,
  author="R. Sparks",
  title="{Explicit Subscriptions for the REFER Method}",
  howpublished="RFC 7614 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7614",
  pages="1--14",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7614.txt",
  key="RFC 7614",
  abstract={The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription.  Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing.  This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.},
  keywords="SIP, SIP Events, nosub, explicitsub, Refer-Events-At",
  doi="10.17487/RFC7614",
  }

@misc{rfc7615,
  author="J. Reschke",
  title="{HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields}",
  howpublished="RFC 7615 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7615",
  pages="1--6",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7615.txt",
  key="RFC 7615",
  abstract={This specification defines the ``Authentication-Info'' and ``Proxy- Authentication-Info'' response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.},
  keywords="HTTP, authentication",
  doi="10.17487/RFC7615",
  }

@misc{rfc7616,
  author="R. Shekh-Yusef and D. Ahrens and S. Bremer",
  title="{HTTP Digest Access Authentication}",
  howpublished="RFC 7616 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7616",
  pages="1--32",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7616.txt",
  key="RFC 7616",
  abstract={The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information.  This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.},
  keywords="HTTP, authentication scheme",
  doi="10.17487/RFC7616",
  }

@misc{rfc7617,
  author="J. Reschke",
  title="{The 'Basic' HTTP Authentication Scheme}",
  howpublished="RFC 7617 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7617",
  pages="1--15",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7617.txt",
  key="RFC 7617",
  abstract={This document defines the ``Basic'' Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.},
  keywords="HTTP, authentication scheme, basic authentication scheme",
  doi="10.17487/RFC7617",
  }

@misc{rfc7618,
  author="Y. Cui and Q. Sun and I. Farrer and Y. Lee and Q. Sun and M. Boucadair",
  title="{Dynamic Allocation of Shared IPv4 Addresses}",
  howpublished="RFC 7618 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7618",
  pages="1--15",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7618.txt",
  key="RFC 7618",
  abstract={This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included. Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.},
  doi="10.17487/RFC7618",
  }

@misc{rfc7619,
  author="V. Smyslov and P. Wouters",
  title="{The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 7619 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7619",
  pages="1--12",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7619.txt",
  key="RFC 7619",
  abstract={This document specifies the NULL Authentication method and the ID\_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2).  This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself.  This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.},
  keywords="unauthenticated, opportunistic security, pervasive monitoring, Peer Authorization Database, PAD, opportunistic encryption",
  doi="10.17487/RFC7619",
  }

@misc{rfc7620,
  author="M. Boucadair and B. Chatras and T. Reddy and B. Williams and B. Sarikaya",
  title="{Scenarios with Host Identification Complications}",
  howpublished="RFC 7620 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7620",
  pages="1--26",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7620.txt",
  key="RFC 7620",
  abstract={This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as ``host identification''. Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase. This document does not include any solution-specific discussions.},
  keywords="IP address sharing, IPv4 service continuity, host identifier, de-multiplexing connections, policy enforcement, service delivery",
  doi="10.17487/RFC7620",
  }

@misc{rfc7621,
  author="A.B. Roach",
  title="{A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework}",
  howpublished="RFC 7621 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7621",
  pages="1--4",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7621.txt",
  key="RFC 7621",
  abstract={Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior. This document updates RFC 6665.},
  keywords="session initiation protocol",
  doi="10.17487/RFC7621",
  }

@misc{rfc7622,
  author="P. Saint-Andre",
  title="{Extensible Messaging and Presence Protocol (XMPP): Address Format}",
  howpublished="RFC 7622 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7622",
  pages="1--27",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7622.txt",
  key="RFC 7622",
  abstract={This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range.  This document obsoletes RFC 6122.},
  keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Messaging, Instant Messaging, Presence, Internationalization, i18n, PRECIS",
  doi="10.17487/RFC7622",
  }

@misc{rfc7623,
  author="A. Sajassi and S. Salam and N. Bitar and A. Isaac and W. Henderickx",
  title="{Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)}",
  howpublished="RFC 7623 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7623",
  pages="1--23",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7623.txt",
  key="RFC 7623",
  abstract={This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes.  The combined solution is referred to as PBB-EVPN.},
  doi="10.17487/RFC7623",
  }

@misc{rfc7624,
  author="R. Barnes and B. Schneier and C. Jennings and T. Hardie and B. Trammell and C. Huitema and D. Borkmann",
  title="{Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement}",
  howpublished="RFC 7624 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7624",
  pages="1--24",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7624.txt",
  key="RFC 7624",
  abstract={Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered.  In this document, we develop a threat model that describes these attacks on Internet confidentiality.  We assume an attacker that is interested in undetected, indiscriminate eavesdropping.  The threat model is based on published, verified attacks.},
  keywords="eavesdropping",
  doi="10.17487/RFC7624",
  }

@misc{rfc7625,
  author="J. T. Hao and P. Maheshwari and R. Huang and L. Andersson and M. Chen",
  title="{Architecture of an IP/MPLS Network with Hardened Pipes}",
  howpublished="RFC 7625 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7625",
  pages="1--15",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7625.txt",
  key="RFC 7625",
  abstract={This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the ``Hard Pipes'', called the ``Hard Pipe Stratum'', and one for the normal IP/MPLS traffic, called the ``Normal IP/MPLS Stratum''. This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon. The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end. The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.},
  doi="10.17487/RFC7625",
  }

@misc{rfc7626,
  author="S. Bortzmeyer",
  title="{DNS Privacy Considerations}",
  howpublished="RFC 7626 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7626",
  pages="1--17",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7626.txt",
  key="RFC 7626",
  abstract={This document describes the privacy issues associated with the use of the DNS by Internet users.  It is intended to be an analysis of the present situation and does not prescribe solutions.},
  keywords="Confidentiality, Pervasive Surveillance, Domain Name System",
  doi="10.17487/RFC7626",
  }

@misc{rfc7627,
  author="K. Bhargavan and A. Delignat-Lavaud and A. Pironti and A. Langley and M. Ray",
  title="{Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension}",
  howpublished="RFC 7627 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7627",
  pages="1--15",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7627.txt",
  key="RFC 7627",
  abstract={The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.},
  doi="10.17487/RFC7627",
  }

@misc{rfc7628,
  author="W. Mills and T. Showalter and H. Tschofenig",
  title="{A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth}",
  howpublished="RFC 7628 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7628",
  pages="1--21",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7628.txt",
  key="RFC 7628",
  abstract={OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.},
  doi="10.17487/RFC7628",
  }

@misc{rfc7629,
  author="S. Gundavelli and K. Leung and G. Tsirtsis and A. Petrescu",
  title="{Flow-Binding Support for Mobile IP}",
  howpublished="RFC 7629 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7629",
  pages="1--19",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7629.txt",
  key="RFC 7629",
  abstract={This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent.  This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic.  Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses.},
  keywords="Multipath, Flow Binding, Hybrid Access, Flow Mobility, MIPv4-NEMO",
  doi="10.17487/RFC7629",
  }

@misc{rfc7630,
  author="J. Merkle and M. Lochter",
  title="{HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3}",
  howpublished="RFC 7630 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7630",
  pages="1--14",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7860",
url="https://www.rfc-editor.org/rfc/rfc7630.txt",
  key="RFC 7630",
  abstract={This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.},
  keywords="Network, Management, SNMP, USM, HMAC, SHA-2",
  doi="10.17487/RFC7630",
  }

@misc{rfc7631,
  author="C. Dearlove and T. Clausen",
  title="{TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format}",
  howpublished="RFC 7631 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7631",
  pages="1--15",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7722",
url="https://www.rfc-editor.org/rfc/rfc7631.txt",
  key="RFC 7631",
  abstract={This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the ``Mobile Ad hoc NETwork (MANET) Parameters'' registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444.},
  keywords="MANET, packet, message, address, TLV",
  doi="10.17487/RFC7631",
  }

@misc{rfc7632,
  author="D. Waltermire and D. Harrington",
  title="{Endpoint Security Posture Assessment: Enterprise Use Cases}",
  howpublished="RFC 7632 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7632",
  pages="1--23",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7632.txt",
  key="RFC 7632",
  abstract={This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture.  From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.},
  keywords="security automation, continuous monitoring, endpoint, posture assessment, use case, asset management, configuration management, vulnerability management, content management",
  doi="10.17487/RFC7632",
  }

@misc{rfc7633,
  author="P. Hallam-Baker",
  title="{X.509v3 Transport Layer Security (TLS) Feature Extension}",
  howpublished="RFC 7633 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7633",
  pages="1--11",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7633.txt",
  key="RFC 7633",
  abstract={The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol.  In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling.  Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled.  This in turn prevents a denial-of-service attack that might otherwise be possible.},
  keywords="PKIX, Transport Layer Security, Cryptography Certificate",
  doi="10.17487/RFC7633",
  }

@misc{rfc7634,
  author="Y. Nir",
  title="{ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec}",
  howpublished="RFC 7634 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7634",
  pages="1--13",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7634.txt",
  key="RFC 7634",
  abstract={This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.},
  keywords="IKE, IPsec, AEAD, ChaCha, ChaCha20, Salsa",
  doi="10.17487/RFC7634",
  }

@misc{rfc7635,
  author="T. Reddy and P. Patil and R. Ravindranath and J. Uberti",
  title="{Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization}",
  howpublished="RFC 7635 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7635",
  pages="1--24",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7635.txt",
  key="RFC 7635",
  abstract={This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication.  The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.},
  keywords="OAuth 2.0, STUN, TURN, WebRTC, Authentication and Authorization",
  doi="10.17487/RFC7635",
  }

@misc{rfc7636,
  author="N. Sakimura and J. Bradley and N. Agarwal",
  title="{Proof Key for Code Exchange by OAuth Public Clients}",
  howpublished="RFC 7636 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7636",
  pages="1--20",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7636.txt",
  key="RFC 7636",
  abstract={OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack.  This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced ``pixy'').},
  keywords="smart phones, apps, XARA, authorization, custom scheme, intent, man-in-the-middle, eavesdropping, user agent swap, spop, pop, openid, connect , pkce, pixie",
  doi="10.17487/RFC7636",
  }

@misc{rfc7637,
  author="P. Garg and Y. Wang",
  title="{NVGRE: Network Virtualization Using Generic Routing Encapsulation}",
  howpublished="RFC 7637 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7637",
  pages="1--17",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7637.txt",
  key="RFC 7637",
  abstract={This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers.  Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure.  This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.},
  doi="10.17487/RFC7637",
  }

@misc{rfc7638,
  author="M. Jones and N. Sakimura",
  title="{JSON Web Key (JWK) Thumbprint}",
  howpublished="RFC 7638 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7638",
  pages="1--13",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7638.txt",
  key="RFC 7638",
  abstract={This specification defines a method for computing a hash value over a JSON Web Key (JWK).  It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed.  The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.},
  keywords="JavaScript Object Notation, JSON, JSON Web Key, JWK, ThumbprintOB, Fingerprint, Digest",
  doi="10.17487/RFC7638",
  }

@misc{rfc7639,
  author="A. Hutton and J. Uberti and M. Thomson",
  title="{The ALPN HTTP Header Field}",
  howpublished="RFC 7639 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7639",
  pages="1--7",
  year=2015,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7639.txt",
  key="RFC 7639",
  abstract={This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.},
  keywords="HTTP CONNECT, Firewall, HTTP proxy",
  doi="10.17487/RFC7639",
  }

@misc{rfc7640,
  author="B. Constantine and R. Krishnan",
  title="{Traffic Management Benchmarking}",
  howpublished="RFC 7640 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7640",
  pages="1--51",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7640.txt",
  key="RFC 7640",
  abstract={This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.).  The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.},
  doi="10.17487/RFC7640",
  }

@misc{rfc7641,
  author="K. Hartke",
  title="{Observing Resources in the Constrained Application Protocol (CoAP)}",
  howpublished="RFC 7641 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7641",
  pages="1--30",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7641.txt",
  key="RFC 7641",
  abstract={The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to ``observe'' resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.},
  keywords="Smart Objects, Internet of Things, IoT, REST",
  doi="10.17487/RFC7641",
  }

@misc{rfc7642,
  author="K. LI and P. Hunt and B. Khasnabish and A. Nadalin and Z. Zeltsan",
  title="{System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements}",
  howpublished="RFC 7642 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7642",
  pages="1--19",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7642.txt",
  key="RFC 7642",
  abstract={This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM).  It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.},
  keywords="SIM user scenarios, SCIM use cases",
  doi="10.17487/RFC7642",
  }

@misc{rfc7643,
  author="P. Hunt and K. Grizzle and E. Wahlstroem and C. Mortimore",
  title="{System for Cross-domain Identity Management: Core Schema}",
  howpublished="RFC 7643 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7643",
  pages="1--104",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7643.txt",
  key="RFC 7643",
  abstract={The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.},
  keywords="Identity, Provisioning, User, Group",
  doi="10.17487/RFC7643",
  }

@misc{rfc7644,
  author="P. Hunt and K. Grizzle and M. Ansari and E. Wahlstroem and C. Mortimore",
  title="{System for Cross-domain Identity Management: Protocol}",
  howpublished="RFC 7644 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7644",
  pages="1--89",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7644.txt",
  key="RFC 7644",
  abstract={The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service.  Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios.  The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.  SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.},
  keywords="SCIM",
  doi="10.17487/RFC7644",
  }

@misc{rfc7645,
  author="U. Chunduri and A. Tian and W. Lu",
  title="{The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis}",
  howpublished="RFC 7645 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7645",
  pages="1--12",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7645.txt",
  key="RFC 7645",
  abstract={This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in ``Keying and Authentication for Routing Protocols (KARP) Design Guidelines'' (RFC 6518) for both manual and automated key management protocols.},
  doi="10.17487/RFC7645",
  }

@misc{rfc7646,
  author="P. Ebersman and W. Kumari and C. Griffiths and J. Livingood and R. Weber",
  title="{Definition and Use of DNSSEC Negative Trust Anchors}",
  howpublished="RFC 7646 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7646",
  pages="1--16",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7646.txt",
  key="RFC 7646",
  abstract={DNS Security Extensions (DNSSEC) is now entering widespread deployment.  However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes.  This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.},
  keywords="NTA, ISP, Internet Service Provider, DNS, DNSSEC, Negative Trust Anchors",
  doi="10.17487/RFC7646",
  }

@misc{rfc7647,
  author="R. Sparks and A.B. Roach",
  title="{Clarifications for the Use of REFER with RFC 6665}",
  howpublished="RFC 7647 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7647",
  pages="1--6",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7647.txt",
  key="RFC 7647",
  abstract={The SIP REFER method relies on the SIP-Specific Event Notification framework.  That framework was revised by RFC 6665.  This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.},
  doi="10.17487/RFC7647",
  }

@misc{rfc7648,
  author="S. Perreault and M. Boucadair and R. Penno and D. Wing and S. Cheshire",
  title="{Port Control Protocol (PCP) Proxy Function}",
  howpublished="RFC 7648 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7648",
  pages="1--14",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7648.txt",
  key="RFC 7648",
  abstract={This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy.  The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s).  A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.},
  keywords="NAT, firewall, CGN, AFTR, NAT64, port forwarding, pinholing, port mapping, external IP address, discover port number, running a server behind NAT, NAT control, NAT cascading, DS-Lite, incoming connection, control outbound connection, referral, address referral, ALG offload, PCP client, PCP server",
  doi="10.17487/RFC7648",
  }

@misc{rfc7649,
  author="P. Saint-Andre and D. York",
  title="{The Jabber Scribe Role at IETF Meetings}",
  howpublished="RFC 7649 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7649",
  pages="1--12",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7649.txt",
  key="RFC 7649",
  abstract={During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom.  Such volunteers are commonly called ``Jabber scribes''.  This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.},
  keywords="Jabber Scribe, IETF Meetings",
  doi="10.17487/RFC7649",
  }

@misc{rfc7650,
  author="J. Jimenez and J. Lopez-Vega and J. Maenpaa and G. Camarillo",
  title="{A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7650 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7650",
  pages="1--19",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7650.txt",
  key="RFC 7650",
  abstract={This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD).  The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSNs) in a peer-to-peer fashion.  The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data.  This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers.  The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.},
  keywords="CoAP, RELOAD",
  doi="10.17487/RFC7650",
  }

@misc{rfc7651,
  author="A. Dodd-Noble and S. Gundavelli and J. Korhonen and F. Baboescu and B. Weis",
  title="{3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 7651 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7651",
  pages="1--10",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7651.txt",
  key="RFC 7651",
  abstract={This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2).  These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF).  When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.},
  keywords="P-CSCF, P-CSCF Option for IKEv2, Proxy-Call Session Control Function, IMS Option for IKEv2",
  doi="10.17487/RFC7651",
  }

@misc{rfc7652,
  author="M. Cullen and S. Hartman and D. Zhang and T. Reddy",
  title="{Port Control Protocol (PCP) Authentication Mechanism}",
  howpublished="RFC 7652 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7652",
  pages="1--34",
  year=2015,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7652.txt",
  key="RFC 7652",
  abstract={An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. This document updates RFC 6887.},
  doi="10.17487/RFC7652",
  }

@misc{rfc7653,
  author="D. Raghuvanshi and K. Kinnear and D. Kukrety",
  title="{DHCPv6 Active Leasequery}",
  howpublished="RFC 7653 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7653",
  pages="1--30",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7653.txt",
  key="RFC 7653",
  abstract={The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings.  That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request.  Continuous update of an external requestor with Leasequery data is sometimes desired.  This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP.  This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.},
  keywords="DHCP, IPv6, ACTIVELEASEQUERY, DHCPv6",
  doi="10.17487/RFC7653",
  }

@misc{rfc7654,
  author="S. Banks and F. Calabria and G. Czirjak and R. Machat",
  title="{Benchmarking Methodology for In-Service Software Upgrade (ISSU)}",
  howpublished="RFC 7654 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7654",
  pages="1--16",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7654.txt",
  key="RFC 7654",
  abstract={Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU).  This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.},
  doi="10.17487/RFC7654",
  }

@misc{rfc7655,
  author="M. Ramalho and P. Jones and N. Harada and M. Perumal and L. Miao",
  title="{RTP Payload Format for G.711.0}",
  howpublished="RFC 7655 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7655",
  pages="1--32",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7655.txt",
  key="RFC 7655",
  abstract={This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0.  ITU-T Rec.  G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks.  This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.},
  keywords="G.711.0, G.711, G.711ZIP, Lossless G.711 Compression, G.711 Data Compression Algorithm",
  doi="10.17487/RFC7655",
  }

@misc{rfc7656,
  author="J. Lennox and K. Gross and S. Nandakumar and G. Salgueiro and B. Burman",
  title="{A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources}",
  howpublished="RFC 7656 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7656",
  pages="1--46",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7656.txt",
  key="RFC 7656",
  abstract={The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque.  This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.},
  keywords="Taxonomy, Terminology, RTP, Grouping",
  doi="10.17487/RFC7656",
  }

@misc{rfc7657,
  author="D. Black and P. Jones",
  title="{Differentiated Services (Diffserv) and Real-Time Communication}",
  howpublished="RFC 7657 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7657",
  pages="1--26",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7657.txt",
  key="RFC 7657",
  abstract={This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP).  Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs).  WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple.  The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering).  In addition, DSCP markings may be changed or removed between the traffic source and destination.  This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.},
  keywords="Diffserv, DSCP, RAI, RTP",
  doi="10.17487/RFC7657",
  }

@misc{rfc7658,
  author="S. Perreault and T. Tsou and S. Sivakumar and T. Taylor",
  title="{Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)}",
  howpublished="RFC 7658 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7658",
  pages="1--62",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7658.txt",
  key="RFC 7658",
  abstract={This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities. This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.},
  keywords="NATV2-MIB, management information base",
  doi="10.17487/RFC7658",
  }

@misc{rfc7659,
  author="S. Perreault and T. Tsou and S. Sivakumar and T. Taylor",
  title="{Definitions of Managed Objects for Network Address Translators (NATs)}",
  howpublished="RFC 7659 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7659",
  pages="1--84",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7659.txt",
  key="RFC 7659",
  abstract={This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function.  The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008).  NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document.  A companion document deprecates all objects in NAT-MIB.  NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function.  Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).},
  keywords="MIB, management information base, NATV2-MIB, NAT-MIB, basic nat, pooled nat, carrier-grade nat, CGN",
  doi="10.17487/RFC7659",
  }

@misc{rfc7660,
  author="L. Bertz and S. Manning and B. Hirschman",
  title="{Diameter Congestion and Filter Attributes}",
  howpublished="RFC 7660 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7660",
  pages="1--9",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7660.txt",
  key="RFC 7660",
  abstract={This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration. RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition. The optional attributes defined in this document are forward and backwards compatible with RFC 5777.},
  doi="10.17487/RFC7660",
  }

@misc{rfc7661,
  author="G. Fairhurst and A. Sathiaseelan and R. Secchi",
  title="{Updating TCP to Support Rate-Limited Traffic}",
  howpublished="RFC 7661 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7661",
  pages="1--21",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7661.txt",
  key="RFC 7661",
  abstract={This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced. This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.},
  keywords="CWV, TCP",
  doi="10.17487/RFC7661",
  }

@misc{rfc7662,
  author="J. Richer",
  title="{OAuth 2.0 Token Introspection}",
  howpublished="RFC 7662 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7662",
  pages="1--17",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7662.txt",
  key="RFC 7662",
  abstract={This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token.  OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.},
  keywords="token validation, oauth token validation, active token, inactive token, token metadata, token status, token status check",
  doi="10.17487/RFC7662",
  }

@misc{rfc7663,
  author="B. Trammell and M. Kuehlewind",
  title="{Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)}",
  howpublished="RFC 7663 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7663",
  pages="1--13",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7663.txt",
  key="RFC 7663",
  abstract={The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack.  The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators).  This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop.  The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.},
  keywords="transport layer, TCP, UDP, encapsulation",
  doi="10.17487/RFC7663",
  }

@misc{rfc7664,
  author="D. Harkins",
  title="{Dragonfly Key Exchange}",
  howpublished="RFC 7664 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7664",
  pages="1--18",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7664.txt",
  key="RFC 7664",
  abstract={This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase.  It is resistant to active attack, passive attack, and offline dictionary attack.  This document is a product of the Crypto Forum Research Group (CFRG).},
  keywords="elliptic curve, PAKE, AKE, dictionary attack, password authentication",
  doi="10.17487/RFC7664",
  }

@misc{rfc7665,
  author="J. Halpern and C. Pignataro",
  title="{Service Function Chaining (SFC) Architecture}",
  howpublished="RFC 7665 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7665",
  pages="1--32",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7665.txt",
  key="RFC 7665",
  abstract={This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, or extensions to existing protocols.},
  doi="10.17487/RFC7665",
  }

@misc{rfc7666,
  author="H. Asai and M. MacFaden and J. Schoenwaelder and K. Shima and T. Tsou",
  title="{Management Information Base for Virtual Machines Controlled by a Hypervisor}",
  howpublished="RFC 7666 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7666",
  pages="1--52",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7666.txt",
  key="RFC 7666",
  abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a.  virtual machine monitor).},
  keywords="MIB, Hypervisor, Virtual Machine, VM-MIB, IANA-STORAGE-MEDIA-TYPE-MIB",
  doi="10.17487/RFC7666",
  }

@misc{rfc7667,
  author="M. Westerlund and S. Wenger",
  title="{RTP Topologies}",
  howpublished="RFC 7667 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7667",
  pages="1--48",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7667.txt",
  key="RFC 7667",
  abstract={This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP).  In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.},
  keywords="Real-time, Multi-party, Mixer, Relay, SFM, Selective Forwarding Middlebox, Translator, Multicast, ASM, SSM",
  doi="10.17487/RFC7667",
  }

@misc{rfc7668,
  author="J. Nieminen and T. Savolainen and M. Isomaki and B. Patil and Z. Shelby and C. Gomez",
  title="{IPv6 over BLUETOOTH(R) Low Energy}",
  howpublished="RFC 7668 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7668",
  pages="1--21",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7668.txt",
  key="RFC 7668",
  abstract={Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group.  The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices.  The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc.  The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6.  This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.},
  keywords="Bluetooth Low Energy, 6lowpan, IPv6, Low power",
  doi="10.17487/RFC7668",
  }

@misc{rfc7669,
  author="J. Levine",
  title="{Assigning Digital Object Identifiers to RFCs}",
  howpublished="RFC 7669 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7669",
  pages="1--7",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7669.txt",
  key="RFC 7669",
  abstract={This document describes the way that Digital Object Identifiers (DOIs) are assigned to past and future RFCs.  The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.},
  doi="10.17487/RFC7669",
  }

@misc{rfc7670,
  author="T. Kivinen and P. Wouters and H. Tschofenig",
  title="{Generic Raw Public-Key Support for IKEv2}",
  howpublished="RFC 7670 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7670",
  pages="1--10",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7670.txt",
  key="RFC 7670",
  abstract={The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys.  In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography.  This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.},
  keywords="Internet Key Exchange Version 2",
  doi="10.17487/RFC7670",
  }

@misc{rfc7671,
  author="V. Dukhovni and W. Hardaker",
  title="{The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance}",
  howpublished="RFC 7671 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7671",
  pages="1--33",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7671.txt",
  key="RFC 7671",
  abstract={This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience.  It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.},
  keywords="DANE, TLSA",
  doi="10.17487/RFC7671",
  }

@misc{rfc7672,
  author="V. Dukhovni and W. Hardaker",
  title="{SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)}",
  howpublished="RFC 7672 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7672",
  pages="1--34",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7672.txt",
  key="RFC 7672",
  abstract={This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).},
  keywords="DANE, TLSA, SMTP",
  doi="10.17487/RFC7672",
  }

@misc{rfc7673,
  author="T. Finch and M. Miller and P. Saint-Andre",
  title="{Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records}",
  howpublished="RFC 7673 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7673",
  pages="1--16",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7673.txt",
  key="RFC 7673",
  abstract={The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers).  However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698.  Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.},
  doi="10.17487/RFC7673",
  }

@misc{rfc7674,
  author="J. Haas",
  title="{Clarification of the Flowspec Redirect Extended Community}",
  howpublished="RFC 7674 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7674",
  pages="1--7",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7674.txt",
  key="RFC 7674",
  abstract={This document updates RFC 5575 (``Dissemination of Flow Specification Rules'') to clarify the formatting of the BGP Flowspec Redirect Extended Community.},
  keywords="bgp, flowspec",
  doi="10.17487/RFC7674",
  }

@misc{rfc7675,
  author="M. Perumal and D. Wing and R. Ravindranath and T. Reddy and M. Thomson",
  title="{Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness}",
  howpublished="RFC 7675 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7675",
  pages="1--10",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7675.txt",
  key="RFC 7675",
  abstract={To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.},
  keywords="WebRTC",
  doi="10.17487/RFC7675",
  }

@misc{rfc7676,
  author="C. Pignataro and R. Bonica and S. Krishnan",
  title="{IPv6 Support for Generic Routing Encapsulation (GRE)}",
  howpublished="RFC 7676 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7676",
  pages="1--11",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7676.txt",
  key="RFC 7676",
  abstract={Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.},
  keywords="GRE, IPv6",
  doi="10.17487/RFC7676",
  }

@misc{rfc7677,
  author="T. Hansen",
  title="{SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms}",
  howpublished="RFC 7677 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7677",
  pages="1--8",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7677.txt",
  key="RFC 7677",
  abstract={This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.},
  doi="10.17487/RFC7677",
  }

@misc{rfc7678,
  author="C. Zhou and T. Taylor and Q. Sun and M. Boucadair",
  title="{Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions}",
  howpublished="RFC 7678 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7678",
  pages="1--23",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7678.txt",
  key="RFC 7678",
  abstract={During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6.  This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques.  To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment.  This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.},
  keywords="DS-Lite, Lightweight 4over6, MAP-E, IPv4 service continuity, IPv6 deployment, IPv4 address sharing, Diameter, Multicast, IPv4 over IPv6",
  doi="10.17487/RFC7678",
  }

@misc{rfc7679,
  author="G. Almes and S. Kalidindi and M. Zekauskas and A. Morton",
  title="{A One-Way Delay Metric for IP Performance Metrics (IPPM)}",
  howpublished="RFC 7679 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7679",
  pages="1--27",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7679.txt",
  key="RFC 7679",
  abstract={This memo defines a metric for one-way delay of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document.  This memo makes RFC 2679 obsolete.},
  keywords="Performance, Measurement, Quality of Service (QoS)",
  doi="10.17487/RFC7679",
  }

@misc{rfc7680,
  author="G. Almes and S. Kalidindi and M. Zekauskas and A. Morton",
  title="{A One-Way Loss Metric for IP Performance Metrics (IPPM)}",
  howpublished="RFC 7680 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7680",
  pages="1--22",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7680.txt",
  key="RFC 7680",
  abstract={This memo defines a metric for one-way loss of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document.  This memo makes RFC 2680 obsolete.},
  keywords="Performance, Measurement, Quality of Service (QoS)",
  doi="10.17487/RFC7680",
  }

@misc{rfc7681,
  author="J. Davin",
  title="{Email Exchange of Secondary School Transcripts}",
  howpublished="RFC 7681 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7681",
  pages="1--40",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7681.txt",
  key="RFC 7681",
  abstract={A common format simplifies exchange of secondary school academic transcripts via electronic mail.  Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients.  By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.},
  keywords="Internet Applications, email, school transcript, MIME, OpenPGP",
  doi="10.17487/RFC7681",
  }

@misc{rfc7682,
  author="D. McPherson and S. Amante and E. Osterweil and L. Blunk and D. Mitchell",
  title="{Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration}",
  howpublished="RFC 7682 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7682",
  pages="1--18",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7682.txt",
  key="RFC 7682",
  abstract={The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades.  Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.},
  keywords="Resource Certification, Internet Routing Registry, IRR, Routing Policy Specification Language, RPSL",
  doi="10.17487/RFC7682",
  }

@misc{rfc7683,
  author="J. Korhonen and S. Donovan and B. Campbell and L. Morand",
  title="{Diameter Overload Indication Conveyance}",
  howpublished="RFC 7683 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7683",
  pages="1--42",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7683.txt",
  key="RFC 7683",
  abstract={This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).},
  keywords="DOIC",
  doi="10.17487/RFC7683",
  }

@misc{rfc7684,
  author="P. Psenak and H. Gredler and R. Shakir and W. Henderickx and J. Tantsura and A. Lindem",
  title="{OSPFv2 Prefix/Link Attribute Advertisement}",
  howpublished="RFC 7684 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7684",
  pages="1--15",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7684.txt",
  key="RFC 7684",
  abstract={OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328.  This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links.  Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs.  The OSPFv2 Opaque LSAs are optional and fully backward compatible.},
  keywords="OSPF-LSA, open shortest path first, link state advertisement, Opaque LSA",
  doi="10.17487/RFC7684",
  }

@misc{rfc7685,
  author="A. Langley",
  title="{A Transport Layer Security (TLS) ClientHello Padding Extension}",
  howpublished="RFC 7685 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7685",
  pages="1--4",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7685.txt",
  key="RFC 7685",
  abstract={This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.},
  doi="10.17487/RFC7685",
  }

@misc{rfc7686,
  author="J. Appelbaum and A. Muffett",
  title="{The ``.onion'' Special-Use Domain Name}",
  howpublished="RFC 7686 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7686",
  pages="1--7",
  year=2015,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7686.txt",
  key="RFC 7686",
  abstract={This document registers the ``.onion'' Special-Use Domain Name.},
  doi="10.17487/RFC7686",
  }

@misc{rfc7687,
  author="S. Farrell and R. Wenning and B. Bos and M. Blanchet and H. Tschofenig",
  title="{Report from the Strengthening the Internet (STRINT) Workshop}",
  howpublished="RFC 7687 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7687",
  pages="1--32",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7687.txt",
  key="RFC 7687",
  abstract={The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.},
  keywords="IAB, W3C, STREWS, security, pervasive monitoring, London",
  doi="10.17487/RFC7687",
  }

@misc{rfc7688,
  author="Y. Lee and G. Bernstein",
  title="{GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks}",
  howpublished="RFC 7688 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7688",
  pages="1--12",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7688.txt",
  key="RFC 7688",
  abstract={This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.},
  doi="10.17487/RFC7688",
  }

@misc{rfc7689,
  author="G. Bernstein and S. Xu and Y. Lee and G. Martinelli and H. Harai",
  title="{Signaling Extensions for Wavelength Switched Optical Networks}",
  howpublished="RFC 7689 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7689",
  pages="1--16",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7689.txt",
  key="RFC 7689",
  abstract={This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs).  Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes.  This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.},
  doi="10.17487/RFC7689",
  }

@misc{rfc7690,
  author="M. Byerly and M. Hite and J. Jaeggli",
  title="{Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))}",
  howpublished="RFC 7690 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7690",
  pages="1--9",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7690.txt",
  key="RFC 7690",
  abstract={This document calls attention to the problem of delivering ICMPv6 type 2 ``Packet Too Big'' (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures.  It discusses operational mitigations that can be employed to address this class of failures.},
  keywords="IPv6, ICMP6, ICMPv6 type 2 PTB",
  doi="10.17487/RFC7690",
  }

@misc{rfc7691,
  author="S. Bradner",
  title="{Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members}",
  howpublished="RFC 7691 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7691",
  pages="1--4",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7691.txt",
  key="RFC 7691",
  abstract={BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical.  This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.},
  doi="10.17487/RFC7691",
  }

@misc{rfc7692,
  author="T. Yoshino",
  title="{Compression Extensions for WebSocket}",
  howpublished="RFC 7692 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7692",
  pages="1--28",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7692.txt",
  key="RFC 7692",
  abstract={This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol.  An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake.  This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages.  Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail.  This document also specifies one specific compression extension using the DEFLATE algorithm.},
  keywords="DEFLATE, LZ77",
  doi="10.17487/RFC7692",
  }

@misc{rfc7693,
  author="M-J. Saarinen and J-P. Aumasson",
  title="{The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)}",
  howpublished="RFC 7693 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7693",
  pages="1--30",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7693.txt",
  key="RFC 7693",
  abstract={This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community.  BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures.  BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).},
  keywords="BLAKE2, Cryptographic Hash",
  doi="10.17487/RFC7693",
  }

@misc{rfc7694,
  author="J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding}",
  howpublished="RFC 7694 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7694",
  pages="1--7",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7694.txt",
  key="RFC 7694",
  abstract={In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the ``gzip'' content coding is widely used for payload data sent in response messages. Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP ``Accept-Encoding'' header field for use in responses, to indicate the content codings that are supported in requests.},
  keywords="HTTP, content-encoding",
  doi="10.17487/RFC7694",
  }

@misc{rfc7695,
  author="P. Pfister and B. Paterson and J. Arkko",
  title="{Distributed Prefix Assignment Algorithm}",
  howpublished="RFC 7695 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7695",
  pages="1--20",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7695.txt",
  key="RFC 7695",
  abstract={This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping.  Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.},
  keywords="distributed, prefix, address, assignment, homenet",
  doi="10.17487/RFC7695",
  }

@misc{rfc7696,
  author="R. Housley",
  title="{Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms}",
  howpublished="RFC 7696 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7696",
  pages="1--19",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7696.txt",
  key="RFC 7696",
  abstract={Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.  Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly.  This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.},
  doi="10.17487/RFC7696",
  }

@misc{rfc7697,
  author="P. Pan and S. Aldrin and M. Venkatesan and K. Sampath and T. Nadeau and S. Boutros",
  title="{MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)}",
  howpublished="RFC 7697 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7697",
  pages="1--36",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7697.txt",
  key="RFC 7697",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).},
  keywords="MPLS-OAM-ID-STD-MIB",
  doi="10.17487/RFC7697",
  }

@misc{rfc7698,
  author="O. Gonzalez de Dios and R. Casellas and F. Zhang and X. Fu and D. Ceccarelli and I. Hussain",
  title="{Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks}",
  howpublished="RFC 7698 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7698",
  pages="1--42",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7698.txt",
  key="RFC 7698",
  abstract={To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the ``frequency slot''. In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid). Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.},
  keywords="DWDM, Flexi-Grid, GMPLS",
  doi="10.17487/RFC7698",
  }

@misc{rfc7699,
  author="A. Farrel and D. King and Y. Li and F. Zhang",
  title="{Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers}",
  howpublished="RFC 7699 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7699",
  pages="1--14",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7699.txt",
  key="RFC 7699",
  abstract={GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFCs 3471 and 6205 by introducing a new label format.},
  keywords="GMPLS, RSVP-TE",
  doi="10.17487/RFC7699",
  }

@misc{rfc7700,
  author="P. Saint-Andre",
  title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames}",
  howpublished="RFC 7700 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7700",
  pages="1--11",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7700.txt",
  key="RFC 7700",
  abstract={This document describes methods for handling Unicode strings representing memorable, human-friendly names (called ``nicknames'', ``display names'', or ``petnames'') for people, devices, accounts, websites, and other entities.},
  keywords="nickname, SIP, SIMPLE, XMPP, MSRP, XCON, chatrooms",
  doi="10.17487/RFC7700",
  }

@misc{rfc7701,
  author="A. Niemi and M. Garcia-Martin and G. Sandbakken",
  title="{Multi-party Chat Using the Message Session Relay Protocol (MSRP)}",
  howpublished="RFC 7701 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7701",
  pages="1--42",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7701.txt",
  key="RFC 7701",
  abstract={The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).  This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.},
  keywords="messaging, message sessions, multi-party, chat, MSRP, SIMPLE",
  doi="10.17487/RFC7701",
  }

@misc{rfc7702,
  author="P. Saint-Andre and S. Ibarra and S. Loreto",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat}",
  howpublished="RFC 7702 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7702",
  pages="1--43",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7702.txt",
  key="RFC 7702",
  abstract={This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).  Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.},
  keywords="Text Chat, Groupchat, Instant Messaging, Session Initiation Protocol, SIP, Message Sessions Relay Protocol, MSRP, Extensible Messaging and Presence Protocol, XMPP",
  doi="10.17487/RFC7702",
  }

@misc{rfc7703,
  author="E. Cordeiro and R. Carnier and A. Moreiras",
  title="{Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)}",
  howpublished="RFC 7703 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7703",
  pages="1--56",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7703.txt",
  key="RFC 7703",
  abstract={This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address. The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.},
  keywords="template",
  doi="10.17487/RFC7703",
  }

@misc{rfc7704,
  author="D. Crocker and N. Clark",
  title="{An IETF with Much Diversity and Professional Conduct}",
  howpublished="RFC 7704 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7704",
  pages="1--18",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7704.txt",
  key="RFC 7704",
  abstract={The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations.  During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions.  In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content.  Groups with greater diversity make better decisions.  Obtaining meaningful diversity requires more than generic good will and statements of principle.  Many different behaviors can serve to reduce participant diversity or participation diversity.  This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it.  The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.},
  doi="10.17487/RFC7704",
  }

@misc{rfc7705,
  author="W. George and S. Amante",
  title="{Autonomous System Migration Mechanisms and Their Effects on the BGP AS\_PATH Attribute}",
  howpublished="RFC 7705 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7705",
  pages="1--16",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7705.txt",
  key="RFC 7705",
  abstract={This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification.  It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.},
  keywords="as-migration, AS-migration, AS\_migration, AS migration, IDR, BGP",
  doi="10.17487/RFC7705",
  }

@misc{rfc7706,
  author="W. Kumari and P. Hoffman",
  title="{Decreasing Access Time to Root Servers by Running One on Loopback}",
  howpublished="RFC 7706 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7706",
  pages="1--12",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7706.txt",
  key="RFC 7706",
  abstract={Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server.  Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties.  Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).  This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.},
  doi="10.17487/RFC7706",
  }

@misc{rfc7707,
  author="F. Gont and T. Chown",
  title="{Network Reconnaissance in IPv6 Networks}",
  howpublished="RFC 7707 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7707",
  pages="1--38",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7707.txt",
  key="RFC 7707",
  abstract={IPv6 offers a much larger address space than that of its IPv4 counterpart.  An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (\#hosts/\#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses.  As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible.  This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.},
  doi="10.17487/RFC7707",
  }

@misc{rfc7708,
  author="T. Nadeau and L. Martini and S. Bryant",
  title="{Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator}",
  howpublished="RFC 7708 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7708",
  pages="1--9",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7708.txt",
  key="RFC 7708",
  abstract={The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW).  This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network.  This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data.  This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).},
  keywords="VCCV, GAL",
  doi="10.17487/RFC7708",
  }

@misc{rfc7709,
  author="A. Malis and B. Wilson and G. Clapp and V. Shukla",
  title="{Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)}",
  howpublished="RFC 7709 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7709",
  pages="1--9",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7709.txt",
  key="RFC 7709",
  abstract={Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience. The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).},
  keywords="generalized multiprotocol label switching, OTN, optical transport networks, WSON,  TDM, WDM, churn, on-demand, wavelength, rapid setup",
  doi="10.17487/RFC7709",
  }

@misc{rfc7710,
  author="W. Kumari and O. Gudmundsson and P. Ebersman and S. Sheng",
  title="{Captive-Portal Identification Using DHCP or Router Advertisements (RAs)}",
  howpublished="RFC 7710 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7710",
  pages="1--8",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7710.txt",
  key="RFC 7710",
  abstract={In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.},
  doi="10.17487/RFC7710",
  }

@misc{rfc7711,
  author="M. Miller and P. Saint-Andre",
  title="{PKIX over Secure HTTP (POSH)}",
  howpublished="RFC 7711 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7711",
  pages="1--18",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7711.txt",
  key="RFC 7711",
  abstract={Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments.  As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain.  Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security.  This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols.  Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.},
  keywords="Extensible Messaging and Presence Protocol, Jabber, federation",
  doi="10.17487/RFC7711",
  }

@misc{rfc7712,
  author="P. Saint-Andre and M. Miller and P. Hancke",
  title="{Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)}",
  howpublished="RFC 7712 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7712",
  pages="1--24",
  year=2015,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7712.txt",
  key="RFC 7712",
  abstract={This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways.  First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of ``prooftypes''.  Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.},
  keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, federation, delegation, security",
  doi="10.17487/RFC7712",
  }

@misc{rfc7713,
  author="M. Mathis and B. Briscoe",
  title="{Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements}",
  howpublished="RFC 7713 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7713",
  pages="1--30",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7713.txt",
  key="RFC 7713",
  abstract={This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow.  Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback.  The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management.  This mechanism is called Congestion Exposure, or ConEx.  The companion document, ``Congestion Exposure (ConEx) Concepts and Use Cases'' (RFC 6789), provides the entry point to the set of ConEx documentation.},
  keywords="Quality of Service, QoS, Congestion Control, Signaling, Protocol, Encoding, Audit, Policing",
  doi="10.17487/RFC7713",
  }

@misc{rfc7714,
  author="D. McGrew and K. Igoe",
  title="{AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)}",
  howpublished="RFC 7714 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7714",
  pages="1--48",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7714.txt",
  key="RFC 7714",
  abstract={This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).},
  doi="10.17487/RFC7714",
  }

@misc{rfc7715,
  author="IJ. Wijnands and K. Raza and A. Atlas and J. Tantsura and Q. Zhao",
  title="{Multipoint LDP (mLDP) Node Protection}",
  howpublished="RFC 7715 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7715",
  pages="1--19",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7715.txt",
  key="RFC 7715",
  abstract={This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP).  In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails.  Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs).  The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.},
  doi="10.17487/RFC7715",
  }

@misc{rfc7716,
  author="J. Zhang and L. Giuliano and E. Rosen and K. Subramanian and D. Pacella",
  title="{Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures}",
  howpublished="RFC 7716 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7716",
  pages="1--22",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7716.txt",
  key="RFC 7716",
  abstract={RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers.  Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network.  With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN.  Multicast that is outside the context of a VPN is known as ``Global Table Multicast'', or sometimes simply as ``Internet multicast''.  In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.},
  keywords="Multicast",
  doi="10.17487/RFC7716",
  }

@misc{rfc7717,
  author="K. Pentikousis and E. Zhang and Y. Cui",
  title="{IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 7717 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7717",
  pages="1--15",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7717.txt",
  key="RFC 7717",
  abstract={The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret.  This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP.  If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency.  The key derivation presented in this document can also facilitate automatic key management.},
  doi="10.17487/RFC7717",
  }

@misc{rfc7718,
  author="A. Morton",
  title="{Registries for the One-Way Active Measurement Protocol (OWAMP)}",
  howpublished="RFC 7718 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7718",
  pages="1--7",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7718.txt",
  key="RFC 7718",
  abstract={This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol.  The registries allow assignment of Mode bit positions and OWAMP Command numbers.  Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry.  This memo updates RFC 4656.},
  doi="10.17487/RFC7718",
  }

@misc{rfc7719,
  author="P. Hoffman and A. Sullivan and K. Fujiwara",
  title="{DNS Terminology}",
  howpublished="RFC 7719 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7719",
  pages="1--27",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7719.txt",
  key="RFC 7719",
  abstract={The DNS is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.},
  doi="10.17487/RFC7719",
  }

@misc{rfc7720,
  author="M. Blanchet and L-J. Liman",
  title="{DNS Root Name Service Protocol and Deployment Requirements}",
  howpublished="RFC 7720 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7720",
  pages="1--6",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7720.txt",
  key="RFC 7720",
  abstract={The DNS root name service is a critical part of the Internet architecture.  The protocol and deployment requirements for the DNS root name service are defined in this document.  Operational requirements are out of scope.},
  doi="10.17487/RFC7720",
  }

@misc{rfc7721,
  author="A. Cooper and F. Gont and D. Thaler",
  title="{Security and Privacy Considerations for IPv6 Address Generation Mechanisms}",
  howpublished="RFC 7721 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7721",
  pages="1--18",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7721.txt",
  key="RFC 7721",
  abstract={This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized.  It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.},
  doi="10.17487/RFC7721",
  }

@misc{rfc7722,
  author="C. Dearlove and T. Clausen",
  title="{Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)}",
  howpublished="RFC 7722 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7722",
  pages="1--23",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7722.txt",
  key="RFC 7722",
  abstract={This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.},
  doi="10.17487/RFC7722",
  }

@misc{rfc7723,
  author="S. Kiesel and R. Penno",
  title="{Port Control Protocol (PCP) Anycast Addresses}",
  howpublished="RFC 7723 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7723",
  pages="1--9",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7723.txt",
  key="RFC 7723",
  abstract={The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel.  This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.},
  keywords="Port Control Protocol, anycast address, anycast server discovery, Port Control Protocol server discovery, port mapping, NAT control, firewall control",
  doi="10.17487/RFC7723",
  }

@misc{rfc7724,
  author="K. Kinnear and M. Stapp and B. Volz and N. Russell",
  title="{Active DHCPv4 Lease Query}",
  howpublished="RFC 7724 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7724",
  pages="1--28",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7724.txt",
  key="RFC 7724",
  abstract={The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388).  That mechanism is limited to queries for individual bindings.  In some situations, individual binding queries may not be efficient, or even possible.  In addition, continuous update of an external requestor with Leasequery data is sometimes desired.  This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP.  This document updates RFC 6926, ``DHCPv4 Bulk Leasequery''.},
  doi="10.17487/RFC7724",
  }

@misc{rfc7725,
  author="T. Bray",
  title="{An HTTP Status Code to Report Legal Obstacles}",
  howpublished="RFC 7725 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7725",
  pages="1--5",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7725.txt",
  key="RFC 7725",
  abstract={This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.},
  keywords="Hypertext Transfer Protocol",
  doi="10.17487/RFC7725",
  }

@misc{rfc7726,
  author="V. Govindan and K. Rajaraman and G. Mirsky and N. Akiya and S. Aldrin",
  title="{Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)}",
  howpublished="RFC 7726 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7726",
  pages="1--7",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7726.txt",
  key="RFC 7726",
  abstract={This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.},
  keywords="RFC5884, MPLS, LSP, BFD, RFC 5884",
  doi="10.17487/RFC7726",
  }

@misc{rfc7727,
  author="M. Zhang and H. Wen and J. Hu",
  title="{Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)}",
  howpublished="RFC 7727 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7727",
  pages="1--25",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7727.txt",
  key="RFC 7727",
  abstract={The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability. In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.},
  doi="10.17487/RFC7727",
  }

@misc{rfc7728,
  author="B. Burman and A. Akram and R. Even and M. Westerlund",
  title="{RTP Stream Pause and Resume}",
  howpublished="RFC 7728 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7728",
  pages="1--55",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7728.txt",
  key="RFC 7728",
  abstract={With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions.  This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport.  This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams.  This document updates RFC 5104.},
  keywords="CCM, RTCP, Feedback, Bandwidth, PAUSED, REFUSED, TMMBR, TMMBN, Mixer, MCU",
  doi="10.17487/RFC7728",
  }

@misc{rfc7729,
  author="B. Khasnabish and E. Haleplidis and J. Hadi Salim",
  title="{Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management}",
  howpublished="RFC 7729 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7729",
  pages="1--20",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7729.txt",
  key="RFC 7729",
  abstract={Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding.  In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality.  We refer to this LFB as the Subsidiary Mechanism (SM) LFB.  A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB.  This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE.  The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.},
  keywords="ForCES, LFB, Subsidiary Management, Virtualization",
  doi="10.17487/RFC7729",
  }

@misc{rfc7730,
  author="G. Huston and S. Weiler and G. Michaelson and S. Kent",
  title="{Resource Public Key Infrastructure (RPKI) Trust Anchor Locator}",
  howpublished="RFC 7730 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7730",
  pages="1--8",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7730.txt",
  key="RFC 7730",
  abstract={This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI).  This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.},
  keywords="RPKI, BGP Security",
  doi="10.17487/RFC7730",
  }

@misc{rfc7731,
  author="J. Hui and R. Kelsey",
  title="{Multicast Protocol for Low-Power and Lossy Networks (MPL)}",
  howpublished="RFC 7731 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7731",
  pages="1--29",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7731.txt",
  key="RFC 7731",
  abstract={This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.},
  keywords="6lowpan, 802.15.4, IPv6, LLN, ROLL, mesh network, trickle, wsn, wireless sensor network",
  doi="10.17487/RFC7731",
  }

@misc{rfc7732,
  author="P. van der Stok and R. Cragie",
  title="{Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)}",
  howpublished="RFC 7732 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7732",
  pages="1--15",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7732.txt",
  key="RFC 7732",
  abstract={The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.},
  keywords="routing, MPL, multicast policy, IP networks",
  doi="10.17487/RFC7732",
  }

@misc{rfc7733,
  author="A. Brandt and E. Baccelli and R. Cragie and P. van der Stok",
  title="{Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control}",
  howpublished="RFC 7733 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7733",
  pages="1--38",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7733.txt",
  key="RFC 7733",
  abstract={The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.},
  keywords="sensor network, ad hoc network, routing, RPL, applicability, building control, home automation, IP networks",
  doi="10.17487/RFC7733",
  }

@misc{rfc7734,
  author="D. Allan and J. Tantsura and D. Fedyk and A. Sajassi",
  title="{Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)}",
  howpublished="RFC 7734 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7734",
  pages="1--11",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7734.txt",
  key="RFC 7734",
  abstract={This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623).  This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.},
  keywords="SPBM, Provider Backbone Bridging Provider Edges, PBB-EVPN",
  doi="10.17487/RFC7734",
  }

@misc{rfc7735,
  author="R. Sparks and T. Kivinen",
  title="{Tracking Reviews of Documents}",
  howpublished="RFC 7735 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7735",
  pages="1--16",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7735.txt",
  key="RFC 7735",
  abstract={Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs.  The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker.  This document discusses requirements for improving those tools without disrupting current work flows.},
  keywords="review tool requirements",
  doi="10.17487/RFC7735",
  }

@misc{rfc7736,
  author="K. Ma",
  title="{Content Delivery Network Interconnection (CDNI) Media Type Registration}",
  howpublished="RFC 7736 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7736",
  pages="1--7",
  year=2015,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7736.txt",
  key="RFC 7736",
  abstract={This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.},
  keywords="CDNI, CDN Interconnect, CDN, content delivery, content delivery network",
  doi="10.17487/RFC7736",
  }

@misc{rfc7737,
  author="N. Akiya and G. Swallow and C. Pignataro and L. Andersson and M. Chen",
  title="{Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification}",
  howpublished="RFC 7737 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7737",
  pages="1--17",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7737.txt",
  key="RFC 7737",
  abstract={The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply.  This document updates the procedures for the ``Reply via Specified Path'' Reply Mode.  The value of this Reply Mode is 5.  The update creates a simple way to indicate that the reverse LSP should be used as the return path.  This document also adds an optional TLV that can carry an ordered list of Reply Mode values.},
  keywords="MPLS, LSP Ping, Reply Mode",
  doi="10.17487/RFC7737",
  }

@misc{rfc7738,
  author="M. Blanchet and A. Schiltknecht and P. Shames",
  title="{A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)}",
  howpublished="RFC 7738 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7738",
  pages="1--8",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7738.txt",
  key="RFC 7738",
  abstract={This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).},
  doi="10.17487/RFC7738",
  }

@misc{rfc7739,
  author="F. Gont",
  title="{Security Implications of Predictable Fragment Identification Values}",
  howpublished="RFC 7739 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7739",
  pages="1--20",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7739.txt",
  key="RFC 7739",
  abstract={IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms.  The Fragment Header contains an ``Identification'' field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host.  The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address.  Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values.  This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.},
  keywords="attack, vulnerability, Denial of Service, protocol identifiers",
  doi="10.17487/RFC7739",
  }

@misc{rfc7740,
  author="Z. Zhang and Y. Rekhter and A. Dolganow",
  title="{Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication}",
  howpublished="RFC 7740 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7740",
  pages="1--8",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7740.txt",
  key="RFC 7740",
  abstract={RFC 6513 (``Multicast in MPLS/BGP IP VPNs'') describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels.  This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication.  This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.},
  keywords="MVPN, Ingress Replication, Bidirectional C-flow, p-tunnel",
  doi="10.17487/RFC7740",
  }

@misc{rfc7741,
  author="P. Westin and H. Lundin and M. Glover and J. Uberti and F. Galligan",
  title="{RTP Payload Format for VP8 Video}",
  howpublished="RFC 7741 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7741",
  pages="1--27",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7741.txt",
  key="RFC 7741",
  abstract={This memo describes an RTP payload format for the VP8 video codec.  The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.},
  keywords="RTP, V8, WebM",
  doi="10.17487/RFC7741",
  }

@misc{rfc7742,
  author="A.B. Roach",
  title="{WebRTC Video Processing and Codec Requirements}",
  howpublished="RFC 7742 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7742",
  pages="1--10",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7742.txt",
  key="RFC 7742",
  abstract={This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network.  It specifies the video processing that is required as well as video codecs and their parameters.},
  keywords="MTI, mandatory-to-implement",
  doi="10.17487/RFC7742",
  }

@misc{rfc7743,
  author="J. Luo and L. Jin and T. Nadeau and G. Swallow",
  title="{Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping}",
  howpublished="RFC 7743 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7743",
  pages="1--18",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7743.txt",
  key="RFC 7743",
  abstract={In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 (``Label Switched Path (LSP) Ping and Traceroute''), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute.  This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator.  This document updates RFC 4379.},
  doi="10.17487/RFC7743",
  }

@misc{rfc7744,
  author="L. Seitz and S. Gerdes and G. Selander and M. Mani and S. Kumar",
  title="{Use Cases for Authentication and Authorization in Constrained Environments}",
  howpublished="RFC 7744 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7744",
  pages="1--30",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7744.txt",
  key="RFC 7744",
  abstract={Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.},
  keywords="Internet of Things, IoT, Smart Object, Security",
  doi="10.17487/RFC7744",
  }

@misc{rfc7745,
  author="T. Manderson",
  title="{XML Schemas for Reverse DNS Management}",
  howpublished="RFC 7745 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7745",
  pages="1--10",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7745.txt",
  key="RFC 7745",
  abstract={This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment.  This document describes a schema that has been developed and deployed by ICANN in a ``RESTful'' system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.},
  doi="10.17487/RFC7745",
  }

@misc{rfc7746,
  author="R. Bonica and I. Minei and M. Conn and D. Pacella and L. Tomotaki",
  title="{Label Switched Path (LSP) Self-Ping}",
  howpublished="RFC 7746 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7746",
  pages="1--12",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7746.txt",
  key="RFC 7746",
  abstract={When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures. LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.},
  doi="10.17487/RFC7746",
  }

@misc{rfc7747,
  author="R. Papneja and B. Parise and S. Hares and D. Lee and I. Varlashkin",
  title="{Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence}",
  howpublished="RFC 7747 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7747",
  pages="1--35",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7747.txt",
  key="RFC 7747",
  abstract={BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol.  It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed.  This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.},
  keywords="BMWG",
  doi="10.17487/RFC7747",
  }

@misc{rfc7748,
  author="A. Langley and M. Hamburg and S. Turner",
  title="{Elliptic Curves for Security}",
  howpublished="RFC 7748 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7748",
  pages="1--22",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7748.txt",
  key="RFC 7748",
  abstract={This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.},
  keywords="elliptic curve, cryptography, ecc",
  doi="10.17487/RFC7748",
  }

@misc{rfc7749,
  author="J. Reschke",
  title="{The ``xml2rfc'' Version 2 Vocabulary}",
  howpublished="RFC 7749 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7749",
  pages="1--76",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 7991",
url="https://www.rfc-editor.org/rfc/rfc7749.txt",
  key="RFC 7749",
  abstract={This document defines the ``xml2rfc'' version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014. This document obsoletes RFC 2629.},
  keywords="XML, IETF, RFC, Internet-Draft, Vocabulary",
  doi="10.17487/RFC7749",
  }

@misc{rfc7750,
  author="J. Hedin and G. Mirsky and S. Baillargeon",
  title="{Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 7750 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7750",
  pages="1--11",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7750.txt",
  key="RFC 7750",
  abstract={This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.},
  keywords="IPPM, TWAMP, Type-P Descriptor",
  doi="10.17487/RFC7750",
  }

@misc{rfc7751,
  author="S. Sorce and T. Yu",
  title="{Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)}",
  howpublished="RFC 7751 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7751",
  pages="1--10",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7751.txt",
  key="RFC 7751",
  abstract={This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED.  It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements.  The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container.  This document updates RFC 4120.},
  keywords="Kerberos",
  doi="10.17487/RFC7751",
  }

@misc{rfc7752,
  author="H. Gredler and J. Medved and S. Previdi and A. Farrel and S. Ray",
  title="{North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP}",
  howpublished="RFC 7752 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7752",
  pages="1--48",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7752.txt",
  key="RFC 7752",
  abstract={In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).},
  keywords="BGP, North-Bound, API, Link-State, Topology, Controller, Multi-Area, Multi-AS",
  doi="10.17487/RFC7752",
  }

@misc{rfc7753,
  author="Q. Sun and M. Boucadair and S. Sivakumar and C. Zhou and T. Tsou and S. Perreault",
  title="{Port Control Protocol (PCP) Extension for Port-Set Allocation}",
  howpublished="RFC 7753 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7753",
  pages="1--19",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7753.txt",
  key="RFC 7753",
  abstract={In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set.  This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole.  This is accomplished using a new MAP option: PORT\_SET.},
  keywords="IPv4 service continuity, IPv4 address shortage, A+P, AplusP, address plus port, MAP, Port range, Port Range Router, MAP-E, port set mapping, port bulk",
  doi="10.17487/RFC7753",
  }

@misc{rfc7754,
  author="R. Barnes and A. Cooper and O. Kolkman and D. Thaler and E. Nordmark",
  title="{Technical Considerations for Internet Service Blocking and Filtering}",
  howpublished="RFC 7754 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7754",
  pages="1--33",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7754.txt",
  key="RFC 7754",
  abstract={The Internet is structured to be an open communications medium.  This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties.  Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications.  Recently, there has been an increasing emphasis on ``blocking'' and ``filtering'', the active prevention of such communications.  This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture.  When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications.  We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.},
  keywords="Firewall, Filter, Deep Packet Inspection, Domain Name Seizure, Web Portal, Web Proxy",
  doi="10.17487/RFC7754",
  }

@misc{rfc7755,
  author="T. Anderson",
  title="{SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments}",
  howpublished="RFC 7755 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7755",
  pages="1--24",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7755.txt",
  key="RFC 7755",
  abstract={This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.},
  keywords="Data Centre, Data Center, Dual Stack, Single Stack, IDC, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT",
  doi="10.17487/RFC7755",
  }

@misc{rfc7756,
  author="T. Anderson and S. Steffann",
  title="{Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode}",
  howpublished="RFC 7756 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7756",
  pages="1--17",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7756.txt",
  key="RFC 7756",
  abstract={This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency. The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.},
  keywords="Data Centre, Data Center, Dual Stack, Single Stack, IDC, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT",
  doi="10.17487/RFC7756",
  }

@misc{rfc7757,
  author="T. Anderson and A. Leiva Popper",
  title="{Explicit Address Mappings for Stateless IP/ICMP Translation}",
  howpublished="RFC 7757 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7757",
  pages="1--19",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7757.txt",
  key="RFC 7757",
  abstract={This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.},
  keywords="Dual Stack, Single Stack, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT",
  doi="10.17487/RFC7757",
  }

@misc{rfc7758,
  author="T. Mizrahi and Y. Moses",
  title="{Time Capability in NETCONF}",
  howpublished="RFC 7758 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7758",
  pages="1--32",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7758.txt",
  key="RFC 7758",
  abstract={This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations.  This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.},
  keywords="NETCONF, network management, time, clock synchronization",
  doi="10.17487/RFC7758",
  }

@misc{rfc7759,
  author="E. Bellagamba and G. Mirsky and L. Andersson and P. Skoldstrom and D. Ward and J. Drake",
  title="{Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping}",
  howpublished="RFC 7759 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7759",
  pages="1--29",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7759.txt",
  key="RFC 7759",
  abstract={This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.},
  keywords="LSP-PING, MPLS, MPLS-TP,  OAM",
  doi="10.17487/RFC7759",
  }

@misc{rfc7760,
  author="R. Housley",
  title="{Statement of Work for Extensions to the IETF Datatracker for Author Statistics}",
  howpublished="RFC 7760 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7760",
  pages="1--8",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7760.txt",
  key="RFC 7760",
  abstract={This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.},
  doi="10.17487/RFC7760",
  }

@misc{rfc7761,
  author="B. Fenner and M. Handley and H. Holbrook and I. Kouvelas and R. Parekh and Z. Zhang and L. Zheng",
  title="{Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)}",
  howpublished="RFC 7761 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7761",
  pages="1--137",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7761.txt",
  key="RFC 7761",
  abstract={This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.},
  doi="10.17487/RFC7761",
  }

@misc{rfc7762,
  author="M. West",
  title="{Initial Assignment for the Content Security Policy Directives Registry}",
  howpublished="RFC 7762 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7762",
  pages="1--5",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7762.txt",
  key="RFC 7762",
  abstract={This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.},
  doi="10.17487/RFC7762",
  }

@misc{rfc7763,
  author="S. Leonard",
  title="{The text/markdown Media Type}",
  howpublished="RFC 7763 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7763",
  pages="1--15",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7763.txt",
  key="RFC 7763",
  abstract={This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.},
  doi="10.17487/RFC7763",
  }

@misc{rfc7764,
  author="S. Leonard",
  title="{Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations}",
  howpublished="RFC 7764 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7764",
  pages="1--28",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7764.txt",
  key="RFC 7764",
  abstract={This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.  Background information, local storage strategies, and additional syntax registrations are supplied.},
  keywords="text/markdown",
  doi="10.17487/RFC7764",
  }

@misc{rfc7765,
  author="P. Hurtig and A. Brunstrom and A. Petlund and M. Welzl",
  title="{TCP and Stream Control Transmission Protocol (SCTP) RTO Restart}",
  howpublished="RFC 7765 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7765",
  pages="1--15",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7765.txt",
  key="RFC 7765",
  abstract={This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection.  The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used.  This enables faster loss detection and recovery for connections that are short lived or application limited.},
  keywords="tcp, retransmission timer, rtor",
  doi="10.17487/RFC7765",
  }

@misc{rfc7766,
  author="J. Dickinson and S. Dickinson and R. Bellis and A. Mankin and D. Wessels",
  title="{DNS Transport over TCP - Implementation Requirements}",
  howpublished="RFC 7766 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7766",
  pages="1--19",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7766.txt",
  key="RFC 7766",
  abstract={This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.  This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.},
  keywords="DNS, TCP/IP, transport",
  doi="10.17487/RFC7766",
  }

@misc{rfc7767,
  author="S. Vinapamula and S. Sivakumar and M. Boucadair and T. Reddy",
  title="{Application-Initiated Check-Pointing via the Port Control Protocol (PCP)}",
  howpublished="RFC 7767 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7767",
  pages="1--12",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7767.txt",
  key="RFC 7767",
  abstract={This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side. This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.},
  keywords="serviceability, SDN, resilience, robustness, network programmability, network API, application control, service-aware networking, automation",
  doi="10.17487/RFC7767",
  }

@misc{rfc7768,
  author="T. Tsou and W. Li and T. Taylor and J. Huang",
  title="{Port Management to Reduce Logging in Large-Scale NATs}",
  howpublished="RFC 7768 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7768",
  pages="1--11",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7768.txt",
  key="RFC 7768",
  abstract={Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete.  There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address.  One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers.  It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs.  This document suggests a way to achieve dynamic port sharing while keeping log volumes low.},
  doi="10.17487/RFC7768",
  }

@misc{rfc7769,
  author="S. Sivabalan and S. Boutros and H. Shah and S. Aldrin and M. Venkatesan",
  title="{Media Access Control (MAC) Address Withdrawal over Static Pseudowire}",
  howpublished="RFC 7769 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7769",
  pages="1--10",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7769.txt",
  key="RFC 7769",
  abstract={This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH).  Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.},
  keywords="PW, ACH, associated channel",
  doi="10.17487/RFC7769",
  }

@misc{rfc7770,
  author="A. Lindem and N. Shen and JP. Vasseur and R. Aggarwal and S. Shaffer",
  title="{Extensions to OSPF for Advertising Optional Router Capabilities}",
  howpublished="RFC 7770 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7770",
  pages="1--15",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7770.txt",
  key="RFC 7770",
  abstract={It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose.  In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).  This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.},
  keywords="ospfv2, ospfv3, open shortest path first, ri, router information, lsa, link state advertisement",
  doi="10.17487/RFC7770",
  }

@misc{rfc7771,
  author="A. Malis and L. Andersson and H. van Helvoort and J. Shin and L. Wang and A. D'Alessandro",
  title="{Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires}",
  howpublished="RFC 7771 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7771",
  pages="1--9",
  year=2016,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7771.txt",
  key="RFC 7771",
  abstract={In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection.  With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection.  However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW.  This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870.  It also contains an optional approach based on MPLS-TP Linear Protection.},
  keywords="end-to-end protection, linear protection",
  doi="10.17487/RFC7771",
  }

@misc{rfc7772,
  author="A. Yourtchenko and L. Colitti",
  title="{Reducing Energy Consumption of Router Advertisements}",
  howpublished="RFC 7772 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7772",
  pages="1--6",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7772.txt",
  key="RFC 7772",
  abstract={Frequent Router Advertisement messages can severely impact host power consumption.  This document recommends operational practices to avoid such impact.},
  doi="10.17487/RFC7772",
  }

@misc{rfc7773,
  author="S. Santesson",
  title="{Authentication Context Certificate Extension}",
  howpublished="RFC 7773 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7773",
  pages="1--16",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7773.txt",
  key="RFC 7773",
  abstract={This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears. This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion Markup Language (SAML) assertion.},
  doi="10.17487/RFC7773",
  }

@misc{rfc7774,
  author="Y. Doi and M. Gillmore",
  title="{Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6}",
  howpublished="RFC 7774 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7774",
  pages="1--10",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7774.txt",
  key="RFC 7774",
  abstract={This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option.  MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in an MPL Domain.  Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.},
  keywords="MPL, DHCPv6",
  doi="10.17487/RFC7774",
  }

@misc{rfc7775,
  author="L. Ginsberg and S. Litkowski and S. Previdi",
  title="{IS-IS Route Preference for Extended IP and IPv6 Reachability}",
  howpublished="RFC 7775 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7775",
  pages="1--11",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7775.txt",
  key="RFC 7775",
  abstract={In existing specifications, the route preferences for IPv4/IPv6 Extended Reachability TLVs are not explicitly stated.  There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs).  This document addresses these issues.},
  doi="10.17487/RFC7775",
  }

@misc{rfc7776,
  author="P. Resnick and A. Farrel",
  title="{IETF Anti-Harassment Procedures}",
  howpublished="RFC 7776 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7776",
  pages="1--18",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7776.txt",
  key="RFC 7776",
  abstract={IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy. This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.},
  keywords="Ombudsman, Ombudsperson, Ombudsteam",
  doi="10.17487/RFC7776",
  }

@misc{rfc7777,
  author="S. Hegde and R. Shakir and A. Smirnov and Z. Li and B. Decraene",
  title="{Advertising Node Administrative Tags in OSPF}",
  howpublished="RFC 7777 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7777",
  pages="1--15",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7777.txt",
  key="RFC 7777",
  abstract={This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to the OSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF. This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.},
  keywords="open shortest path first",
  doi="10.17487/RFC7777",
  }

@misc{rfc7778,
  author="D. Kutscher and F. Mir and R. Winter and S. Krishnan and Y. Zhang and CJ. Bernardos",
  title="{Mobile Communication Congestion Exposure Scenario}",
  howpublished="RFC 7778 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7778",
  pages="1--25",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7778.txt",
  key="RFC 7778",
  abstract={This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS).  This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied.  Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.},
  keywords="congestion exposure, mobile communications",
  doi="10.17487/RFC7778",
  }

@misc{rfc7779,
  author="H. Rogge and E. Baccelli",
  title="{Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)}",
  howpublished="RFC 7779 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7779",
  pages="1--21",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7779.txt",
  key="RFC 7779",
  abstract={This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).},
  keywords="MANET, metric, ad hoc network, routing, IP networks, OLSR, ETT, ETX, Funkfeuer, DAT",
  doi="10.17487/RFC7779",
  }

@misc{rfc7780,
  author="D. {Eastlake 3rd} and M. Zhang and R. Perlman and A. Banerjee and A. Ghanwani and S. Gupta",
  title="{Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates}",
  howpublished="RFC 7780 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7780",
  pages="1--57",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7780.txt",
  key="RFC 7780",
  abstract={Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates.  RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively.  This document provides other known clarifications, corrections, and updates.  It obsoletes RFC 7180 (the previous ``TRILL clarifications, corrections, and updates'' RFC), and it updates RFCs 6325, 7177, and 7179.},
  keywords="TRILL, RBridge, IS-IS, reachability, overload, MTU, DEI, multicast, RPF, color, E-L1FS, purge",
  doi="10.17487/RFC7780",
  }

@misc{rfc7781,
  author="H. Zhai and T. Senevirathne and R. Perlman and M. Zhang and Y. Li",
  title="{Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access}",
  howpublished="RFC 7781 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7781",
  pages="1--35",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7781.txt",
  key="RFC 7781",
  abstract={The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology.  Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379.  In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge.  Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.},
  keywords="virtual RBridge, aggregation, flip-flopping",
  doi="10.17487/RFC7781",
  }

@misc{rfc7782,
  author="M. Zhang and R. Perlman and H. Zhai and M. Durrani and S. Gupta",
  title="{Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments}",
  howpublished="RFC 7782 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7782",
  pages="1--22",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7782.txt",
  key="RFC 7782",
  abstract={TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379. This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.},
  keywords="LAALP, vSwitch, MC-LAG, DRNI",
  doi="10.17487/RFC7782",
  }

@misc{rfc7783,
  author="T. Senevirathne and J. Pathangi and J. Hudson",
  title="{Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)}",
  howpublished="RFC 7783 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7783",
  pages="1--16",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7783.txt",
  key="RFC 7783",
  abstract={TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs.  Appointed Forwarders provide VLAN-based load sharing with an active-standby model.  High-performance applications require an active-active load-sharing model.  The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch).  Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations.  This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues.  CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree.  This document updates RFC 6325.},
  keywords="Affinity, RPF",
  doi="10.17487/RFC7783",
  }

@misc{rfc7784,
  author="D. Kumar and S. Salam and T. Senevirathne",
  title="{Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB}",
  howpublished="RFC 7784 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7784",
  pages="1--50",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7784.txt",
  key="RFC 7784",
  abstract={This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).},
  keywords="CFM, MEP, MIP, Fault Management",
  doi="10.17487/RFC7784",
  }

@misc{rfc7785,
  author="S. Vinapamula and M. Boucadair",
  title="{Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite}",
  howpublished="RFC 7785 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7785",
  pages="1--9",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7785.txt",
  key="RFC 7785",
  abstract={This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.},
  keywords="IPv4 service continuity, IPv4 address exhaustion, Service Availability, High Availability, Address sharing, IPv6, Reliability, IPv4 over IPv6, State migration, Stability, Disruption, Privacy",
  doi="10.17487/RFC7785",
  }

@misc{rfc7786,
  author="M. Kuehlewind and R. Scheffenegger",
  title="{TCP Modifications for Congestion Exposure (ConEx)}",
  howpublished="RFC 7786 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7786",
  pages="1--20",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7786.txt",
  key="RFC 7786",
  abstract={Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow.  This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).},
  doi="10.17487/RFC7786",
  }

@misc{rfc7787,
  author="M. Stenberg and S. Barth",
  title="{Distributed Node Consensus Protocol}",
  howpublished="RFC 7787 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7787",
  pages="1--41",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7787.txt",
  key="RFC 7787",
  abstract={This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees.  DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.},
  keywords="Homenet",
  doi="10.17487/RFC7787",
  }

@misc{rfc7788,
  author="M. Stenberg and S. Barth and P. Pfister",
  title="{Home Networking Control Protocol}",
  howpublished="RFC 7788 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7788",
  pages="1--40",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7788.txt",
  key="RFC 7788",
  abstract={This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices.  HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP).  HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.},
  keywords="IPv6, Homenet, DNCP",
  doi="10.17487/RFC7788",
  }

@misc{rfc7789,
  author="C. Cardona and P. Francois and P. Lucente",
  title="{Impact of BGP Filtering on Inter-Domain Routing Policies}",
  howpublished="RFC 7789 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7789",
  pages="1--16",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7789.txt",
  key="RFC 7789",
  abstract={This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes.  We provide a review of the techniques to detect the occurrence of this issue and defend against it.},
  keywords="More-specific prefix, Less-specific prefix, Autonomous systems, Traffic engineering",
  doi="10.17487/RFC7789",
  }

@misc{rfc7790,
  author="Y. Yoneya and T. Nemoto",
  title="{Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)}",
  howpublished="RFC 7790 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7790",
  pages="1--10",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7790.txt",
  key="RFC 7790",
  abstract={The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols.  Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping.  In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration.  This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols.  In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.},
  doi="10.17487/RFC7790",
  }

@misc{rfc7791,
  author="D. Migault and V. Smyslov",
  title="{Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 7791 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7791",
  pages="1--14",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7791.txt",
  key="RFC 7791",
  abstract={This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address. The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.},
  keywords="MIF, Load balancing, Load sharing, MOBIKE",
  doi="10.17487/RFC7791",
  }

@misc{rfc7792,
  author="F. Zhang and X. Zhang and A. Farrel and O. Gonzalez de Dios and D. Ceccarelli",
  title="{RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks}",
  howpublished="RFC 7792 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7792",
  pages="1--12",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7792.txt",
  key="RFC 7792",
  abstract={This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.},
  keywords="Flexible-grid, Flexible optical grid, Optical network, Optical trail, Optical LSP, GMPLS, WDM, PCE, spectrum reservation, flexible spectrum",
  doi="10.17487/RFC7792",
  }

@misc{rfc7793,
  author="M. Andrews",
  title="{Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry}",
  howpublished="RFC 7793 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7793",
  pages="1--6",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7793.txt",
  key="RFC 7793",
  abstract={RFC 6598 specifies that ``Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure.'' This document formally directs IANA to add the associated zones to the ``IPv4 Locally-Served DNS Zones Registry'' to prevent such queries from accidentally leaking to the global DNS infrastructure.},
  doi="10.17487/RFC7793",
  }

@misc{rfc7794,
  author="L. Ginsberg and B. Decraene and S. Previdi and X. Xu and U. Chunduri",
  title="{IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability}",
  howpublished="RFC 7794 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7794",
  pages="1--9",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7794.txt",
  key="RFC 7794",
  abstract={This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.},
  keywords="ISIS",
  doi="10.17487/RFC7794",
  }

@misc{rfc7795,
  author="J. Dong and H. Wang",
  title="{Pseudowire Redundancy on the Switching Provider Edge (S-PE)}",
  howpublished="RFC 7795 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7795",
  pages="1--9",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7795.txt",
  key="RFC 7795",
  abstract={This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659.  Operations of the S-PEs that provide PW redundancy are specified in this document.  Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused.  This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.},
  doi="10.17487/RFC7795",
  }

@misc{rfc7796,
  author="Y. Jiang and L. Yong and M. Paul",
  title="{Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)}",
  howpublished="RFC 7796 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7796",
  pages="1--26",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7796.txt",
  key="RFC 7796",
  abstract={This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services.  A VPLS Provider Edge (PE) model is illustrated as an example for the solution.  In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute.  The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively.  A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.},
  keywords="Etree",
  doi="10.17487/RFC7796",
  }

@misc{rfc7797,
  author="M. Jones",
  title="{JSON Web Signature (JWS) Unencoded Payload Option}",
  howpublished="RFC 7797 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7797",
  pages="1--11",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7797.txt",
  key="RFC 7797",
  abstract={JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit. This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.},
  keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, Digital Signature, Message Authentication Code, MAC, Unencoded Payload",
  doi="10.17487/RFC7797",
  }

@misc{rfc7798,
  author="Y.-K. Wang and Y. Sanchez and T. Schierl and S. Wenger and M. M. Hannuksela",
  title="{RTP Payload Format for High Efficiency Video Coding (HEVC)}",
  howpublished="RFC 7798 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7798",
  pages="1--86",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7798.txt",
  key="RFC 7798",
  abstract={This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC).  The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.  Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams.  When multiple RTP streams are used, a single transport or multiple transports may be utilized.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.},
  keywords="H.265, : ISO/IEC 23008-2, Single NAL Unit Packet, Aggregation Packet, Fragmentation Unit, Payload Content Information Packet, Use of HEVC with Feedback Messages.",
  doi="10.17487/RFC7798",
  }

@misc{rfc7799,
  author="A. Morton",
  title="{Active and Passive Metrics and Methods (with Hybrid Types In-Between)}",
  howpublished="RFC 7799 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7799",
  pages="1--14",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7799.txt",
  key="RFC 7799",
  abstract={This memo provides clear definitions for Active and Passive performance assessment.  The construction of Metrics and Methods can be described as either ``Active'' or ``Passive''.  Some methods may use a subset of both Active and Passive attributes, and we refer to these as ``Hybrid Methods''.  This memo also describes multiple dimensions to help evaluate new methods as they emerge.},
  keywords="IP Performance, Measurements, Testing, Network Characterization",
  doi="10.17487/RFC7799",
  }

@misc{rfc7800,
  author="M. Jones and J. Bradley and H. Tschofenig",
  title="{Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)}",
  howpublished="RFC 7800 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7800",
  pages="1--15",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7800.txt",
  key="RFC 7800",
  abstract={This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter.  Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.},
  keywords="JSON Web Token, JWT, Proof-of-Possession, Holder-of-Key",
  doi="10.17487/RFC7800",
  }

@misc{rfc7801,
  author="V. Dolmatov",
  title="{GOST R 34.12-2015: Block Cipher ``Kuznyechik''}",
  howpublished="RFC 7801 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7801",
  pages="1--14",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7801.txt",
  key="RFC 7801",
  abstract={This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as ``Kuznyechik''.  This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).},
  keywords="Kuznyechik, Block Cipher",
  doi="10.17487/RFC7801",
  }

@misc{rfc7802,
  author="S. Emery and N. Williams",
  title="{A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism}",
  howpublished="RFC 7802 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7802",
  pages="1--8",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7802.txt",
  key="RFC 7802",
  abstract={This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.},
  doi="10.17487/RFC7802",
  }

@misc{rfc7803,
  author="B. Leiba",
  title="{Changing the Registration Policy for the NETCONF Capability URNs Registry}",
  howpublished="RFC 7803 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7803",
  pages="1--3",
  year=2016,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7803.txt",
  key="RFC 7803",
  abstract={The registration policy for the ``Network Configuration Protocol (NETCONF) Capability URNs'' registry, set up by RFC 6241, has turned out to be unnecessarily strict.  This document changes that registration policy to ``IETF Review'', allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs.},
  doi="10.17487/RFC7803",
  }

@misc{rfc7804,
  author="A. Melnikov",
  title="{Salted Challenge Response HTTP Authentication Mechanism}",
  howpublished="RFC 7804 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7804",
  pages="1--18",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7804.txt",
  key="RFC 7804",
  abstract={This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.},
  keywords="HTTPAUTH, HTTP, SASL, SCRAM, GS2, GSSAPI, GSS-API",
  doi="10.17487/RFC7804",
  }

@misc{rfc7805,
  author="A. Zimmermann and W. Eddy and L. Eggert",
  title="{Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status}",
  howpublished="RFC 7805 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7805",
  pages="1--8",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7805.txt",
  key="RFC 7805",
  abstract={This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to ``Historic'' status.  The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013.  Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to ``Informational'' status.},
  doi="10.17487/RFC7805",
  }

@misc{rfc7806,
  author="F. Baker and R. Pan",
  title="{On Queuing, Marking, and Dropping}",
  howpublished="RFC 7806 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7806",
  pages="1--16",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7806.txt",
  key="RFC 7806",
  abstract={This note discusses queuing and marking/dropping algorithms.  While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.},
  doi="10.17487/RFC7806",
  }

@misc{rfc7807,
  author="M. Nottingham and E. Wilde",
  title="{Problem Details for HTTP APIs}",
  howpublished="RFC 7807 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7807",
  pages="1--16",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7807.txt",
  key="RFC 7807",
  abstract={This document defines a ``problem detail'' as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.},
  keywords="status, HTTP, error, problem, API, JSON, XML",
  doi="10.17487/RFC7807",
  }

@misc{rfc7808,
  author="M. Douglass and C. Daboo",
  title="{Time Zone Data Distribution Service}",
  howpublished="RFC 7808 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7808",
  pages="1--56",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7808.txt",
  key="RFC 7808",
  abstract={This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.},
  keywords="time zone, calendaring, scheduling",
  doi="10.17487/RFC7808",
  }

@misc{rfc7809,
  author="C. Daboo",
  title="{Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference}",
  howpublished="RFC 7809 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7809",
  pages="1--13",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7809.txt",
  key="RFC 7809",
  abstract={This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.},
  keywords="CalDAV, calendaring, iCalendar, time zone",
  doi="10.17487/RFC7809",
  }

@misc{rfc7810,
  author="S. Previdi and S. Giacalone and D. Ward and J. Drake and Q. Wu",
  title="{IS-IS Traffic Engineering (TE) Metric Extensions}",
  howpublished="RFC 7810 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7810",
  pages="1--18",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7810.txt",
  key="RFC 7810",
  abstract={In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.},
  doi="10.17487/RFC7810",
  }

@misc{rfc7811,
  author="G. Enyedi and A. Csaszar and A. Atlas and C. Bowers and A. Gopalan",
  title="{An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)}",
  howpublished="RFC 7811 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7811",
  pages="1--118",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7811.txt",
  key="RFC 7811",
  abstract={This document supports the solution put forth in ``An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)'' (RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.},
  keywords="MRT, FRR, LFA, recovery, failure, routing",
  doi="10.17487/RFC7811",
  }

@misc{rfc7812,
  author="A. Atlas and C. Bowers and G. Enyedi",
  title="{An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)}",
  howpublished="RFC 7812 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7812",
  pages="1--44",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7812.txt",
  key="RFC 7812",
  abstract={This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR).  MRT-FRR is a technology that gives link-protection and node-protection with 100\% coverage in any network topology that is still connected after the failure.},
  keywords="MRT, FRR, LFA, recovery, failure, routing",
  doi="10.17487/RFC7812",
  }

@misc{rfc7813,
  author="J. Farkas and N. Bragg and P. Unbehagen and G. Parsons and P. Ashwood-Smith and C. Bowers",
  title="{IS-IS Path Control and Reservation}",
  howpublished="RFC 7813 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7813",
  pages="1--33",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7813.txt",
  key="RFC 7813",
  abstract={IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB).  IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain.  This document specifies the sub-TLVs for IS-IS PCR.},
  keywords="IS-IS, SPB",
  doi="10.17487/RFC7813",
  }

@misc{rfc7814,
  author="X. Xu and C. Jacquenet and R. Raszuk and T. Boyes and B. Fee",
  title="{Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution}",
  howpublished="RFC 7814 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7814",
  pages="1--15",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7814.txt",
  key="RFC 7814",
  abstract={This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as ``Virtual Subnet'', which can be used for building Layer 3 network virtualization overlays within and/or between data centers.},
  keywords="Data Center Interconnect, Data Center Network, Virtual Machine (VM) migration",
  doi="10.17487/RFC7814",
  }

@misc{rfc7815,
  author="T. Kivinen",
  title="{Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation}",
  howpublished="RFC 7815 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7815",
  pages="1--41",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7815.txt",
  key="RFC 7815",
  abstract={This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other. This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.},
  keywords="IKE, IPsec, IoT, Constrained",
  doi="10.17487/RFC7815",
  }

@misc{rfc7816,
  author="S. Bortzmeyer",
  title="{DNS Query Name Minimisation to Improve Privacy}",
  howpublished="RFC 7816 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7816",
  pages="1--11",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7816.txt",
  key="RFC 7816",
  abstract={This document describes a technique to improve DNS privacy, a technique called ``QNAME minimisation'', where the DNS resolver no longer sends the full original QNAME to the upstream name server.},
  doi="10.17487/RFC7816",
  }

@misc{rfc7817,
  author="A. Melnikov",
  title="{Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols}",
  howpublished="RFC 7817 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7817",
  pages="1--13",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7817.txt",
  key="RFC 7817",
  abstract={This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients.  It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.},
  keywords="SMTP, Submission, IMAP, POP, ManageSieve",
  doi="10.17487/RFC7817",
  }

@misc{rfc7818,
  author="M. Jethanandani",
  title="{URN Namespace for MEF Documents}",
  howpublished="RFC 7818 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7818",
  pages="1--5",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7818.txt",
  key="RFC 7818",
  abstract={This document describes the Namespace Identifier (NID) ``mef'' for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (https://www.mef.net).  MEF specifies and manages resources that utilize this URN identification model.  Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry.},
  doi="10.17487/RFC7818",
  }

@misc{rfc7819,
  author="S. Jiang and S. Krishnan and T. Mrugalski",
  title="{Privacy Considerations for DHCP}",
  howpublished="RFC 7819 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7819",
  pages="1--14",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7819.txt",
  key="RFC 7819",
  abstract={DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts.  This document discusses the various identifiers used by DHCP and the potential privacy issues.},
  keywords="DHCP Privacy",
  doi="10.17487/RFC7819",
  }

@misc{rfc7820,
  author="T. Mizrahi",
  title="{UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)}",
  howpublished="RFC 7820 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7820",
  pages="1--15",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7820.txt",
  key="RFC 7820",
  abstract={The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks.  Delay measurement is performed in these protocols by using timestamped test packets.  Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission.  Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification.  This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field.  The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.},
  keywords="Checksum, UDP, IPPM, timestamping",
  doi="10.17487/RFC7820",
  }

@misc{rfc7821,
  author="T. Mizrahi",
  title="{UDP Checksum Complement in the Network Time Protocol (NTP)}",
  howpublished="RFC 7821 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7821",
  pages="1--14",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7821.txt",
  key="RFC 7821",
  abstract={The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages.  To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission.  Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification.  This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field.  The behavior defined in this document is interoperable with existing NTP implementations.},
  keywords="NTP, UDP, Checksum, timestamping",
  doi="10.17487/RFC7821",
  }

@misc{rfc7822,
  author="T. Mizrahi and D. Mayer",
  title="{Network Time Protocol Version 4 (NTPv4) Extension Fields}",
  howpublished="RFC 7822 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7822",
  pages="1--8",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7822.txt",
  key="RFC 7822",
  abstract={The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields.  An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header.  This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).},
  keywords="NTP, extension field",
  doi="10.17487/RFC7822",
  }

@misc{rfc7823,
  author="A. Atlas and J. Drake and S. Giacalone and S. Previdi",
  title="{Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions}",
  howpublished="RFC 7823 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7823",
  pages="1--10",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7823.txt",
  key="RFC 7823",
  abstract={In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP).  Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load.  This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.},
  keywords="Traffic Engineering,  Path Computation",
  doi="10.17487/RFC7823",
  }

@misc{rfc7824,
  author="S. Krishnan and T. Mrugalski and S. Jiang",
  title="{Privacy Considerations for DHCPv6}",
  howpublished="RFC 7824 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7824",
  pages="1--18",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7824.txt",
  key="RFC 7824",
  abstract={DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts.  This document describes the privacy issues associated with the use of DHCPv6 by Internet users.  It is intended to be an analysis of the present situation and does not propose any solutions.},
  doi="10.17487/RFC7824",
  }

@misc{rfc7825,
  author="J. Goldberg and M. Westerlund and T. Zeng",
  title="{A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)}",
  howpublished="RFC 7825 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7825",
  pages="1--33",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7825.txt",
  key="RFC 7825",
  abstract={This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0).  It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.},
  keywords="ICE, Media Delivery, RTP, RTCP, D-ICE, AVP, AVPF, SAVP, SAVPF, setup.ice-d-m, rtsp-ice-d-m, SDP",
  doi="10.17487/RFC7825",
  }

@misc{rfc7826,
  author="H. Schulzrinne and A. Rao and R. Lanphier and M. Westerlund and M. Stiemerling",
  title="{Real-Time Streaming Protocol Version 2.0}",
  howpublished="RFC 7826 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7826",
  pages="1--318",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7826.txt",
  key="RFC 7826",
  abstract={This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).},
  keywords="mmusic, RTSP, RTSP/2.0, real-time streaming protocol",
  doi="10.17487/RFC7826",
  }

@misc{rfc7827,
  author="L. Eggert",
  title="{The Role of the IRTF Chair}",
  howpublished="RFC 7827 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7827",
  pages="1--7",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7827.txt",
  key="RFC 7827",
  abstract={This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.},
  doi="10.17487/RFC7827",
  }

@misc{rfc7828,
  author="P. Wouters and J. Abley and S. Dickinson and R. Bellis",
  title="{The edns-tcp-keepalive EDNS0 Option}",
  howpublished="RFC 7828 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7828",
  pages="1--11",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7828.txt",
  key="RFC 7828",
  abstract={DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option (``edns-tcp-keepalive'') that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.},
  keywords="long-lived, dnssec, DNS, TCP/IP, transport",
  doi="10.17487/RFC7828",
  }

@misc{rfc7829,
  author="Y. Nishida and P. Natarajan and A. Caro and P. Amer and K. Nielsen",
  title="{SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol}",
  howpublished="RFC 7829 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7829",
  pages="1--23",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7829.txt",
  key="RFC 7829",
  abstract={The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management. This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960. Additionally, this document introduces an alternative switchback operation mode called ``Primary Path Switchover'' that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation. The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.},
  keywords="SCTP, Failover, multipath, multihoming, Potentially Failed",
  doi="10.17487/RFC7829",
  }

@misc{rfc7830,
  author="A. Mayrhofer",
  title="{The EDNS(0) Padding Option}",
  howpublished="RFC 7830 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7830",
  pages="1--5",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7830.txt",
  key="RFC 7830",
  abstract={This document specifies the EDNS(0) ``Padding'' option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.},
  keywords="Domain Name System, DNS, EDNS, EDNS0, Security, Encryption, Padding",
  doi="10.17487/RFC7830",
  }

@misc{rfc7831,
  author="J. Howlett and S. Hartman and H. Tschofenig and J. Schaad",
  title="{Application Bridging for Federated Access Beyond Web (ABFAB) Architecture}",
  howpublished="RFC 7831 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7831",
  pages="1--46",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7831.txt",
  key="RFC 7831",
  abstract={Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including the Remote Authentication Dial-In User Service (RADIUS), the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP), and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, Relying Parties, and federations.},
  keywords="Federated Authentication, AAA, RADIUS, Diameter, GSS-API, EAP, SAML",
  doi="10.17487/RFC7831",
  }

@misc{rfc7832,
  author="R. Smith",
  title="{Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases}",
  howpublished="RFC 7832 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7832",
  pages="1--13",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7832.txt",
  key="RFC 7832",
  abstract={Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts.  The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.},
  keywords="Federated Authentication, AAA, RADIUS, Diameter, GSS-API, EAP, SASL",
  doi="10.17487/RFC7832",
  }

@misc{rfc7833,
  author="J. Howlett and S. Hartman and A. Perez-Mendez",
  title="{A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)}",
  howpublished="RFC 7833 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7833",
  pages="1--32",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7833.txt",
  key="RFC 7833",
  abstract={This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture.  It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods.  The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding.  The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients).  These clients may be named using a Network Access Identifier (NAI) name identifier format.  Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject.  The use of the artifacts defined in this document is not exclusive to ABFAB.  They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.},
  keywords="ABFAB, AAA, EAP, RADIUS, SAML",
  doi="10.17487/RFC7833",
  }

@misc{rfc7834,
  author="D. Saucez and L. Iannone and A. Cabellos and F. Coras",
  title="{Locator/ID Separation Protocol (LISP) Impact}",
  howpublished="RFC 7834 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7834",
  pages="1--18",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7834.txt",
  key="RFC 7834",
  abstract={The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping.  In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.},
  doi="10.17487/RFC7834",
  }

@misc{rfc7835,
  author="D. Saucez and L. Iannone and O. Bonaventure",
  title="{Locator/ID Separation Protocol (LISP) Threat Analysis}",
  howpublished="RFC 7835 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7835",
  pages="1--19",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7835.txt",
  key="RFC 7835",
  abstract={This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).},
  doi="10.17487/RFC7835",
  }

@misc{rfc7836,
  author="S. Smyshlyaev and E. Alekseev and I. Oshkin and V. Popov and S. Leontiev and V. Podobaev and D. Belyavsky",
  title="{Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012}",
  howpublished="RFC 7836 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7836",
  pages="1--32",
  year=2016,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7836.txt",
  key="RFC 7836",
  abstract={The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms. These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.},
  keywords="HMAC, PRF, key agreement, VKO, key exchange, key derivation, KDF, key tree, elliptic curve, Weierstrass, twisted Edwards, TLS, IPsec, IKE, IKEv2",
  doi="10.17487/RFC7836",
  }

@misc{rfc7837,
  author="S. Krishnan and M. Kuehlewind and B. Briscoe and C. Ralli",
  title="{IPv6 Destination Option for Congestion Exposure (ConEx)}",
  howpublished="RFC 7837 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7837",
  pages="1--13",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7837.txt",
  key="RFC 7837",
  abstract={Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow.  This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.},
  keywords="Accountability, Traffic Management, Fairness, Resource Sharing, Congestion Control, Quality of Service, QoS, Denial of Service",
  doi="10.17487/RFC7837",
  }

@misc{rfc7838,
  author="M. Nottingham and P. McManus and J. Reschke",
  title="{HTTP Alternative Services}",
  howpublished="RFC 7838 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7838",
  pages="1--20",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7838.txt",
  key="RFC 7838",
  abstract={This document specifies ``Alternative Services'' for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.},
  keywords="HTTP, ALPN, Alternative Services",
  doi="10.17487/RFC7838",
  }

@misc{rfc7839,
  author="S. Bhandari and S. Gundavelli and M. Grayson and B. Volz and J. Korhonen",
  title="{Access-Network-Identifier Option in DHCP}",
  howpublished="RFC 7839 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7839",
  pages="1--20",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7839.txt",
  key="RFC 7839",
  abstract={This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.},
  keywords="Operator-Realm, Access-Network-Identifier, Access-Technology-Type, Access-Point, BSSID, Operator-Identifier, DHCPv4, DHCPv6, Local Mobility Anchor (LMA), Proxy Mobile IPv6 (PMIPv6), Service Set Identifier (SSID)",
  doi="10.17487/RFC7839",
  }

@misc{rfc7840,
  author="J. Winterbottom and H. Tschofenig and L. Liess",
  title="{A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol}",
  howpublished="RFC 7840 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7840",
  pages="1--16",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7840.txt",
  key="RFC 7840",
  abstract={For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information.  This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function.  Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.},
  keywords="Emergency, Call, Routing, Location, HELD",
  doi="10.17487/RFC7840",
  }

@misc{rfc7841,
  author="J. Halpern and L. Daigle and O. Kolkman",
  title="{RFC Streams, Headers, and Boilerplates}",
  howpublished="RFC 7841 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7841",
  pages="1--14",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7841.txt",
  key="RFC 7841",
  abstract={RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.  This document describes them and introduces some updates to reflect current usage and requirements of RFC publication.  In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.  This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.},
  doi="10.17487/RFC7841",
  }

@misc{rfc7842,
  author="R. Sparks",
  title="{Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool}",
  howpublished="RFC 7842 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7842",
  pages="1--7",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7842.txt",
  key="RFC 7842",
  abstract={The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014.  This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.},
  doi="10.17487/RFC7842",
  }

@misc{rfc7843,
  author="A. Ripke and R. Winter and T. Dietz and J. Quittek and R. da Silva",
  title="{Port Control Protocol (PCP) Third-Party ID Option}",
  howpublished="RFC 7843 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7843",
  pages="1--14",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7843.txt",
  key="RFC 7843",
  abstract={This document describes a new Port Control Protocol (PCP) option called the THIRD\_PARTY\_ID option. It is designed to be used together with the THIRD\_PARTY option specified in RFC 6887. The THIRD\_PARTY\_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD\_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.},
  keywords="PCP, option, third party, ID",
  doi="10.17487/RFC7843",
  }

@misc{rfc7844,
  author="C. Huitema and T. Mrugalski and S. Krishnan",
  title="{Anonymity Profiles for DHCP Clients}",
  howpublished="RFC 7844 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7844",
  pages="1--26",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7844.txt",
  key="RFC 7844",
  abstract={Some DHCP options carry unique identifiers.  These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses.  The anonymity profiles are designed for clients that wish to remain anonymous to the visited network.  The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.},
  keywords="DHCP, DHCPv4, DHCPv6, pervasive monitoring, fingerprinting, privacy, Anonymity, MAC Address Randomization, Privacy, Surveillance",
  doi="10.17487/RFC7844",
  }

@misc{rfc7845,
  author="T. Terriberry and R. Lee and R. Giles",
  title="{Ogg Encapsulation for the Opus Audio Codec}",
  howpublished="RFC 7845 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7845",
  pages="1--35",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7845.txt",
  key="RFC 7845",
  abstract={This document defines the Ogg encapsulation for the Opus interactive speech and audio codec.  This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.},
  keywords="container, mapping",
  doi="10.17487/RFC7845",
  }

@misc{rfc7846,
  author="R. Cruz and M. Nunes and J. Xia and R. Huang and J. Taveira and D. Lingli",
  title="{Peer-to-Peer Streaming Tracker Protocol (PPSTP)}",
  howpublished="RFC 7846 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7846",
  pages="1--55",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7846.txt",
  key="RFC 7846",
  abstract={This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers.  The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics.  The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.},
  keywords="structured media, peer swarms control, live streaming, video on demand",
  doi="10.17487/RFC7846",
  }

@misc{rfc7847,
  author="T. Melia and S. Gundavelli",
  title="{Logical-Interface Support for IP Hosts with Multi-Access Support}",
  howpublished="RFC 7847 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7847",
  pages="1--16",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7847.txt",
  key="RFC 7847",
  abstract={A logical interface is a software semantic internal to the host operating system.  This semantic is available in all popular operating systems and is used in various protocol implementations.  Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support.  This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks.  Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.},
  keywords="Logical-interface, virtual-interface, Logical interface",
  doi="10.17487/RFC7847",
  }

@misc{rfc7848,
  author="G. Lozano",
  title="{Mark and Signed Mark Objects Mapping}",
  howpublished="RFC 7848 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7848",
  pages="1--24",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7848.txt",
  key="RFC 7848",
  abstract={Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD). One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public. This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.},
  keywords="Trademark Clearinghouse, Signed Mark Data, Signed Mark, Mark, SMD",
  doi="10.17487/RFC7848",
  }

@misc{rfc7849,
  author="D. Binet and M. Boucadair and A. Vizdal and G. Chen and N. Heatley and R. Chandler and D. Michaud and D. Lopez and W. Haeffner",
  title="{An IPv6 Profile for 3GPP Mobile Devices}",
  howpublished="RFC 7849 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7849",
  pages="1--22",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7849.txt",
  key="RFC 7849",
  abstract={This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in ``IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts'' (RFC 7066). Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.},
  keywords="IPv4 service continuity, address shortage, address depletion, dual-stack, IPv6-only, IPv6 introduction, IPv6 transition, IPv6 migration, cellular networks, mobile networks, PLMN, and IPv6 configuration",
  doi="10.17487/RFC7849",
  }

@misc{rfc7850,
  author="S. Nandakumar",
  title="{Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles}",
  howpublished="RFC 7850 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7850",
  pages="1--7",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7850.txt",
  key="RFC 7850",
  abstract={The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods.  This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.},
  doi="10.17487/RFC7850",
  }

@misc{rfc7851,
  author="H. Song and X. Jiang and R. Even and D. Bryan and Y. Sun",
  title="{Peer-to-Peer (P2P) Overlay Diagnostics}",
  howpublished="RFC 7851 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7851",
  pages="1--30",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7851.txt",
  key="RFC 7851",
  abstract={This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics.  It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions.  Useful diagnostic information for connection and node status monitoring is also defined.  The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.},
  keywords="Real-time Applications and Infrastructure, P2PSIP Working Group, Diagnostics, P2P, P2PSIP",
  doi="10.17487/RFC7851",
  }

@misc{rfc7852,
  author="R. Gellens and B. Rosen and H. Tschofenig and R. Marshall and J. Winterbottom",
  title="{Additional Data Related to an Emergency Call}",
  howpublished="RFC 7852 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7852",
  pages="1--113",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7852.txt",
  key="RFC 7852",
  abstract={When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.},
  keywords="Additional Call Data, Emergency Services, Call Information",
  doi="10.17487/RFC7852",
  }

@misc{rfc7853,
  author="S. Martin and S. Tuecke and B. McCollam and M. Lidman",
  title="{A URN Namespace for Globus}",
  howpublished="RFC 7853 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7853",
  pages="1--7",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7853.txt",
  key="RFC 7853",
  abstract={This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.},
  doi="10.17487/RFC7853",
  }

@misc{rfc7854,
  author="J. Scudder and R. Fernando and S. Stuart",
  title="{BGP Monitoring Protocol (BMP)}",
  howpublished="RFC 7854 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7854",
  pages="1--27",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7854.txt",
  key="RFC 7854",
  abstract={This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions.  BMP is intended to provide a convenient interface for obtaining route views.  Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views.  The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.  BMP is not suitable for use as a routing protocol.},
  keywords="IDR, BGP, GROW, BMP",
  doi="10.17487/RFC7854",
  }

@misc{rfc7855,
  author="S. Previdi and C. Filsfils and B. Decraene and S. Litkowski and M. Horneffer and R. Shakir",
  title="{Source Packet Routing in Networking (SPRING) Problem Statement and Requirements}",
  howpublished="RFC 7855 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7855",
  pages="1--19",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7855.txt",
  key="RFC 7855",
  abstract={The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term ``source'' means ``the point at which the explicit route is imposed''; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.},
  doi="10.17487/RFC7855",
  }

@misc{rfc7856,
  author="Y. Cui and J. Dong and P. Wu and M. Xu and A. Yla-Jaaski",
  title="{Softwire Mesh Management Information Base (MIB)}",
  howpublished="RFC 7856 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7856",
  pages="1--18",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7856.txt",
  key="RFC 7856",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing a softwire mesh.},
  keywords="Management Information Base, MIB, SMIv2, mesh",
  doi="10.17487/RFC7856",
  }

@misc{rfc7857,
  author="R. Penno and S. Perreault and M. Boucadair and S. Sivakumar and K. Naito",
  title="{Updates to Network Address Translation (NAT) Behavioral Requirements}",
  howpublished="RFC 7857 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7857",
  pages="1--14",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7857.txt",
  key="RFC 7857",
  abstract={This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44). This document updates RFCs 4787, 5382, and 5508.},
  keywords="address sharing, IPv4 service continuity, Carrier Grade NAT, CGN, LSN, NAT traversal, RFC4787, RFC5382, RFC5508, DS-Lite, NAT64, Address depletion",
  doi="10.17487/RFC7857",
  }

@misc{rfc7858,
  author="Z. Hu and L. Zhu and J. Heidemann and A. Mankin and D. Wessels and P. Hoffman",
  title="{Specification for DNS over Transport Layer Security (TLS)}",
  howpublished="RFC 7858 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7858",
  pages="1--19",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7858.txt",
  key="RFC 7858",
  abstract={This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.},
  keywords="DNS encryption, DNS privacy",
  doi="10.17487/RFC7858",
  }

@misc{rfc7859,
  author="C. Dearlove",
  title="{Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols}",
  howpublished="RFC 7859 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7859",
  pages="1--17",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7859.txt",
  key="RFC 7859",
  abstract={This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444.  It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.},
  keywords="Mobile Ad hoc Networking (MANET), MANET, TLV, OLSRv2, integrity check value, ICV, ECCSI, elliptic curve, identity-based signature, IBS, identity-based encryption, IBE",
  doi="10.17487/RFC7859",
  }

@misc{rfc7860,
  author="J. Merkle and M. Lochter",
  title="{HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3}",
  howpublished="RFC 7860 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7860",
  pages="1--14",
  year=2016,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7860.txt",
  key="RFC 7860",
  abstract={This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.  It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified.},
  keywords="SNMP, USM, HMAC, SHA-2",
  doi="10.17487/RFC7860",
  }

@misc{rfc7861,
  author="A. Adamson and N. Williams",
  title="{Remote Procedure Call (RPC) Security Version 3}",
  howpublished="RFC 7861 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7861",
  pages="1--26",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7861.txt",
  key="RFC 7861",
  abstract={This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC\_GSS).  This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings.  This document updates RFC 5403.},
  keywords="RPCSEC\_GSS, ONC, RPC, GSS, GSS-API, NFS, authentication, privacy, confidentiality, encryption, mechanism, context",
  doi="10.17487/RFC7861",
  }

@misc{rfc7862,
  author="T. Haynes",
  title="{Network File System (NFS) Version 4 Minor Version 2 Protocol}",
  howpublished="RFC 7862 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7862",
  pages="1--104",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7862.txt",
  key="RFC 7862",
  abstract={This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.  Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.},
  keywords="NFSv4.2, pNFS, Server-Side Copy, Server-Side Clone, Labeled NFS",
  doi="10.17487/RFC7862",
  }

@misc{rfc7863,
  author="T. Haynes",
  title="{Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description}",
  howpublished="RFC 7863 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7863",
  pages="1--87",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7863.txt",
  key="RFC 7863",
  abstract={This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.},
  keywords="NFSv4.2, XDR",
  doi="10.17487/RFC7863",
  }

@misc{rfc7864,
  author="CJ. Bernardos",
  title="{Proxy Mobile IPv6 Extensions to Support Flow Mobility}",
  howpublished="RFC 7864 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7864",
  pages="1--19",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7864.txt",
  key="RFC 7864",
  abstract={Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces. This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.},
  keywords="flow mobility, NB-IFOM, PMIPv6, FMI, FMA",
  doi="10.17487/RFC7864",
  }

@misc{rfc7865,
  author="R. Ravindranath and P. Ravindran and P. Kyzivat",
  title="{Session Initiation Protocol (SIP) Recording Metadata}",
  howpublished="RFC 7865 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7865",
  pages="1--34",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7865.txt",
  key="RFC 7865",
  abstract={Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.  The recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.},
  doi="10.17487/RFC7865",
  }

@misc{rfc7866,
  author="L. Portman and H. Lum and C. Eckel and A. Johnston and A. Hutton",
  title="{Session Recording Protocol}",
  howpublished="RFC 7866 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7866",
  pages="1--45",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7866.txt",
  key="RFC 7866",
  abstract={This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device.  The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device.  This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording.  Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document.  In addition, lawful intercept is outside the scope of this document.},
  keywords="siprec",
  doi="10.17487/RFC7866",
  }

@misc{rfc7867,
  author="R. Huang",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications}",
  howpublished="RFC 7867 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7867",
  pages="1--16",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7867.txt",
  key="RFC 7867",
  abstract={This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.},
  doi="10.17487/RFC7867",
  }

@misc{rfc7868,
  author="D. Savage and J. Ng and S. Moore and D. Slice and P. Paluch and R. White",
  title="{Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)}",
  howpublished="RFC 7868 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7868",
  pages="1--80",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7868.txt",
  key="RFC 7868",
  abstract={This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP).  EIGRP is a routing protocol based on Distance Vector technology.  The specific algorithm used is called ``DUAL'', a Diffusing Update Algorithm as referenced in ``Loop-Free Routing Using Diffusing Computations'' (Garcia-Luna-Aceves 1993).  The algorithm and procedures were researched, developed, and simulated by SRI International.},
  doi="10.17487/RFC7868",
  }

@misc{rfc7869,
  author="D. Warden and I. Iordanov",
  title="{The ``vnc'' URI Scheme}",
  howpublished="RFC 7869 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7869",
  pages="1--25",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7869.txt",
  key="RFC 7869",
  abstract={Virtual Network Computing (VNC) software provides remote desktop functionality.  This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications.  The scheme specifies parameters useful in securely connecting clients with remote hosts.},
  keywords="RFB, Remote Framebuffer, Virtual Network Computing",
  doi="10.17487/RFC7869",
  }

@misc{rfc7870,
  author="Y. Fu and S. Jiang and J. Dong and Y. Chen",
  title="{Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)}",
  howpublished="RFC 7870 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7870",
  pages="1--27",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7870.txt",
  key="RFC 7870",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).},
  keywords="IPv6",
  doi="10.17487/RFC7870",
  }

@misc{rfc7871,
  author="C. Contavalli and W. van der Gaast and D. Lawrence and W. Kumari",
  title="{Client Subnet in DNS Queries}",
  howpublished="RFC 7871 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7871",
  pages="1--30",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7871.txt",
  key="RFC 7871",
  abstract={This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached.  Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.},
  keywords="edns-client-subnet, ECS, DNS geolocation, DNS load-balancing, EDNS, EDNS0, geolocation, privacy",
  doi="10.17487/RFC7871",
  }

@misc{rfc7872,
  author="F. Gont and J. Linkova and T. Chown and W. Liu",
  title="{Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World}",
  howpublished="RFC 7872 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7872",
  pages="1--15",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7872.txt",
  key="RFC 7872",
  abstract={This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs.  The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time.  This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.},
  keywords="packet drops",
  doi="10.17487/RFC7872",
  }

@misc{rfc7873,
  author="D. {Eastlake 3rd} and M. Andrews",
  title="{Domain Name System (DNS) Cookies}",
  howpublished="RFC 7873 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7873",
  pages="1--25",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7873.txt",
  key="RFC 7873",
  abstract={DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers.  DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)},
  keywords="denial of service, forgery, cache poisoning, off-path",
  doi="10.17487/RFC7873",
  }

@misc{rfc7874,
  author="JM. Valin and C. Bran",
  title="{WebRTC Audio Codec and Processing Requirements}",
  howpublished="RFC 7874 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7874",
  pages="1--7",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7874.txt",
  key="RFC 7874",
  abstract={This document outlines the audio codec and processing requirements for WebRTC endpoints.},
  doi="10.17487/RFC7874",
  }

@misc{rfc7875,
  author="S. Proust",
  title="{Additional WebRTC Audio Codecs for Interoperability}",
  howpublished="RFC 7875 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7875",
  pages="1--12",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7875.txt",
  key="RFC 7875",
  abstract={To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.},
  keywords="WebRTC, audio, codec, G.722, AMR, AMR-WB",
  doi="10.17487/RFC7875",
  }

@misc{rfc7876,
  author="S. Bryant and S. Sivabalan and S. Soni",
  title="{UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks}",
  howpublished="RFC 7876 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7876",
  pages="1--10",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7876.txt",
  key="RFC 7876",
  abstract={RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM).  This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.},
  keywords="MPLS",
  doi="10.17487/RFC7876",
  }

@misc{rfc7877,
  author="K. Cartwright and V. Bhatia and S. Ali and D. Schwartz",
  title="{Session Peering Provisioning Framework (SPPF)}",
  howpublished="RFC 7877 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7877",
  pages="1--57",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7877.txt",
  key="RFC 7877",
  abstract={This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores.  The framework is called the ``Session Peering Provisioning Framework'' (SPPF).  The provisioned data is typically used by network elements for session establishment.},
  keywords="SPPP, SIP, Peering, SED, Provisioning",
  doi="10.17487/RFC7877",
  }

@misc{rfc7878,
  author="K. Cartwright and V. Bhatia and J-F. Mule and A. Mayrhofer",
  title="{Session Peering Provisioning (SPP) Protocol over SOAP}",
  howpublished="RFC 7878 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7878",
  pages="1--83",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7878.txt",
  key="RFC 7878",
  abstract={The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores.  To utilize this framework, one needs a substrate protocol.  Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF.  The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an \\%SPPF- based protocol.},
  keywords="SPPP, SIP, Peering, SED, Provisioning",
  doi="10.17487/RFC7878",
  }

@misc{rfc7879,
  author="R. Ravindranath and T. Reddy and G. Salgueiro and V. Pascual and P. Ravindran",
  title="{DTLS-SRTP Handling in SIP Back-to-Back User Agents}",
  howpublished="RFC 7879 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7879",
  pages="1--13",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7879.txt",
  key="RFC 7879",
  abstract={Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints.  This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.},
  keywords="Session Initiation Protocol, B2BUA, Secure Real-time Transport, Datagram Transport Layer Security",
  doi="10.17487/RFC7879",
  }

@misc{rfc7880,
  author="C. Pignataro and D. Ward and N. Akiya and M. Bhatia and S. Pallagatti",
  title="{Seamless Bidirectional Forwarding Detection (S-BFD)}",
  howpublished="RFC 7880 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7880",
  pages="1--24",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7880.txt",
  key="RFC 7880",
  abstract={This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. This document updates RFC 5880.},
  keywords="BFD, seamless BFD, negotiation free, segment routing, IP",
  doi="10.17487/RFC7880",
  }

@misc{rfc7881,
  author="C. Pignataro and D. Ward and N. Akiya",
  title="{Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS}",
  howpublished="RFC 7881 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7881",
  pages="1--8",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7881.txt",
  key="RFC 7881",
  abstract={This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.},
  keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP",
  doi="10.17487/RFC7881",
  }

@misc{rfc7882,
  author="S. Aldrin and C. Pignataro and G. Mirsky and N. Kumar",
  title="{Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases}",
  howpublished="RFC 7882 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7882",
  pages="1--15",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7882.txt",
  key="RFC 7882",
  abstract={This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures. These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.},
  keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP",
  doi="10.17487/RFC7882",
  }

@misc{rfc7883,
  author="L. Ginsberg and N. Akiya and M. Chen",
  title="{Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS}",
  howpublished="RFC 7883 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7883",
  pages="1--5",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7883.txt",
  key="RFC 7883",
  abstract={This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.},
  doi="10.17487/RFC7883",
  }

@misc{rfc7884,
  author="C. Pignataro and M. Bhatia and S. Aldrin and T. Ranganath",
  title="{OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators}",
  howpublished="RFC 7884 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7884",
  pages="1--7",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7884.txt",
  key="RFC 7884",
  abstract={This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier.  This mechanism is applicable to both OSPFv2 and OSPFv3.},
  keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP",
  doi="10.17487/RFC7884",
  }

@misc{rfc7885,
  author="V. Govindan and C. Pignataro",
  title="{Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)}",
  howpublished="RFC 7885 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7885",
  pages="1--11",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7885.txt",
  key="RFC 7885",
  abstract={This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV). This document updates RFC 5885 by extending the CV Type values and the capability selection.},
  keywords="RFC5885, L2TPv3, VCCV, S-BFD",
  doi="10.17487/RFC7885",
  }

@misc{rfc7886,
  author="V. Govindan and C. Pignataro",
  title="{Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)}",
  howpublished="RFC 7886 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7886",
  pages="1--6",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7886.txt",
  key="RFC 7886",
  abstract={This document defines a new Attribute-Value Pair (AVP) that allows L2TP Control Connection Endpoints (LCCEs) to advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).},
  keywords="S-BFD",
  doi="10.17487/RFC7886",
  }

@misc{rfc7887,
  author="S. Venaas and J. Arango and I. Kouvelas",
  title="{Hierarchical Join/Prune Attributes}",
  howpublished="RFC 7887 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7887",
  pages="1--8",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7887.txt",
  key="RFC 7887",
  abstract={This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message.  This document updates RFC 5384 by renaming the encoding type registry specified there.},
  keywords="multicast, pim",
  doi="10.17487/RFC7887",
  }

@misc{rfc7888,
  author="A. Melnikov",
  title="{IMAP4 Non-synchronizing Literals}",
  howpublished="RFC 7888 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7888",
  pages="1--9",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7888.txt",
  key="RFC 7888",
  abstract={The Internet Message Access Protocol (RFC 3501) contains the ``literal'' syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip. This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less. This document obsoletes RFC 2088.},
  keywords="IMAP, LITERAL+, LITERAL-, APPENDLIMIT",
  doi="10.17487/RFC7888",
  }

@misc{rfc7889,
  author="J. SrimushnamBoovaraghamoorthy and N. Bisht",
  title="{The IMAP APPENDLIMIT Extension}",
  howpublished="RFC 7889 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7889",
  pages="1--7",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7889.txt",
  key="RFC 7889",
  abstract={This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.},
  doi="10.17487/RFC7889",
  }

@misc{rfc7890,
  author="D. Bryan and P. Matthews and E. Shim and D. Willis and S. Dawkins",
  title="{Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)}",
  howpublished="RFC 7890 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7890",
  pages="1--19",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7890.txt",
  key="RFC 7890",
  abstract={This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism.  These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties.  This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.},
  keywords="Distributed Database, P2PSIP, SIP, Server-less, DHT",
  doi="10.17487/RFC7890",
  }

@misc{rfc7891,
  author="J. Asghar and IJ. Wijnands and S. Krishnaswamy and A. Karan and V. Arya",
  title="{Explicit Reverse Path Forwarding (RPF) Vector}",
  howpublished="RFC 7891 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7891",
  pages="1--9",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7891.txt",
  key="RFC 7891",
  abstract={The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree. This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.},
  keywords="Path diversity, MoFRR, Maximally redundant paths",
  doi="10.17487/RFC7891",
  }

@misc{rfc7892,
  author="Z. Ali and A. Bonfanti and M. Hartley and F. Zhang",
  title="{IANA Allocation Procedures for the GMPLS OTN Signal Type Registry}",
  howpublished="RFC 7892 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7892",
  pages="1--4",
  year=2016,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7892.txt",
  key="RFC 7892",
  abstract={IANA defined the ``OTN Signal Type'' subregistry of the ``Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters'' registry in RFC 7139.  This document updates the ``OTN Signal Type'' subregistry to allow registration via Specification Required.},
  doi="10.17487/RFC7892",
  }

@misc{rfc7893,
  author="Y(J) Stein and D. Black and B. Briscoe",
  title="{Pseudowire Congestion Considerations}",
  howpublished="RFC 7893 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7893",
  pages="1--27",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7893.txt",
  key="RFC 7893",
  abstract={Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows.  Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion.  We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms.  For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow.  For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound.  Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow.  If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.},
  keywords="pseudowire, congestion, TCP friendliness",
  doi="10.17487/RFC7893",
  }

@misc{rfc7894,
  author="M. Pritikin and C. Wallace",
  title="{Alternative Challenge Password Attributes for Enrollment over Secure Transport}",
  howpublished="RFC 7894 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7894",
  pages="1--10",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7894.txt",
  key="RFC 7894",
  abstract={This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol.  These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in ``PKCS \#9: Selected Object Classes and Attribute Types Version 2.0'' (RFC 2985).  Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.},
  keywords="Enrollment over Secure Transport",
  doi="10.17487/RFC7894",
  }

@misc{rfc7895,
  author="A. Bierman and M. Bjorklund and K. Watsen",
  title="{YANG Module Library}",
  howpublished="RFC 7895 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7895",
  pages="1--13",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7895.txt",
  key="RFC 7895",
  abstract={This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server).  Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.},
  keywords="NETCONF, RESTCONF",
  doi="10.17487/RFC7895",
  }

@misc{rfc7896,
  author="D. Dhody",
  title="{Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)}",
  howpublished="RFC 7896 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7896",
  pages="1--5",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7896.txt",
  key="RFC 7896",
  abstract={The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit. This document updates RFC 5440 regarding the IRO specification.},
  keywords="PCEP, PCE, IRO",
  doi="10.17487/RFC7896",
  }

@misc{rfc7897,
  author="D. Dhody and U. Palle and R. Casellas",
  title="{Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)}",
  howpublished="RFC 7897 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7897",
  pages="1--35",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7897.txt",
  key="RFC 7897",
  abstract={The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement.  In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS).  This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains.  This document also defines new subobjects to be used to encode domain identifiers.},
  keywords="PCEP, PCE, domain, subobjects",
  doi="10.17487/RFC7897",
  }

@misc{rfc7898,
  author="D. Dhody and U. Palle and V. Kondreddy and R. Casellas",
  title="{Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)}",
  howpublished="RFC 7898 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7898",
  pages="1--18",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7898.txt",
  key="RFC 7898",
  abstract={The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.},
  keywords="RSVP-TE, domain, subobjects",
  doi="10.17487/RFC7898",
  }

@misc{rfc7899,
  author="T. Morin and S. Litkowski and K. Patel and Z. Zhang and R. Kebler and J. Haas",
  title="{Multicast VPN State Damping}",
  howpublished="RFC 7899 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7899",
  pages="1--18",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7899.txt",
  key="RFC 7899",
  abstract={This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites.  The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure.  The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.},
  keywords="dampening, multicast, vpn, damping, bgp, pim",
  doi="10.17487/RFC7899",
  }

@misc{rfc7900,
  author="Y. Rekhter and E. Rosen and R. Aggarwal and Y. Cai and T. Morin",
  title="{Extranet Multicast in BGP/IP MPLS VPNs}",
  howpublished="RFC 7900 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7900",
  pages="1--65",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7900.txt",
  key="RFC 7900",
  abstract={Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network).  However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN.  This is known as a ``Multicast VPN (MVPN) extranet''.  This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.},
  keywords="Multicast",
  doi="10.17487/RFC7900",
  }

@misc{rfc7901,
  author="P. Wouters",
  title="{CHAIN Query Requests in DNS}",
  howpublished="RFC 7901 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7901",
  pages="1--16",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7901.txt",
  key="RFC 7901",
  abstract={This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer.  The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once.  This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.},
  keywords="DNSSEC, EDNS0, latency",
  doi="10.17487/RFC7901",
  }

@misc{rfc7902,
  author="E. Rosen and T. Morin",
  title="{Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags}",
  howpublished="RFC 7902 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7902",
  pages="1--7",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7902.txt",
  key="RFC 7902",
  abstract={The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the ``P-Multicast Service Interface (PMSI) Tunnel'' attribute.  The attribute contains a one-octet ``Flags'' field.  The purpose of this document is to establish an IANA registry for the assignment of the bits in this field.  Since the ``Flags'' field contains only eight bits, this document also defines a new BGP Extended Community, ``Additional PMSI Tunnel Attribute Flags'', that can be used to carry additional flags for the ``P-Multicast Service Interface (PMSI) Tunnel'' attribute.  This document updates RFC 6514.},
  doi="10.17487/RFC7902",
  }

@misc{rfc7903,
  author="S. Leonard",
  title="{Windows Image Media Types}",
  howpublished="RFC 7903 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7903",
  pages="1--12",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7903.txt",
  key="RFC 7903",
  abstract={This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats.  Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.},
  doi="10.17487/RFC7903",
  }

@misc{rfc7904,
  author="C. Jennings and B. Lowekamp and E. Rescorla and S. Baset and H. Schulzrinne and T. Schmidt",
  title="{A SIP Usage for REsource LOcation And Discovery (RELOAD)}",
  howpublished="RFC 7904 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7904",
  pages="1--20",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7904.txt",
  key="RFC 7904",
  abstract={This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD).  The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay.  It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay.  After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.},
  keywords="p2psip, p2p, sip, reload, peer-to-peer, session initiation, distributed session management, overlay network, SIP registrar",
  doi="10.17487/RFC7904",
  }

@misc{rfc7905,
  author="A. Langley and W. Chang and N. Mavrogiannopoulos and J. Strombergson and S. Josefsson",
  title="{ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)}",
  howpublished="RFC 7905 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7905",
  pages="1--8",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7905.txt",
  key="RFC 7905",
  abstract={This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. This document updates RFCs 5246 and 6347.},
  keywords="AEAD, DTLS",
  doi="10.17487/RFC7905",
  }

@misc{rfc7906,
  author="P. Timmel and R. Housley and S. Turner",
  title="{NSA's Cryptographic Message Syntax (CMS) Key Management Attributes}",
  howpublished="RFC 7906 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7906",
  pages="1--68",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7906.txt",
  key="RFC 7906",
  abstract={This document defines key management attributes used by the National Security Agency (NSA).  The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages.  Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.},
  doi="10.17487/RFC7906",
  }

@misc{rfc7908,
  author="K. Sriram and D. Montgomery and D. McPherson and E. Osterweil and B. Dickson",
  title="{Problem Definition and Classification of BGP Route Leaks}",
  howpublished="RFC 7908 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7908",
  pages="1--11",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7908.txt",
  key="RFC 7908",
  abstract={A systemic vulnerability of the Border Gateway Protocol routing system, known as ``route leaks'', has received significant attention in recent years.  Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking.  This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention.  Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet.  The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.},
  keywords="BGP, BGPSEC, Route Leak, Route Leak Detection, Route Leak Mitigation, BGP Security",
  doi="10.17487/RFC7908",
  }

@misc{rfc7909,
  author="R. Kisteleki and B. Haberman",
  title="{Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures}",
  howpublished="RFC 7909 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7909",
  pages="1--14",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7909.txt",
  key="RFC 7909",
  abstract={This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures.  This allows relying parties to detect accidental or malicious modifications of such objects.  It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects.  This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.},
  doi="10.17487/RFC7909",
  }

@misc{rfc7910,
  author="W. Zhou",
  title="{Interoperability between the Virtual Router Redundancy Protocol and PIM}",
  howpublished="RFC 7910 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7910",
  pages="1--6",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7910.txt",
  key="RFC 7910",
  abstract={This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP).  It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled.  The mechanism described in this document is based on Cisco IOS software implementation.},
  doi="10.17487/RFC7910",
  }

@misc{rfc7911,
  author="D. Walton and A. Retana and E. Chen and J. Scudder",
  title="{Advertisement of Multiple Paths in BGP}",
  howpublished="RFC 7911 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7911",
  pages="1--8",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7911.txt",
  key="RFC 7911",
  abstract={This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones.  The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.},
  keywords="border gateway protocol",
  doi="10.17487/RFC7911",
  }

@misc{rfc7912,
  author="A. Melnikov",
  title="{Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure}",
  howpublished="RFC 7912 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7912",
  pages="1--11",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7912.txt",
  key="RFC 7912",
  abstract={This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field.  The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.},
  keywords="MMHS, S/MIME, MIXER, email",
  doi="10.17487/RFC7912",
  }

@misc{rfc7913,
  author="C. Holmberg",
  title="{P-Access-Network-Info ABNF Update}",
  howpublished="RFC 7913 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7913",
  pages="1--4",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7913.txt",
  key="RFC 7913",
  abstract={This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'.  The values are defined in the ABNF but are not included in the list.},
  keywords="Transport, PANI, ABNF, P-Access-Network-Info, 3GPP, IMS",
  doi="10.17487/RFC7913",
  }

@misc{rfc7914,
  author="C. Percival and S. Josefsson",
  title="{The scrypt Password-Based Key Derivation Function}",
  howpublished="RFC 7914 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7914",
  pages="1--16",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7914.txt",
  key="RFC 7914",
  abstract={This document specifies the password-based key derivation function scrypt.  The function derives one or more secret keys from a secret string.  It is based on memory-hard functions, which offer added protection against attacks using custom hardware.  The document also provides an ASN.1 schema.},
  keywords="PBKDF",
  doi="10.17487/RFC7914",
  }

@misc{rfc7915,
  author="C. Bao and X. Li and F. Baker and T. Anderson and F. Gont",
  title="{IP/ICMP Translation Algorithm}",
  howpublished="RFC 7915 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7915",
  pages="1--34",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7915.txt",
  key="RFC 7915",
  abstract={This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers).  This document obsoletes RFC 6145.},
  keywords="SIIT, internet, protocol, control, message, IPv4, IPv6, Stateless IP/ICMP Translation Algorithm, RFC6145bis",
  doi="10.17487/RFC7915",
  }

@misc{rfc7916,
  author="S. Litkowski and B. Decraene and C. Filsfils and K. Raza and M. Horneffer and P. Sarkar",
  title="{Operational Management of Loop-Free Alternates}",
  howpublished="RFC 7916 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7916",
  pages="1--31",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7916.txt",
  key="RFC 7916",
  abstract={Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote-LFA solutions.},
  keywords="IGP, LFA, policy, FRR, fast reroute, network planning",
  doi="10.17487/RFC7916",
  }

@misc{rfc7917,
  author="P. Sarkar and H. Gredler and S. Hegde and S. Litkowski and B. Decraene",
  title="{Advertising Node Administrative Tags in IS-IS}",
  howpublished="RFC 7917 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7917",
  pages="1--11",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7917.txt",
  key="RFC 7917",
  abstract={This document describes an extension to the IS-IS routing protocol to advertise node administrative tags.  This optional capability allows tagging and grouping of the nodes in an IS-IS domain.  The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability.  Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.},
  keywords="IGP, IS-IS, Admin-Tag, Traffic Engineering",
  doi="10.17487/RFC7917",
  }

@misc{rfc7918,
  author="A. Langley and N. Modadugu and B. Moeller",
  title="{Transport Layer Security (TLS) False Start}",
  howpublished="RFC 7918 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7918",
  pages="1--11",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7918.txt",
  key="RFC 7918",
  abstract={This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed ``False Start''.  It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally.  A TLS False Start reduces handshake latency to one round trip.},
  doi="10.17487/RFC7918",
  }

@misc{rfc7919,
  author="D. Gillmor",
  title="{Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)}",
  howpublished="RFC 7919 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7919",
  pages="1--29",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7919.txt",
  key="RFC 7919",
  abstract={Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS ``Supported Groups Registry'' (renamed from ``EC Named Curve Registry'' by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).},
  keywords="Diffie-Hellman, Discrete Logarithm, Finite Field, Transport Layer Security, TLS, Negotiation",
  doi="10.17487/RFC7919",
  }

@misc{rfc7920,
  author="A. Atlas and T. Nadeau and D. Ward",
  title="{Problem Statement for the Interface to the Routing System}",
  howpublished="RFC 7920 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7920",
  pages="1--12",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7920.txt",
  key="RFC 7920",
  abstract={Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems. This document proposes meeting this need via an Interface to the Routing System (I2RS).},
  doi="10.17487/RFC7920",
  }

@misc{rfc7921,
  author="A. Atlas and J. Halpern and S. Hares and D. Ward and T. Nadeau",
  title="{An Architecture for the Interface to the Routing System}",
  howpublished="RFC 7921 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7921",
  pages="1--40",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7921.txt",
  key="RFC 7921",
  abstract={This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system.  It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).},
  doi="10.17487/RFC7921",
  }

@misc{rfc7922,
  author="J. Clarke and G. Salgueiro and C. Pignataro",
  title="{Interface to the Routing System (I2RS) Traceability: Framework and Information Model}",
  howpublished="RFC 7922 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7922",
  pages="1--17",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7922.txt",
  key="RFC 7922",
  abstract={This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework.  It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol.  This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when.  It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.},
  keywords="I2RS, I2RS Traceability, I2RS Traceability",
  doi="10.17487/RFC7922",
  }

@misc{rfc7923,
  author="E. Voit and A. Clemm and A. Gonzalez Prieto",
  title="{Requirements for Subscription to YANG Datastores}",
  howpublished="RFC 7923 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7923",
  pages="1--18",
  year=2016,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7923.txt",
  key="RFC 7923",
  abstract={This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore.  Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients.  Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF).  Such a service can be summarized as a ``pub/sub'' service for YANG datastore updates.  Beyond a set of basic requirements for the service, various refinements are addressed.  These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.},
  keywords="pub/sub, push updates",
  doi="10.17487/RFC7923",
  }

@misc{rfc7924,
  author="S. Santesson and H. Tschofenig",
  title="{Transport Layer Security (TLS) Cached Information Extension}",
  howpublished="RFC 7924 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7924",
  pages="1--19",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7924.txt",
  key="RFC 7924",
  abstract={Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.},
  keywords="TLS Cached Information, TLS Cached Info, TLS Extension, TLS Optimization",
  doi="10.17487/RFC7924",
  }

@misc{rfc7925,
  author="H. Tschofenig and T. Fossati",
  title="{Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things}",
  howpublished="RFC 7925 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7925",
  pages="1--61",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7925.txt",
  key="RFC 7925",
  abstract={A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.},
  keywords="Internet of Things Security, TLS Profile, DTLS Profile, IoT Security, DTLS over SMS",
  doi="10.17487/RFC7925",
  }

@misc{rfc7926,
  author="A. Farrel and J. Drake and N. Bitar and G. Swallow and D. Ceccarelli and X. Zhang",
  title="{Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks}",
  howpublished="RFC 7926 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7926",
  pages="1--67",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7926.txt",
  key="RFC 7926",
  abstract={In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.},
  keywords="Abstract link, Abstract node, Abstraction, Abstraction layer, Aggregation, Virtual node, Virtual link",
  doi="10.17487/RFC7926",
  }

@misc{rfc7927,
  author="D. Kutscher and S. Eum and K. Pentikousis and I. Psaras and D. Corujo and D. Saucez and T. Schmidt and M. Waehlisch",
  title="{Information-Centric Networking (ICN) Research Challenges}",
  howpublished="RFC 7927 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7927",
  pages="1--38",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7927.txt",
  key="RFC 7927",
  abstract={This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).},
  keywords="Information centric networking",
  doi="10.17487/RFC7927",
  }

@misc{rfc7928,
  author="N. Kuhn and P. Natarajan and N. Khademi and D. Ros",
  title="{Characterization Guidelines for Active Queue Management (AQM)}",
  howpublished="RFC 7928 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7928",
  pages="1--37",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7928.txt",
  key="RFC 7928",
  abstract={Unmanaged large buffers in today's networks have given rise to a slew of performance issues.  These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing.  This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.},
  doi="10.17487/RFC7928",
  }

@misc{rfc7929,
  author="P. Wouters",
  title="{DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP}",
  howpublished="RFC 7929 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7929",
  pages="1--20",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7929.txt",
  key="RFC 7929",
  abstract={OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys.  DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS.  This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record.  Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the ``web of trust'' or manual verification.  The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.},
  keywords="opportunistic security, encrypted email",
  doi="10.17487/RFC7929",
  }

@misc{rfc7930,
  author="S. Hartman",
  title="{Larger Packets for RADIUS over TCP}",
  howpublished="RFC 7930 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7930",
  pages="1--10",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7930.txt",
  key="RFC 7930",
  abstract={The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic.  This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets.  This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information.  This document registers a new RADIUS code, an action that required IESG approval.},
  keywords="ABFAB",
  doi="10.17487/RFC7930",
  }

@misc{rfc7931,
  author="D. Noveck and P. Shivam and C. Lever and B. Baker",
  title="{NFSv4.0 Migration: Specification Update}",
  howpublished="RFC 7931 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7931",
  pages="1--55",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7931.txt",
  key="RFC 7931",
  abstract={The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients.  Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0.  This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.},
  doi="10.17487/RFC7931",
  }

@misc{rfc7932,
  author="J. Alakuijala and Z. Szabadka",
  title="{Brotli Compressed Data Format}",
  howpublished="RFC 7932 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7932",
  pages="1--128",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7932.txt",
  key="RFC 7932",
  abstract={This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.},
  doi="10.17487/RFC7932",
  }

@misc{rfc7933,
  author="C. Westphal and S. Lederer and D. Posch and C. Timmerer and A. Azgin and W. Liu and C. Mueller and A. Detti and D. Corujo and J. Wang and M. Montpetit and N. Murray",
  title="{Adaptive Video Streaming over Information-Centric Networking (ICN)}",
  howpublished="RFC 7933 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7933",
  pages="1--40",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7933.txt",
  key="RFC 7933",
  abstract={This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution.  As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms.  Several important topics related to video distribution over ICN are presented.  The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN.  Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.},
  keywords="ICN, CCN, NDN, DASH, adaptive video streaming, scalable video streaming, IPTV, P2P, DRM",
  doi="10.17487/RFC7933",
  }

@misc{rfc7934,
  author="L. Colitti and V. Cerf and S. Cheshire and D. Schinazi",
  title="{Host Address Availability Recommendations}",
  howpublished="RFC 7934 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7934",
  pages="1--15",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7934.txt",
  key="RFC 7934",
  abstract={This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.},
  keywords="IPv6, IPv4, SLAAC, DHCPv6, Prefix Delegation, NAT, NAT64, 464XLAT, /64, Address Assignment, Addressing",
  doi="10.17487/RFC7934",
  }

@misc{rfc7935,
  author="G. Huston and G. Michaelson",
  title="{The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure}",
  howpublished="RFC 7935 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7935",
  pages="1--9",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7935.txt",
  key="RFC 7935",
  abstract={This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.},
  doi="10.17487/RFC7935",
  }

@misc{rfc7936,
  author="T. Hardie",
  title="{Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry}",
  howpublished="RFC 7936 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7936",
  pages="1--3",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7936.txt",
  key="RFC 7936",
  abstract={This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.},
  doi="10.17487/RFC7936",
  }

@misc{rfc7937,
  author="F. Le Faucheur and G. Bertrand and I. Oprescu and R. Peterkofsky",
  title="{Content Distribution Network Interconnection (CDNI) Logging Interface}",
  howpublished="RFC 7937 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7937",
  pages="1--63",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7937.txt",
  key="RFC 7937",
  abstract={This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework.  First, it describes a reference model for CDNI logging.  Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.},
  keywords="CDNI, Logging, CDN, Interconnection",
  doi="10.17487/RFC7937",
  }

@misc{rfc7938,
  author="P. Lapukhov and A. Premji and J. Mitchell",
  title="{Use of BGP for Routing in Large-Scale Data Centers}",
  howpublished="RFC 7938 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7938",
  pages="1--35",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7938.txt",
  key="RFC 7938",
  abstract={Some network operators build and operate data centers that support over one hundred thousand servers.  In this document, such data centers are referred to as ``large-scale'' to differentiate them from smaller infrastructures.  Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability.  This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol.  The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.},
  keywords="BGP, ECMP,  Clos",
  doi="10.17487/RFC7938",
  }

@misc{rfc7939,
  author="U. Herberg and R. Cole and I. Chakeres and T. Clausen",
  title="{Definition of Managed Objects for the Neighborhood Discovery Protocol}",
  howpublished="RFC 7939 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7939",
  pages="1--72",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7939.txt",
  key="RFC 7939",
  abstract={This document replaces RFC 6779; it contains revisions and extensions to the original document.  It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router.  The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466.  The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP.  This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.},
  keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, Neighbor Discovery, MANET, NHDP-MIB",
  doi="10.17487/RFC7939",
  }

@misc{rfc7940,
  author="K. Davies and A. Freytag",
  title="{Representing Label Generation Rulesets Using XML}",
  howpublished="RFC 7940 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7940",
  pages="1--82",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7940.txt",
  key="RFC 7940",
  abstract={This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML).  These policies, known as ``Label Generation Rulesets'' (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example.  The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.},
  keywords="IDN, LGR, IDN table, variant table",
  doi="10.17487/RFC7940",
  }

@misc{rfc7941,
  author="M. Westerlund and B. Burman and R. Even and M. Zanaty",
  title="{RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items}",
  howpublished="RFC 7941 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7941",
  pages="1--17",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7941.txt",
  key="RFC 7941",
  abstract={Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP).  In some cases, it can be beneficial to speed up the delivery of these items.  The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items.  To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.},
  doi="10.17487/RFC7941",
  }

@misc{rfc7942,
  author="Y. Sheffer and A. Farrel",
  title="{Improving Awareness of Running Code: The Implementation Status Section}",
  howpublished="RFC 7942 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7942",
  pages="1--8",
  year=2016,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7942.txt",
  key="RFC 7942",
  abstract={This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.},
  doi="10.17487/RFC7942",
  }

@misc{rfc7943,
  author="F. Gont and W. Liu",
  title="{A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}",
  howpublished="RFC 7943 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7943",
  pages="1--10",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7943.txt",
  key="RFC 7943",
  abstract={This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients.  This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications.  The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.},
  keywords="security, privacy, resiliency, attack, scanning, tracking",
  doi="10.17487/RFC7943",
  }

@misc{rfc7944,
  author="S. Donovan",
  title="{Diameter Routing Message Priority}",
  howpublished="RFC 7944 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7944",
  pages="1--18",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7944.txt",
  key="RFC 7944",
  abstract={When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages.  This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions.  With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.},
  keywords="Diameter, Overload",
  doi="10.17487/RFC7944",
  }

@misc{rfc7945,
  author="K. Pentikousis and B. Ohlman and E. Davies and S. Spirou and G. Boggia",
  title="{Information-Centric Networking: Evaluation and Security Considerations}",
  howpublished="RFC 7945 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7945",
  pages="1--38",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7945.txt",
  key="RFC 7945",
  abstract={This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security.  It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.},
  doi="10.17487/RFC7945",
  }

@misc{rfc7946,
  author="H. Butler and M. Daly and A. Doyle and S. Gillies and S. Hagen and T. Schaub",
  title="{The GeoJSON Format}",
  howpublished="RFC 7946 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7946",
  pages="1--28",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7946.txt",
  key="RFC 7946",
  abstract={GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON).  It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents.  GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees.},
  keywords="JSON, Geospatial, JavaScript Object Notation",
  doi="10.17487/RFC7946",
  }

@misc{rfc7947,
  author="E. Jasinska and N. Hilliard and R. Raszuk and N. Bakker",
  title="{Internet Exchange BGP Route Server}",
  howpublished="RFC 7947 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7947",
  pages="1--12",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7947.txt",
  key="RFC 7947",
  abstract={This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs).  Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server.  Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.},
  keywords="IDR",
  doi="10.17487/RFC7947",
  }

@misc{rfc7948,
  author="N. Hilliard and E. Jasinska and R. Raszuk and N. Bakker",
  title="{Internet Exchange BGP Route Server Operations}",
  howpublished="RFC 7948 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7948",
  pages="1--15",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7948.txt",
  key="RFC 7948",
  abstract={The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP (EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs.},
  keywords="GROW",
  doi="10.17487/RFC7948",
  }

@misc{rfc7949,
  author="I. Chen and A. Lindem and R. Atkinson",
  title="{OSPFv3 over IPv4 for IPv6 Transition}",
  howpublished="RFC 7949 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7949",
  pages="1--11",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7949.txt",
  key="RFC 7949",
  abstract={This document defines a mechanism to use IPv4 to transport OSPFv3 packets.  Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain.  This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.},
  keywords="IPv4 transport, OSPFv3 transition",
  doi="10.17487/RFC7949",
  }

@misc{rfc7950,
  author="M. Bjorklund",
  title="{The YANG 1.1 Data Modeling Language}",
  howpublished="RFC 7950 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7950",
  pages="1--217",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7950.txt",
  key="RFC 7950",
  abstract={YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).},
  keywords="NETCONF, XML, data modeling",
  doi="10.17487/RFC7950",
  }

@misc{rfc7951,
  author="L. Lhotka",
  title="{JSON Encoding of Data Modeled with YANG}",
  howpublished="RFC 7951 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7951",
  pages="1--20",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7951.txt",
  key="RFC 7951",
  abstract={This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.},
  keywords="I-JSON, RESTCONF",
  doi="10.17487/RFC7951",
  }

@misc{rfc7952,
  author="L. Lhotka",
  title="{Defining and Using Metadata with YANG}",
  howpublished="RFC 7952 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7952",
  pages="1--21",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7952.txt",
  key="RFC 7952",
  abstract={This document defines a YANG extension that allows for defining metadata annotations in YANG modules.  The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.},
  keywords="metadata annotations, YANG extension",
  doi="10.17487/RFC7952",
  }

@misc{rfc7953,
  author="C. Daboo and M. Douglass",
  title="{Calendar Availability}",
  howpublished="RFC 7953 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7953",
  pages="1--24",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7953.txt",
  key="RFC 7953",
  abstract={This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed. This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.},
  keywords="availability, calendaring, free-busy, iCalendar, CalDAV",
  doi="10.17487/RFC7953",
  }

@misc{rfc7954,
  author="L. Iannone and D. Lewis and D. Meyer and V. Fuller",
  title="{Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block}",
  howpublished="RFC 7954 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7954",
  pages="1--12",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7954.txt",
  key="RFC 7954",
  abstract={This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP).  The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.},
  doi="10.17487/RFC7954",
  }

@misc{rfc7955,
  author="L. Iannone and R. Jorgensen and D. Conrad and G. Huston",
  title="{Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block}",
  howpublished="RFC 7955 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7955",
  pages="1--10",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7955.txt",
  key="RFC 7955",
  abstract={This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block.  The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.},
  doi="10.17487/RFC7955",
  }

@misc{rfc7956,
  author="W. Hao and Y. Li and A. Qu and M. Durrani and P. Sivamurugan",
  title="{Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway}",
  howpublished="RFC 7956 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7956",
  pages="1--28",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7956.txt",
  key="RFC 7956",
  abstract={The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues: 1. Sub-optimum forwarding paths for inter-subnet traffic. 2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus. 3. A traffic bottleneck at the gateway. This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.},
  keywords="tenant,  data center",
  doi="10.17487/RFC7956",
  }

@misc{rfc7957,
  author="B. Campbell and A. Cooper and B. Leiba",
  title="{DISPATCH-Style Working Groups and the SIP Change Process}",
  howpublished="RFC 7957 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7957",
  pages="1--6",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7957.txt",
  key="RFC 7957",
  abstract={RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area.  These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups.  This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes.  It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.},
  keywords="dispatch, RAI, ART, sip-change",
  doi="10.17487/RFC7957",
  }

@misc{rfc7958,
  author="J. Abley and J. Schlyter and G. Bailey and P. Hoffman",
  title="{DNSSEC Trust Anchor Publication for the Root Zone}",
  howpublished="RFC 7958 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7958",
  pages="1--14",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7958.txt",
  key="RFC 7958",
  abstract={The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.},
  keywords="DNS, ICANN, IANA, KSK",
  doi="10.17487/RFC7958",
  }

@misc{rfc7959,
  author="C. Bormann and Z. Shelby",
  title="{Block-Wise Transfers in the Constrained Application Protocol (CoAP)}",
  howpublished="RFC 7959 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7959",
  pages="1--37",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7959.txt",
  key="RFC 7959",
  abstract={The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of ``Block'' options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.},
  keywords="CoAP, Constrained Application Protocol, REST, Internet of Things, IoT, Smart Object, Embedded Internet, Constrained Node",
  doi="10.17487/RFC7959",
  }

@misc{rfc7960,
  author="F. Martin and E. Lear and T. Draegen. Ed. and E. Zwicky and K. Andersen",
  title="{Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows}",
  howpublished="RFC 7960 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7960",
  pages="1--27",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7960.txt",
  key="RFC 7960",
  abstract={Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting.  However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.  Collectively, these email flows are referred to as ``indirect email flows''.  This document describes these interoperability issues and presents possible methods for addressing them.},
  keywords="DMARC, SMTP, DKIM, SPF",
  doi="10.17487/RFC7960",
  }

@misc{rfc7961,
  author="D. {Eastlake 3rd} and L. Yizhou",
  title="{Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV}",
  howpublished="RFC 7961 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7961",
  pages="1--24",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7961.txt",
  key="RFC 7961",
  abstract={This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses.  Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable.  For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch.  Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.},
  keywords="reachability, AFN, template",
  doi="10.17487/RFC7961",
  }

@misc{rfc7962,
  author="J. Saldana and A. Arcia-Moret and B. Braem and E. Pietrosemoli and A. Sathiaseelan and M. Zennaro",
  title="{Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures}",
  howpublished="RFC 7962 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7962",
  pages="1--43",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7962.txt",
  key="RFC 7962",
  abstract={This document presents a taxonomy of a set of ``Alternative Network Deployments'' that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models. The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties. The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.},
  keywords="alternative network deployments, community networks, user-centric networks, Wireless Internet Service Providers, mainstream network, gaia, global access to the Internet for all",
  doi="10.17487/RFC7962",
  }

@misc{rfc7963,
  author="Z. Ali and A. Bonfanti and M. Hartley and F. Zhang",
  title="{RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs)}",
  howpublished="RFC 7963 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7963",
  pages="1--5",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7963.txt",
  key="RFC 7963",
  abstract={RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features.  However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2).  This document defines new Signal Types for these additional containers.},
  keywords="GMPLS",
  doi="10.17487/RFC7963",
  }

@misc{rfc7964,
  author="D. Walton and A. Retana and E. Chen and J. Scudder",
  title="{Solutions for BGP Persistent Route Oscillation}",
  howpublished="RFC 7964 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7964",
  pages="1--9",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7964.txt",
  key="RFC 7964",
  abstract={Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies.  This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.},
  keywords="BGP churn oscillation",
  doi="10.17487/RFC7964",
  }

@misc{rfc7965,
  author="M. Chen and W. Cao and A. Takacs and P. Pan",
  title="{LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels}",
  howpublished="RFC 7965 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7965",
  pages="1--16",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7965.txt",
  key="RFC 7965",
  abstract={Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes.  This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels.  The extension applies to both single-segment and multi-segment PWs.},
  doi="10.17487/RFC7965",
  }

@misc{rfc7966,
  author="H. Tschofenig and J. Korhonen and G. Zorn and K. Pillay",
  title="{Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements}",
  howpublished="RFC 7966 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7966",
  pages="1--11",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7966.txt",
  key="RFC 7966",
  abstract={This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).},
  keywords="Diameter, End-to-End Security",
  doi="10.17487/RFC7966",
  }

@misc{rfc7967,
  author="A. Bhattacharyya and S. Bandyopadhyay and A. Pal and T. Bose",
  title="{Constrained Application Protocol (CoAP) Option for No Server Response}",
  howpublished="RFC 7967 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7967",
  pages="1--18",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7967.txt",
  key="RFC 7967",
  abstract={There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating ``the result of the attempt to understand and satisfy the request'', per RFC 7252. This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.},
  keywords="No-Response",
  doi="10.17487/RFC7967",
  }

@misc{rfc7968,
  author="Y. Li and D. {Eastlake 3rd} and W. Hao and H. Chen and S. Chatterjee",
  title="{Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data}",
  howpublished="RFC 7968 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7968",
  pages="1--22",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7968.txt",
  key="RFC 7968",
  abstract={TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information. This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.},
  keywords="VLAN, fine-grained label, multicast",
  doi="10.17487/RFC7968",
  }

@misc{rfc7969,
  author="T. Lemon and T. Mrugalski",
  title="{Customizing DHCP Configuration on the Basis of Network Topology}",
  howpublished="RFC 7969 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7969",
  pages="1--20",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7969.txt",
  key="RFC 7969",
  abstract={DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications.  One aspect of this functionality is support for context-specific configuration information.  This memo describes some such features and explains their operation.},
  keywords="dhcpv4, dhcpv6, relay-agents (relay agents), multiple subnets, subnets, links, prefixes",
  doi="10.17487/RFC7969",
  }

@misc{rfc7970,
  author="R. Danyliw",
  title="{The Incident Object Description Exchange Format Version 2}",
  howpublished="RFC 7970 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7970",
  pages="1--172",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7970.txt",
  key="RFC 7970",
  abstract={The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning.  This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema.  This new information and data model obsoletes RFCs 5070 and 6685.},
  keywords="incident data format, incident report, cyber threat indicators, computer security incident, computer security incident response team, CSIRT, CERT, security data sharing, Computer Network Defense Service Provider, CNDSP, information sharing, automated information sharing, cyber indicators",
  doi="10.17487/RFC7970",
  }

@misc{rfc7971,
  author="M. Stiemerling and S. Kiesel and M. Scharf and H. Seidel and S. Previdi",
  title="{Application-Layer Traffic Optimization (ALTO) Deployment Considerations}",
  howpublished="RFC 7971 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7971",
  pages="1--77",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7971.txt",
  key="RFC 7971",
  abstract={Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts.  This includes, but is not limited to, peer-to-peer file sharing applications.  The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.  This memo discusses deployment-related issues of ALTO.  It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples.  The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.},
  doi="10.17487/RFC7971",
  }

@misc{rfc7972,
  author="P. Lemieux",
  title="{Entertainment Identifier Registry (EIDR) URN Namespace Definition}",
  howpublished="RFC 7972 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7972",
  pages="1--10",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7972.txt",
  key="RFC 7972",
  abstract={Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers. This document obsoletes RFC 7302.},
  keywords="EIDR, Entertainment Identifier Registry, and URN",
  doi="10.17487/RFC7972",
  }

@misc{rfc7973,
  author="R. Droms and P. Duffy",
  title="{Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation}",
  howpublished="RFC 7973 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7973",
  pages="1--5",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7973.txt",
  key="RFC 7973",
  abstract={When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram.  The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.},
  keywords="6lowpan, header compression, ethertype",
  doi="10.17487/RFC7973",
  }

@misc{rfc7974,
  author="B. Williams and M. Boucadair and D. Wing",
  title="{An Experimental TCP Option for Host Identification}",
  howpublished="RFC 7974 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="7974",
  pages="1--20",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7974.txt",
  key="RFC 7974",
  abstract={Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies.  Potential solutions for revealing a host identifier in shared address deployments have also been discussed.  This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.},
  keywords="Policy enforcement, Address sharing, NAT, Host reveal, Host-ID",
  doi="10.17487/RFC7974",
  }

@misc{rfc7975,
  author="B. Niven-Jenkins and R. van Brandenburg",
  title="{Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection}",
  howpublished="RFC 7975 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7975",
  pages="1--35",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7975.txt",
  key="RFC 7975",
  abstract={The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request.  This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.},
  keywords="HTTP, DNS",
  doi="10.17487/RFC7975",
  }

@misc{rfc7976,
  author="C. Holmberg and N. Biondic and G. Salgueiro",
  title="{Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses}",
  howpublished="RFC 7976 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7976",
  pages="1--8",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7976.txt",
  key="RFC 7976",
  abstract={The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as ``P-'' header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected ``P-'' header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.},
  keywords="P-, 3GPP, IMS",
  doi="10.17487/RFC7976",
  }

@misc{rfc7977,
  author="P. Dunkley and G. Llewellyn and V. Pascual and G. Salgueiro and R. Ravindranath",
  title="{The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)}",
  howpublished="RFC 7977 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7977",
  pages="1--28",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7977.txt",
  key="RFC 7977",
  abstract={The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser).  This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios.  This document normatively updates RFCs 4975 and 4976.},
  keywords="MSRP, WebSocket",
  doi="10.17487/RFC7977",
  }

@misc{rfc7978,
  author="D. {Eastlake 3rd} and M. Umair and Y. Li",
  title="{Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension}",
  howpublished="RFC 7978 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7978",
  pages="1--25",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7978.txt",
  key="RFC 7978",
  abstract={The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link.  This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages.  This document updates RFC 7178.},
  keywords="tunnel, encapsulation",
  doi="10.17487/RFC7978",
  }

@misc{rfc7979,
  author="E. Lear and R. Housley",
  title="{Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries}",
  howpublished="RFC 7979 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7979",
  pages="1--37",
  year=2016,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7979.txt",
  key="RFC 7979",
  abstract={The U.S.  National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions.  After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group.  That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters.  This document contains the IETF response to that solicitation for protocol parameters.  It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities.  A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.},
  doi="10.17487/RFC7979",
  }

@misc{rfc7980,
  author="M. Behringer and A. Retana and R. White and G. Huston",
  title="{A Framework for Defining Network Complexity}",
  howpublished="RFC 7980 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7980",
  pages="1--24",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7980.txt",
  key="RFC 7980",
  abstract={Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking. This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.},
  keywords="Complicated, Fragile, Self-organization, Trade-off, Technical Debt, Dependency",
  doi="10.17487/RFC7980",
  }

@misc{rfc7981,
  author="L. Ginsberg and S. Previdi and M. Chen",
  title="{IS-IS Extensions for Advertising Router Information}",
  howpublished="RFC 7981 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7981",
  pages="1--10",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7981.txt",
  key="RFC 7981",
  abstract={This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.  This document obsoletes RFC 4971.},
  doi="10.17487/RFC7981",
  }

@misc{rfc7982,
  author="P. Martinsen and T. Reddy and D. Wing and V. Singh",
  title="{Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)}",
  howpublished="RFC 7982 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7982",
  pages="1--10",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7982.txt",
  key="RFC 7982",
  abstract={A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.},
  doi="10.17487/RFC7982",
  }

@misc{rfc7983,
  author="M. Petit-Huguenin and G. Salgueiro",
  title="{Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 7983 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7983",
  pages="1--13",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7983.txt",
  key="RFC 7983",
  abstract={This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 (``SRTP Extension for DTLS''), which suffered from four issues described and fixed in this document. This document updates RFC 5764.},
  keywords="TLS, STUN, TURN, TLS, TURN Channel Numbers, STUN Methods, RFC 5764, SRTP-DTLS, ZRTP",
  doi="10.17487/RFC7983",
  }

@misc{rfc7984,
  author="O. Johansson and G. Salgueiro and V. Gurbani and D. Worley",
  title="{Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network}",
  howpublished="RFC 7984 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7984",
  pages="1--10",
  year=2016,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7984.txt",
  key="RFC 7984",
  abstract={RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures.  As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations.  This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying ``Happy Eyeballs'' principles to SIP.},
  keywords="A record, address family preference, AAAA record, DNS, getaddrinfo, Happy Eyeballs, IPv6 address selection, SIP, SRV record, dual-stack, IPv4, IPv6",
  doi="10.17487/RFC7984",
  }

@misc{rfc7985,
  author="J. Yi and T. Clausen and U. Herberg",
  title="{Security Threats to Simplified Multicast Forwarding (SMF)}",
  howpublished="RFC 7985 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7985",
  pages="1--15",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7985.txt",
  key="RFC 7985",
  abstract={This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).},
  keywords="MANET",
  doi="10.17487/RFC7985",
  }

@misc{rfc7986,
  author="C. Daboo",
  title="{New Properties for iCalendar}",
  howpublished="RFC 7986 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7986",
  pages="1--23",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7986.txt",
  key="RFC 7986",
  abstract={This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.},
  keywords="alarms, calendaring, iCalendar",
  doi="10.17487/RFC7986",
  }

@misc{rfc7987,
  author="L. Ginsberg and P. Wells and B. Decraene and T. Przygienda and H. Gredler",
  title="{IS-IS Minimum Remaining Lifetime}",
  howpublished="RFC 7987 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7987",
  pages="1--9",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7987.txt",
  key="RFC 7987",
  abstract={Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected.  In certain scenarios, this may cause or exacerbate flooding storms.  It is also a possible denial-of-service attack vector.  This document defines a backwards-compatible solution to this problem.},
  doi="10.17487/RFC7987",
  }

@misc{rfc7988,
  author="E. Rosen and K. Subramanian and Z. Zhang",
  title="{Ingress Replication Tunnels in Multicast VPN}",
  howpublished="RFC 7988 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7988",
  pages="1--23",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7988.txt",
  key="RFC 7988",
  abstract={RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers.  These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone.  One type of P2MP tree that may be used is known as an ``Ingress Replication (IR) tunnel''.  In an IR tunnel, a parent node need not be directly connected to its child nodes.  When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so.  Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node.  While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels.  This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.},
  doi="10.17487/RFC7988",
  }

@misc{rfc7989,
  author="P. Jones and G. Salgueiro and C. Pearce and P. Giralt",
  title="{End-to-End Session Identification in IP-Based Multimedia Communication Networks}",
  howpublished="RFC 7989 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7989",
  pages="1--45",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7989.txt",
  key="RFC 7989",
  abstract={This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP). This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document. This document obsoletes RFC 7329.},
  keywords="SIP, Session Initiation Protocol, troubleshooting, Session-ID, session identifier, H460.27, remote parameter, UUID",
  doi="10.17487/RFC7989",
  }

@misc{rfc7990,
  author="H. Flanagan",
  title="{RFC Format Framework}",
  howpublished="RFC 7990 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7990",
  pages="1--16",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7990.txt",
  key="RFC 7990",
  abstract={In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document.  With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs.  This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.},
  keywords="Format, xml2rfcv3, v3",
  doi="10.17487/RFC7990",
  }

@misc{rfc7991,
  author="P. Hoffman",
  title="{The ``xml2rfc'' Version 3 Vocabulary}",
  howpublished="RFC 7991 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7991",
  pages="1--151",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7991.txt",
  key="RFC 7991",
  abstract={This document defines the ``xml2rfc'' version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.  It is heavily derived from the version 2 vocabulary that is also under discussion.  This document obsoletes the v2 grammar described in RFC 7749.},
  keywords="v3, xml2rfcv3, format",
  doi="10.17487/RFC7991",
  }

@misc{rfc7992,
  author="J. Hildebrand and P. Hoffman",
  title="{HTML Format for RFCs}",
  howpublished="RFC 7992 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7992",
  pages="1--43",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7992.txt",
  key="RFC 7992",
  abstract={In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats.  This document defines the HTML format that will be rendered for an RFC or Internet-Draft.},
  keywords="html, css, v3, xml2rfcv3, format",
  doi="10.17487/RFC7992",
  }

@misc{rfc7993,
  author="H. Flanagan",
  title="{Cascading Style Sheets (CSS) Requirements for RFCs}",
  howpublished="RFC 7993 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7993",
  pages="1--14",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7993.txt",
  key="RFC 7993",
  abstract={The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series.  The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model.  This document describes the requirements for the default CSS used by the RFC Editor.  The class names are based on the classes defined in ``HTML for RFCs'' (RFC 7992).},
  keywords="v3, xml2rfcv3, format, html",
  doi="10.17487/RFC7993",
  }

@misc{rfc7994,
  author="H. Flanagan",
  title="{Requirements for Plain-Text RFCs}",
  howpublished="RFC 7994 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7994",
  pages="1--8",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7994.txt",
  key="RFC 7994",
  abstract={In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML.  The high-level requirements that informed this change were defined in RFC 6949, ``RFC Series Format Requirements and Future Development''.  Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML.  This document outlines the rendering requirements for the plain-text RFC publication format.  These requirements do not apply to plain-text RFCs published before the format transition.},
  keywords="RFC, ASCII, format, plain-text, plain text, xml2rfcv3, v3",
  doi="10.17487/RFC7994",
  }

@misc{rfc7995,
  author="T. Hansen and L. Masinter and M. Hardy",
  title="{PDF Format for RFCs}",
  howpublished="RFC 7995 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7995",
  pages="1--22",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7995.txt",
  key="RFC 7995",
  abstract={This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949.  It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.},
  keywords="Requests for Comment, xml2rfcv3, v3, format",
  doi="10.17487/RFC7995",
  }

@misc{rfc7996,
  author="N. Brownlee",
  title="{SVG Drawings for RFCs: SVG 1.2 RFC}",
  howpublished="RFC 7996 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7996",
  pages="1--53",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7996.txt",
  key="RFC 7996",
  abstract={This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.},
  keywords="RFC, v3, xml2rfcv3, format",
  doi="10.17487/RFC7996",
  }

@misc{rfc7997,
  author="H. Flanagan",
  title="{The Use of Non-ASCII Characters in RFCs}",
  howpublished="RFC 7997 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7997",
  pages="1--15",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7997.txt",
  key="RFC 7997",
  abstract={In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs. This document updates RFC 7322. Please view this document in PDF form to see the full text.},
  keywords="RFC Series, UTF-8, ASCII, format, non-ASCII, v3, xml2rfcv3",
  doi="10.17487/RFC7997",
  }

@misc{rfc7998,
  author="P. Hoffman and J. Hildebrand",
  title="{``xml2rfc'' Version 3 Preparation Tool Description}",
  howpublished="RFC 7998 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7998",
  pages="1--18",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7998.txt",
  key="RFC 7998",
  abstract={This document describes some aspects of the ``prep tool'' that is expected to be created when the new xml2rfc version 3 specification is deployed.},
  keywords="xml2rfcv3, v3, format",
  doi="10.17487/RFC7998",
  }

@misc{rfc7999,
  author="T. King and C. Dietzel and J. Snijders and G. Doering and G. Hankins",
  title="{BLACKHOLE Community}",
  howpublished="RFC 7999 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7999",
  pages="1--9",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7999.txt",
  key="RFC 7999",
  abstract={This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks.  This well-known advisory transitive BGP community named ``BLACKHOLE'' allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.},
  keywords="well-known, well known, RTBH, Remotely Triggered Blackholing",
  doi="10.17487/RFC7999",
  }

@misc{rfc8000,
  author="A. Adamson and N. Williams",
  title="{Requirements for NFSv4 Multi-Domain Namespace Deployment}",
  howpublished="RFC 8000 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8000",
  pages="1--17",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8000.txt",
  key="RFC 8000",
  abstract={This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains.  To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC\_GSS for user authentication.  In most instances, the server must also support identity-mapping services.},
  keywords="multi-domain, multi-domain-capable file system, Federated File System, FedFS",
  doi="10.17487/RFC8000",
  }

@misc{rfc8001,
  author="F. Zhang and O. Gonzalez de Dios and C. Margaria and M. Hartley and Z. Ali",
  title="{RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information}",
  howpublished="RFC 8001 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8001",
  pages="1--16",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8001.txt",
  key="RFC 8001",
  abstract={This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).},
  doi="10.17487/RFC8001",
  }

@misc{rfc8002,
  author="T. Heer and S. Varjonen",
  title="{Host Identity Protocol Certificates}",
  howpublished="RFC 8002 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8002",
  pages="1--13",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8002.txt",
  key="RFC 8002",
  abstract={The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter. This document updates RFC 7401 and obsoletes RFC 6253.},
  keywords="Hip Certificate Extension",
  doi="10.17487/RFC8002",
  }

@misc{rfc8003,
  author="J. Laganier and L. Eggert",
  title="{Host Identity Protocol (HIP) Registration Extension}",
  howpublished="RFC 8003 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8003",
  pages="1--16",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8003.txt",
  key="RFC 8003",
  abstract={This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.  This document obsoletes RFC 5203.},
  keywords="HIP, Host Identity Protocol, Host Identity Payload, Registration, register",
  doi="10.17487/RFC8003",
  }

@misc{rfc8004,
  author="J. Laganier and L. Eggert",
  title="{Host Identity Protocol (HIP) Rendezvous Extension}",
  howpublished="RFC 8004 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8004",
  pages="1--14",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8004.txt",
  key="RFC 8004",
  abstract={This document defines a rendezvous extension for the Host Identity Protocol (HIP).  The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers.  Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile.  This document obsoletes RFC 5204.},
  keywords="HIP, Host Identity Protocol, Host Identity Payload, Rendezvous, HIP nodes, HIP rendezvous server",
  doi="10.17487/RFC8004",
  }

@misc{rfc8005,
  author="J. Laganier",
  title="{Host Identity Protocol (HIP) Domain Name System (DNS) Extension}",
  howpublished="RFC 8005 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8005",
  pages="1--18",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8005.txt",
  key="RFC 8005",
  abstract={This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP).  This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs).  This document obsoletes RFC 5205.},
  keywords="HIP, Host Identity Protocol, Host Identity Payload, DNS, Domain Name System",
  doi="10.17487/RFC8005",
  }

@misc{rfc8006,
  author="B. Niven-Jenkins and R. Murray and M. Caulfield and K. Ma",
  title="{Content Delivery Network Interconnection (CDNI) Metadata}",
  howpublished="RFC 8006 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8006",
  pages="1--66",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8006.txt",
  key="RFC 8006",
  abstract={The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery.  The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN.  This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.},
  keywords="CDN, cascaded CDN, cascading CDNs, content acquisition, content delegation, request delegation, acquisition protocol, delivery restriction, delivery policy, policy enforcement, delivery protocol, content expiration, geo-fencing, geofencing, geo fencing, geo-blocking,  geoblocking, geo blocking, footprint, cache control",
  doi="10.17487/RFC8006",
  }

@misc{rfc8007,
  author="R. Murray and B. Niven-Jenkins",
  title="{Content Delivery Network Interconnection (CDNI) Control Interface / Triggers}",
  howpublished="RFC 8007 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8007",
  pages="1--49",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8007.txt",
  key="RFC 8007",
  abstract={This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf.  The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content.  The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.},
  keywords="CDN, pre-position, invalidate, purge",
  doi="10.17487/RFC8007",
  }

@misc{rfc8008,
  author="J. Seedorf and J. Peterson and S. Previdi and R. van Brandenburg and K. Ma",
  title="{Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics}",
  howpublished="RFC 8008 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8008",
  pages="1--31",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8008.txt",
  key="RFC 8008",
  abstract={This document captures the semantics of the ``Footprint and Capabilities Advertisement'' part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of ``Footprint'' and ``Capabilities'' in the CDNI context and what the ``Footprint \& Capabilities Advertisement interface (FCI)'' offers within CDNI.  The document also provides guidelines for the CDNI FCI protocol.  It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.},
  keywords="CDNI, CDN Interconnect, Request Routing",
  doi="10.17487/RFC8008",
  }

@misc{rfc8009,
  author="M. Jenkins and M. Peck and K. Burgin",
  title="{AES Encryption with HMAC-SHA2 for Kerberos 5}",
  howpublished="RFC 8009 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8009",
  pages="1--19",
  year=2016,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8009.txt",
  key="RFC 8009",
  abstract={This document specifies two encryption types and two corresponding checksum types for Kerberos 5.  The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.},
  doi="10.17487/RFC8009",
  }

@misc{rfc8010,
  author="M. Sweet and I. McDonald",
  title="{Internet Printing Protocol/1.1: Encoding and Transport}",
  howpublished="RFC 8010 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8010",
  pages="1--51",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8010.txt",
  key="RFC 8010",
  abstract={The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies.  This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called ``application/ipp''.  It also defines the rules for transporting a message body whose Content-Type is ``application/ipp'' over HTTP and/or HTTPS.  The IPP data model and operation semantics are described in ``Internet Printing Protocol/1.1: Model and Semantics'' (RFC 8011).},
  keywords="IPP, Printer, PWG, Printer Working Group",
  doi="10.17487/RFC8010",
  }

@misc{rfc8011,
  author="M. Sweet and I. McDonald",
  title="{Internet Printing Protocol/1.1: Model and Semantics}",
  howpublished="RFC 8011 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8011",
  pages="1--221",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8011.txt",
  key="RFC 8011",
  abstract={The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents. IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of Print Jobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers. Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in ``Internet Printing Protocol/1.1: Encoding and Transport'' (RFC 8010). This document obsoletes RFCs 2911, 3381, and 3382.},
  keywords="IPP, Printer, PWG, Printer Working Group",
  doi="10.17487/RFC8011",
  }

@misc{rfc8012,
  author="N. Akiya and G. Swallow and C. Pignataro and A. Malis and S. Aldrin",
  title="{Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)}",
  howpublished="RFC 8012 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8012",
  pages="1--23",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8012.txt",
  key="RFC 8012",
  abstract={Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load-balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based. This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.},
  keywords="MPLS, LSP Ping, and Entropy",
  doi="10.17487/RFC8012",
  }

@misc{rfc8013,
  author="D. Joachimpillai and J. Hadi Salim",
  title="{Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)}",
  howpublished="RFC 8013 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8013",
  pages="1--25",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8013.txt",
  key="RFC 8013",
  abstract={This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class.  The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification.  The document focuses on Ethernet transport.},
  keywords="ForCES, Inter-FE",
  doi="10.17487/RFC8013",
  }

@misc{rfc8014,
  author="D. Black and J. Hudson and L. Kreeger and M. Lasserre and T. Narten",
  title="{An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)}",
  howpublished="RFC 8014 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8014",
  pages="1--35",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8014.txt",
  key="RFC 8014",
  abstract={This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks.  The architecture is given at a high level, showing the major components of an overall system.  An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions.  It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components.  That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.},
  doi="10.17487/RFC8014",
  }

@misc{rfc8015,
  author="V. Singh and C. Perkins and A. Clark and R. Huang",
  title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics}",
  howpublished="RFC 8015 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8015",
  pages="1--15",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8015.txt",
  key="RFC 8015",
  abstract={This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.},
  keywords="XRBLOCK",
  doi="10.17487/RFC8015",
  }

@misc{rfc8016,
  author="T. Reddy and D. Wing and P. Patil and P. Martinsen",
  title="{Mobility with Traversal Using Relays around NAT (TURN)}",
  howpublished="RFC 8016 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8016",
  pages="1--13",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8016.txt",
  key="RFC 8016",
  abstract={It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address. This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.},
  keywords="IP Address Mobility, VoIP, ICE, STUN, RTP, TUNNEL",
  doi="10.17487/RFC8016",
  }

@misc{rfc8017,
  author="K. Moriarty and B. Kaliski and J. Jonsson and A. Rusch",
  title="{PKCS \#1: RSA Cryptography Specifications Version 2.2}",
  howpublished="RFC 8017 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8017",
  pages="1--78",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8017.txt",
  key="RFC 8017",
  abstract={This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS \#1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447.},
  keywords="RSA public-key cryptosystem, RSA signature scheme, RSA public key, RSA private key, PKCS \#1 v1.5, RSA-OAEP, RSA-PSS, Optimal Asymmetric Encryption Padding, Probabilistic Signature Scheme",
  doi="10.17487/RFC8017",
  }

@misc{rfc8018,
  author="K. Moriarty and B. Kaliski and A. Rusch",
  title="{PKCS \#5: Password-Based Cryptography Specification Version 2.1}",
  howpublished="RFC 8018 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8018",
  pages="1--40",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8018.txt",
  key="RFC 8018",
  abstract={This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS \#5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898.},
  keywords="password-based encryption, password-based key derivation, salt",
  doi="10.17487/RFC8018",
  }

@misc{rfc8019,
  author="Y. Nir and V. Smyslov",
  title="{Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks}",
  howpublished="RFC 8019 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8019",
  pages="1--32",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8019.txt",
  key="RFC 8019",
  abstract={This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks.  Additionally, the document introduces a new mechanism called ``Client Puzzles'' that helps accomplish this task.},
  keywords="puzzle, dos, ddos, bitcoin",
  doi="10.17487/RFC8019",
  }

@misc{rfc8020,
  author="S. Bortzmeyer and S. Huque",
  title="{NXDOMAIN: There Really Is Nothing Underneath}",
  howpublished="RFC 8020 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8020",
  pages="1--10",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8020.txt",
  key="RFC 8020",
  abstract={This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.},
  doi="10.17487/RFC8020",
  }

@misc{rfc8021,
  author="F. Gont and W. Liu and T. Anderson",
  title="{Generation of IPv6 Atomic Fragments Considered Harmful}",
  howpublished="RFC 8021 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8021",
  pages="1--12",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8021.txt",
  key="RFC 8021",
  abstract={This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments.  It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).},
  keywords="attack, DoS, Extension Headers",
  doi="10.17487/RFC8021",
  }

@misc{rfc8022,
  author="L. Lhotka and A. Lindem",
  title="{A YANG Data Model for Routing Management}",
  howpublished="RFC 8022 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8022",
  pages="1--64",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8022.txt",
  key="RFC 8022",
  abstract={This document contains a specification of three YANG modules and one submodule.  Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem.  It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions.  The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.},
  keywords="configuration, IPv6 router advertisements, NETCONF, RESTCONF",
  doi="10.17487/RFC8022",
  }

@misc{rfc8023,
  author="M. Thomas and A. Mankin and L. Zhang",
  title="{Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions}",
  howpublished="RFC 8023 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8023",
  pages="1--17",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8023.txt",
  key="RFC 8023",
  abstract={This document provides context and a report on the workshop on ``Root Causes and Mitigation of Name Collisions'', which took place in London, United Kingdom, from March 8 to 10, 2014.  The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions.  This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.},
  doi="10.17487/RFC8023",
  }

@misc{rfc8024,
  author="Y. Jiang and Y. Luo and E. Mallette and Y. Shen and W. Cheng",
  title="{Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS}",
  howpublished="RFC 8024 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8024",
  pages="1--16",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8024.txt",
  key="RFC 8024",
  abstract={Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes.  Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge.  Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services.  This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.},
  keywords="PON Protection",
  doi="10.17487/RFC8024",
  }

@misc{rfc8025,
  author="P. Thubert and R. Cragie",
  title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch}",
  howpublished="RFC 8025 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8025",
  pages="1--8",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8025.txt",
  key="RFC 8025",
  abstract={This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.},
  keywords="LNN, IOT",
  doi="10.17487/RFC8025",
  }

@misc{rfc8026,
  author="M. Boucadair and I. Farrer",
  title="{Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism}",
  howpublished="RFC 8026 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8026",
  pages="1--11",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8026.txt",
  key="RFC 8026",
  abstract={In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity.  A number of differing functional approaches have been developed for this, each having their own specific characteristics.  As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.},
  keywords="Provisioning, Softwire, IPv4 over IPv6, IPv4 service continuity, IPv4 address depletion, MAP, MAP-T, MAP-E, DS-Lite, Lightweight 4 over 6",
  doi="10.17487/RFC8026",
  }

@misc{rfc8027,
  author="W. Hardaker and O. Gudmundsson and S. Krishnaswamy",
  title="{DNSSEC Roadblock Avoidance}",
  howpublished="RFC 8027 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="8027",
  pages="1--19",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8027.txt",
  key="RFC 8027",
  abstract={This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure.  It outlines potential detection and mitigation techniques.  The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.},
  keywords="DNSSEC, Network Problems, DNS",
  doi="10.17487/RFC8027",
  }

@misc{rfc8028,
  author="F. Baker and B. Carpenter",
  title="{First-Hop Router Selection by Hosts in a Multi-Prefix Network}",
  howpublished="RFC 8028 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8028",
  pages="1--13",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8028.txt",
  key="RFC 8028",
  abstract={This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from.  It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters.  Host behavior in choosing a first-hop router may interact with source address selection in a given implementation.  However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen.  Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission.  It updates RFC 4861.},
  doi="10.17487/RFC8028",
  }

@misc{rfc8029,
  author="K. Kompella and G. Swallow and C. Pignataro and N. Kumar and S. Aldrin and M. Chen",
  title="{Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures}",
  howpublished="RFC 8029 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8029",
  pages="1--78",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8029.txt",
  key="RFC 8029",
  abstract={This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an ``MPLS echo request'' and a response message called an ``MPLS echo reply'' for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.},
  keywords="MPLS echo request, MPLS echo reply",
  doi="10.17487/RFC8029",
  }

@misc{rfc8030,
  author="M. Thomson and E. Damaggio and B. Raymor",
  title="{Generic Event Delivery Using HTTP Push}",
  howpublished="RFC 8030 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8030",
  pages="1--31",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8030.txt",
  key="RFC 8030",
  abstract={This document describes a simple protocol for the delivery of real- time events to user agents.  This scheme uses HTTP/2 server push.},
  keywords="HTTP, HTTP2, Push, WebPush",
  doi="10.17487/RFC8030",
  }

@misc{rfc8031,
  author="Y. Nir and S. Josefsson",
  title="{Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement}",
  howpublished="RFC 8031 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8031",
  pages="1--8",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8031.txt",
  key="RFC 8031",
  abstract={This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).},
  keywords="Curve25519, Curve448, Goldilocks, Diffie Hellman",
  doi="10.17487/RFC8031",
  }

@misc{rfc8032,
  author="S. Josefsson and I. Liusvaara",
  title="{Edwards-Curve Digital Signature Algorithm (EdDSA)}",
  howpublished="RFC 8032 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8032",
  pages="1--60",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8032.txt",
  key="RFC 8032",
  abstract={This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves.  An example implementation and test vectors are provided.},
  keywords="signature, digital signature, EdDSA",
  doi="10.17487/RFC8032",
  }

@misc{rfc8033,
  author="R. Pan and P. Natarajan and F. Baker and G. White",
  title="{Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem}",
  howpublished="RFC 8033 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8033",
  pages="1--30",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8033.txt",
  key="RFC 8033",
  abstract={Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users. This document presents a lightweight active queue management design called ``PIE'' (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.},
  keywords="active queue management, AQM",
  doi="10.17487/RFC8033",
  }

@misc{rfc8034,
  author="G. White and R. Pan",
  title="{Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems}",
  howpublished="RFC 8034 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8034",
  pages="1--17",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8034.txt",
  key="RFC 8034",
  abstract={Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide.  In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet.  As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience.  The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance.  In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements.  This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the ``DOCSIS-PIE'' algorithm that is required on DOCSIS 3.1 cable modems.},
  keywords="latency, access network, bufferbloat",
  doi="10.17487/RFC8034",
  }

@misc{rfc8035,
  author="C. Holmberg",
  title="{Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing}",
  howpublished="RFC 8035 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8035",
  pages="1--7",
  year=2016,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8035.txt",
  key="RFC 8035",
  abstract={This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing.  It makes it clear that an answerer can only include an ``a=rtcp-mux'' attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.},
  keywords="RTP, RTCP, multiplex, rtcp-mux, SDP, offer, answer",
  doi="10.17487/RFC8035",
  }

@misc{rfc8036,
  author="N. Cam-Winget and J. Hui and D. Popa",
  title="{Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks}",
  howpublished="RFC 8036 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8036",
  pages="1--24",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8036.txt",
  key="RFC 8036",
  abstract={This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.},
  keywords="constrained environment, smart meter, utilities, smartgrid, secure smartgrid, connected energy",
  doi="10.17487/RFC8036",
  }

@misc{rfc8037,
  author="I. Liusvaara",
  title="{CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)}",
  howpublished="RFC 8037 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8037",
  pages="1--14",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8037.txt",
  key="RFC 8037",
  abstract={This document defines how to use the Diffie-Hellman algorithms ``X25519'' and ``X448'' as well as the signature algorithms ``Ed25519'' and ``Ed448'' from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).},
  keywords="Ed25519, Ed448, X25519, X448",
  doi="10.17487/RFC8037",
  }

@misc{rfc8038,
  author="P. Aitken and B. Claise and S. B S and C. McDowall and J. Schoenwaelder",
  title="{Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol}",
  howpublished="RFC 8038 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8038",
  pages="1--85",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8038.txt",
  key="RFC 8038",
  abstract={This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified. Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.},
  keywords="IPFIX, MIB, SNMP",
  doi="10.17487/RFC8038",
  }

@misc{rfc8039,
  author="A. Shpiner and R. Tse and C. Schelp and T. Mizrahi",
  title="{Multipath Time Synchronization}",
  howpublished="RFC 8039 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8039",
  pages="1--17",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8039.txt",
  key="RFC 8039",
  abstract={Clock synchronization protocols are very widely used in IP-based networks.  The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP).  As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy.  This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols.  The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance.  The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.},
  keywords="NTP, PTP, IEEE 1588, multiple paths",
  doi="10.17487/RFC8039",
  }

@misc{rfc8040,
  author="A. Bierman and M. Bjorklund and K. Watsen",
  title="{RESTCONF Protocol}",
  howpublished="RFC 8040 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8040",
  pages="1--137",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8040.txt",
  key="RFC 8040",
  abstract={This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).},
  keywords="YANG, NETCONF, REST, HTTP",
  doi="10.17487/RFC8040",
  }

@misc{rfc8041,
  author="O. Bonaventure and C. Paasch and G. Detal",
  title="{Use Cases and Operational Experience with Multipath TCP}",
  howpublished="RFC 8041 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8041",
  pages="1--30",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8041.txt",
  key="RFC 8041",
  abstract={This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks.  It lists several prominent use cases where Multipath TCP has been considered and is being used.  It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.},
  keywords="TCP, MPTCP, Middlebox, Congestion Control, Path Manager, Scheduler, Proxy, Load-Balancer, Datacenter, Cellular/WiFi Offload, Hybrid Access Networks",
  doi="10.17487/RFC8041",
  }

@misc{rfc8042,
  author="Z. Zhang and L. Wang and A. Lindem",
  title="{OSPF Two-Part Metric}",
  howpublished="RFC 8042 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8042",
  pages="1--9",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8042.txt",
  key="RFC 8042",
  abstract={This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router.  For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts.  This document updates RFC 2328.},
  keywords="OSPF, Broadcast, Interface, SPF metrics, Radio Networks",
  doi="10.17487/RFC8042",
  }

@misc{rfc8043,
  author="B. Sarikaya and M. Boucadair",
  title="{Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space}",
  howpublished="RFC 8043 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8043",
  pages="1--16",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8043.txt",
  key="RFC 8043",
  abstract={This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing. The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.},
  keywords="Neighbor Discovery, Duplicate Address Detection, ND Relay Agent",
  doi="10.17487/RFC8043",
  }

@misc{rfc8044,
  author="A. DeKok",
  title="{Data Types in RADIUS}",
  howpublished="RFC 8044 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8044",
  pages="1--35",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8044.txt",
  key="RFC 8044",
  abstract={RADIUS specifications have used data types for two decades without defining them as managed entities.  During this time, RADIUS implementations have named the data types and have used them in attribute definitions.  This document updates the specifications to better follow established practice.  We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865.  We provide an IANA registry for the data types and update the ``RADIUS Attribute Types'' registry to include a Data Type field for each attribute.  Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice.  This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.},
  doi="10.17487/RFC8044",
  }

@misc{rfc8045,
  author="D. Cheng and J. Korhonen and M. Boucadair and S. Sivakumar",
  title="{RADIUS Extensions for IP Port Configuration and Reporting}",
  howpublished="RFC 8045 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8045",
  pages="1--43",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8045.txt",
  key="RFC 8045",
  abstract={This document defines three new RADIUS attributes.  For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts.  This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc.  This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers.},
  keywords="address sharing, address continuity, CGN, NAT, IP assignment, port assignment, port control, port accounting, port set, port range, IP/Port Limit, Provider Wi-Fi, Port forwarding, Internal port, External port, Port mapping",
  doi="10.17487/RFC8045",
  }

@misc{rfc8046,
  author="T. Henderson and C. Vogt and J. Arkko",
  title="{Host Mobility with the Host Identity Protocol}",
  howpublished="RFC 8046 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8046",
  pages="1--37",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8046.txt",
  key="RFC 8046",
  abstract={This document defines a mobility extension to the Host Identity Protocol (HIP).  Specifically, this document defines a ``LOCATOR\_SET'' parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached.  This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts.  The same LOCATOR\_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047).  This document obsoletes RFC 5206.},
  keywords="hip, multihoming extensions, mobility extensions, locator",
  doi="10.17487/RFC8046",
  }

@misc{rfc8047,
  author="T. Henderson and C. Vogt and J. Arkko",
  title="{Host Multihoming with the Host Identity Protocol}",
  howpublished="RFC 8047 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8047",
  pages="1--22",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8047.txt",
  key="RFC 8047",
  abstract={This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.},
  keywords="hip, multihoming extensions, mobility extensions, locator",
  doi="10.17487/RFC8047",
  }

@misc{rfc8048,
  author="P. Saint-Andre",
  title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence}",
  howpublished="RFC 8048 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8048",
  pages="1--34",
  year=2016,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8048.txt",
  key="RFC 8048",
  abstract={This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).  This document obsoletes RFC 7248.},
  keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Session Initiation Protocol, SIP, SIMPLE, presence, availability",
  doi="10.17487/RFC8048",
  }

@misc{rfc8049,
  author="S. Litkowski and L. Tomotaki and K. Ogaki",
  title="{YANG Data Model for L3VPN Service Delivery}",
  howpublished="RFC 8049 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8049",
  pages="1--157",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8049.txt",
  key="RFC 8049",
  abstract={This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service.  This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This model is intended to be instantiated at the management system to deliver the overall service.  It is not a configuration model to be used directly on network elements.  This model provides an abstracted view of the Layer 3 IP VPN service configuration components.  It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service.  How the configuration of network elements is done is out of scope for this document.},
  keywords="YANG, l3sm, l3vpn, service model",
  doi="10.17487/RFC8049",
  }

@misc{rfc8051,
  author="X. Zhang and I. Minei",
  title="{Applicability of a Stateful Path Computation Element (PCE)}",
  howpublished="RFC 8051 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8051",
  pages="1--24",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8051.txt",
  key="RFC 8051",
  abstract={A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs).  This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases.  PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.},
  keywords="Stateful PCE, Applicability",
  doi="10.17487/RFC8051",
  }

@misc{rfc8053,
  author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku",
  title="{HTTP Authentication Extensions for Interactive Clients}",
  howpublished="RFC 8053 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8053",
  pages="1--28",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8053.txt",
  key="RFC 8053",
  abstract={This document specifies extensions for the HTTP authentication framework for interactive clients.  Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications.  This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents.  The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.},
  doi="10.17487/RFC8053",
  }

@misc{rfc8054,
  author="K. Murchison and J. Elie",
  title="{Network News Transfer Protocol (NNTP) Extension for Compression}",
  howpublished="RFC 8054 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8054",
  pages="1--23",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8054.txt",
  key="RFC 8054",
  abstract={This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.},
  keywords="NNTP, Usenet, NetNews, COMPRESS, DEFLATE, compression",
  doi="10.17487/RFC8054",
  }

@misc{rfc8055,
  author="C. Holmberg and Y. Jiang",
  title="{Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm}",
  howpublished="RFC 8055 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8055",
  pages="1--13",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8055.txt",
  key="RFC 8055",
  abstract={This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.},
  keywords="SIP, Via, transit, realm",
  doi="10.17487/RFC8055",
  }

@misc{rfc8056,
  author="J. Gould",
  title="{Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping}",
  howpublished="RFC 8056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8056",
  pages="1--11",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8056.txt",
  key="RFC 8056",
  abstract={This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP).  This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.},
  doi="10.17487/RFC8056",
  }

@misc{rfc8057,
  author="B. Stark and D. Sinicrope and W. Lupton",
  title="{Uniform Resource Name (URN) Namespaces for Broadband Forum}",
  howpublished="RFC 8057 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8057",
  pages="1--11",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8057.txt",
  key="RFC 8057",
  abstract={This document describes the Namespace Identifiers (NIDs) ``bbf'', ``broadband-forum-org'', and ``dslforum-org'' for Uniform Resource Names (URNs) used to identify resources published by Broadband Forum (BBF).  BBF specifies and manages resources that utilize these three URN identification models.  Management activities for these and other resource types are handled by BBF.},
  keywords="URN, Broadband Forum, BBF",
  doi="10.17487/RFC8057",
  }

@misc{rfc8058,
  author="J. Levine and T. Herkula",
  title="{Signaling One-Click Functionality for List Email Headers}",
  howpublished="RFC 8058 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8058",
  pages="1--9",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8058.txt",
  key="RFC 8058",
  abstract={This document describes a method for signaling a one-click function for the List-Unsubscribe email header field.  The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.},
  keywords="email, mailing list",
  doi="10.17487/RFC8058",
  }

@misc{rfc8059,
  author="J. Arango and S. Venaas and I. Kouvelas and D. Farinacci",
  title="{PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments}",
  howpublished="RFC 8059 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8059",
  pages="1--9",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8059.txt",
  key="RFC 8059",
  abstract={This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites.  These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).},
  doi="10.17487/RFC8059",
  }

@misc{rfc8060,
  author="D. Farinacci and D. Meyer and J. Snijders",
  title="{LISP Canonical Address Format (LCAF)}",
  howpublished="RFC 8060 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8060",
  pages="1--36",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8060.txt",
  key="RFC 8060",
  abstract={This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.},
  keywords="Locator/ID Separation Protocol",
  doi="10.17487/RFC8060",
  }

@misc{rfc8061,
  author="D. Farinacci and B. Weis",
  title="{Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality}",
  howpublished="RFC 8061 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8061",
  pages="1--18",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8061.txt",
  key="RFC 8061",
  abstract={This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP).  The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.},
  keywords="lcaf",
  doi="10.17487/RFC8061",
  }

@misc{rfc8062,
  author="L. Zhu and P. Leach and S. Hartman and S. Emery",
  title="{Anonymity Support for Kerberos}",
  howpublished="RFC 8062 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8062",
  pages="1--18",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8062.txt",
  key="RFC 8062",
  abstract={This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm.  It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC).  This document updates RFCs 4120, 4121, and 4556.  This document obsoletes RFC 6112 and reclassifies that document as Historic.  RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation.  This specification describes a protocol that interoperates with multiple implementations.},
  doi="10.17487/RFC8062",
  }

@misc{rfc8063,
  author="H.W. Ribbers and M.W. Groeneweg and R. Gieben and A.L.J. Verschuren",
  title="{Key Relay Mapping for the Extensible Provisioning Protocol}",
  howpublished="RFC 8063 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8063",
  pages="1--16",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8063.txt",
  key="RFC 8063",
  abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730. This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.},
  keywords="Extensible Provisioning Protocol",
  doi="10.17487/RFC8063",
  }

@misc{rfc8064,
  author="F. Gont and A. Cooper and D. Thaler and W. Liu",
  title="{Recommendation on Stable IPv6 Interface Identifiers}",
  howpublished="RFC 8064 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8064",
  pages="1--9",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8064.txt",
  key="RFC 8064",
  abstract={This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.  It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs.  It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121.  This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.},
  doi="10.17487/RFC8064",
  }

@misc{rfc8065,
  author="D. Thaler",
  title="{Privacy Considerations for IPv6 Adaptation-Layer Mechanisms}",
  howpublished="RFC 8065 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8065",
  pages="1--10",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8065.txt",
  key="RFC 8065",
  abstract={This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.},
  doi="10.17487/RFC8065",
  }

@misc{rfc8066,
  author="S. Chakrabarti and G. Montenegro and R. Droms and J. Woodyatt",
  title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines}",
  howpublished="RFC 8066 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8066",
  pages="1--9",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8066.txt",
  key="RFC 8066",
  abstract={RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header.  The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944.  This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.},
  doi="10.17487/RFC8066",
  }

@misc{rfc8067,
  author="B. Leiba",
  title="{Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level}",
  howpublished="RFC 8067 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="8067",
  pages="1--3",
  year=2017,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8067.txt",
  key="RFC 8067",
  abstract={RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels (``downrefs''), which involves calling out the downref explicitly in the Last Call notice.  That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.},
  keywords="downref, maturity, last call",
  doi="10.17487/RFC8067",
  }

@misc{rfc8068,
  author="R. Ravindranath and P. Ravindran and P. Kyzivat",
  title="{Session Initiation Protocol (SIP) Recording Call Flows}",
  howpublished="RFC 8068 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8068",
  pages="1--34",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8068.txt",
  key="RFC 8068",
  abstract={Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons.  The recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).},
  keywords="sipreq",
  doi="10.17487/RFC8068",
  }

@misc{rfc8069,
  author="A. Thomas",
  title="{URN Namespace for IEEE}",
  howpublished="RFC 8069 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8069",
  pages="1--6",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8069.txt",
  key="RFC 8069",
  abstract={This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE).  IEEE specifies and manages resources that utilize this URN identification model.  Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority.},
  doi="10.17487/RFC8069",
  }

@misc{rfc8070,
  author="M. Short and S. Moore and P. Miller",
  title="{Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension}",
  howpublished="RFC 8070 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8070",
  pages="1--9",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8070.txt",
  key="RFC 8070",
  abstract={This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.},
  doi="10.17487/RFC8070",
  }

@misc{rfc8071,
  author="K. Watsen",
  title="{NETCONF Call Home and RESTCONF Call Home}",
  howpublished="RFC 8071 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8071",
  pages="1--13",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8071.txt",
  key="RFC 8071",
  abstract={This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.},
  keywords="call-home",
  doi="10.17487/RFC8071",
  }

@misc{rfc8072,
  author="A. Bierman and M. Bjorklund and K. Watsen",
  title="{YANG Patch Media Type}",
  howpublished="RFC 8072 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8072",
  pages="1--39",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8072.txt",
  key="RFC 8072",
  abstract={This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.},
  keywords="RESTCONF",
  doi="10.17487/RFC8072",
  }

@misc{rfc8073,
  author="K. Moriarty and M. Ford",
  title="{Coordinating Attack Response at Internet Scale (CARIS) Workshop Report}",
  howpublished="RFC 8073 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8073",
  pages="1--16",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8073.txt",
  key="RFC 8073",
  abstract={This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.},
  doi="10.17487/RFC8073",
  }

@misc{rfc8074,
  author="J. Bi and G. Yao and J. Halpern and E. Levy-Abegnoli",
  title="{Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario}",
  howpublished="RFC 8074 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8074",
  pages="1--12",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8074.txt",
  key="RFC 8074",
  abstract={In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods.  This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.},
  keywords="SAVI-DHCP, FCFS SAVI, SEND SAVI",
  doi="10.17487/RFC8074",
  }

@misc{rfc8075,
  author="A. Castellani and S. Loreto and A. Rahman and T. Fossati and E. Dijk",
  title="{Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)}",
  howpublished="RFC 8075 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8075",
  pages="1--40",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8075.txt",
  key="RFC 8075",
  abstract={This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP).  This will enable an HTTP client to access resources on a CoAP server through the proxy.  This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response.  This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.},
  keywords="CoAP, HTTP-CoAP mapping, HTTP-CoAP translation, proxy implementation",
  doi="10.17487/RFC8075",
  }

@misc{rfc8076,
  author="A. Knauf and T. Schmidt and G. Hege and M. Waehlisch",
  title="{A Usage for Shared Resources in RELOAD (ShaRe)}",
  howpublished="RFC 8076 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8076",
  pages="1--22",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8076.txt",
  key="RFC 8076",
  abstract={This document defines a REsource LOcation And Discovery (RELOAD) Usage for managing shared write access to RELOAD Resources.  Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers.  Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list.  A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate.  This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required.},
  keywords="P2PSIP, SIP, Conferencing, Voice over IP, Peer-to-Peer, Access Control, Group Management, Rendezvous",
  doi="10.17487/RFC8076",
  }

@misc{rfc8077,
  author="L. Martini and G. Heron",
  title="{Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)}",
  howpublished="RFC 8077 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8077",
  pages="1--35",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8077.txt",
  key="RFC 8077",
  abstract={Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents. This document is a rewrite of RFC 4447 for publication as an Internet Standard.},
  doi="10.17487/RFC8077",
  }

@misc{rfc8078,
  author="O. Gudmundsson and P. Wouters",
  title="{Managing DS Records from the Parent via CDS/CDNSKEY}",
  howpublished="RFC 8078 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8078",
  pages="1--10",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8078.txt",
  key="RFC 8078",
  abstract={RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.},
  keywords="dnssec, trust maintenance",
  doi="10.17487/RFC8078",
  }

@misc{rfc8079,
  author="L. Miniero and S. Garcia Murillo and V. Pascual",
  title="{Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)}",
  howpublished="RFC 8079 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8079",
  pages="1--16",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8079.txt",
  key="RFC 8079",
  abstract={SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.},
  doi="10.17487/RFC8079",
  }

@misc{rfc8080,
  author="O. Sury and R. Edmonds",
  title="{Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC}",
  howpublished="RFC 8080 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8080",
  pages="1--7",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8080.txt",
  key="RFC 8080",
  abstract={This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC).  It uses EdDSA with the choice of two curves: Ed25519 and Ed448.},
  keywords="DNSSEC, EdDSA, ed25519, ed448",
  doi="10.17487/RFC8080",
  }

@misc{rfc8081,
  author="C. Lilley",
  title="{The ``font'' Top-Level Media Type}",
  howpublished="RFC 8081 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8081",
  pages="1--18",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8081.txt",
  key="RFC 8081",
  abstract={This memo serves to register and document the ``font'' top-level media type, under which subtypes for representation formats for fonts may be registered.  This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the ``application'' tree by their separate registrations.},
  keywords="Internet Media Types, MIME",
  doi="10.17487/RFC8081",
  }

@misc{rfc8082,
  author="S. Wenger and J. Lennox and B. Burman and M. Westerlund",
  title="{Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs}",
  howpublished="RFC 8082 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8082",
  pages="1--11",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8082.txt",
  key="RFC 8082",
  abstract={This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs.  In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows.  The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.},
  keywords="Layered Codec, Full Intra Request, FIR, Decoder Refresh Point",
  doi="10.17487/RFC8082",
  }

@misc{rfc8083,
  author="C. Perkins and V. Singh",
  title="{Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions}",
  howpublished="RFC 8083 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8083",
  pages="1--25",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8083.txt",
  key="RFC 8083",
  abstract={The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.},
  doi="10.17487/RFC8083",
  }

@misc{rfc8084,
  author="G. Fairhurst",
  title="{Network Transport Circuit Breakers}",
  howpublished="RFC 8084 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="8084",
  pages="1--24",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8084.txt",
  key="RFC 8084",
  abstract={This document explains what is meant by the term ``network transport Circuit Breaker''.  It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.  It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.},
  keywords="Congestion control, CC, UDP, Tunnel, Encapsulation, Transport Protocol, Congestion Control",
  doi="10.17487/RFC8084",
  }

@misc{rfc8085,
  author="L. Eggert and G. Fairhurst and G. Shepherd",
  title="{UDP Usage Guidelines}",
  howpublished="RFC 8085 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="8085",
  pages="1--55",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8085.txt",
  key="RFC 8085",
  abstract={The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.},
  keywords="UDP, guidelines",
  doi="10.17487/RFC8085",
  }

@misc{rfc8086,
  author="L. Yong and E. Crabbe and X. Xu and T. Herbert",
  title="{GRE-in-UDP Encapsulation}",
  howpublished="RFC 8086 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8086",
  pages="1--27",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8086.txt",
  key="RFC 8086",
  abstract={This document specifies a method of encapsulating network protocol packets within GRE and UDP headers.  This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field.  This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms.  There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment.  The controlled environment has less restrictive requirements than the general Internet.},
  doi="10.17487/RFC8086",
  }

@misc{rfc8087,
  author="G. Fairhurst and M. Welzl",
  title="{The Benefits of Using Explicit Congestion Notification (ECN)}",
  howpublished="RFC 8087 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8087",
  pages="1--19",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8087.txt",
  key="RFC 8087",
  abstract={The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN).  The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking.  It also discusses challenges for successful deployment of ECN.  It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.},
  keywords="ecn, aqm, sctp, tcp",
  doi="10.17487/RFC8087",
  }

@misc{rfc8088,
  author="M. Westerlund",
  title="{How to Write an RTP Payload Format}",
  howpublished="RFC 8088 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8088",
  pages="1--65",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8088.txt",
  key="RFC 8088",
  abstract={This document contains information on how best to write an RTP payload format specification.  It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results.  A template is also included with instructions.},
  keywords="RTP, Payload format, Process",
  doi="10.17487/RFC8088",
  }

@misc{rfc8089,
  author="M. Kerwin",
  title="{The ``file'' URI Scheme}",
  howpublished="RFC 8089 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8089",
  pages="1--19",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8089.txt",
  key="RFC 8089",
  abstract={This document provides a more complete specification of the ``file'' Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738. It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.},
  keywords="uniform resource identifier, URL",
  doi="10.17487/RFC8089",
  }

@misc{rfc8090,
  author="R. Housley",
  title="{Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)}",
  howpublished="RFC 8090 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8090",
  pages="1--7",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8090.txt",
  key="RFC 8090",
  abstract={This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.},
  doi="10.17487/RFC8090",
  }

@misc{rfc8091,
  author="E. Wilde",
  title="{A Media Type Structured Syntax Suffix for JSON Text Sequences}",
  howpublished="RFC 8091 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8091",
  pages="1--5",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8091.txt",
  key="RFC 8091",
  abstract={Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation.  This specification defines and registers ``+json-seq'' as a structured syntax suffix for JSON text sequences.},
  doi="10.17487/RFC8091",
  }

@misc{rfc8092,
  author="J. Heitz and J. Snijders and K. Patel and I. Bagdonas and N. Hilliard",
  title="{BGP Large Communities Attribute}",
  howpublished="RFC 8092 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8092",
  pages="1--8",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8092.txt",
  key="RFC 8092",
  abstract={This document describes the BGP Large Communities attribute, an extension to BGP-4.  This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management.  The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs.},
  keywords="BGP, large, communities, four-octet",
  doi="10.17487/RFC8092",
  }

@misc{rfc8093,
  author="J. Snijders",
  title="{Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243}",
  howpublished="RFC 8093 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8093",
  pages="1--3",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8093.txt",
  key="RFC 8093",
  abstract={This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as ``Deprecated''.},
  doi="10.17487/RFC8093",
  }

@misc{rfc8094,
  author="T. Reddy and D. Wing and P. Patil",
  title="{DNS over Datagram Transport Layer Security (DTLS)}",
  howpublished="RFC 8094 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8094",
  pages="1--13",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8094.txt",
  key="RFC 8094",
  abstract={DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.},
  doi="10.17487/RFC8094",
  }

@misc{rfc8095,
  author="G. Fairhurst and B. Trammell and M. Kuehlewind",
  title="{Services Provided by IETF Transport Protocols and Congestion Control Mechanisms}",
  howpublished="RFC 8095 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8095",
  pages="1--54",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8095.txt",
  key="RFC 8095",
  abstract={This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services.  It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport.  This survey provides background for the definition of transport services within the TAPS working group.},
  keywords="Transmission Control Protocol (TCP), Multipath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), UDP-Lite, Datagram Congestion Control Protocol (DCCP), Internet Control Message Protocol (ICMP), Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), Hypertext Transport Protocol (HTTP), TAPS",
  doi="10.17487/RFC8095",
  }

@misc{rfc8096,
  author="B. Fenner",
  title="{The IPv6-Specific MIB Modules Are Obsolete}",
  howpublished="RFC 8096 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8096",
  pages="1--65",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8096.txt",
  key="RFC 8096",
  abstract={In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table.  This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories.  This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.},
  doi="10.17487/RFC8096",
  }

@misc{rfc8097,
  author="P. Mohapatra and K. Patel and J. Scudder and D. Ward and R. Bush",
  title="{BGP Prefix Origin Validation State Extended Community}",
  howpublished="RFC 8097 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8097",
  pages="1--6",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8097.txt",
  key="RFC 8097",
  abstract={This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system.  Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.},
  doi="10.17487/RFC8097",
  }

@misc{rfc8098,
  author="T. Hansen and A. Melnikov",
  title="{Message Disposition Notification}",
  howpublished="RFC 8098 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8098",
  pages="1--37",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8098.txt",
  key="RFC 8098",
  abstract={This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary ``LAN-based'' systems, and are often referred to as ``read receipts,'' ``acknowledgements,'' or ``receipt notifications.'' The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary ``LAN-based'' systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of ``foreign'' addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support ``tunneling'' of foreign notifications through Internet Mail. This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).},
  keywords="delivery notification, mdn",
  doi="10.17487/RFC8098",
  }

@misc{rfc8099,
  author="H. Chen and R. Li and A. Retana and Y. Yang and Z. Liu",
  title="{OSPF Topology-Transparent Zone}",
  howpublished="RFC 8099 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8099",
  pages="1--27",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8099.txt",
  key="RFC 8099",
  abstract={This document presents a Topology-Transparent Zone (TTZ) in an OSPF area.  A TTZ comprises a group of routers and a number of links connecting these routers.  Any router outside of the zone is not aware of the zone.  A TTZ hides the internal topology of the TTZ from the outside.  It does not directly advertise any internal information about the TTZ to a router outside of the TTZ.  The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.},
  keywords="IGP, OSPF, TTZ",
  doi="10.17487/RFC8099",
  }

@misc{rfc8100,
  author="R. Geib and D. Black",
  title="{Diffserv-Interconnection Classes and Practice}",
  howpublished="RFC 8100 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8100",
  pages="1--21",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8100.txt",
  key="RFC 8100",
  abstract={This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation.  Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks.  This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model.  While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.},
  keywords="Diffserv, Interconnection, PHB, Treatment Aggregate, MPLS Short Pipe",
  doi="10.17487/RFC8100",
  }

@misc{rfc8101,
  author="C. Holmberg and J. Axell",
  title="{IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service}",
  howpublished="RFC 8101 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8101",
  pages="1--6",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8101.txt",
  key="RFC 8101",
  abstract={This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.},
  keywords="Resource-Priority, namespace, Resource-priorith, 3GPP, IMS, MCPTT",
  doi="10.17487/RFC8101",
  }

@misc{rfc8102,
  author="P. Sarkar and S. Hegde and C. Bowers and H. Gredler and S. Litkowski",
  title="{Remote-LFA Node Protection and Manageability}",
  howpublished="RFC 8102 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8102",
  pages="1--22",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8102.txt",
  key="RFC 8102",
  abstract={The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called ``PQ-nodes'') may not guarantee node protection for all destinations being protected by it. This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.},
  keywords="LFA, Remote-LFA, IGP, Node Protection",
  doi="10.17487/RFC8102",
  }

@misc{rfc8103,
  author="R. Housley",
  title="{Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)}",
  howpublished="RFC 8103 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8103",
  pages="1--9",
  year=2017,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8103.txt",
  key="RFC 8103",
  abstract={This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS).  ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.},
  doi="10.17487/RFC8103",
  }

@misc{rfc8104,
  author="Y. Shen and R. Aggarwal and W. Henderickx and Y. Jiang",
  title="{Pseudowire (PW) Endpoint Fast Failure Protection}",
  howpublished="RFC 8104 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8104",
  pages="1--43",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8104.txt",
  key="RFC 8104",
  abstract={This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure.  Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure.  The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel.  Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.},
  keywords="pseudowire, PW, protection, local repair, fast reroute",
  doi="10.17487/RFC8104",
  }

@misc{rfc8105,
  author="P. Mariager and J. Petersen and Z. Shelby and M. Van de Logt and D. Barthel",
  title="{Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)}",
  howpublished="RFC 8105 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8105",
  pages="1--22",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8105.txt",
  key="RFC 8105",
  abstract={Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI. The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services. DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications. This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.},
  keywords="6LoWPAN, ETSI, IoT, and Internet of Things",
  doi="10.17487/RFC8105",
  }

@misc{rfc8106,
  author="J. Jeong and S. Park and L. Beloeil and S. Madanapalli",
  title="{IPv6 Router Advertisement Options for DNS Configuration}",
  howpublished="RFC 8106 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8106",
  pages="1--19",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8106.txt",
  key="RFC 8106",
  abstract={This document specifies IPv6 Router Advertisement (RA) options (called ``DNS RA options'') to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.},
  keywords="DNS Service, DNS Option, Recursive DNS Server Address, DNS Search List, Stateless Autoconfiguration",
  doi="10.17487/RFC8106",
  }

@misc{rfc8107,
  author="J. Wold",
  title="{Advertising Digital Identifier (Ad-ID) URN Namespace Definition}",
  howpublished="RFC 8107 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8107",
  pages="1--7",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8107.txt",
  key="RFC 8107",
  abstract={Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms.  This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) ``adid'' for Ad-IDs.},
  doi="10.17487/RFC8107",
  }

@misc{rfc8108,
  author="J. Lennox and M. Westerlund and Q. Wu and C. Perkins",
  title="{Sending Multiple RTP Streams in a Single RTP Session}",
  howpublished="RFC 8108 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8108",
  pages="1--29",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8108.txt",
  key="RFC 8108",
  abstract={This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs).  This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session.  This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior.  It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.},
  doi="10.17487/RFC8108",
  }

@misc{rfc8109,
  author="P. Koch and M. Larson and P. Hoffman",
  title="{Initializing a DNS Resolver with Priming Queries}",
  howpublished="RFC 8109 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="8109",
  pages="1--7",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8109.txt",
  key="RFC 8109",
  abstract={This document describes the queries that a DNS resolver should emit to initialize its cache.  The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.},
  doi="10.17487/RFC8109",
  }

@misc{rfc8110,
  author="D. Harkins and W. Kumari",
  title="{Opportunistic Wireless Encryption}",
  howpublished="RFC 8110 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8110",
  pages="1--12",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8110.txt",
  key="RFC 8110",
  abstract={This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.},
  keywords="opportunistic encryption wireless",
  doi="10.17487/RFC8110",
  }

@misc{rfc8113,
  author="M. Boucadair and C. Jacquenet",
  title="{Locator/ID Separation Protocol (LISP): Shared Extension Message \& IANA Registry for Packet Type Allocations}",
  howpublished="RFC 8113 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8113",
  pages="1--6",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8113.txt",
  key="RFC 8113",
  abstract={This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension.  It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.},
  keywords="Shared Experiment Code, LISP codepoints, Experiment Identifier, Experiment ID, LISP Experimental Registry, LISP Extension, Extending LISP",
  doi="10.17487/RFC8113",
  }

@misc{rfc8114,
  author="M. Boucadair and C. Qin and C. Jacquenet and Y. Lee and Q. Wang",
  title="{Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network}",
  howpublished="RFC 8114 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8114",
  pages="1--23",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8114.txt",
  key="RFC 8114",
  abstract={This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network.  The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic.  The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).},
  keywords="Multicast, DS-Lite, IPv4-IPv6 Interconnection, PREFIX64, SSM, ASM, IPv4 service continuity, Multicast service continuity, IPv6-only, IPv6-only multicast, PIM, MLD, IGMP, A+P, MAP, MAP-E, address-sharing, CGN, NAT64, IPv4 over IPv6, IPv6 Address Synthesis, Any-Source Multicast, Source-Specific Multicast",
  doi="10.17487/RFC8114",
  }

@misc{rfc8115,
  author="M. Boucadair and J. Qin and T. Tsou and X. Deng",
  title="{DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes}",
  howpublished="RFC 8115 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8115",
  pages="1--9",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8115.txt",
  key="RFC 8115",
  abstract={This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.},
  keywords="PREFIX64, SSM, ASM, Prefix Discovery, IPv4-Converted IPv6 Addresses, IPv4 service continuity, IPv6 Address Synthesis, Any-Source Multicast, Source-Specific Multicast, PIM, IPv4-IPv6 interconnection, IPv4  over IPv6, A+P, MAP, MAP-E, address-sharing, CGN, NAT64",
  doi="10.17487/RFC8115",
  }

@misc{rfc8117,
  author="C. Huitema and D. Thaler and R. Winter",
  title="{Current Hostname Practice Considered Harmful}",
  howpublished="RFC 8117 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8117",
  pages="1--12",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8117.txt",
  key="RFC 8117",
  abstract={Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.},
  doi="10.17487/RFC8117",
  }

@misc{rfc8118,
  author="M. Hardy and L. Masinter and D. Markovic and D. Johnson and M. Bailey",
  title="{The application/pdf Media Type}",
  howpublished="RFC 8118 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8118",
  pages="1--12",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8118.txt",
  key="RFC 8118",
  abstract={The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.  This document provides an overview of the PDF format and updates the media type registration of ``application/pdf''.  It obsoletes RFC 3778.},
  keywords="Portable Document Format, MIME type",
  doi="10.17487/RFC8118",
  }

@misc{rfc8119,
  author="M. Mohali and M. Barnes",
  title="{SIP ``cause'' URI Parameter for Service Number Translation}",
  howpublished="RFC 8119 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8119",
  pages="1--12",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8119.txt",
  key="RFC 8119",
  abstract={RFC 4458 (regarding SIP URIs for applications) defines a ``cause'' URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message.  This document updates RFC 4458 by creating a new predefined value for the ``cause'' URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number.  This document also provides guidance, which was missing in RFC 4458, for using the ``cause'' URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.},
  keywords="Cause",
  doi="10.17487/RFC8119",
  }

@misc{rfc8120,
  author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku",
  title="{Mutual Authentication Protocol for HTTP}",
  howpublished="RFC 8120 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8120",
  pages="1--53",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8120.txt",
  key="RFC 8120",
  abstract={This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol.  This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication.  Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.},
  keywords="HTTP, authentication",
  doi="10.17487/RFC8120",
  }

@misc{rfc8121,
  author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku",
  title="{Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)}",
  howpublished="RFC 8121 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8121",
  pages="1--17",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8121.txt",
  key="RFC 8121",
  abstract={This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).},
  keywords="HTTP, authentication",
  doi="10.17487/RFC8121",
  }

@misc{rfc8122,
  author="J. Lennox and C. Holmberg",
  title="{Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)}",
  howpublished="RFC 8122 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8122",
  pages="1--18",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8122.txt",
  key="RFC 8122",
  abstract={This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.},
  keywords="SDP, TLS, Fingerprint, Offer, Answer",
  doi="10.17487/RFC8122",
  }

@misc{rfc8123,
  author="P. Dawes and C. Arunachalam",
  title="{Requirements for Marking SIP Messages to be Logged}",
  howpublished="RFC 8123 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8123",
  pages="1--11",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8123.txt",
  key="RFC 8123",
  abstract={SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end. This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.},
  keywords="logme, troubleshooting, debug, logging",
  doi="10.17487/RFC8123",
  }

@misc{rfc8124,
  author="R. Ravindranath and G. Salgueiro",
  title="{The Session Description Protocol (SDP) WebSocket Connection URI Attribute}",
  howpublished="RFC 8124 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8124",
  pages="1--12",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8124.txt",
  key="RFC 8124",
  abstract={The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications.  This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.},
  keywords="Secure WebSocket, Uniform Resource Identifier",
  doi="10.17487/RFC8124",
  }

@misc{rfc8125,
  author="J. Schmidt",
  title="{Requirements for Password-Authenticated Key Agreement (PAKE) Schemes}",
  howpublished="RFC 8125 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8125",
  pages="1--10",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8125.txt",
  key="RFC 8125",
  abstract={Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password.  This document reviews different types of PAKE schemes.  Furthermore, it presents requirements and gives recommendations to designers of new schemes.  It is a product of the Crypto Forum Research Group (CFRG).},
  keywords="Password, Key Agreement, Password-Authenticated Key Agreement, Cryptographic Protocol",
  doi="10.17487/RFC8125",
  }

@misc{rfc8128,
  author="C. Morgan",
  title="{IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee}",
  howpublished="RFC 8128 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8128",
  pages="1--5",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8128.txt",
  key="RFC 8128",
  abstract={This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).},
  doi="10.17487/RFC8128",
  }

@misc{rfc8129,
  author="A. Jain and N. Kinder and N. McCallum",
  title="{Authentication Indicator in Kerberos Tickets}",
  howpublished="RFC 8129 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8129",
  pages="1--6",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8129.txt",
  key="RFC 8129",
  abstract={This document updates RFC 4120, as it specifies an extension in the Kerberos protocol.  It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR.  The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.},
  doi="10.17487/RFC8129",
  }

@misc{rfc8130,
  author="V. Demjanenko and D. Satterlee",
  title="{RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec}",
  howpublished="RFC 8130 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8130",
  pages="1--30",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8130.txt",
  key="RFC 8130",
  abstract={This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder.  MELPe's three different speech encoding rates and sample frame sizes are supported.  Comfort noise procedures and packet loss concealment are described in detail.},
  keywords="MELP, MELPe, MELP2400, MELP1200, MELP600, SCIP-210, SCIP210",
  doi="10.17487/RFC8130",
  }

@misc{rfc8131,
  author="X. Zhang and H. Zheng and R. Gandhi and Z. Ali and P. Brzozowski",
  title="{RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing}",
  howpublished="RFC 8131 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8131",
  pages="1--15",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8131.txt",
  key="RFC 8131",
  abstract={In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs. This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.},
  keywords="Association Object, LSP Reversion, LSP Recovery, GMPLS Make-Before-Break, GMPLS 1+R, GMPLS 1+1+R",
  doi="10.17487/RFC8131",
  }

@misc{rfc8132,
  author="P. van der Stok and C. Bormann and A. Sehgal",
  title="{PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)}",
  howpublished="RFC 8132 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8132",
  pages="1--21",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8132.txt",
  key="RFC 8132",
  abstract={The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.},
  keywords="CoAP",
  doi="10.17487/RFC8132",
  }

@misc{rfc8133,
  author="S. Smyshlyaev. Ed. and E. Alekseev and I. Oshkin and V. Popov",
  title="{The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol}",
  howpublished="RFC 8133 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8133",
  pages="1--51",
  year=2017,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8133.txt",
  key="RFC 8133",
  abstract={This document describes the Security Evaluated Standardized Password- Authenticated Key Exchange (SESPAKE) protocol.  The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information.  The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.},
  keywords="cryptography, secure channel, elliptic curve",
  doi="10.17487/RFC8133",
  }

@misc{rfc8135,
  author="M. Danielson and M. Nilsson",
  title="{Complex Addressing in IPv6}",
  howpublished="RFC 8135 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8135",
  pages="1--16",
  year=2017,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8135.txt",
  key="RFC 8135",
  abstract={The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world.  It also allows for new and improved security measures and supports advanced cloud computing challenges.},
  doi="10.17487/RFC8135",
  }

@misc{rfc8136,
  author="B. Carpenter and R. Hinden",
  title="{Additional Transition Functionality for IPv6}",
  howpublished="RFC 8136 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8136",
  pages="1--7",
  year=2017,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8136.txt",
  key="RFC 8136",
  abstract={This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.},
  doi="10.17487/RFC8136",
  }

@misc{rfc8138,
  author="P. Thubert and C. Bormann and L. Toutain and R. Cragie",
  title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header}",
  howpublished="RFC 8138 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8138",
  pages="1--37",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8138.txt",
  key="RFC 8138",
  abstract={This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550).  Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.},
  doi="10.17487/RFC8138",
  }

@misc{rfc8140,
  author="A. Farrel",
  title="{The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character}",
  howpublished="RFC 8140 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8140",
  pages="1--16",
  year=2017,
  month=apr,
  day="1",  
issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8140.txt",
  key="RFC 8140",
  abstract={Ever since Gutenberg discovered and patented ASCII and the corresponding ``Courier New'' font with its now-famous ``ten'' point size, artisans and artificers have striven to represent their views of the world in print. Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called ``nature''. This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.},
  doi="10.17487/RFC8140",
  }

@misc{rfc8141,
  author="P. Saint-Andre and J. Klensin",
  title="{Uniform Resource Names (URNs)}",
  howpublished="RFC 8141 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8141",
  pages="1--40",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8141.txt",
  key="RFC 8141",
  abstract={A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the ``urn'' URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier.  With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance.  With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA).  This document obsoletes both RFCs 2141 and 3406.},
  keywords="Uniform Resource Name, URN, Uniform Resource Identifier, URI",
  doi="10.17487/RFC8141",
  }

@misc{rfc8142,
  author="S. Gillies",
  title="{GeoJSON Text Sequences}",
  howpublished="RFC 8142 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8142",
  pages="1--5",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8142.txt",
  key="RFC 8142",
  abstract={This document describes the GeoJSON text sequence format and ``application/geo+json-seq'' media type.  This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.},
  keywords="JSON, Geospatial, JavaScript Object Notation",
  doi="10.17487/RFC8142",
  }

@misc{rfc8143,
  author="J. Elie",
  title="{Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)}",
  howpublished="RFC 8143 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8143",
  pages="1--13",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8143.txt",
  key="RFC 8143",
  abstract={This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS).  It modernizes the NNTP usage of TLS to be consistent with TLS best current practices.  This document updates RFC 4642.},
  keywords="NNTP, Usenet, NetNews, TLS, STARTTLS",
  doi="10.17487/RFC8143",
  }

@misc{rfc8144,
  author="K. Murchison",
  title="{Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)}",
  howpublished="RFC 8144 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8144",
  pages="1--28",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8144.txt",
  key="RFC 8144",
  abstract={This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request.  Furthermore, it defines the new ``depth-noroot'' preference.},
  keywords="http, prefer, webav, caldav",
  doi="10.17487/RFC8144",
  }

@misc{rfc8145,
  author="D. Wessels and W. Kumari and P. Hoffman",
  title="{Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)}",
  howpublished="RFC 8145 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8145",
  pages="1--13",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8145.txt",
  key="RFC 8145",
  abstract={The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust.  The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.},
  keywords="DNS, DNSSEC, Trust Anchor",
  doi="10.17487/RFC8145",
  }

@misc{rfc8146,
  author="D. Harkins",
  title="{Adding Support for Salted Password Databases to EAP-pwd}",
  howpublished="RFC 8146 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8146",
  pages="1--11",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8146.txt",
  key="RFC 8146",
  abstract={EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks.  It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords.  There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.},
  keywords="Password-Authenticated Key Exchange, PAKE, Dictionary Attack, Authentication EAP",
  doi="10.17487/RFC8146",
  }

@misc{rfc8147,
  author="R. Gellens and H. Tschofenig",
  title="{Next-Generation Pan-European eCall}",
  howpublished="RFC 8147 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8147",
  pages="1--43",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8147.txt",
  key="RFC 8147",
  abstract={This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as ``eCall''). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests. Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.},
  keywords="emergency, call, calls, emergency call, emergency calls, vehicle, acn, aacn, automatic crash notification, automatic collision notification, advanced automatic crash notification, advanced automatic collision notification, crash, vehicle-initiated",
  doi="10.17487/RFC8147",
  }

@misc{rfc8148,
  author="R. Gellens and B. Rosen and H. Tschofenig",
  title="{Next-Generation Vehicle-Initiated Emergency Calls}",
  howpublished="RFC 8148 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8148",
  pages="1--40",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8148.txt",
  key="RFC 8148",
  abstract={This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as ``Automatic Crash Notification'' (ACN), or ``Advanced Automatic Crash Notification'' (AACN), even in the case of manual trigger. The ``Advanced'' qualifier refers to the ability to carry a richer set of data. This document also registers a MIME media type and Emergency Call Data Type for the vehicle, sensor, and location data (often referred to as ``crash data'' even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document. This document reuses the technical aspects of next-generation Pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.},
  keywords="emergency, call, calls, emergency call, emergency calls, vehicle, acn, aacn, automatic crash notification, automatic collision notification,  advanced automatic crash notification, advanced automatic collision notification, crash, vehicle-initiated, ecall",
  doi="10.17487/RFC8148",
  }

@misc{rfc8149,
  author="T. Saad and R. Gandhi and Z. Ali and R. Venator and Y. Kamite",
  title="{RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)}",
  howpublished="RFC 8149 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8149",
  pages="1--17",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8149.txt",
  key="RFC 8149",
  abstract={The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.  This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them.  When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented.  This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.},
  keywords="RSVP fragmentation, RSVP fragment identifier, P2MP-TE tree reoptimization, P2MP-TE tree re-evaluation, Preferable P2MP-TE tree, Inter-domain P2MP-TE",
  doi="10.17487/RFC8149",
  }

@misc{rfc8150,
  author="S. Kingston Smiler and M. Venkatesan and D. King and S. Aldrin and J. Ryoo",
  title="{MPLS Transport Profile Linear Protection MIB}",
  howpublished="RFC 8150 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8150",
  pages="1--48",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8150.txt",
  key="RFC 8150",
  abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing Multiprotocol Label Switching - Transport Profile (MPLS-TP) linear protection.},
  keywords="Network Management, Management Information Base, MIB, SMIv2",
  doi="10.17487/RFC8150",
  }

@misc{rfc8153,
  author="H. Flanagan",
  title="{Digital Preservation Considerations for the RFC Series}",
  howpublished="RFC 8153 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8153",
  pages="1--18",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8153.txt",
  key="RFC 8153",
  abstract={The RFC Editor is both the publisher and the archivist for the RFC Series.  This document applies specifically to the archivist role of the RFC Editor.  It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary.  This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.},
  keywords="archive, archiving",
  doi="10.17487/RFC8153",
  }

@misc{rfc8154,
  author="C. Hellwig",
  title="{Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout}",
  howpublished="RFC 8154 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8154",
  pages="1--30",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8154.txt",
  key="RFC 8154",
  abstract={The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file.  The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.},
  keywords="NFSv4",
  doi="10.17487/RFC8154",
  }

@misc{rfc8155,
  author="P. Patil and T. Reddy and D. Wing",
  title="{Traversal Using Relays around NAT (TURN) Server Auto Discovery}",
  howpublished="RFC 8155 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8155",
  pages="1--16",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8155.txt",
  key="RFC 8155",
  abstract={Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery. This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.},
  doi="10.17487/RFC8155",
  }

@misc{rfc8157,
  author="N. Leymann and C. Heidemann and M. Zhang and B. Sarikaya and M. Cullen",
  title="{Huawei's GRE Tunnel Bonding Protocol}",
  howpublished="RFC 8157 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8157",
  pages="1--44",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8157.txt",
  key="RFC 8157",
  abstract={There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time. In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.},
  keywords="Hybrid Access, Bandwidth Aggregation, Bonding Tunnel, GRE Channel, Hybrid Access Aggregation Point, Home Gateway",
  doi="10.17487/RFC8157",
  }

@misc{rfc8159,
  author="M. Konstantynowicz and G. Heron and R. Schatzmayr and W. Henderickx",
  title="{Keyed IPv6 Tunnel}",
  howpublished="RFC 8159 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8159",
  pages="1--12",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8159.txt",
  key="RFC 8159",
  abstract={This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses.  The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.},
  keywords="L2TPv3, pseudowire",
  doi="10.17487/RFC8159",
  }

@misc{rfc8160,
  author="S. Tatham and D. Tucker",
  title="{IUTF8 Terminal Mode in Secure Shell (SSH)}",
  howpublished="RFC 8160 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8160",
  pages="1--4",
  year=2017,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8160.txt",
  key="RFC 8160",
  abstract={This document specifies a new opcode in the Secure Shell terminal modes encoding.  The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.},
  keywords="Secure Shell, SSH",
  doi="10.17487/RFC8160",
  }

@misc{rfc8161,
  author="W. Cerveny and R. Bonica and R. Thomas",
  title="{Benchmarking the Neighbor Discovery Protocol}",
  howpublished="RFC 8161 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8161",
  pages="1--17",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8161.txt",
  key="RFC 8161",
  abstract={This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP).  It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.},
  keywords="IPv6, Scaling, NDP",
  doi="10.17487/RFC8161",
  }

@misc{rfc8163,
  author="K. Lynn and J. Martocci and C. Neilson and S. Donaldson",
  title="{Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks}",
  howpublished="RFC 8163 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8163",
  pages="1--27",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8163.txt",
  key="RFC 8163",
  abstract={Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks.  This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.},
  doi="10.17487/RFC8163",
  }

@misc{rfc8164,
  author="M. Nottingham and M. Thomson",
  title="{Opportunistic Security for HTTP/2}",
  howpublished="RFC 8164 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="8164",
  pages="1--10",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8164.txt",
  key="RFC 8164",
  abstract={This document describes how ``http'' URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks.  This mechanism not a replacement for ``https'' URIs; it is vulnerable to active attacks.},
  keywords="Opportunistic Security, HTTP",
  doi="10.17487/RFC8164",
  }

@misc{rfc8165,
  author="T. Hardie",
  title="{Design Considerations for Metadata Insertion}",
  howpublished="RFC 8165 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="8165",
  pages="1--7",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8165.txt",
  key="RFC 8165",
  abstract={The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications.  This document considers the implications of protocol designs that associate metadata with encrypted flows.  In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.},
  keywords="surveillance, proxy, proxying, middlebox",
  doi="10.17487/RFC8165",
  }