idnits 2.17.1 draft-newton-ir-dir-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The service MUST be capable of allowing a centralized authority entity the means to distribute authentication information of entities accessing the service. The service MUST not require all Internet registries to participate in distributed authentication and SHOULD allow the participation by an Internet registry in distributed authentication by many centralized authority entities. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2002) is 8112 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2251 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 2167 (ref. '3') ** Obsolete normative reference: RFC 954 (ref. '4') (Obsoleted by RFC 3912) ** Obsolete normative reference: RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: August 8, 2002 S. Kerr 5 RIPE NCC 6 February 7, 2002 8 Internet Registry Directory Requirements 9 draft-newton-ir-dir-requirements-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 8, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 Internet registries expose administrative and operational data via 41 varying directory services. This document defines the common 42 requirements for the directory services of these Internet registries. 44 Table of Contents 46 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Internet Registry Communities . . . . . . . . . . . . . . . 5 48 2.1 Registries . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.1.1 Regional Internet Registries . . . . . . . . . . . . . . . . 5 50 2.1.2 Local Internet Registries . . . . . . . . . . . . . . . . . 5 51 2.1.3 Internet Routing Registries . . . . . . . . . . . . . . . . 5 52 2.1.4 Domain Registries . . . . . . . . . . . . . . . . . . . . . 5 53 2.1.5 Domain Registrars . . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Implementers . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3 End Users . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.3.1 Service Providers and Network Operators . . . . . . . . . . 7 57 2.3.2 Intellectual Property Holders . . . . . . . . . . . . . . . 7 58 2.3.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . . 7 59 2.3.4 Certificate Authorities . . . . . . . . . . . . . . . . . . 7 60 2.4 Other Actors . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Functional Requirements . . . . . . . . . . . . . . . . . . 8 62 3.1 Common Functions . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . . 8 64 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . . 8 65 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . . 8 66 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . . 8 68 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . . 9 69 3.1.7 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.8 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.9 Decentralization . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2 RIR Functions . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2.1 Network Lookup . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2.2 Autonomous System Lookup . . . . . . . . . . . . . . . . . . 9 75 3.2.3 DNS Referencing . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.4 Network Search by Contact . . . . . . . . . . . . . . . . . 10 77 3.3 IRR Functions . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.3.1 Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.3.2 Router Lookup . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.3.3 Route Lookup . . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.3.4 Route set Lookup . . . . . . . . . . . . . . . . . . . . . . 10 82 3.4 Domain Functions . . . . . . . . . . . . . . . . . . . . . . 10 83 3.4.1 Domain Status Lookup . . . . . . . . . . . . . . . . . . . . 10 84 3.4.2 Domain Registrant Search . . . . . . . . . . . . . . . . . . 10 85 3.4.3 Domain Information Lookup . . . . . . . . . . . . . . . . . 11 86 3.4.4 Nameserver Search . . . . . . . . . . . . . . . . . . . . . 11 87 3.4.5 Escrow Support . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.4.6 Authentication Distribution . . . . . . . . . . . . . . . . 11 89 3.4.7 Domain Name Search . . . . . . . . . . . . . . . . . . . . . 11 90 3.4.8 DNS Referencing . . . . . . . . . . . . . . . . . . . . . . 11 91 4. Feature Requirements . . . . . . . . . . . . . . . . . . . . 12 92 4.1 Client Authentication . . . . . . . . . . . . . . . . . . . 12 93 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.3 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.4 Structured Queries and Responses . . . . . . . . . . . . . . 12 96 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . . 12 97 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . . 12 98 4.7 Serialization Definition . . . . . . . . . . . . . . . . . . 12 99 5. Internationalization Considerations . . . . . . . . . . . . 13 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 101 7. Security Considerations . . . . . . . . . . . . . . . . . . 15 102 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 104 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 106 B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 B.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . 19 108 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 110 1. Background 112 The expansion and growth of the Internet has seen the registry 113 function of a traditionally centralized and managed Network 114 Information Center become the responsibility of various autonomous, 115 functionally disparate, and globally distributed Internet 116 registries. With the broadening number of Internet registries, the 117 uses of their administrative directory services have expanded from 118 the original and traditional use of the whois[4] protocol to include 119 the use of whois outside the scope of its specification, formal and 120 informal definitions of syntax, undocumented security mechanisms, 121 the use of other protocols, such as rwhois[3], to fulfill other 122 needs, and proposals for the use of other technologies such as 123 LDAP[1] and XML. 125 The scope of the requirements captured in this document relate to 126 the directory services of the specified Internet registries (Section 127 2.1) and their related communities (Section 2.2,Section 2.3, and 128 Section 2.4). The requirements are of both the current use of these 129 directory services and the desired functionality based on input from 130 relevant forums (Appendix B.1). These requirements are not specific 131 to any protocol. 133 The requirements captured in this document are for the purpose of 134 designing technical specifications. The words used in this document 135 for compliance with RFC2119[8] do not reference or specify policy 136 and speak only to the capabilities in the derived technology. The 137 scope of the requirements in this document are also restricted to 138 access of data from Internet registries. Requirements for 139 modification, addition, or provisioning of data in Internet 140 registries are out of scope. 142 2. Internet Registry Communities 144 The Internet registries are composed of various communities which 145 provide scope for the requirements in this document. These 146 communities can be generalized into the following categories: 147 registries, implementers, end-users, and other actors. 149 2.1 Registries 151 2.1.1 Regional Internet Registries 153 Regional Internet Registries (RIR's) administer the allocation of IP 154 address space and autonomous system numbers. Each RIR serves a 155 specific geographic region, and collectively they service the entire 156 Internet. Each RIR is a membership-based, non-profit organization 157 that facilitates and implements global addressing policy based on 158 the direction of their regional community. 160 2.1.2 Local Internet Registries 162 Local Internet Registries (LIR's) and National Internet Registries 163 (NIR's) are sub-registries of RIR's and coordinate the same 164 functions of the RIR's for smaller, more specific geographic 165 regions, sovereign nations, and localities. 167 2.1.3 Internet Routing Registries 169 Internet Routing Registries are routing policy databases. Their 170 purpose is to provide information helpful in administering Internet 171 routers. Frequently, the syntax and contents are defined by RPSL[5]. 173 IRR's are operated by academic, commercial, governmental, and other 174 types of organizations, including several of the RIR's. The contents 175 of the databases vary and reflect the needs of the users directly 176 served (e.g. an ISP may look up route entries added by their 177 customers to decide whether to accept specific route advertisements 178 they receive). 180 Unlike RIR and domain registry data, IRR data is often duplicated 181 between separate organizations. The IRR data has the unique 182 characteristics of being largely available through other sources 183 (i.e. it is advertised by the Internet routing protocols) and most 184 often having a common data format, RPSL. 186 2.1.4 Domain Registries 188 Domain registries are responsible for the registration of domains 189 for use with DNS[2] and forward lookups (i.e. does not include the 190 IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically 191 served two main domain functions: as the registry for a gTLD or as a 192 registry for a ccTLD. In many instances, one entity will operate 193 multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD 194 domain registry operator may be a governmental entity, 195 non-governmental, non-commercial entity, or a commercial entity. 197 Some ccTLD's have second-level domain registrations similar in 198 nature to gTLD's or have distinctly separate entities operating 199 second-level domain registries similar in nature to gTLD's within 200 the ccTLD. 202 Domain registries usually follow one of two models for conducting 203 registrations of domains. The "thick" model is the more traditional 204 model. In a "thick" domain registry, the registry contains both the 205 operational data for the domain and the contact or social data for 206 the domain. In this model, the registry is typically the interface 207 to the domain registrant but may also interface with the domain 208 registrant through domain registrars. The "thin" model domain 209 registry contains only operational data for domains. In the "thin" 210 model, contact or social data for the domain are maintained by a 211 domain registrar. 213 Domain registries not described in this section are not the subject 214 of this document and may have requirements that are out of scope for 215 this subject matter. 217 2.1.5 Domain Registrars 219 Domain registrars accept domain registrations from registrants on 220 behalf of domain registries, both "thick" and "thin". In a "thin" 221 model registry/registrar system, a domain registrar maintains the 222 contact and social data of a domain while the registry maintains the 223 operational data of a domain. In a "thick" model registry/registrar 224 system, a domain registrar passes both the operational data and 225 contact data to the registry. Domain registrars may register a 226 domain on behalf of a registrant in more than one domain registry. 228 2.2 Implementers 230 Implementers of client software are often either affiliated with 231 large network operators, registry operators, or commercial entities 232 offering value-added services, or are general citizens of the 233 Internet. Much of the client software for use with the directory 234 services of Internet registries is either freely available, open 235 source, or both, or available as a service. Implementers of server 236 software are often affiliated with operators or commercial entities 237 specializing in the out-sourcing of development for Internet 238 registries. 240 2.3 End Users 242 2.3.1 Service Providers and Network Operators 244 Service providers and network operators provide connectivity, 245 routing, and naming services to many other entities, some commercial 246 and some non-commercial, both large and small. Their operational and 247 administrative staff often interact with Internet registries on 248 behalf of other end-users. Service providers and network operators 249 interact with all of the Internet registry operators outlined in 250 this document on a frequent and consistent basis. 252 2.3.2 Intellectual Property Holders 254 Intellectual Property Holders have legal rights to domain names 255 based on copyright and trademark laws of various governments. They 256 use the directory services of Internet registries, mostly domain 257 registries and registrars, for purposes of maintaining and defending 258 claims to domain names consistent with applicable laws and 259 regulations. 261 2.3.3 Law Enforcement 263 Law enforcement agencies use the directory services of Internet 264 registries in the enforcement of laws within their jurisdictions. 266 2.3.4 Certificate Authorities 268 Certificate authorities use the directory services of Internet 269 registries as part of their verification process when issuing 270 certificates for Internet named hosts. 272 2.4 Other Actors 274 Requirements must also consider the influence and regulations placed 275 on the use of Internet registry directory services by other actors. 276 These actors include governments, non-governmental policy-setting 277 bodies, and other non-governmental organizations. 279 3. Functional Requirements 281 Functional requirements describe an overall need or process for 282 which the directory service is used by an Internet registry to 283 fulfill its obligations to provide access to its respective 284 customers, members, or other constituents. This section makes 285 reference to terms and definitions declared in Appendix A. This 286 section makes use of the term "service" to denote the protocol or 287 protocols derived from these requirements. 289 3.1 Common Functions 291 3.1.1 Mining Prevention 293 The service MUST have a mechanism to limit the amount of data that 294 may be accessed. The service MAY have different limits for different 295 types of data, as well as authenticated and non-authenticated 296 entities. 298 3.1.2 Minimal Technical Reinvention 300 The service MUST NOT employ unique technology solutions for all 301 aspects and layers above the network and transport layers of the 302 total service solution and SHOULD make use of existing technology 303 standards where applicable. The service MUST employ the use of 304 network and transport layer standards as defined by the Internet 305 Engineering Task Force. 307 3.1.3 Standard and Extensible Schemas 309 The service MUST define standard schemas for the exchange of data 310 needed to implement the functionality in this document. In addition, 311 there MUST be a means to allow for the use of schemas not defined by 312 the needs of this document. Both types of schemas MUST use the same 313 schema language. 315 3.1.4 Level of Access 317 The service MUST be capable of authenticating priviledged entities 318 and MUST be capable of restricting access of priviledged data to 319 only priviledged entities. In addition, the service MUST be capable 320 of serving both priviledged data and non-priviledged data and MUST 321 allow for the classification of data, be it social or operational 322 data, as priviledged data or non-priviledged data for the purpose of 323 restricting its access. 325 3.1.5 Client Processing 327 The service MUST be capable of allowing machine parsable requests 328 and responses. 330 3.1.6 Entity Referencing 332 There MUST be a mechanism for an entity contained within a server to 333 be referenced uniquely by an entry in another server. 335 3.1.7 Contact Lookup 337 The service SHOULD allow access to social data of contact entities 338 given a unique reference to the contact entity. 340 3.1.8 Nameserver Lookup 342 The service SHOULD allow access to operational and social data given 343 the fully-qualified host name or IP address of a nameserver. 345 3.1.9 Decentralization 347 The service MUST be decentralized in design and principle and MUST 348 NOT require the aggregation of data to a central repository, server, 349 or entity. The service MAY allow for the optional aggregation of 350 data indexes or hints. The service MUST NOT require aggregation of 351 data indexes or hints. 353 3.2 RIR Functions 355 3.2.1 Network Lookup 357 The service MUST provide access to operational and social data of a 358 network given an IP address contained within the network. The 359 service SHOULD provide access to address-to-name mapping information 360 (IN-ADDR.ARPA or IP6.ARPA) of a network given an IP address 361 contained within the network. 363 3.2.2 Autonomous System Lookup 365 The service MUST provide access to operational and social data of a 366 network given the Autonomous System Number of a network. 368 3.2.3 DNS Referencing 370 The service MUST use DNS[2] to determine the authoritative source of 371 information about address-to-name mapping (IN-ADDR.ARPA or 372 IP6.ARPA). The service SHOULD use DNSSEC[7] when available for this 373 purpose. 375 3.2.4 Network Search by Contact 377 The service SHOULD provide access to a list of networks given a 378 contact name or a subset of a contact name associated with the 379 networks. 381 3.3 IRR Functions 383 3.3.1 Mirroring 385 The service SHOULD provide near real-time mirroring of operational 386 routing data. The service MAY provide this capability via a 387 mechanism separate from that which the service provides for other 388 data access means. 390 3.3.2 Router Lookup 392 The service MUST provide access to operational and social data of an 393 Internet router given the fully-qualified domain name of the 394 Internet router. 396 3.3.3 Route Lookup 398 The service MUST provide access to operational and social data of a 399 network route given the network number of a route. 401 3.3.4 Route set Lookup 403 The service MUST provide access to operational and social data of a 404 network route set given the name of the network route set. 406 3.4 Domain Functions 408 3.4.1 Domain Status Lookup 410 The service MUST provide access to the status of a domain given the 411 domain's fully qualified name. This status MUST indicate the 412 activation status of the domain. The activation status is the same 413 as would be available in Section 3.4.3. 415 3.4.2 Domain Registrant Search 417 The service MUST provide the capability of searching for registrants 418 by name or a reasonable name subset. The service MUST provide a 419 mechanism to distribute this search across all applicable domain 420 registries and registrars. The service SHOULD have a means to narrow 421 the scope of a search to a specific TLD. 423 3.4.3 Domain Information Lookup 425 The service MUST provide access to operational and social data 426 specific to a domain given the domain's fully qualified name (FQDN). 427 This information SHOULD include the activation status, registrant 428 name and contact data, hosting nameservers, and the technical, 429 billing, or other entity types associated with the domain and their 430 relevant contact data. 432 3.4.4 Nameserver Search 434 The service MAY allow the ability to list all domains hosted by a 435 specific nameserver given the fully-qualified host name or IP 436 address, if applicable, of the nameserver. The service MAY provide a 437 mechanism to distribute this search across all applicable domain 438 registries and registrars. 440 3.4.5 Escrow Support 442 The service MUST provide a means to escrow data of domain registrars 443 to an escrow entity using a common schema. This escrow capability 444 SHOULD be "off-line" and "out-of-band" from the normal operations of 445 the service. 447 3.4.6 Authentication Distribution 449 The service MUST be capable of allowing a centralized authority 450 entity the means to distribute authentication information of 451 entities accessing the service. The service MUST not require all 452 Internet registries to participate in distributed authentication and 453 SHOULD allow the participation by an Internet registry in 454 distributed authentication by many centralized authority entities. 456 3.4.7 Domain Name Search 458 The service MUST allow searching for domains given a reasonable 459 subset of a domain name. The service MUST provide a mechanism to 460 distribute this search across all applicable domain registries and 461 registrars. There should be a means to narrow this search based on a 462 TLD. The search mechanism SHOULD provide for differences in domain 463 names between the native representation and the canonical form 464 existing in the registry. 466 3.4.8 DNS Referencing 468 The service MUST use DNS[2] to determine the authoritative source of 469 information about domain names. The service SHOULD use DNSSEC[7] 470 when available for this purpose. 472 4. Feature Requirements 474 Feature requirements describe the perceived need derived from the 475 functional requirements for specific technical criteria of the 476 directory service. This section makes references to terms and 477 definitions declared in Appendix A . This section makes use of the 478 term "service" to denote the protocol or protocols derived from 479 these requirements. 481 4.1 Client Authentication 483 Entities accessing the service (users) MUST be provided a mechanism 484 for passing credentials to a server for the purpose of 485 authentication. 487 4.2 Referrals 489 To distribute queries for search continuations and to issue entity 490 references, the service MUST provide a referral mechanism. 492 4.3 URIs 494 To distribute queries for search continuation and to issue entity 495 references, the service MUST define a URI scheme and syntax. 497 4.4 Structured Queries and Responses 499 To provide for machine consumption as well as human consumption, the 500 service MUST employ structured queries and responses. 502 4.5 Existing Schema Language 504 To provide structured queries and responses and allow for minimal 505 technological reinvention, the service MUST employ a pre-existing 506 schema language. 508 4.6 Defined Schemas 510 To provide for machine consumption as well as human consumption, the 511 service MUST define schemas for use the structured queries and 512 responses. 514 4.7 Serialization Definition 516 To provide for data escrow and allow for minimal technological 517 reinvention, the service MUST employ a pre-existing serialization 518 specification. 520 5. Internationalization Considerations 522 Requirements defined in this document MUST consider the best 523 practices spelled out in [6]. 525 6. IANA Considerations 527 There are no IANA considerations. 529 7. Security Considerations 531 This document contains requirements for the validation of 532 authenticated entities and the access of authenticated entities 533 compared with the access of non-authenticated entities. This 534 document does not define the mechanism for validation of 535 authenticated entities. Requirements defined in this document MUST 536 allow for the implementation of this mechanism according best common 537 practices. 539 In addition, this document contains requirements for referrals and 540 entity references. Client implementations based on these 541 requirements SHOULD take proper care in the safe-guarding of 542 credential information when resolving referrals or entity references 543 according to best common practices. 545 References 547 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 548 Protocol (v3)", RFC 2251, December 1997. 550 [2] Mockapetris, P., "Domain names - implementation and 551 specification", STD 13, RFC 1035, November 1987. 553 [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. 554 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, 555 June 1997. 557 [4] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 558 954, October 1985. 560 [5] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 561 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 562 Policy Specification Language (RPSL)", RFC 2622, June 1999. 564 [6] Alvestrand, H.T., "IETF Policy on Character Sets and 565 Languages", BCP 18, RFC 2277, January 1998. 567 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 568 2535, March 1999. 570 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 571 Levels", BCP 14, RFC 2119, March 1997. 573 [9] 575 [10] 577 [11] 580 [12] 583 [13] 585 Authors' Addresses 587 Andrew L. Newton 588 VeriSign, Inc. 589 21345 Ridgetop Circle 590 Sterling, VA 20166 591 USA 593 Phone: +1 703 948 3382 594 EMail: anewton@research.netsol.com 595 URI: http://www.verisignlabs.com/ 597 Shane Kerr 598 RIPE NCC 599 Singel 258 600 Amsterdam 1016 AB 601 The Netherlands 603 Phone: +31 20 535 4427 604 EMail: shane@ripe.net 606 Appendix A. Glossary 608 o TLD: Initials for "top level domain." Referes to domains in 609 DNS[2]that are hierarchically at the level just beneath the root. 611 o ccTLD: Initials for "country code top level domain." TLD's which 612 use one of the two character country codes defined by ISO. 614 o gTLD: Initials for "generic top level domain." TLD's that do not 615 use one of the two character country codes defined by ISO. 617 o social data: Data containing names and contact information (i.e. 618 postal addresses, phone numbers, e-mail addresses) of humans or 619 legal entities. 621 o operational data: Data necessary to the operation of networks and 622 network related services and items. 624 o RIR: Initials for "regional Internet registry." 626 o IRR: Initials for "Internet routing registry." 628 o authenticated entity: A person, or person acting on behalf of an 629 organization, who has provided validatable credentials of 630 identification via client software to the directory service of an 631 Internet registry. 633 o non-authenticated entity: A person, or person acting on behalf of 634 an organization, who has not provided validatable credentials of 635 identification via client software to the directory service of an 636 Internet registry. 638 o priviledged entity: A person, or person acting on behalf of an 639 organization, with authorization to access data. 641 o non-priviledged entity: A person, or person acting on behalf on 642 an organization, with no authorization to access data. 644 o priviledged data: Data accessible by a priviledged entities. 646 o non-priviledged data: Data accessible by priviledged entities and 647 non-priviledged entities. 649 o forward lookup: a DNS lookup where a domain name is resolved to 650 an IP address. 652 o reverse lookup: a DNS lookup where an IP address is resolved to a 653 domain name. 655 Appendix B. Acknowledgements 657 B.1 Forums 659 The proceedings of the following public forums were used as input to 660 the scope and requirements for this document: 662 o whois BOF of the 49th IETF[9]; December 10-15, 2000; San Diego, 663 CA, USA 665 o whoisfix BOF of the 51st IETF[10]; August 5-10, 2001; London, 666 England 668 o First UWho Consultation[11]; August 15, 2001; Washington, DC, USA 670 o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, 671 USA 673 o Third UWho Consultation; November 19, 2001; Washington, DC, USA 675 o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic 677 o Database WG of RIPE 40[12]; October 1-5, 2001; Praque, Czech 678 Republic 680 o General Session of NANOG 23[13]; October 21-23; Oakland, CA, USA 682 o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands 684 o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The 685 Netherlands 687 B.2 Contributions 689 Comments, suggestions, and feedback of significant substance have 690 been provided by Leslie Daigle, Mark Kosters, and Cathy Murphy. 692 Full Copyright Statement 694 Copyright (C) The Internet Society (2002). All Rights Reserved. 696 This document and translations of it may be copied and furnished to 697 others, and derivative works that comment on or otherwise explain it 698 or assist in its implementation may be prepared, copied, published 699 and distributed, in whole or in part, without restriction of any 700 kind, provided that the above copyright notice and this paragraph 701 are included on all such copies and derivative works. However, this 702 document itself may not be modified in any way, such as by removing 703 the copyright notice or references to the Internet Society or other 704 Internet organizations, except as needed for the purpose of 705 developing Internet standards in which case the procedures for 706 copyrights defined in the Internet Standards process must be 707 followed, or as required to translate it into languages other than 708 English. 710 The limited permissions granted above are perpetual and will not be 711 revoked by the Internet Society or its successors or assigns. 713 This document and the information contained herein is provided on an 714 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 715 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 716 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 717 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 718 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 720 Acknowledgement 722 Funding for the RFC editor function is currently provided by the 723 Internet Society.