File: rfc2832.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2187 lines) | stat: -rw-r--r-- 77,057 bytes parent folder | download | duplicates (5)
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






Network Working Group                                      S. Hollenbeck
Request for Comments: 2832                                 M. Srivastava
Category: Informational                 Network Solutions, Inc. Registry
                                                                May 2000


          NSI Registry Registrar Protocol (RRP) Version 1.1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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 protocol was developed by the Network
   Solutions Registry for use within the Shared Registration System and
   is being published "as-is" to document the protocol implementation
   developed by the Network Solutions, Inc. Registry.

   Internet domain name registration typically involves three entities:
   a registrant who wishes to register a domain name, a registrar who
   provides services to the registrant, and a registry that provides
   services to the registrar while serving as the authoritative
   repository of all functional information required to resolve names
   registered in the registry's TLDs.  This document describes a
   protocol for registry-registrar communication only.  The protocol
   does not provide any registrant services.

   This document is being discussed on the "rrp" mailing list.  To join
   the list, send a message to <majordomo@NSIRegistry.com> with the
   words "subscribe rrp" in the body of the message. There is also a web
   site for the mailing list archives at
   <http://www.NSIRegistry.net/maillist/rrp>.

Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD]. Further,



Hollenbeck & Srivastava      Informational                      [Page 1]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   the term "implicit attribute" refers to an entity attribute whose
   value is derived either from another attribute or is dependent on an
   established RRP session.

   In examples, "C:" represents lines sent by the registrar client and
   "S:" represents lines sent by the registry server.

   The term "System" is used in this document to collectively refer to
   this protocol and the software and hardware that implements the
   protocol.

Table of Contents

   1. Introduction .................................................    3
   2. Security Services ............................................    4
   2.1 Connection Security .........................................    4
   2.2 System Data Security ........................................    5
   3. Connection Model .............................................    5
   4. Protocol Description .........................................    6
   4.1 Request Format ..............................................    7
   4.2 Response Format .............................................    8
   4.3 Protocol Commands ...........................................    8
   4.3.1 ADD .......................................................    8
   4.3.2 CHECK .....................................................   11
   4.3.3 DEL .......................................................   12
   4.3.4 DESCRIBE ..................................................   14
   4.3.5 MOD .......................................................   14
   4.3.6 QUIT ......................................................   16
   4.3.7 RENEW .....................................................   17
   4.3.8 SESSION ...................................................   18
   4.3.9 STATUS ....................................................   18
   4.3.10 TRANSFER .................................................   21
   5. Response Codes ...............................................   23
   5.1 Response Code Summary .......................................   23
   5.2 Command-Response Correspondence .............................   28
   6. Domain Status Codes ..........................................   29
   6.1 Domain Status Code Description ..............................   30
   7. Formal Syntax ................................................   30
   8. Internationalization .........................................   35
   9. Known Issues .................................................   35
   10. Security Considerations .....................................   37
   11. IANA Considerations .........................................   37
   12. References ..................................................   37
   13. Acknowledgments .............................................   38
   14. Authors' Addresses ..........................................   38
   15. Full Copyright Statement ....................................   39





Hollenbeck & Srivastava      Informational                      [Page 2]

RFC 2832            NSI Registry Registrar Protocol             May 2000


1. Introduction

   This document describes the specifications for the NSI Registry
   Registrar Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII
   text protocol that permits multiple registrars to provide second
   level Internet domain name registration services in the top level
   domains (TLDs) administered by a TLD registry. RRP is specified using
   Augmented Backus-Nauer Form (ABNF) as described in [ABNF]. Note that
   all ABNF string literals are case-insensitive and the examples
   provided in this document may use mixed case to improve readability.

   RRP was developed by the Network Solutions, Inc. Registry under the
   auspices of the Shared Registration System program. The protocol was
   initially deployed in April 1999 as part of a test bed implementation
   of the Shared Registration System with five registrars. Additional
   registrars began using the protocol in July 1999. The operational
   experiences of both the registry and the registrars identified
   several "lessons learned" which have been documented here as "Known
   Issues".

   This document provides both a description of a protocol and notice of
   learned operational issues that may be useful as first steps in
   developing a standards track domain registration services protocol.
   This document and the protocol it describes may be modified in the
   future based on continued operational experience and community
   reaction.

   The registry stores information about registered domain names and
   associated name servers. A domain name's data includes its name, name
   servers, registrar, registration expiration date, and status. A name
   server's data includes its server name, IP addresses, and registrar.
   A registrar MAY perform the following registration service procedures
   using RRP:

   - Determine if a domain name has been registered.
   - Register a domain name.
   - Renew the registration of a domain name.
   - Cancel the registration of a domain name.
   - Update the name servers of a domain name.
   - Transfer a domain name from another registrar.
   - Examine the status of domain names that the registrar has
     registered.
   - Modify the status of domain names that the registrar has
     registered.
   - Determine if a name server has been registered.
   - Register a name server.
   - Update the IP addresses of a name server.




Hollenbeck & Srivastava      Informational                      [Page 3]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   - Delete a name server.
   - Examine the status of name servers that the registrar has
     registered.

   All RRP commands include features to provide idempotency.  That is,
   the effect of each command is the same if the command is executed
   once or if the command is executed multiple times. This property is
   extremely useful in situations when a command is retried due to an
   error condition that results in a missed command response and a
   command retry is attempted. Command retries will be caught by the
   System and rejected with an appropriate error response code. Command
   parameters that do not provide idempotency will be explained fully as
   part of the appropriate command description.

2. Security Services

   RRP provides only basic password-based registrar authentication
   services.  Additional security services, including privacy and
   registrar authentication using public key cryptography, are provided
   through other System features.

2.1 Connection Security

   Each RRP session MUST be encrypted using the Secure Socket Layer
   (SSL) v3.0 protocol as specified in [SSL]. SSL provides privacy
   services that reduce the risk of inadvertent disclosure of
   registrar-sensitive information, such as the registrar's user
   identifier and password.

   SSL supports mutual authentication of both the client and server
   using signed digital certificates. The Shared Registration System
   implemented by the NSI Registry requires digital certificates issued
   by a commercial certification authority for both registrar clients
   and public registry RRP servers. Both the registrar client and the
   public registry RRP server are authenticated when establishing an SSL
   connection. Further, a registrar MUST be authenticated when
   establishing an RRP connection via the RRP SESSION command by
   providing a registrar user identifier and password known only to the
   registrar and the System. Registrars may change their session
   password at any time using the RRP SESSION command.

   The SSL protocol is not an IETF Standards Track protocol. The
   Transport Layer Security protocol, specified in [TLS], is a Standards
   Track protocol that provides SSL v3.0 compatibility features.







Hollenbeck & Srivastava      Informational                      [Page 4]

RFC 2832            NSI Registry Registrar Protocol             May 2000


2.2 System Data Security

   The System stores information about the registered domain names and
   their name servers.  Only the current registrar of a registered
   domain name is authorized to query it, update its name servers, and
   cancel or renew it. Any registrar can request a transfer of a domain
   name and its associated name servers from another registrar to the
   requesting registrar. Only the current sponsoring registrar can
   receive and explicitly approve or reject domain transfer requests.

   Only a name server's registrar can query, update, and delete it.  In
   general, name servers must be registered through the current
   registrar of the name server's parent domain name, though an
   implementation MAY allow use of name servers registered in other TLDs
   without specifying IP addresses or requiring parent domain
   registration. Use of ccTLD name servers for a gTLD domain name is one
   such example.

   Name servers are implicitly transferred by the System when their
   parent domain name is transferred. In addition, a name server cannot
   be deleted if it is hosting domain names.

3. Connection Model

   IANA has assigned TCP port 648 for RRP use. All RRP implementations
   MUST provide RRP services over SSL on TCP port 648. An RRP server
   MUST return a banner in the following format to confirm that a
   connection has been established:

   <registry name> RRP Server version <version><crlf>
   <server build date and time><crlf>

   Each line ends with carriage return and line feed characters. The
   server build date and time string includes the day, month, date, time
   (specified in hours, minutes, and seconds), the local time zone, and
   the four-digit year. A dot (".") in column one on a line by itself
   marks the end of banner text.

   Example

   A registrar successfully establishes a connection with the NSI
   Registry on TCP port 648:

   S:NSI RRP Server version 1.1.0
   S:Mon Oct 25 20:20:34 EDT 1999
   S:.





Hollenbeck & Srivastava      Informational                      [Page 5]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4. Protocol Description

   A typical RRP session will go through a number of states during its
   lifetime.  Figure 1 illustrates the possible states of an RRP server.

   Initially, the server waits for a client connection and
   authentication (PRE).  All client connections MUST be authenticated.

                                      |
                                      |
                                      v
                             +-----------------+   Timeout
                             |   Waiting for   |-------------------+
   Authentication Succeeded  |      Client     |                   |
                   +---------|  Authentication | Authentication    |
                   |         |      (PRE)      |-----+  Failed     |
                   |         +-----------------+     |             |
                   |                                 |             |
                   V                                 V             |
             +-----------+     Succeeded    +--------------------+ |
             |Waiting for|<-----------------|    Waiting for     | |
             |  Command  |----------+       |Authentication Retry| |
             |   (WFC)   |  Timeout |       |       (WFR)        | |
             +-----------+          |       +--------------------+ |
                 |   ^              |           |         |        |
                 |   |              |   Timeout |         | Failed |
         Request V   |Response      |           |         |        |
             +-----------+          |           V         V        V
             | Executing |          |          +--------------------+
             |  Command  |          +--------->|    Disconnected    |
             |   (EXE)   |-------------------->|       (DIS)        |
             +-----------+          QUIT       +--------------------+

                Figure 1: RRP Server Finite State Machine

   If the authentication fails, the server gives the client another
   chance to identify itself (WFR). If the authentication fails again,
   the server disconnects (DIS).  Otherwise, the server waits for a
   request from the client (WFC).  Upon receiving a request, the server
   executes it and responds to the client with the result (EXE). The
   server then waits again for another request from the client (WFC). If
   the client sends a QUIT command, the server ends the session and
   disconnects (DIS). To keep its state in sync with that of the server,
   the client SHOULD wait for a response from the server before sending
   another request on the same connection.  The following table
   summarizes these states:





Hollenbeck & Srivastava      Informational                      [Page 6]

RFC 2832            NSI Registry Registrar Protocol             May 2000


        PRE     Waiting for client connection and authentication
        WFR     Waiting for authentication retry
        WFC     Waiting for a command from an authenticated client
        EXE     Executing a command
        DIS     Disconnected

   The WFR and WFC states MAY time out. An implementation SHOULD define
   inactivity timeout periods for these states based on System-specific
   factors, including (but not limited to) resource availability and
   security risk. In the absence of other factors, a default timeout
   period of 10 minutes SHOULD be used. The server MAY disconnect if the
   server is in one of these states and no message is received from the
   client during the timeout period.

4.1 Request Format

   An RRP request nominally consists of a command name, an entity block,
   command options, and an end-of-command delimiter. Command options and
   entity blocks collectively define command parameters and their
   specification is order independent; examples provided in this
   document specify entity blocks before command options.

     CommandName [EntityBlock] [CommandOptions] EndOfCommand

   A command name specifies the type of an RRP request.  A command is a
   word or abbreviation terminated by a carriage-return linefeed (crlf)
   sequence.

     CommandName<crlf>

   An entity block specifies the data in an RRP request. It consists of
   attribute name-value pairs specifying the entity and all of the
   attributes of the entity.  Each attribute name-value pair starts with
   the attribute name, followed by a colon, the attribute value, and is
   finally terminated by a carriage-return linefeed sequence.  Entity
   blocks are optional for some requests.

     entityName:entityValue<crlf>
     attributeName:attributeValue<crlf>

   Command options specify control parameters for an RRP request. A
   command option starts with a dash, followed by the option name, a
   colon, the option value, and is finally terminated by a carriage-
   return linefeed sequence.

     -commandOptionName:commandOptionValue<crlf>





Hollenbeck & Srivastava      Informational                      [Page 7]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   An EndOfCommand delimiter specifies the end of an RRP request.  It
   consists of a dot (".") in column one followed by a carriage-return
   linefeed sequence.

     .<crlf>

4.2 Response Format

   An RRP response starts with a three-digit response code, followed by
   a space, an ASCII text description of the response, a carriage-return
   linefeed sequence, and zero or more attribute name-value pair lines.
   An RRP response is terminated by a dot in column one followed by a
   carriage-return linefeed sequence.

     ResponseCode<space>responseDescription<crlf>
     [attributeName:attributeValue<crlf>]
     .<crlf>

4.3 Protocol Commands

   Implementations of RRP commands MUST provide "all or nothing" success
   and failure operation. Failed command execution MUST leave the System
   in the same state it was in before the command was attempted and
   failed.

   All RRP commands include features to provide idempotency. Command
   features that are not idempotent are explained fully as needed as
   part of the appropriate command description.

4.3.1 ADD

   This command allows a registrar to register a domain name or a name
   server in the System.

4.3.1.1 Registering a Domain Name

   The request to register a domain name MUST contain the following
   data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.









Hollenbeck & Srivastava      Informational                      [Page 8]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   The request to register a domain name MAY contain 1 or more, and a
   maximum of 13, fully qualified name servers hosting the domain name
   in multiple instances of the "NameServer" parameter. The name servers
   MUST have already been registered in the registry. Implementations
   MAY allow specification of name servers associated with domains
   registered in other TLDs. For example, an implementation MAY allow
   use of ccTLD name servers for gTLD domain name registration.

   The request to register a domain name MAY contain the initial
   registration period in years for the domain being registered in a
   single instance of the "Period" parameter. The System MUST provide a
   default initial registration period in years if the "Period"
   parameter is not provided. The acceptable year values for the
   "Period" parameter are implementation specific.

   The System will register the domain name to the registrar for the
   period specified by the registrar. If the registrar does not specify
   a registration period, a System-specified default value MUST be used
   for the initial registration period. If the domain name is
   successfully registered, the System MUST return the registration
   expiration date in the "registration expiration date" attribute in
   the response.

   Authorized User: All registrars MAY use the ADD command to register
   domain names.

   Examples

   A registrar registers a domain name without specifying name servers:

   C:add<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:-Period:10<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2009-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:.<crlf>












Hollenbeck & Srivastava      Informational                      [Page 9]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   A registrar registers a domain name using previously-registered name
   servers:

   C:add<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example2.com<crlf>
   C:-Period:10<crlf>
   C:NameServer:ns1.example.com<crlf>
   C:NameServer:ns2.example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2000-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:.<crlf>

4.3.1.2 Registering a Name Server

   The request to register a name server MUST contain the following
   data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name of the name server in the "NameServer"
     parameter.

   If the name server being registered is the child of a registered
   domain name, the name server registration request MUST include one or
   more, and a maximum of 13, name server IP addresses in multiple
   instances of the "IPAddress" parameter. Name servers associated with
   domains registered in other TLDs SHOULD NOT be specified with IP
   addresses to reduce the possibility of duplicating DNS NS records for
   the name servers in multiple zone files.

   The registrar MUST register the name server in the System before
   using it to host domain names. Further, the name server MUST be
   registered through the same registrar that is the current registrar
   of its parent domain name. The System MAY allow any registrar to use
   the name server to host domain names.

   Authorized User: All registrars MAY use the ADD command to register
   name servers.











Hollenbeck & Srivastava      Informational                     [Page 10]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   Examples

   A registrar registers a new name server in an existing domain name:

   C:add<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.example.com<crlf>
   C:IPAddress:198.41.1.11<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.2 CHECK

   This command allows a registrar to determine if a domain name or name
   server has been registered in the System.

4.3.2.1 Domain Name Check

   The request to determine if a domain name is registered MUST contain
   the following data:

   - The "EntityName" parameter set to value "Domain".
     - Fully qualified second level domain name in the "DomainName"
     parameter.

   The System MUST provide a positive or negative response to document
   domain name availability at the moment the command is executed.

   Authorized User: All registrars MAY use the CHECK command to
   determine if a domain name has been registered or not.

   Examples

   A registrar checks the availability of a domain name in the System:

   C:check<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:211 Domain name not available<crlf>
   S:.<crlf>









Hollenbeck & Srivastava      Informational                     [Page 11]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4.3.2.2 Name Server Check

   The request to determine if a name server is registered MUST contain
   the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name in the "NameServer" parameter.

   The System MUST provide a positive or negative response to document
   name server availability at the moment the command is executed. If
   the name server has been registered, the System MUST return the IP
   address(es) of the name server.

   Authorized User: All registrars MAY use the CHECK command to
   determine if a name server has been registered or not.

   Examples

   A registrar checks the availability of a server name in the System:

   C:check<crlf>
   C:EntityName:Nameserver<crlf>
   C:Nameserver:ns1.example.com<crlf>
   C:.<crlf>
   S:213 Name server not available<crlf>
   S:ipAddress:192.10.10.10<crlf>
   S:.<crlf>

4.3.3 DEL

   This command allows a registrar to delete (cancel the registration)
   of a domain name or delete a name server.

4.3.3.1 Deleting a Domain Name

   The request to cancel the registration of a domain name MUST contain
   the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   A request to delete a domain name SHOULD cause the deletion of all
   name servers that are children of the domain name being deleted. The
   name servers SHOULD be deleted if they are not actively hosting other
   domains. A domain MUST not be deleted if it has child name servers
   hosting other domains.




Hollenbeck & Srivastava      Informational                     [Page 12]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   Authorized User: The current registrar of a domain name MAY use the
   DEL command to delete a domain name from the System.

   Examples

   A registrar deletes a domain name, implicitly deleting all name
   servers registered in the domain:

   C:del<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.3.2 Deleting a Name Server

   The request to delete a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified name of the name server in the "NameServer"
     parameter.

   A name server MUST not be deleted if it is hosting domains. Deleting
   such domains or name servers is prohibited because their deletion
   WILL result in orphaning the hosted domains.

   Authorized User: The current registrar of a name server MAY use the
   DEL command to delete a name server from the System.

   Examples

   A registrar deletes a name server that is not hosting domains:

   C:del<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>











Hollenbeck & Srivastava      Informational                     [Page 13]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   A registrar tries to delete a name server that is hosting domains:

   C:del<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:532 Domain names linked with name server<crlf>
   S:.<crlf>

4.3.4 DESCRIBE

   This command allows a registrar to obtain general information about
   an RRP implementation. The command MAY contain the following
   parameters:

   - The "Target" parameter set to value "Protocol".

   The implementation MUST return the protocol version number whether or
   not the request contains the "Target" parameter.

   Authorized User: All registrars MAY use the DESCRIBE command.

   Examples

   A registrar obtains general information about an RRP implementation:

   C:describe<crlf>
   C:-Target:Protocol<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:Protocol:RRP 1.1.0<crlf>
   S:.<crlf>

4.3.5 MOD

   This command allows a registrar to update a registered domain name or
   a name server. The command allows the following operations on an
   attribute value for both single-valued and multi-valued attributes:

   - Add an attribute value. The value to be added MUST be unique among
     the values of the attribute. For a single-valued attribute, it
     replaces the current value.
   - Remove an attribute value. The value to be removed MUST exist.
     Further, an attribute value cannot be removed if it is the only
     value of a required attribute.

   Attribute values to be removed are identified by tagging with an "="
   suffix.



Hollenbeck & Srivastava      Informational                     [Page 14]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4.3.5.1 Domain Modification

   The request to modify a registered domain name MUST contain the
   following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The registrar can perform the following update operations on the
   domain name:

   - Update the name servers of the domain name by setting one or more
     instances of the "NameServer" parameter.
   - Update the status of the domain name by setting one or more
     instances of the "Status" parameter. Valid values for the "Status"
     parameter are defined in Section 6.

   Authorized User: The current registrar of a domain name MAY use the
   MOD command to modify the attributes of a domain name.

   Examples

   A registrar removes one name server (ns1) from a domain and adds a
   new name server (ns3) to the same domain:

   C:mod<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:NameServer:ns3.registrarA.com<crlf>
   C:NameServer:ns1.registrarA.com=<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.5.2 Name Server Modification

   The request to update a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified server name of the name server in the "NameServer"
     parameter.









Hollenbeck & Srivastava      Informational                     [Page 15]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   The registrar can perform the following update operations on the name
   server:

   - Update the "NameServer" attribute of the name server. This allows a
     registrar to change the name of a name server while preserving all
     existing associations.
   - Update the IP addresses of the name server by setting one or more
     instances of the "IPAddress" parameter.

   Authorized User: The current registrar of a name server MAY use the
   MOD command to modify the attributes of a domain name.

   Examples

   A registrar changes the name and IP address of a name server:

   C:mod<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:NewNameServer:ns2.registrarA.com<crlf>
   C:IPAddress:198.42.1.11<crlf>
   C:IPAddress:198.41.1.11=<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.6 QUIT

   This command allows a registrar to close an RRP connection. A
   response MUST be sent before closing the connection.

   Authorized User: All registrars MAY use the QUIT command.

   Examples

   A registrar ends an RRP session and closes an existing connection:

   C:quit<crlf>
   C:.<crlf>
   S:220 Command completed successfully. Server closing connection<crlf>
   S:.<crlf>










Hollenbeck & Srivastava      Informational                     [Page 16]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4.3.7 RENEW

   This command allows a registrar to renew a domain name in the System.
   The request to renew a domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The request to renew a domain name MAY contain the renewal period in
   years for the domain being renewed in a single instance of a "Period"
   parameter and a single instance of a "CurrentExpirationYear"
   parameter. These parameters MUST appear together if either is
   specified, though the order in which the parameters appear is
   insignificant. The "Period" parameter identifies the number of years
   to be added to the registration. The "CurrentExpirationYear"
   parameter identifies the current expiration year, and is required to
   ensure that repeated attempts to retry this command do not result in
   multiple successful renewals. The System MUST provide a default
   number of renewal years if the "Period" and "CurrentExpirationYear"
   parameters are not provided. Repeated use of this command without the
   "Period" and "CurrentExpirationYear" parameters may result in
   repeated successful renewals since idempotency is not provided when
   these parameters are not used. The acceptable year values for the
   "Period" parameter are implementation specific subject to syntax
   restrictions.

   The System renews the domain name for a period specified by the
   registrar. If the domain name renewal is completed successfully, the
   System MUST return the new registration expiration date in the
   "RegistrationExpirationDate" attribute in the response.

   Authorized User: The current registrar of a domain name MAY use the
   RENEW command.

   Examples

   A registrar renews a domain name using a specified renewal period:

   C:renew<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:-Period:9<crlf>
   C:-CurrentExpirationYear:2001<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:registration expiration date:2010-09-22 10:27:00.0<crlf>
   S:.<crlf>



Hollenbeck & Srivastava      Informational                     [Page 17]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4.3.8 SESSION

   This command allows a registrar to establish an RRP session. A
   registrar can also use this command to change their password. The
   request to establish an RRP connection MUST contain the following
   command parameters:

   - The "Id" parameter set to the registrar's System user ID.
   - The "Password" parameter set to the registrar's current System
     password.

   The request to establish an RRP session MAY contain a new password
   for the registrar in a single instance of the "NewPassword"
   parameter.

   The registrar MUST send this command to the System before any other
   command.  If the command fails due to invalid information (such as an
   invalid registrar ID or password), the registrar can resend this
   request with corrected information. If the command fails a second
   time, the System SHOULD close the connection.

   Authorized User: All registrars MAY use the SESSION command.

   Examples

   A registrar establishes an RRP session:

   C:session<crlf>
   C:-Id:registrarA<crlf>
   C:-Password:i-am-registrarA<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

4.3.9 STATUS

   This command allows a registrar to determine the current status of a
   domain name or name server.

4.3.9.1 Domain Status

   The request to query a domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.





Hollenbeck & Srivastava      Informational                     [Page 18]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   The response from the System MAY contain the following data:

   - Fully qualified server names of name servers hosting the domain
     name in multiple instances of the "nameserver" attribute.
   - Registration expiration date in the "registration expiration date"
     attribute.
   - ID of the current registrar of the domain name in the "registrar"
     attribute.
   - Date the domain name was transferred by the current registrar in
     the "registrar transfer date" attribute.
   - Current statuses of the domain name in multiple instances of the
     "status" attribute.
   - Date the domain name was originally registered in the "created
     date" attribute.
   - ID of the registrar that originally registered the domain name in
     the "created by" attribute.
   - Date the domain name was last updated in the "updated date"
     attribute.
   - ID of the entity (either a registrar or the registry) that last
     updated the domain name in the "updated by" attribute.

   Authorized User: The current registrar of a domain name MAY use the
   STATUS command to view current domain name attributes.

   Examples

   The current registrar of a domain name queries the domain name:

   C:status<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:nameserver:ns2.registrarA.com<crlf>
   S:nameserver:ns3.registrarA.com<crlf>
   S:registration expiration date:2010-09-22 10:27:00.0<crlf>
   S:registrar:registrarA<crlf>
   S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
   S:status:ACTIVE<crlf>
   S:created date:1998-09-22 10:27:00.0<crlf>
   S:created by:registrarA<crlf>
   S:updated date:2002-09-22 10:27:00.0<crlf>
   S:updated by:registrarA<crlf>
   S:.<crlf>







Hollenbeck & Srivastava      Informational                     [Page 19]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   A registrar queries a domain name currently registered by another
   registrar:

   C:status<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:531 Authorization failed<crlf>
   S:.<crlf>

4.3.9.2 Name Server Status

   The request to query a name server MUST contain the following data:

   - The "EntityName" parameter set to value "NameServer".
   - Fully qualified name of the name server in the "NameServer"
     parameter.

   The response from the System MAY contain the following data:

   - Fully qualified name of the name server in the "nameserver"
     attribute.
   - IP addresses of the name server in multiple instances of the
     "ipaddress" attribute.
   - ID of the current registrar of the name server in the "registrar"
     attribute.
   - Date the name server was transferred by the current registrar in
     the "registrar transfer date" attribute.
   - Date the name server was registered in the "created date"
     attribute.
   - ID of the entity that registered the name server in the "created
     by" attribute.
   - Date the name server was last updated in the "updated date"
     attribute.
   - ID of the entity that last updated the name server in the "updated
     by" attribute.

   Authorized User: The current registrar of a name server MAY use the
   STATUS command to view current domain name attributes.

   Examples

   The current registrar of a name server queries the name server:

   C:status<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>



Hollenbeck & Srivastava      Informational                     [Page 20]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   S:200 Command completed successfully<crlf>
   S:ipaddress:198.42.1.11<crlf>
   S:registrar:registrarA<crlf>
   S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
   S:CreatedDate:1998-09-22 10:27:00.0<crlf>
   S:CreatedBy:registrarA<crlf>
   S:UpdatedDate:2002-09-22 10:27:00.0<crlf>
   S:UpdatedBy:registrarA<crlf>
   S:.<crlf>

   A registrar queries a name server that was registered by another
   registrar:

   C:status<crlf>
   C:EntityName:NameServer<crlf>
   C:NameServer:ns1.registrarA.com<crlf>
   C:.<crlf>
   S:531 Authorization failed<crlf>
   S:.<crlf>

4.3.10 TRANSFER

   This command allows a registrar to request transfer of domain name
   sponsorship from a second registrar and to approve or reject transfer
   requests initiated by other registrars. The request to transfer a
   domain name MUST contain the following data:

   - The "EntityName" parameter set to value "Domain".
   - Fully qualified second level domain name in the "DomainName"
     parameter.

   The identity of the requesting registrar is derived from the current
   active session. The identity of the current sponsoring registrar (the
   registrar who must approve or reject the transfer request) is known
   by the registry and does not need to be known by the requesting
   registrar in advance of issuing the transfer request.

   The System MUST notify the potential losing registrar when a domain
   transfer request has been received using an out-of-band transport
   mechanism such as electronic mail and/or transaction reporting. The
   losing registrar SHOULD then explicitly approve or reject the
   transfer. A request to approve or reject a transfer request MUST
   contain a single instance of the "Approve" parameter with a value of
   "Yes" to approve the transfer or a value of "No" to reject the
   transfer. A server implementation MAY provide a default approval or
   rejection action to be taken if the losing registrar does not
   explicitly approve or reject the transfer request within a fixed
   amount of time. The criteria used by registrars to approve or deny



Hollenbeck & Srivastava      Informational                     [Page 21]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   requested transfers are typically based on business policies that are
   beyond the scope of this document.

   Approval of a transfer by the current sponsoring registrar results in
   a change of sponsorship to the original requesting registrar.
   Approval attempts by any other registrar MUST result in explicit
   failure of the attempted approval.  Rejection of the transfer by the
   current sponsoring registrar results in an end to the transfer
   request with no change in sponsorship. Rejection attempts by any
   other registrar MUST result in explicit failure of the attempted
   rejection.

   Name servers MUST be implicitly transferred when their parent domain
   name is transferred.

   Authorized User: All registrars MAY use the TRANSFER command to
   request transfer of registration service authority to the requesting
   registrar. Only the current sponsoring registrar of a domain name may
   explicitly approve or reject a requested transfer. The registry MAY
   implicitly approve or reject requested transfers after a fixed amount
   of time.

   Examples

   A registrar requests transfer of a domain name from another
   registrar:

   C:transfer<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>

   The original registrar approves the transfer request:

   C:transfer<crlf>
   C:-Approve:Yes<crlf>
   C:EntityName:Domain<crlf>
   C:DomainName:example.com<crlf>
   C:.<crlf>
   S:200 Command completed successfully<crlf>
   S:.<crlf>








Hollenbeck & Srivastava      Informational                     [Page 22]

RFC 2832            NSI Registry Registrar Protocol             May 2000


5. Response Codes

   RRP commands may return a variety of response codes to signify normal
   completion or error conditions. This section documents all of the
   defined RRP response codes.

5.1 Response Code Summary

   200 Command completed successfully
   This is the normal response for successful completion of most RRP
   commands.

   210 Domain name available
   This is the normal response for successful completion of an RRP CHECK
   command for a domain name that is not currently registered.

   211 Domain name not available
   This is the normal response for successful completion of an RRP CHECK
   command for a domain name that is currently registered.

   212 Name server available
   This is the normal response for successful completion of an RRP CHECK
   command for a name server that is not currently registered.

   213 Name server not available
   This is the normal response for successful completion of an RRP CHECK
   command for a name server that is currently registered.

   220 Command completed successfully. Server closing connection This is
   the normal response for successful completion of an RRP QUIT command.
   It may also be returned by other RRP commands if a transient
   situation is noted that requires closing the connection after
   successfully completing the RRP command.

   420 Command failed due to server error. Server closing connection A
   transient server error has caused RRP command failure and session
   termination. A new session must be established before continued
   processing can be attempted.

   421 Command failed due to server error. Client should try again A
   transient server error has caused RRP command failure. A subsequent
   retry may produce successful results.

   500 Invalid command name
   A client-specified RRP command name was not recognized as a valid RRP
   command name.





Hollenbeck & Srivastava      Informational                     [Page 23]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   501 Invalid command option
   A client-specified RRP command parameter was not recognized as a
   valid RRP command parameter.

   502 Invalid entity value
   The "value" of an entity name-value pair is invalid. Command blocks
   that require an "EntityName" parameter also require a value that
   specifies the entity name, and the provided value is invalid.

   503 Invalid attribute name
   A client-specified RRP command parameter was not recognized as a
   valid RRP command parameter.

   504 Missing required attribute
   A parameter required to execute the RRP command was not provided by
   the client. The command should be retried with all required
   parameters specified.

   505 Invalid attribute value syntax
   A supplied parameter value is syntactically incorrect. For example, a
   year value digit such as "5" may be required but the client provided
   a string of characters such as "five".

   506 Invalid option value
   A client-specified value for an RRP command parameter is out-of-
   bounds or otherwise not within acceptable System limits.

   507 Invalid command format
   The specified command does not resemble a well-formed RRP command.
   The command should be retried using the proper command structure and
   syntax.

   508 Missing required entity
   An entity required for command completion was not provided by the
   client. For example, the CHECK command requires specification of
   either a "Domain" entity or a "Nameserver" entity.

   509 Missing command option
   A command parameter that isn't really optional (such as the registrar
   ID in a SESSION command) was not provided by the client. The command
   should be retried with all needed parameters.

   520 Server closing connection. Client should try opening new
   connection; <why>
   A timeout event has been detected, and the client's session is being
   ended.  The System SHOULD define timeout periods to begin a client





Hollenbeck & Srivastava      Informational                     [Page 24]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   command, complete a client command, and for the duration of an open
   session. The reason for the timeout MUST be provided at the end of
   the response code string.

   521 Too many sessions open. Server closing connection
   A System-defined limit on the number of open connections has been
   exceeded, and it is impossible to establish a new session at the
   moment. It may be possible to establish a session by waiting for a
   few moments or by closing existing unused sessions.

   530 Authentication failed
   The client-supplied registrar identifier or password was not
   recognized by the System. A subsequent retry with valid values may
   produce successful results. Repeated authorization failures MAY
   result in termination of the TCP connection.

   531 Authorization failed
   Registrars may not view or alter data associated with either the
   registry or another registrar. This response code is typically
   returned when a registrar attempts to view or modify data belonging
   to either the registry or another registrar. A typical situation
   includes doing a STATUS command for a domain registered to another
   registrar.

   532 Domain names linked with name server
   The name server is hosting active domains. This error occurs when a
   registrar is trying to delete a server that is the name server for
   active domains.  The registry MUST not allow the registrar to delete
   this server. All of the domain names using this server MUST be
   modified to use a different name server before the name server can be
   deleted.

   533 Domain name has active name servers
   The domain name has active name servers. The registrar is trying to
   delete a domain name that is a parent domain of an active name
   server, i.e., a server that is hosting active domains. All of the
   name servers within the domain MUST be removed from service before
   the domain can be deleted.

   534 Domain name has not been flagged for transfer
   The registrar is trying to approve or reject a domain name transfer
   for a domain name that is not pending transfer.

   535 Restricted IP address
   IANA identifies certain IP address ranges that are not valid for
   normal use.  The registrar is trying to use an IP address that is in
   a restricted IP address range as identified by IANA.




Hollenbeck & Srivastava      Informational                     [Page 25]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   536 Domain already flagged for transfer
   The registrar tried to perform a transfer command for a domain name
   that is awaiting approval of an earlier transfer request.

   540 Attribute value is not unique
   A supplied attribute value is not unique. This occurs when the
   registrar is adding a domain name that already exists in the
   registry, a server that already exists in the registry, or an IP
   address that is already being used by another server in the registry.
   Another possibility occurs when performing domain modifications and
   the registrar is adding a server that is already in the list of
   servers for the domain name or setting a domain name to a status to
   which it is already set. The RRP STATUS command MAY be used to
   determine current domain name status before attempting to change the
   status. When modifying or adding a name server, the IP address of the
   name server might not be unique. The registry MUST not allow IP
   addresses to be used by more than one server.

   541 Invalid attribute value
   A supplied parameter value is invalid. Examples of invalid attribute
   values include an invalid IP address, an invalid domain name, an
   invalid server name, or an invalid renewal period.

   542 Invalid old value for an attribute
   A current attribute value to be modified is invalid. The registrar is
   trying to modify an attribute of a server or a domain name that does
   not exist in the registry.

   543 Final or implicit attribute cannot be updated
   The registrar is attempting to modify an attribute that is only
   modifiable by the registry. Registrars can not modify final or
   implicit attribute values.

   544 Entity on hold
   The attempted operation was rejected because the entity is on HOLD
   status. If the HOLD status was set by the registrar, the status can
   be changed using the MOD command and the requested command can be
   retried. If the HOLD status was set by the registry, the registrar
   must contact the registry to change the status before the command can
   be successful.

   545 Entity reference not found
   A required entity reference was not found. This occurs when the
   registrar tries to add a new name server and the parent domain of the
   name server does not exist in the registry. It also occurs when the
   user is trying to add a new name server to a domain name when the
   name server does not exist in the registry.




Hollenbeck & Srivastava      Informational                     [Page 26]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   546 Credit limit exceeded
   The registrar's credit limit has been exceeded. This is an
   implementation specific error that occurs when a potentially billable
   operation, such as adding a domain name, renewing a domain name, or
   transferring a domain name, is attempted and the registrar does not
   have sufficient financial standing with the registry to complete the
   operation.

   547 Invalid command sequence
   RRP commands are issued using a well-formed syntax that requires
   entry of command structures in particular sequences. This response
   code indicates that an ill-formed command was received and rejected.

   548 Domain is not up for renewal
   A RENEW command was attempted during a period in which the domain can
   not be renewed. Implementations MAY limit renewal periods to
   particular time frames, such as within 90 days of the domain's
   expiration. This response indicates that the RENEW command was
   received outside of the System-defined domain renewal period.

   549 Command failed
   A System error prevented successful completion of the requested RRP
   command.  Retrying the command might produce success, but a repeated
   failure indicates a System error condition.

   550 Parent domain not registered
   The parent domain of a name server being registered is not
   registered. This occurs when the registrar tries to add a new name
   server and the parent domain for the server does not exist in the
   registry.

   551 Parent domain status does not allow for operation
   The status of the parent domain does not allow the requested
   operation. This occurs when a registrar tries to modify a server
   whose parent domain is flagged as LOCK or HOLD in the registry.

   552 Domain status does not allow for operation
   The status of the domain does not allow the requested operation. This
   occurs when a registrar tries to modify or delete a domain that is
   flagged as LOCK or HOLD in the registry.

   553 Operation not allowed. Domain pending transfer
   The status of the domain does not allow the requested operation. The
   registrar is attempting to delete a domain that is pending approval
   or denial of a transfer request.






Hollenbeck & Srivastava      Informational                     [Page 27]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   554 Domain already registered
   A registrar tried to register a domain name that has already been
   registered by the same registrar.

   555 Domain already renewed
   A registrar tried to renew a domain using the same parameters as
   specified for an earlier, successful renewal. This will commonly
   occur when executing the same RENEW command more than once.

   556 Maximum registration period exceeded
   A registrar tried to renew a domain registration, and the resulting
   new registration period exceeds the System-defined maximum
   registration period. If there is renewal time available with the
   System-defined maximum registration period it may be possible to
   retry the RENEW command with specified renewal period parameters.

5.2 Command-Response Correspondence

   The session between the client and the server is intended to be an
   alternating dialogue. Each command issued by a client MUST be acted
   upon by the server, which MUST return a response code to document the
   success or failure of command execution. "Success" means that the
   command completed normal execution without error.  "Failure" means
   that the System did not complete the command as requested. Failure
   may be due to either syntax, semantic, data, or System errors.

   A complete list of response codes for each RRP command is listed
   below.

   Command: ADD
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
   540, 541, 545, 546, 547, 549, 550, 554

   Command: CHECK
   Success: 210, 211, 212, 213
   Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541,
   547, 549

   Command: DEL
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532,
   533, 541, 544, 545, 547, 549, 551, 552, 553

   Command: DESCRIBE
   Success: 200, 220
   Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549




Hollenbeck & Srivastava      Informational                     [Page 28]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   Command: MOD
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
   540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553

   Command: QUIT
   Success: 220
   Failure: 420, 421, 500, 507, 520, 547, 549

   Command: RENEW
   Success: 200, 220
   Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541,
   545, 546, 547, 548, 549, 552, 553, 555, 556

   Command: SESSION
   Success: 200, 220
   Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531,
   547, 549

   Command: STATUS
   Success: 200, 220
   Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
   531, 541, 545, 547, 549

   Command: TRANSFER
   Success: 200, 220
   Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
   531, 534, 536, 541, 544, 545, 546, 547, 549, 552, 553

6. Domain Status Codes

   The status of a domain can be viewed using the RRP STATUS command and
   modified using the RRP MOD command. Both the registry and the
   sponsoring registrar MAY view and change the status of a domain. The
   criteria for status changes are highly dependent on registry and
   registrar business models and are thus beyond the scope of this
   specification.

   The domain's status SHOULD have a direct bearing on whether or not
   the domain appears in the appropriate TLD zone file and whether or
   not the domain can be modified. A domain can have more than one
   assigned status, e.g., REGISTRAR-HOLD and REGISTRAR-LOCK. If a domain
   is in ACTIVE status, then the domain name can only be in this status.
   When a registrar sets a domain name to REGISTRAR-LOCK, the registry
   MUST automatically remove the ACTIVE status. When the registrar
   removes the REGISTRAR-LOCK and other domain statuses, the registry
   MUST automatically set the domain name status to ACTIVE.




Hollenbeck & Srivastava      Informational                     [Page 29]

RFC 2832            NSI Registry Registrar Protocol             May 2000


6.1 Domain Status Code Description

   ACTIVE: This is the default status of a domain at registration time.
   The registry sets the domain to this status. The domain is modifiable
   by the registrar. The domain can be renewed. The domain SHALL be
   included in the zone file when in this status if the domain has at
   least one associated name server.

   REGISTRY-LOCK: The registry sets the domain to this status. The
   domain cannot be modified or deleted by the registrar. The registry
   MUST remove the REGISTRY-LOCK status for the registrar to modify the
   domain. The domain can be renewed. The domain SHALL be included in
   the zone file when in this status if the domain has at least one
   associated name server.

   REGISTRY-HOLD: The registry sets the domain to this status. The
   domain cannot be modified or deleted by the registrar. The registry
   MUST remove the REGISTRY-HOLD status for the registrar to modify the
   domain. The domain can be renewed. The domain SHALL NOT be included
   in the zone file when in this status.

   REGISTRAR-HOLD: The registrar of the domain sets the domain to this
   status. The domain can not be modified or deleted when in this
   status. The registrar MUST remove REGISTRAR-HOLD status to modify the
   domain. The domain can be renewed. The domain SHALL NOT be included
   in the zone file when in this status.

   REGISTRAR-LOCK: The registrar of the domain sets the domain to this
   status. The domain cannot be modified or deleted when in this status.
   The registrar MUST remove REGISTRAR-LOCK status to modify the domain.
   The domain can be renewed. The domain SHALL be included in the zone
   file when in this status.

   REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has
   expired and has child name servers that are hosting other domains.
   Only the registry may set this status. The domain SHALL be included
   in the zone file when in this status if the domain has at least one
   associated name server.

7. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0
; Note that character string literals are case insensitive.





Hollenbeck & Srivastava      Informational                     [Page 30]

RFC 2832            NSI Registry Registrar Protocol             May 2000


; Lexical tokens
space = %x20 ; " "
dot = %x2E ; "."
dash = %x2D ; "-"
underscore = %x5F ; "_"
colon = %x3A ; ":"
cr = %x0D ; ASCII carriage return
lf = %x0A ; ASCII linefeed
crlf = cr lf
alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
dns-char = alpha / digit / dash
id-char = alpha / digit / underscore / dash
id-prefix = alpha / digit
id-word = id-prefix *id-char
printable-char = %x20-7E ; ASCII " " - "~"

; Start of basic grammar.
year = 4digit
month = 2digit
day = 2digit
ymd = year dash month dash day
hour = 2digit
minute = 2digit
second = 2digit
split-second = 1digit
hms = hour colon minute colon second dot split-second
time-stamp = ymd space hms
ip-address = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
password = 4*16printable-char
option-name = 1*128id-word
option-tag = dash option-name
option-value = 1*128id-word
attribute-name = 1*128id-word
attribute-value = 1*128printable-char
attribute-line = attribute-name colon attribute-value crlf
response = 3digit space 1*printable-char crlf
version-number = "RRP" space 1*digit dot 1*digit dot 1*digit
label = id-prefix [*61dns-char id-prefix]
sldn = label dot label
servername = *(label dot) sldn
period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99"
period-option = dash "Period" colon period crlf
yesno = "Yes" / "No"
domainstatus = "Active" / "Registry-Lock" / "Registry-Hold" /
               "Registrar-Lock" / "Registrar-Hold" /
               "Registry-Delete-Notify"




Hollenbeck & Srivastava      Informational                     [Page 31]

RFC 2832            NSI Registry Registrar Protocol             May 2000


; RRP commands and responses.
rrp = add / check / delete / describe / mod / quit / renew /
      session / status / transfer

add = add-request add-response
check = check-request check-response
delete = del-request del-response
describe = describe-request describe-response
mod = mod-request mod-response
quit = quit-request quit-response
renew = renew-request renew-response
session = session-request session-response
status = status-request status-response
transfer = transfer-request transfer-response

; ADD command.
add-request = add-domain-request / add-nameserver-request
add-response = add-domain-response / add-nameserver-response
add-domain-request = "add" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 [period-option]
 0*13("NameServer" colon servername crlf)
 dot crlf
add-nameserver-request = "add" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 1*("IPAddress" colon ip-address crlf)
 dot crlf
add-domain-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
 "status" colon domainstatus crlf
 dot crlf
add-nameserver-response = response
 dot crlf

; CHECK command.
check-request = check-domain-request / check-nameserver-request
check-response = check-domain-response / check-nameserver-response
check-domain-request = "check" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
check-nameserver-request = "check" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf
check-domain-response = response



Hollenbeck & Srivastava      Informational                     [Page 32]

RFC 2832            NSI Registry Registrar Protocol             May 2000


 dot crlf
check-nameserver-response = available-check-nameserver-response /
                            notavailable-check-nameserver-response
available-check-nameserver-response = response
 dot crlf
notavailable-check-nameserver-response = response
 1*("IPAddress" colon ip-address crlf)
 dot crlf

; DEL command.
del-request = del-domain-request / del-nameserver-request
del-response = response
 dot crlf
del-domain-request = "del" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
del-nameserver-request = "del" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf

; DESCRIBE command.
describe-request = "describe" crlf
 [target-option]
 *(option-tag colon option-value crlf)
 dot crlf
describe-response = response
 "Protocol" colon version-number crlf
 *attribute-line
 dot crlf
target-option = dash "Target" colon "Protocol" crlf

; MOD command.
mod-request = mod-domain-request / mod-nameserver-request
mod-response = response
 *attribute-line
 dot crlf
mod-domain-request = "mod" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 *(add-attribute-value-line /
 remove-attribute-value-line /
 replace-attribute-value-line)







Hollenbeck & Srivastava      Informational                     [Page 33]

RFC 2832            NSI Registry Registrar Protocol             May 2000


 dot crlf
mod-nameserver-request = "mod" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 ["NewNameServer" colon attribute-value crlf]
 *(add-attribute-value-line /
 remove-attribute-value-line /
 replace-attribute-value-line)
 dot crlf
add-attribute-value-line =
 attribute-name colon new-attribute-value
remove-attribute-value-line =
 attribute-name colon old-attribute-value "="
replace-attribute-value-line =
 attribute-name colon old-attribute-value "="
 new-attribute-value
old-attribute-value = attribute-value
new-attribute-value = attribute-value

; QUIT command.
quit-request = "quit" crlf
 dot crlf
quit-response = response
 dot crlf

; RENEW command.
renew-request = "renew" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 [renew-period-option]
 dot crlf
expiration-year-option = dash "CurrentExpirationYear" colon year crlf
renew-period-option = period-option expiration-year-option /
                      expiration-year-option period-option
renew-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
 dot crlf

; SESSION command.
session-request = "session" crlf
 registrar-id-option
 registrar-password-option
 [registrar-newpassword-option]
 dot crlf
session-response = response
 dot crlf
registrar-id-option = dash "Id" colon option-value crlf
registrar-password-option =



Hollenbeck & Srivastava      Informational                     [Page 34]

RFC 2832            NSI Registry Registrar Protocol             May 2000


 dash "Password" colon password crlf
registrar-newpassword-option =
 dash "NewPassword" colon password crlf

; STATUS command.
status-request = status-domain-request /
                 status-nameserver-request
status-response = response
 *attribute-line
 dot crlf
status-domain-request = "status" crlf
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
status-nameserver-request = "status" crlf
 "EntityName" colon "NameServer" crlf
 "NameServer" colon servername crlf
 dot crlf

; TRANSFER command.
transfer-request = "transfer" crlf
 [approve-option]
 "EntityName" colon "Domain" crlf
 "DomainName" colon sldn crlf
 dot crlf
transfer-response = response
 "RegistrationExpirationDate" colon time-stamp crlf
 dot crlf
approve-option = dash "Approve" colon yesno crlf

; End of grammar.

8. Internationalization

   RRP is defined using 7-bit US-ASCII characters. Other character sets
   and character codes are not currently supported.

9. Known Issues

   RRP was not designed to provide bulk data query features. The primary
   goal of the original protocol designers was to provide a fast, light
   weight transactional protocol that could be implemented with minimal
   need for database queries that would take a "long" time to complete
   or that would return a "large" amount of data. Implementers SHOULD
   consider developing offline reporting features to provide bulk data
   for registrar reporting in a fashion suitable for the given
   registry-registrar operating environment.




Hollenbeck & Srivastava      Informational                     [Page 35]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   This version of RRP does contain a few limitations noted over the
   course of several months of operational experience with live domain
   name registrars.  Later versions of this protocol or its successors
   should strive to resolve or address each of the following issues:

   The DESCRIBE command should return information describing System-
   defined default implementation values.

   Use of the RENEW command without the "CurrentExpirationYear" and
   "Period" parameters does not provide idempotency. Repeated execution
   of a RENEW command without these parameters can result in multiple
   successful RENEW commands, which may not be the desired action if a
   registrar is retrying a RENEW command due to network connectivity
   problems.

   Time stamps returned by RRP do not include time zone identifiers and
   SHOULD be interpreted as local registry time.

   The protocol does not provide features for a registrar to become
   aware of domain transfer requests and responses. Systems must rely on
   means outside of the protocol, such as electronic mail and/or
   registry-provided reports, to inform registrars of transfer requests
   and responses.

   The protocol does not provide features for a registrar to determine
   all of the domains served by a name server. Systems must provide this
   information using a method outside of the protocol, such as through
   periodic extracts from a System database.

   The protocol does not provide features to manage lame delegation of
   name servers. Any registrar may "use" name servers registered by
   another registrar.  When a registrar tries to delete a domain or name
   server it is quite possible that name servers in the domain to be
   deleted or the name server to be deleted will be associated with
   other live domains, precluding immediate deletion.  Systems must rely
   on means outside of the protocol to manage lame delegation of name
   servers.

   The use of "=" within the MOD command to indicate a value to be
   removed is somewhat confusing. A more explicit means of identifying
   old and new attribute values within the protocol syntax could make
   this feature more obvious.

   The CHECK command also returns name server IP addresses when
   returning positive confirmation of the registration of a name server.
   This extra information may be useful, but it is inconsistent with the
   limited function of the command.  The command should return a
   positive or negative response and nothing more.



Hollenbeck & Srivastava      Informational                     [Page 36]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   The formal protocol syntax described in this document requires a
   specific order for the elements of a command entity block and command
   options. The NSI Registry's server-side implementation of the
   protocol provides the additional flexibility of allowing order
   independent specification of options and entity block elements.
   Client-side implementers are strongly urged to observe the order of
   command elements as specified here to ensure compliance if the more
   restricted form is enforced in the future.

   RRP does not return time stamps or transaction identifiers to track
   transactions. The NSI Registry provides registrars with daily and
   weekly reports that include time stamps in local registry time to
   document and synchronize data on a per-registrar basis.

10. Security Considerations

   Misuse of the Registry Registrar Protocol can have catastrophic
   operational consequences for registrants, registrars, and registries.
   As such, all registrars must be authenticated prior to all
   interactions with the registry.  In addition, all data exchanged
   between the registrar and the registry must be protected to avoid
   unintended disclosure of information.

11. IANA Considerations

   IANA assigned TCP port 648 for RRP use in November 1998. No other
   action is required of IANA to support operation of this protocol.

   IANA has reserved certain IPv4 address ranges as described in
   [ALLOCATION].  Implementers MUST ensure that name server IP addresses
   do not fall into one of the reserved address ranges to avoid
   operational DNS errors.

12. References

   [ABNF]       Crocker, D. (Editor) and P. Overell, "Augmented BNF for
                Syntax Specifications: ABNF", RFC 2234, November 1997.

   [ALLOCATION] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and
                J. Postel, "Internet Registry IP Allocation Guidelines",
                BCP 12, RFC 2050, November 1996.

   [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.







Hollenbeck & Srivastava      Informational                     [Page 37]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   [SSL]        A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
                Protocol", Netscape Communications Corp., November 18,
                1996.

   [TLS]        Dierks T. and C. Allen, "The TLS Protocol Version 1.0",
                RFC 2246, January 1999.

13. Acknowledgments

   Many people have contributed significantly to this document and the
   protocol it describes. Brad McMillen and Neeran Saraf deserve special
   mention as co-authors of an earlier internal protocol specification.
   Other content contributors to the earlier internal specification
   include Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh,
   and Yibing Wu. Finally, significant contributors to the review of
   this document include Steve Mahlstedt and Chris Smith.

14. Authors' Addresses

   Scott Hollenbeck
   Network Solutions, Inc. Registry
   505 Huntmar Park Dr.
   Herndon, VA 20170
   USA

   EMail: shollenb@netsol.com


   Manoj Srivastava
   Network Solutions, Inc. Registry
   505 Huntmar Park Dr.
   Herndon, VA 20170
   USA

   EMail: manojs@netsol.com
















Hollenbeck & Srivastava      Informational                     [Page 38]

RFC 2832            NSI Registry Registrar Protocol             May 2000


15.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hollenbeck & Srivastava      Informational                     [Page 39]