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
|
<pre>Network Working Group A. Newton
Request for Comments: 3663 VeriSign, Inc.
Category: Experimental December 2003
<span class="h1">Domain Administrative Data</span>
<span class="h1">in Lightweight Directory Access Protocol (LDAP)</span>
Status of this Memo
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
<span class="grey">Newton Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
1.1. Historical Directory Services for Domain Registration
Data . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Motivations. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Abbreviations Used . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Service Description. . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1.1">3.1.1</a>. DIT Structure. . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1.2">3.1.2</a>. Allowed Searches . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.1.3">3.1.3</a>. Access Control . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Name Server DIT. . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.2.1">3.2.1</a>. DIT Structure. . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.2.2">3.2.2</a>. Allowed Searches . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Registrar Referral DIT . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.3.1">3.3.1</a>. DIT Structure. . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.1.1">4.1.1</a>. DIT Structure. . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.1.2">4.1.2</a>. Allowed Searches . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1.3">4.1.3</a>. Access Control . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Name Server and Contact DIT. . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.1">4.2.1</a>. DIT Structure. . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.2">4.2.2</a>. Allowed Searches . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. Intra-Server Referrals . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.2">6.2</a>. Inter-Server Referrals . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. Common DIT . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.4">6.4</a>. Universal Client . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.5">6.5</a>. Targeting Searches by Tier . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.6">6.6</a>. Data Mining. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7">7</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. Internationalization Considerations. . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9">9</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10">10</a>. Intellectual Property Statement. . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11">11</a>. Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A">Appendix A</a>. Other Work. . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-B">Appendix B</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Newton Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes the Referral Lightweight Directory Access
Protocol (LDAP) Service, an experimental project launched by
VeriSign, Inc., to explore the use of LDAP and LDAP-related
technologies for use as a directory service of administrative domain
registration information.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Historical Directory Services for Domain Registration Data</span>
The original National Science Foundation contract for the InterNIC
called for the creation of an X.500 directory service for the
administrative needs of the domain registration data and information.
Due to problems with implementations of X.500 server software, a
server based on the Nicname/Whois [<a href="#ref-1" title=""NICNAME/WHOIS"">1</a>] protocol was temporarily
erected.
In 1994, the Rwhois [<a href="#ref-3" title=""Referral Whois (RWhois) Protocol V1.5"">3</a>] protocol was introduced to enhance the
Nicname/Whois protocol. This directory service never gained wide
acceptance for use with domain data.
Presently, ICANN requires the operation of Nicname/Whois servers by
registries and registrars of generic Top-Level Domains (TLD's).
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Motivations</span>
With the recent split in functional responsibilities between
registries and registrars, the constant misuse and data-mining of
domain registration data, and the difficulties with machine-
readability of Nicname/Whois output, the creation of the Referral
LDAP Service had the following motivations:
o Use a mechanism native to the directory protocol to refer clients
from inquiries about specific domains made at a registry to the
appropriate domain within the appropriate directory service at a
registrar.
o Limit access to domain data based on authentication of the client.
o Provide structured queries and well-known and structured results.
o Use a directory service technology already in general use.
Given these general criteria, LDAP [<a href="#ref-5" title=""Lightweight Directory Access Protocol (v3)"">5</a>] was selected as the protocol
for this directory service. The decision was also made to restrict
the use of LDAP to features most readily available in common
implementations. Therefore, a goal was set to not define any new
object classes, syntaxes, or matching rules.
<span class="grey">Newton Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
The experiment was successful in exploring how LDAP might be used in
this context and demonstrating the level of customization required
for an operational service. Conclusions and observations about this
experiment are outlined in <a href="#section-6">Section 6</a>.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Abbreviations Used</span>
The following abbreviations are used to describe the nature of this
experiment:
TLD: Top-Level Domain. Refers to the domain names just beneath
the root in the Domain Name System. This experiment used the
TLD's .com, .net, .org, and .edu.
SLD: Second-Level Domain. Refers to the domain names just beneath
a TLD in the Domain Name System. An example of such a domain name
would be "example.com".
DIT: Directory Information Tree. One of many hierarchies of data
entries in an LDAP server.
DN: Distinguished Name. The unique name of an entry in a DIT.
cn: common name. See <a href="./rfc2256">RFC 2256</a> [<a href="#ref-7" title=""A Summary of the X.500(96) User Schema for use with LDAPv3"">7</a>].
dc: domain component. See <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>].
uid: user id. See <a href="./rfc2798">RFC 2798</a> [<a href="#ref-9" title=""Definition of the inetOrgPerson LDAP Object Class"">9</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Service Description</span>
The service is composed of three distinct server types: a registry
LDAP server, registrar LDAP servers, and registrant LDAP servers.
The registry LDAP server contains three Directory Information Trees
(DIT's).
o The Top-Level Domain DIT's follow the DNS hierarchy for domains
(e.g., dc=foo,dc=com).
o The name server DIT allows a view of the name servers, many of
which serve multiple domains.
o The registrar-referral DIT provides referrals from the registry
into the respective TLD DIT of the registrars (on a TLD basis).
<span class="grey">Newton Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
The registrar LDAP server contains two types of DIT's.
o The TLD DIT follows the DNS hierarchy for domains (e.g.,
dc=foo,dc=com) and parallels the TLD DIT of the registry.
o The name server and contact DIT allow a view of the name servers
and contacts, many of which are associated and serve multiple
domains.
There is no specification on the DIT or schema for the registrant
LDAP server. Referrals from the registrar server to the registrant
server are provided solely for the purpose of allowing the registrant
direct control over extra administrative information as it relates to
a particular domain.
Access control for this service is merely a demonstration of using a
Distinguished Name (DN) and password. Should registries and
registrars uniformly adopt LDAP as a means to disseminate domain
registration data, standardization of these DN's would need to be
undertaken based on each type of user base.
<span class="grey">Newton Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Registry LDAP Service</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. TLD DIT</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. DIT Structure</span>
The registry TLD DIT has the following structural hierarchy:
TLD (e.g., dc=net)
|
|
-------------------------------------
| |
SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
| |
--------------------- ---------------------
| | | | | |
name server | | name server | |
(e.g., | | (e.g., | |
cn=nameserver1, | | cn=nameserver1, | |
dc=foo,dc=net ) | | dc=bar,dc=net ) | |
| | | |
name server | name server |
(e.g., | (e.g., |
cn=nameserver2, | cn=nameserver2, |
dc=foo,dc=net ) | dc=bar,dc=net ) |
| |
registrar referral registrar referral
(e.g., (e.g.,
cn=registrar, cn=registrar,
dc=foo,dc=net ) dc=bar,dc=net )
Figure 1: Registry DIT Overview
The root of a TLD DIT is an entry of objectclass domain as specified
by <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>] and represents a top-level domain.
The second tier of the DIT represents second-level domains. Each of
these entries is of objectclass domain as specified by <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>].
The description attribute on these entries often contains descriptive
text giving the name of the registrar through which these domains
have been registered.
The third tier contains entries specific to each second-level domain.
Name server entries are of objectclass ipHost as specified by <a href="./rfc2307">RFC</a>
<a href="./rfc2307">2307</a> [<a href="#ref-8" title=""An Approach for Using LDAP as a Network Information Service"">8</a>]. The distinguished names of these name server entries are
algorithmically calculated, where the first component is the word
<span class="grey">Newton Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
"nameserver" concatenated with an index number of the name server
entry and the remaining components are the appropriate domain names.
There is no specification relating the value of the name server entry
to the index it may be assigned other than it is unique and
consistent with respect to the client session. This tier also
contains the referral from the registry to the registrar. This
referral is a direct referral to the entry in the appropriate
registrar LDAP server corresponding to the domain name that the
referral falls beneath in this DIT.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Allowed Searches</span>
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to expensive searches that would be
far too costly for a publicly available service. The searches
allowed are as follows:
o One-level scoped searches based at the root of the DIT. Substring
matching is allowed on dc attributes, but the substring must be at
least be 3 characters in length.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any second level
domain name (the second tier) and below.
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Access Control</span>
The registry TLD DIT only has one access control type. When a client
binds with a DN of "cn=trademark" and password of "attorney", the
second-level domain entries also take on an objectclass of
extensibleObject with the added attributes of "createddate" and
"registrationexpirationdate", which are of type Generalized Time, as
specified by <a href="./rfc2252">RFC 2252</a> [<a href="#ref-6" title=""Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions"">6</a>].
<span class="grey">Newton Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Name Server DIT</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. DIT Structure</span>
The registry name server DIT has the following structural hierarchy:
(o=nsiregistry.com)
|
|
-------------------------------------
| | |
name server name server name server
(cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
Figure 2: Registry DIT Overview
The root of a name server DIT is an entry of objectclass organization
as specified by <a href="./rfc1617">RFC 1617</a> [<a href="#ref-2" title=""Naming and Structuring Guidelines for X.500 Directory Pilots"">2</a>]. It has no significance other than to
serve as the root of the DIT.
The second tier of this DIT represents name servers. Each of these
entries is of objectclass ipHost, as specified by <a href="./rfc2307">RFC 2307</a> [<a href="#ref-8" title=""An Approach for Using LDAP as a Network Information Service"">8</a>].
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Allowed Searches</span>
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to searches far too costly for a
publicly available service. The searches allowed are as follows:
o One-level and sub-tree scoped searches based at the root of the
DIT if a filter on the cn attribute is provided.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any name server
entry.
<span class="grey">Newton Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Registrar Referral DIT</span>
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. DIT Structure</span>
The registry registrar-referral DIT has the following structural
hierarchy:
(o=tlds)
|
|
-------------------------------
| | | |
tld tld tld tld
(dc=net) (dc=com) (dc=org) (dc=edu)
| | | |
: : | :
: : | :
|
---------------------------
| | |
referral to referral to referral to
registrar 1 registrar 2 registrar n
dc=org DIT dc=org DIT dc=org DIT
Figure 3: Registry Referral DIT Overview
The root of the registrar referral DIT is an entry of objectclass
organization, as specified by <a href="./rfc1617">RFC 1617</a> [<a href="#ref-2" title=""Naming and Structuring Guidelines for X.500 Directory Pilots"">2</a>]. It has no significance
other than to serve as the root of this DIT.
The second tier of this DIT represents top-level domains. Each of
these entries is of objectclass domain, as specified by <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>].
Underneath each TLD entry, the third tier contains referrals to the
appropriate TLD DIT of each registrar.
<span class="grey">Newton Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Registrar LDAP Service</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. TLD DIT</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. DIT Structure</span>
The registrar TLD DIT, which is similar to the registry TLD DIT, has
the following structural hierarchy:
TLD (e.g., dc=net)
|
|
------------------------------------------------
| | |
SLD (e.g., dc=foo,dc=net) : :
| : :
---------------------------------------------
| | |
| | |
name server contact referral to
(e.g., cn=nameserver1, (e.g., cn=contact1, registrant
dc=foo,dc=net ) dc=foo,dc=net )
|
|
name server contact
(e.g., cn=contact,
cn=nameserver1,
dc=foo,dc=net )
Figure 4: Registrar DIT Overview
The root of a TLD DIT is an entry of objectclass domain, as specified
by <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>] and represents a top-level domain.
The second tier of the DIT represents second-level domains. Each of
these entries is of objectclass domain, as specified by <a href="./rfc2247">RFC 2247</a> [<a href="#ref-4" title=""Using Domains in LDAP/X.500 Distinguished Names"">4</a>].
The third tier contains entries specific to each second-level domain.
The entries at this level are as follows:
o Name server entries are of objectclass ipHost, as specified by <a href="./rfc2307">RFC</a>
<a href="./rfc2307">2307</a> [<a href="#ref-8" title=""An Approach for Using LDAP as a Network Information Service"">8</a>]. The distinguished names of these name server entries
are algorithmically calculated where the first component is the
word "nameserver" concatenated with an index number of the name
server entry and the remaining components are the appropriate
domain names. There is no specification relating the value of the
name server entry to the index it may be assigned other than it is
unique and consistent with respect to the client session.
<span class="grey">Newton Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
o Contact entries are of objectclass inetOrgPerson, as specified by
<a href="./rfc2798">RFC 2798</a> [<a href="#ref-9" title=""Definition of the inetOrgPerson LDAP Object Class"">9</a>]. The distinguished names of these contact entries
are algorithmically calculated, where the first component is the
word "contact" concatenated with an index number of the contact
and the remaining components are the appropriate domain names.
There is no specification relating the value of the contact entry
to the index it may be assigned other than it is unique and
consistent with respect to the client session. The description
attribute of the entry contains the role for which a contact is
related to a domain. These roles are identified as "Admin
Contact", "Technical Contact", and "Billing Contact", and may
appear in any order.
o Finally, this third tier contains the referral from the registrar
to the registrant.
The fourth tier only contains name server contact entries. These
entries are of objectclass inetOrgPerson, as specified by <a href="./rfc2798">RFC 2798</a>
[<a href="#ref-9" title=""Definition of the inetOrgPerson LDAP Object Class"">9</a>].
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Allowed Searches</span>
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to searches far too costly for a
publicly available service. The searches allowed are as follows:
o One-level scoped searches based at the root of the DIT. Substring
matching is allowed on dc and o attributes, but the substring must
be at least 3 characters in length.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any second level
domain name (the second tier) and below.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Access Control</span>
The registrar TLD DIT has two access control types. When binding
anonymously, a client only sees dc, o, and c attributes of the
second-level domain entries. When a client binds with a DN of
"cn=trademark" and password of "attorney", all of the other
attributes normally available on entries of objectclass domain are
visible if they have values. In addition, if a client binds with the
DN of a contact and password of "password", all attributes for
second-level domain entries for which the bind DN has a relation are
visible.
<span class="grey">Newton Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Name Server and Contact DIT</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. DIT Structure</span>
The registrar name server and contact DIT has the following
structural hierarchy:
(o=nsi.com)
|
|
--------------------------------------
| |
Contacts Name Servers
(ou=contacts) (ou=name servers)
| |
----------------- ------------------------
| | | | | |
Contact : : Name Server : :
(uid=handle) : : (cn=handle) : :
|
Name Server
Contact
(cn=contact1)
Figure 5: Registrar DIT Overview
The first tier of the name server and contact DIT is an entry of
objectclass organization, as specified by <a href="./rfc1617">RFC 1617</a> [<a href="#ref-2" title=""Naming and Structuring Guidelines for X.500 Directory Pilots"">2</a>].
The second tier of the DIT contains two entries, each of which is of
objectclass organizationalUnit, as specified by <a href="./rfc2256">RFC 2256</a> [<a href="#ref-7" title=""A Summary of the X.500(96) User Schema for use with LDAPv3"">7</a>]. One
entry represents the part of the DIT containing contacts and the
other entry represents the part of the DIT containing name servers.
Entries underneath the contacts organizationalUnit entry are of
objectclass inetOrgPerson and represent contacts registered with the
registrar. Their RDN is composed of the uid attribute. The uid
attribute's value is a unique identifier or handle that is registrar
assigned.
Entries underneath the name server organizationalUnit entry are of
objectclass ipHost and represent name servers registered with the
registrar. Their RDN is composed of the cn attribute. The cn
attribute's value is a unique identifier or handle that is registrar
assigned. Each name server entry may optionally have children
entries of objectclass inetOrgPerson. These entries represent the
contacts of the name server they fall beneath.
<span class="grey">Newton Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Allowed Searches</span>
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to searches far too costly for a
publicly available service. The searches allowed are as follows:
o One-level and base searches at the root of the DIT.
o Sub-tree searches at the root of the DIT using cn and uid
attributes as a filter.
o Base searches at either entry of the second tier.
o One-level and sub-tree searches at either entry of the second
tier, using cn or uid attributes as a filter.
o Base, one-level, and sub-tree searches based at any contact or
name server entry and below.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Clients</span>
Early scoping and analysis of this project were based on the use of
output from command line clients, specifically the "ldapsearch"
command present with many implementations of LDAP servers. Our
survey of this tool, available from many vendors, showed that
referral chasing was difficult to control or predict, and the
behavior between these implementations with respect to referral
chasing was inconsistent.
Based on the limited nature of the expressive capabilities present
with just command line tools, searches involving nested queries or
advanced referral chasing were deemed the domain of clients making
direct use of LDAP client libraries. Three of these types of clients
were produced: a web-based client, a cross-platform C-based client,
and a Java client. No significant deficiencies or problems were
found with the LDAP client libraries in the construction of these
clients, and the level of control provided by their programming
interfaces was adequate to create the necessary searches. Instead,
most of the problems encountered with these clients were based on
usability concerns.
It was found that the web-based client caused a great amount of
confusion for users not familiar with LDAP or Nicname/Whois with
respect to the underlying technology and the network model. Thus,
many users believed the web-based client to be the only interface to
the data and were unaware or confused by the intermediate LDAP
protocol. In addition, it was difficult to express to users the
<span class="grey">Newton Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
registry-registrar-registrant service model in adequate terms from
search results where the results could be rendered properly among the
various common web browsers.
Both the C and Java based clients were built to be both graphical and
cross-platform (in the case of the C-based client, the Linux and
Windows platforms were chosen as targets). The LDAP client libraries
chosen for both clients proved to be quite capable and offered the
necessary levels of control for conducting nested queries and
advanced referral chasing. Expectations at the outset for
construction of both clients, based on past experience, were that the
C-based client would not only perform better than the Java client but
also have a better appearance. In reality, these assumptions were
incorrect as there was no perceivable difference in performance and
the look of the Java client was often considered to be far superior
to its counter-part. In addition, the Java client required much less
time to create. Both clients are available under the terms of an
open source license. Though it is impossible to have accurate
measurements of their popularity, through monitoring and feedback it
was perceived that the web-based client had far greater use.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Lessons Learned</span>
Based on the experience of piloting this experimental service,
feedback from users of the service, and general comments and
observations of current and common opinions, the following items have
been noted.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Intra-Server Referrals</span>
Original analysis of the data set to be used revealed a high degree
of relationships between name servers, contacts, and domains.
Storing the data in non-normalized form according to the DIT outlined
in this document would make an original relational dataset of roughly
20 million objects explode to over 115 million objects.
To combat this problem, the first pass at defining the DIT's made
heavy use of referrals between the TLD DIT's and the name server and
contact DIT's. The use of the 'alias' objectclass was considered but
ruled out in hopes of using referrals for load balancing across
servers (i.e., placing each TLD DIT on a separate server, and
separate servers for the name server and contact DIT's). However,
initial testing with the 'ldapsearch' command found inconsistencies
with the interpretation of the referrals and how they were managed.
Not only were the results inconsistent between implementations, but
many of these clients would easily get caught in referral loops.
<span class="grey">Newton Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
The final solution to the problem was to create a customized back-end
data store containing the data in a normalized form. This gave the
client the appearance of having a non-normalized data set which
required no intra-server referrals. Aliases may have been a better
solution, however our interpretation of their output with
implementations of the 'ldapsearch' tool was not satisfactory. It
was also later learned that some LDAP server implementations place
certain restrictions on aliases that would have conflicted with our
overall DIT structure. In the end, it was felt that a customized
back-end would be required by any server with a large data-set, but
smaller data-sets for less populated domains could easily use off-
the-shelf implementations.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Inter-Server Referrals</span>
The modeling of the overall service to provide the split in
operational responsibility between registry and registrar required
the use of referrals (i.e., the two servers would not be operated by
the same organization, therefore would most likely not co-exist on
the same physical machine or network). The chief problem with LDAP
referrals returned for this purpose grew out of the need to limit
data returned to the client and the priority given to referrals. It
was quite easy to cause a sub-tree query at certain levels, for
instance a TLD level, to return nothing but referrals. This was true
because referrals would be returned out of the scope of the supplied
search filter and therefore would fill the result set to its limit,
normally set to 50 entries.
In certain use cases, a result set with nothing but referrals was
desired (e.g., o=tlds). However, even in these cases it was possible
for some referrals to not be returned due to the size limit. In this
case, it was felt that a result set of 50 referrals, the default for
the size limit in most cases, was too large for any practical use by
a client and was a failing of query distribution in general rather
than a limitation of LDAP.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Common DIT</span>
Because of the nature of software development, the graphical and web
clients were developed after the development of the server software.
The 'ldapsearch' client was used for testing and development during
server software creation. It was not until the creation of more
advanced clients that it was discovered that the design decision of
uniform DIT naming should have been made. Technically, this would
have allowed for slightly better software modularization and re-use.
In addition, the use of a company name in the DIT structure did not
allow the easy integration of another domain registry, as in the
registry-registrar model. Not only would clients have to be
<span class="grey">Newton Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
reconfigured for each new registry operator, but this would most
likely have social implications as well.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Universal Client</span>
The construction of the clients revealed yet another misconception.
Though this project used a generic directory service technology, the
clients required a high-degree of algorithmic knowledge about the DIT
structure and schemas being used. The graphical clients could not be
used against an LDAP service with another DIT or schema. Therefore,
a generic or universal client, one that could be used for all LDAP
applications, would either not be able to make full use of the data
provided by the service or would be far too complex for operation by
the average user.
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Targeting Searches by Tier</span>
The network model for this service was divided into three tiers:
registry, registrar, and registrant. Despite this, all searches
needed to start at the registry level causing overhead for searches
that could be targeted at a select tier. This service did not
implement a solution to this problem, such as using SRV and/or NAPTR
records in DNS to allow a client to find a responsible LDAP server.
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Data Mining</span>
<a href="#section-3.1.2">Section 3.1.2</a> and <a href="#section-4.1.2">Section 4.1.2</a> describe the searches allowed by this
service. However, the most common question asked by users of the
service revolved around getting around these restrictions. Because
browsing at the TLD level was not permitted, many users asked about
the feasibility of using recursive dictionary queries to circumvent
the search restrictions.
It should be noted that many operators of Nicname/Whois server
consider this practice to be data mining and often refer to it
specifically as a dictionary attack.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
There are no applicable IANA considerations presented in this
document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Internationalization Considerations</span>
The domain administrative data in this service did not cover
Internationalized Domain Names (IDN's).
<span class="grey">Newton Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This experiment did not endeavor to use security mechanisms beyond
those readily available in LDAP [<a href="#ref-5" title=""Lightweight Directory Access Protocol (v3)"">5</a>]. <a href="#section-3.1.3">Section 3.1.3</a> and <a href="#section-4.1.3">Section 4.1.3</a>
describe the various access controls used within the scope of the
defined security mechanisms. While these mechanisms were adequate
for this experimental deployment, they would not be adequate for a
production environment, and they should not be taken as a model for
those contemplating deployment on the Internet.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Intellectual Property Statement</span>
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in <a href="https://www.rfc-editor.org/bcp/bcp11">BCP-11</a>. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
<span class="grey">Newton Experimental [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Normative References</span>
[<a id="ref-1">1</a>] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", <a href="./rfc954">RFC</a>
<a href="./rfc954">954</a>, October 1985.
[<a id="ref-2">2</a>] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
Structuring Guidelines for X.500 Directory Pilots", <a href="./rfc1617">RFC 1617</a>,
May 1994.
[<a id="ref-3">3</a>] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", <a href="./rfc2167">RFC 2167</a>,
June 1997.
[<a id="ref-4">4</a>] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", <a href="./rfc2247">RFC 2247</a>,
January 1998.
[<a id="ref-5">5</a>] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", <a href="./rfc2251">RFC 2251</a>, December 1997.
[<a id="ref-6">6</a>] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
<a href="./rfc2252">RFC 2252</a>, December 1997.
[<a id="ref-7">7</a>] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", <a href="./rfc2256">RFC 2256</a>, December 1997.
[<a id="ref-8">8</a>] Howard, L., "An Approach for Using LDAP as a Network Information
Service", <a href="./rfc2307">RFC 2307</a>, March 1998.
[<a id="ref-9">9</a>] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
<a href="./rfc2798">RFC 2798</a>, April 2000.
<span class="grey">Newton Experimental [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Other Work</span>
In addition to the deployment of servers and development of clients,
VeriSign conducted two sub-projects related to this experiment.
The first project was a Nicname/Whois-to-LDAP gateway. The goal of
the project was to create an LDAP server for use by registrars to
deploy in front of their Nicname/Whois servers. This gateway would
take LDAP requests, translate them to Nicname/Whois requests, issue
the request to a specific Nicname/Whois server deployed on port 43,
interpret the response, and return LDAP result sets. Because of the
unspecified nature of Nicname/Whois result sets, the gateway was
programmed to specifically recognize only the output of three
distinct registrars. While this gateway proved valuable enough to
allow domain lookups and limited searches, it was unable to provide
consistent contact lookups, nameserver lookups, or registrant
referrals. This software was also made publicly available under the
terms of an open source license.
The second project was an informal survey of registrants with
deployed LDAP servers. This was conducted by using the com, net,
org, and edu zone files and testing for the existence of an LDAP
server on port 389 using the name of the domain, a host named "ldap"
in the domain, and a host named "dir" in the domain (e.g., "foo.com",
"ldap.foo.com", and "dir.foo.com"). This survey did not attempt to
resolve LDAP services using SRV records in DNS.
The result of this survey found that roughly 0.5% of active domains
had an LDAP server. By profiling a server's root DSA-specific Entry
(DSE), the survey found that about 90% of the servers were
implementations provided by vendor A, 9% of the servers were
implementations provided by vendor B, and 1% of the servers were
implementations provided by other vendors. Of the servers queried
that were determined to be implementations provided by vendor A, it
appeared that about only 10% contained public data (this also led to
the assumption that the other 90% were not intended to be publicly
queried). Of the servers queried that were determined to be
implementations provided by vendor B, it appears that nearly all
contained public data.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Acknowledgments</span>
Significant analysis, design, and implementation for this project
were conducted by Brad McMillen, David Blacka, Anna Zhang, and
Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance
by reviewing this project, the project's goals, and this document.
<span class="grey">Newton Experimental [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
Author's Address
Andrew Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
<span class="grey">Newton Experimental [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3663">RFC 3663</a> Domain Administrative Data in LDAP December 2003</span>
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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.
Newton Experimental [Page 21]
</pre>
|
