idnits 2.17.1 draft-ietf-crisp-requirements-05.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 : ---------------------------------------------------------------------------- No issues found here. 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). -- 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 (May 10, 2003) is 7629 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 informational reference (is this intentional?): RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 954 (ref. '6') (Obsoleted by RFC 3912) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: November 8, 2003 May 10, 2003 6 Cross Registry Internet Service Protocol (CRISP) Requirements 7 draft-ietf-crisp-requirements-05 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 8, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Internet registries expose administrative and operational data via 39 varying directory services. This document defines functional 40 requirements for the directory services of domain registries and the 41 common base requirements for extending the use of these services for 42 other types of Internet registries. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4 49 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 50 2. Internet Registry Communities . . . . . . . . . . . . . . 6 51 2.1 Domain Name System Registries . . . . . . . . . . . . . . 6 52 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 53 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7 55 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7 56 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7 57 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7 58 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7 59 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.4.1 Internet Resource Registrants . . . . . . . . . . . . . . 8 62 2.4.2 Service Providers and Network Operators . . . . . . . . . 8 63 2.4.3 Intellectual Property Holders . . . . . . . . . . . . . . 8 64 2.4.4 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9 65 2.4.5 Certificate Authorities . . . . . . . . . . . . . . . . . 9 66 2.4.6 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9 67 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 68 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Functional Requirements . . . . . . . . . . . . . . . . . 10 70 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10 71 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10 72 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10 73 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 74 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11 75 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12 76 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12 77 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12 78 3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12 79 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12 80 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13 81 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13 82 3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 13 83 3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 84 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 15 85 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16 88 3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17 89 3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 18 90 3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18 91 3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 19 92 3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19 93 3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 20 94 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21 95 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21 96 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21 97 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21 98 4.4 Structured Queries and Responses . . . . . . . . . . . . . 21 99 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21 100 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21 101 5. Internationalization Considerations . . . . . . . . . . . 22 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 103 7. Security Considerations . . . . . . . . . . . . . . . . . 24 104 Normative References . . . . . . . . . . . . . . . . . . . 25 105 Informative References . . . . . . . . . . . . . . . . . . 26 106 Author's Address . . . . . . . . . . . . . . . . . . . . . 26 107 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 109 B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 28 111 B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 29 112 Intellectual Property and Copyright Statements . . . . . . 30 114 1. Introduction 116 1.1 Background 118 The expansion and growth of the Internet has seen the registry 119 function of a traditionally centralized and managed Network 120 Information Center become the responsibility of various autonomous, 121 functionally disparate, and globally distributed Internet registries. 122 With the broadening number of Internet registries, the uses of their 123 administrative directory services have expanded from the original and 124 traditional use of the whois [6] protocol to include the use of whois 125 outside the scope of its specification, formal and informal 126 definitions of syntax, undocumented security mechanisms, the use of 127 other protocols, such as rwhois [5], to fulfill other needs, and 128 proposals for the use of other technologies such as LDAP [4] and XML. 130 1.2 Requirements Scope 132 The scope of the requirements captured in this document relate to the 133 directory services of Internet registries and their related 134 communities (Section 2.3,Section 2.4, and Section 2.5). This scoping 135 specifically targets the requirements of domain name registries 136 (Section 2.1). The requirements for other registry types will be 137 made available in other memos. The requirements are of both the 138 current use of these directory services and the desired functionality 139 based on input from relevant forums (Appendix B.1). These 140 requirements are not specific to any protocol. Terms used in the 141 definition of requirements in this document may be found in the 142 glossary (Appendix A). 144 The scope of the requirements in this document are also restricted to 145 access of data from Internet registries. Requirements for 146 modification, addition, or provisioning of data in Internet 147 registries are out of scope. 149 1.3 Requirements Specification 151 The requirements captured in this document are for the purpose of 152 designing technical specifications. The words used in this document 153 for compliance with RFC2119 [3] do not reference or specify policy 154 and speak only to the capabilities in the derived technology. For 155 instance, this document may say that the protocol "MUST" support 156 certain features. An actual service operator is always free to 157 disable it (and then to return an error such as "permission denied".) 159 Requirements in this document specifying the capabilities of the 160 protocol required for proper interaction between a client and a 161 server will be specified with the "MUST/SHOULD" language of RFC2119 163 [3]. This document also contains language relating to the 164 interaction of a client with multiple servers to form a coherent, 165 cross-network service. Such service requirements will not be 166 described using RFC2119 language. 168 While individual servers/service operators may not support all 169 features that the protocol can support, they must respect the 170 semantics of the protocol queries and responses. For example, a 171 server should not return referrals if it does not have referent data. 173 2. Internet Registry Communities 175 The Internet registries are composed of various communities which 176 provide scope for the requirements in this document. These 177 communities can be generalized into the following categories: 178 registries, registrars, implementers, end-users, and other actors. 180 2.1 Domain Name System Registries 182 2.1.1 Domain Registries 184 Domain registries are responsible for the registration of domains for 185 use with DNS [1] and forward lookups (i.e. does not include the 186 .ARPA domain). These registries have typically served two main 187 domain functions: as the registry for a gTLD or as a registry for a 188 ccTLD. In some instances, one entity will operate multiple TLD's, 189 both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry 190 operator may be a governmental entity, non-governmental, 191 non-commercial entity, or a commercial entity. 193 Some ccTLD's have second-level domain registrations similar in nature 194 to gTLD's or have distinctly separate entities operating second-level 195 domain registries similar in nature to gTLD's within the ccTLD. 197 Domain registries usually follow one of two models for conducting 198 registrations of domains. The "thick" model is the more traditional 199 model. In a "thick" domain registry, the registry contains both the 200 operational data for the domain and the contact data (Appendix A) for 201 the domain. In this model, the registry is typically the interface 202 to the domain registrant but may also interface with the domain 203 registrant through domain registrars. The "thin" model domain 204 registry contains only operational data for domains. In the "thin" 205 model, contact data for the domain are maintained by a domain 206 registrar. 208 Domain registries not described in this section (Section 2.1.1) are 209 not the subject of this document and may have requirements that are 210 out of scope for this subject matter. 212 2.1.2 Domain Registrars 214 Domain registrars accept domain registrations from registrants on 215 behalf of domain registries, both "thick" and "thin". In a "thin" 216 model registry/registrar system, a domain registrar maintains the 217 contact data of a domain while the registry maintains the operational 218 data of a domain. In a "thick" model registry/registrar system, a 219 domain registrar passes both the operational data and contact data to 220 the registry. Domain registrars may register a domain on behalf of a 221 registrant in more than one domain registry. 223 2.2 Other Registries 225 This section describes Internet registries other than those listed in 226 Section 2.1. These descriptions are not definitive and this list is 227 not absolute. They are provided in this document for informational 228 purposes only. 230 2.2.1 Regional Internet Registries 232 Regional Internet Registries (RIR's) administer the allocation of IP 233 address space and autonomous system numbers. Each RIR serves a 234 specific geographic region, and collectively they service the entire 235 Internet. Each RIR is a membership-based, non-profit organization 236 that facilitates and implements global addressing policy based on the 237 direction of their regional community. 239 2.2.2 Local Internet Registries 241 Local Internet Registries (LIR's) and National Internet Registries 242 (NIR's) are sub-registries of RIR's and coordinate the same functions 243 of the RIR's for smaller, more specific geographic regions, sovereign 244 nations, and localities. 246 2.2.3 Internet Routing Registries 248 Internet Routing Registries are routing policy databases. Their 249 purpose is to provide information helpful in administering Internet 250 routers. Frequently, the syntax and contents are defined by RPSL 251 [7]. 253 IRR's are operated by academic, commercial, governmental, and other 254 types of organizations, including several of the RIR's. The contents 255 of the databases vary and reflect the needs of the users directly 256 served (e.g. an ISP may look up route entries added by their 257 customers to decide whether to accept specific route advertisements 258 they receive). 260 Unlike RIR and domain registry data, IRR data is often duplicated 261 between separate organizations. The IRR data has the unique 262 characteristics of being largely available through other sources 263 (i.e. it is advertised by the Internet routing protocols) and most 264 often having a common data format, RPSL. 266 2.2.4 Incident Coordination Contact Registries 268 Incident coordination contact registries allow operators of network 269 resources such as network infrastructure, network names, or network 270 services to register contact information for the purpose of providing 271 a means of incident notification. Using this type of registry, an 272 operators of network resources are provided information for 273 contacting the operator of another network resource from which an 274 incident may be occurring. 276 2.3 Implementers 278 Implementers of client software are often either affiliated with 279 large network operators, registry operators, or commercial entities 280 offering value-added services, or are general citizens of the 281 Internet. Much of the client software for use with the directory 282 services of Internet registries is either freely available, open 283 source, or both, or available as a service. Implementers of server 284 software are often affiliated with operators or commercial entities 285 specializing in the out-sourcing of development for Internet 286 registries. 288 2.4 End Users 290 This section describes the many type of end-users. Individuals and 291 organizations may have multiple roles and may concurrently occupy 292 many of the categories. 294 2.4.1 Internet Resource Registrants 296 Entities given authority over an Internet resource via purchase, 297 lease, or grant from an Internet registry, either directly or via the 298 services of a registrar. 300 2.4.2 Service Providers and Network Operators 302 Service providers and network operators provide connectivity, 303 routing, and naming services to many other entities, some commercial 304 and some non-commercial, both large and small. Their operational and 305 administrative staff often interact with Internet registries on 306 behalf of other end-users. Service providers and network operators 307 interact with all of the Internet registry operators outlined in this 308 document on a frequent and consistent basis. For example, network 309 operators use the directory services of Internet registries to 310 determine contact information for network resources that have 311 technical problems. 313 2.4.3 Intellectual Property Holders 315 A number of parties, such as trademark, service mark and intellectual 316 property holders, individuals, governments and other geopolitical 317 entities, have some legal rights on certain alphanumeric strings. 318 They use the directory services of Internet registries, mostly domain 319 registries and registrars, for purposes of maintaining and defending 320 claims to domain names consistent with applicable laws and 321 regulations. 323 2.4.4 Law Enforcement 325 Law enforcement agencies use the directory services of Internet 326 registries to find information used to carry out the enforcement of 327 laws within their jurisdictions. 329 2.4.5 Certificate Authorities 331 Certificate authorities use the directory services of Internet 332 registries as part of their verification process when issuing 333 certificates for Internet named hosts. 335 2.4.6 DNS Users 337 Users of the Internet have client software that resolves domain names 338 to IP addresses and IP addresses to domain names. Often when trouble 339 occurs in the resolution process of DNS, these users trouble shoot 340 system problems with the aid of information from the directory 341 services of Internet registries. 343 2.4.7 Abusive Users 345 The administrative directory services of Internet registries are 346 often the target of practices by abusive users. Using information 347 obtained from Internet registries, abusive users undertake certain 348 activities that are counter to the acceptable use of the information 349 as intended by a registry, registrar, or registrant. Many times, 350 these practices violate law in the jurisdiction of the user, 351 registry, registrar, or registrant. One example is the use of 352 Internet registry information for the use of sending unsolicited bulk 353 or commercial email. 355 2.5 Other Actors 357 Requirements must also consider the positions and policies of other 358 actors on the use of Internet registry directory services. These 359 actors include governments, non-governmental policy-setting bodies, 360 and other non-governmental organizations. 362 3. Functional Requirements 364 Functional requirements describe an overall need or process for which 365 the directory service is used by an Internet registry to fulfill its 366 obligations to provide access to its respective customers, members, 367 or other constituents. This section describes requirements in the 368 manner specified in Section 1.3. 370 3.1 Base Functions 372 This section describes basic directory service protocol requirements 373 for Internet registries. Additional requirements, specific to domain 374 registries, are described in Domain Specific Functions (Section 3.2). 376 3.1.1 Mining Prevention 378 In order to prevent the inappropriate acquisition of data from an 379 Internet registry's directory service, many servers will limit the 380 amount of data that may be returned in a fixed time period from a 381 server to a client. This will most likely be especially true for 382 anonymous access uses (see Section 3.1.4). 384 The limits placed on differing types of data or applied depending 385 upon access status will most likely differ from server to server 386 based on policy and need. Support for varying service models in the 387 effort to limit data and prevent data mining may or may not have a 388 direct impact on the client-to-server protocol. 390 3.1.2 Minimal Technical Reinvention 392 The protocol MUST NOT employ unique technology solutions for all 393 aspects and layers above the network and transport layers and SHOULD 394 make use of existing technology standards where applicable. The 395 protocol MUST employ the use of network and transport layer standards 396 as defined by the Internet Engineering Task Force. The protocol MUST 397 define one or more transport mechanisms for mandatory implementation. 399 3.1.3 Standard and Extensible Schemas 401 3.1.3.1 Protocol Requirement 403 The protocol MUST contain standard schemas for the exchange of data 404 needed to implement the functionality in this document. In addition, 405 there MUST be a means to allow the use of schemas not defined by the 406 needs of this document. Both types of schemas MUST use the same 407 schema language. The schemas MUST be able to express data elements 408 with identifying tags for the purpose of localization of the meaning 409 of the identifying tags. 411 3.1.3.2 Service Description 413 The client-to-server protocol must define a standard set of data 414 structures or schemas to be used when exchanging information. It 415 must also poses the ability to allow for the use of newer data 416 structures that are currently nor foreseen by this specification. In 417 both cases, the description and specification of both types of data 418 structures or schemas must be done in the same way (i.e. the same 419 schema language). 421 The schemas must also be capable of "tagging" data with a unique 422 identifier. This identifier can then be used to localize the name of 423 that type of data. For instance, a piece of data may have the value 424 "Bob" and its type identified with the number "5.1". Client software 425 could use this to display "Name: Bob" in an English locale or 426 "Nombre: Bob" in a Spanish locale. 428 3.1.4 Level of Access 430 3.1.4.1 Protocol Requirement 432 The protocol MUST NOT prohibit an operator from granularly assigning 433 multiple types of access to data according to the policies of the 434 operator. The protocol MUST provide an authentication mechanism and 435 MUST NOT prohibit an operator from granting types of access based on 436 authentication. 438 The protocol MUST provide an anonymous access mechanism that may be 439 turned on or off based on the policy of an operator. 441 3.1.4.2 Service Description 443 Server operators will offer varying degrees of access depending on 444 policy and need. The following are some examples: 446 o users will be allowed access only to data for which they have a 447 relationship 449 o unauthenticated or anonymous access status may not yield any 450 contact information 452 o full access may be granted to a special group of authenticated 453 users 455 The types of access allowed by a server will most likely vary from 456 one operator to the next. 458 3.1.5 Client Processing 460 The protocol MUST be capable of allowing machine parsable requests 461 and responses. 463 3.1.6 Entity Referencing 465 There MUST be a mechanism for an entity contained within a server to 466 be referenced uniquely by an entry in another server. 468 3.1.7 Decentralization 470 3.1.7.1 Protocol Requirement 472 The protocol MUST NOT require the aggregation of data to a central 473 repository, server, or entity. The protocol MUST NOT require 474 aggregation of data indexes or hints to a central repository, server, 475 or entity. 477 3.1.7.2 Service Description 479 Some server operators may have a need to coordinate service in a mesh 480 or some other framework with other server operators. However, the 481 ability to operate a CRISP compliant server must not require this. 483 3.1.8 Query of Access Permission 485 3.1.8.1 Protocol Requirement 487 The protocol MUST provide a mechanism allowing a client to determine 488 if a query will be denied before the query is submitted according to 489 the appropriate policies of the operator. 491 3.1.8.2 Service Description 493 Because usage scenarios will differ depending on both policy and type 494 of service, some server operators may want to provide the ability for 495 a client to predetermine its ability to retrieve data from a query. 496 However, some operators will not allow this for security reasons, 497 policy restrictions, or other matters. 499 3.1.9 Authentication Distribution 501 3.1.9.1 Protocol Requirement 503 The protocol MUST NOT require any Internet registry to participate in 504 any authentication system. The protocol MUST NOT prohibit the 505 participation by an Internet registry in federated, distributed 506 authentication systems. 508 3.1.9.2 Service Description 510 Some server operators may have a need to delegate authentication to 511 another party or participate in a system where authentication 512 information is distributed. However, the ability to operate a CRISP 513 compliant server must not require this. 515 3.1.10 Base Error Responses 517 The protocol MUST be capable of returning the following types of 518 non-result or error responses to all lookups and searches: 520 o permission denied - a response indicating that the search or 521 lookup has failed due to insufficient authorization. 523 o not found - the desired results do not exist. 525 o insufficient resources - the search or lookup requires resources 526 that cannot be allocated. 528 3.1.11 Query Distribution 530 3.1.11.1 Protocol Requirement 532 The protocol MUST NOT prohibit a server from participating in a query 533 distribution system. 535 3.1.11.2 Service Description 537 For lookups and searches requiring distribution of queries, the 538 client must be allowed to distribute these queries among the 539 participants in an established mesh of server operators. It is not a 540 requirement that the protocol enable the discovery of servers, but 541 cooperating servers should be able to intelligently handle 542 distribution with its established mesh. Individual server operators 543 will respond to all queries received according to their policies for 544 authentication, privacy, and performance. 546 However, the ability to operate a CRISP compliant server must not 547 require the participation in any query distribution system. 549 3.1.12 Protocol and Schema Versioning 550 3.1.12.1 Protocol Requirements 552 The protocol MUST provide a means by which the end-systems can either 553 identify or negotiate over the protocol version to be used for any 554 query or set of queries. 556 All resource-specific schema MUST provide a version identifier 557 attribute which uniquely and unambiguously identifies the version of 558 the schema being returned in the answer set to a query. 560 3.1.12.2 Service Description 562 The service should allow end-systems using different protocol 563 versions to fallback to a mutually supported protocol version. If 564 this is not possible, the service must provide a meaningful error 565 which indicates that this is the specific case. 567 The service must suggest negotiation and/or recovery mechanisms for 568 clients to use when an unknown schema version is received. 570 3.1.13 Relay Bag 572 The term "bag" in this section describes a flexible container which 573 may contain unspecified data. 575 3.1.13.1 Protocol Requirement 577 When issuing a referral, the protocol MUST be capable of supplying a 578 relay bag from the server to the client, and the protocol MUST be 579 capable of allowing the client to submit this relay bag with a query 580 to the referred server. The use of the relay bag MUST be OPTIONAL. 581 The protocol MUST NOT make any assumptions regarding the contents of 582 the relay bag, but the relay bag MUST be described using the schema 583 language of the protocol. 585 The protocol MUST provide different error messages to indicate 586 whether the bag is of unrecognized format (permanent failure), if it 587 contains unacceptable data (permanent failure), or if it contains 588 data that means processing is refused at this time (transient 589 failure). 591 There MUST be no more than one bag per referral. The protocol MUST 592 NOT make an association or linkage between successive bags in a 593 referral chain. 595 The client MUST pass the bag as part of any query made to a referrant 596 server as a result of a referral. 598 3.1.13.2 Service Description 600 In some models where service coordination among participating server 601 operators is utilized, there might be needs to allow a referring 602 server to pass operator-to-operator coordination data along with the 603 referral to the referent server. Such needs might be auditing or 604 tracking. This feature requirement allows a server to pass to the 605 client a flexible container of unspecified data ("bag") that the 606 client should pass to the referent server. The bag has no meaning to 607 the client. 609 3.2 Domain Specific Functions 611 These functions describe requirements specifically needed by domain 612 registries (Section 2.1.1) and domain registrars (Section 2.1.2). 613 Requirements specific to other registries (Section 2.2) MUST be 614 specified separately. No compliant server operator is required to 615 support the functions required by every registry type. 617 3.2.1 Lookups 619 3.2.1.1 Protocol Requirement 621 The protocol MUST contain the following lookup functions: 623 1. Contact lookup given a unique reference to a contact of a 624 resource. 626 2. Nameserver lookup given a fully-qualified host name or IP address 627 of a nameserver. 629 3. Domain lookup given a fully-qualified domain name. 631 See Section 3.2.3 for the requirements regarding the expected return 632 values. 634 3.2.1.2 Service Description 636 These lookups are all single index queries and should produce zero or 637 only one entity. 639 Depending on the policy and need of an Internet registry, a server 640 operator may not allow all or any of these lookups to return part or 641 all of the information. See Section 3.2.3. 643 3.2.2 Searches 644 3.2.2.1 Protocol Requirement 646 The protocol MUST contain the following search functions: 648 1. Domain name search given an exact match or reasonable subset of a 649 name. This search SHOULD allow for parameters and qualifiers 650 designed to allow better matching of internationalized domain 651 names and SHOULD allow for both exact and partial matching within 652 the limits of internationalized domain names. This search SHOULD 653 NOT require special transformations of internationalized domain 654 names to accommodate this search. This search MUST provide a 655 means to narrow the search by names delegated under a particular 656 TLD. 658 2. Domain registrant search by either exact name or partial name 659 match with the ability to narrow the search to registrants of a 660 particular TLD. 662 3. Domains hosted by a nameserver given the fully-qualified host 663 name or IP address of a nameserver. 665 See Section 3.2.3 for the requirements regarding the expected return 666 values. 668 3.2.2.2 Service Description 670 Depending on the policy and need of an Internet registry, a server 671 operator may not allow all or any of these searches to return part or 672 all of the information. See Section 3.1.4. Access to information 673 resulting from these searches may also be limited, depending on 674 policy, by quantity. Section 3.2.5 describes these types of 675 restrictions. 677 Some Internet registries may also be participating in a query 678 distribution system. See Section 3.1.11. 680 3.2.3 Information Sets 682 3.2.3.1 Protocol Requirements 684 The data sets for contacts, nameservers, and domains MUST be able to 685 express and represent the attributes and allowable values of 686 registration requests in domain registration and provisioning 687 protocols. 689 The schema MUST be capable of expressing the following information 690 for domains: 692 o activation status 694 o registrant 696 o nameservers 698 o technical, billing or other contacts 700 o registry delegating the domain 702 o registrar for the domain 704 The data set for domains MUST be able to express arbitrary textual 705 information for extensions on an individual operator basis. Examples 706 of such information are license agreements, authorized use policies, 707 extended status notifications, marketing/for sale notices, and URI 708 references to other sources. 710 3.2.3.2 Service Description 712 It is not expected that every Internet registry supply all of the 713 information spelled out above, however the schemas employed by the 714 protocol must be capable of expressing this information should a 715 registry need to provide it. 717 The following sections describe requirements relative to the use of 718 schemas with respect to individual registry need and policy: 720 o Section 3.2.8 722 o Section 3.2.5 724 o Section 3.1.4 726 o Section 3.1.1 728 3.2.4 Serialization Support 730 The schemas used by the protocol SHOULD be capable of off-line 731 serialization 733 Off-line serialization allows for implementation independent 734 operations such as backup and recovery, load-balancing, etc. This 735 MAY also make possible, in whole or in part, data escrow capabilities 736 and other usages, however such usages are out of the scope of this 737 document. 739 3.2.5 Result Set Limits 741 3.2.5.1 Protocol Requirement 743 The protocol MUST contain a feature, used at the discretion of a 744 server operator, to allow a server to express to a client a limit on 745 the number of results from searches and lookups. When returning 746 result sets, the protocol MUST be able to make the following 747 distinctions: 749 1. an empty result set. 751 2. a result set truncated for the purpose of improving performance 752 bottlenecks. 754 3. a result set truncated to comply with Section 3.1.1 756 3.2.5.2 Service Description 758 Client software will operate more usefully if it can understand 759 reasons for the truncation of result sets. Of course, some Internet 760 registries may not be able to expose their policies for the limiting 761 of result sets, but, when it is possible, clients will have a better 762 operational view. This may eliminate re-queries and other repeated 763 actions that are not desirable. 765 3.2.6 DNS Delegation Referencing 767 3.2.6.1 Protocol Requirement 769 The protocol MUST use the delegation authority model available in DNS 770 [1] as the primary means for determining the authoritative source for 771 information regarding domains or any other objects when applicable. 773 3.2.6.2 Service Description 775 The intent of this requirement is to have clients use the DNS 776 delegation model to find servers authoritative for resources instead 777 of using a master or central server containing pointer information. 778 In other words, when a resource is naturally mapped by DNS, the 779 desired behavior is to consult the DNS to find an authoritative 780 server containing information about that resource. Using 781 'example.com', the authoritative server for information about 782 example.com according to the registrant of that domain may be found 783 by querying the DNS zone for example.com. To find the registry 784 information for example.com, the DNS zone for com should be queried. 786 There are cases where resources will not naturally map into the DNS 787 delegation hierarchy. This requirement is not meant to force such a 788 mapping. 790 3.2.7 Distribution for Domain Registry Types 792 3.2.7.1 Protocol Requirement 794 The protocol MUST NOT prohibit the distribution of data to exclude 795 any of the registry/registrar models stated in Section 2.1.1. The 796 protocol MUST be capable of expressing referrals and entity 797 references between the various models described in Section 2.1.1. 799 3.2.7.2 Service Description 801 Depending on the domain registry/registrar model in use, technical 802 data for a domain may only reside in one server while contact data 803 for the same domain may only reside in a server operated by a 804 separate entity. However, in many uses, this is not the situation. 805 Therefore, the service must accommodate for the various registration 806 distribution models of domain registry types described in Section 807 2.1.1 while complying with Section 3.1.7. 809 3.2.8 Data Omission 811 3.2.8.1 Protocol Requirement 813 When a value in an answer to a query cannot be given due to policy 814 constraints, the protocol MUST be capable of expressing the value in 815 one of three ways: 817 1. complete omission of the value without explanation 819 2. an indication that the value cannot be given due to insufficient 820 authorization 822 3. an indication that the value cannot be given due to privacy 823 constraints regardless of authorization status 825 The protocol MAY define other values for this purpose, but MUST 826 define values defined above at a minimum. 828 3.2.8.2 Service Description 830 Internet registries will have varying constraints regarding their 831 ability to expose certain types of data, usually social information. 832 Server operators must have the ability to accommodate this need while 833 client software will be more useful when provided with proper 834 explanations. Therefore, depending on policy, a server operator has 835 a choice between not returning the data at all, signaling a 836 permission error, or indicating a privacy constraint. 838 3.2.9 Internationalization 840 The schema defining domain related resources MUST conform to RFC 2277 841 [2] regarding textual data. In particular, the schema MUST be able 842 to indicate the charset and language in use with unstructured textual 843 data. 845 The protocol MUST be able to support multiple representations of 846 contact data, with these representations complying with the 847 requirements in Section 3.2.3. The protocol MUST be able to provide 848 contact data in UTF-8 and SHOULD be able to provide contact data in 849 US-ASCII, other character sets, and capable of specifying the 850 language of the data. 852 4. Feature Requirements 854 Feature requirements describe the perceived need derived from the 855 functional requirements for specific technical criteria of the 856 directory service. This section describes requirements in the manner 857 specified in Section 1.3. 859 4.1 Client Authentication 861 Entities accessing the service (users) MUST be provided a mechanism 862 for passing credentials to a server for the purpose of 863 authentication. The protocol MUST provide a mechanism capable of 864 employing many authentication types and capable of extension for 865 future authentication types. 867 4.2 Referrals 869 To distribute queries for search continuations and to issue entity 870 references, the protocol MUST provide a referral mechanism. 872 4.3 Common Referral Mechanism 874 To distribute queries for search continuations and to issue entity 875 references, the protocol MUST define a common referral scheme and 876 syntax. 878 4.4 Structured Queries and Responses 880 To provide for machine consumption as well as human consumption, the 881 protocol MUST employ structured queries and responses. 883 4.5 Existing Schema Language 885 To provide structured queries and responses and allow for minimal 886 technological reinvention, the protocol MUST employ a pre-existing 887 schema language. 889 4.6 Defined Schemas 891 To provide for machine consumption as well as human consumption, the 892 protocol MUST define schemas for use by the structured queries and 893 responses. 895 5. Internationalization Considerations 897 Requirements defined in this document MUST consider the best 898 practices spelled out in [2]. 900 6. IANA Considerations 902 IANA consideration for any service meeting these requirements will 903 depend upon the technologies chosen and MUST be specified by any 904 document describing such a service. 906 7. Security Considerations 908 This document contains requirements for the validation of 909 authenticated entities and the access of authenticated entities 910 compared with the access of non-authenticated entities. This 911 document does not define the mechanism for validation of 912 authenticated entities. Requirements defined in this document MUST 913 allow for the implementation of this mechanism according best common 914 practices. 916 The requirement in Section 3.1.4 must be weighed against other 917 requirements specifying search or lookup capabilities. 919 This document contains requirements for referrals and entity 920 references. Client implementations based on these requirements 921 SHOULD take proper care in the safe-guarding of credential 922 information when resolving referrals or entity references according 923 to best common practices. 925 This document contains requirements for the distribution of queries 926 among a mesh of participating service providers. Protocols proposed 927 to meet these requirements must be able to protect against the use of 928 that distribution system as a vector of distributed denial of service 929 attacks or unauthorized data mining. 931 Normative References 933 [1] Mockapetris, P., "Domain names - implementation and 934 specification", STD 13, RFC 1035, November 1987. 936 [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", 937 BCP 18, RFC 2277, January 1998. 939 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 940 Levels", BCP 14, RFC 2119, March 1997. 942 Informative References 944 [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 945 Protocol (v3)", RFC 2251, December 1997. 947 [5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. 948 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, 949 June 1997. 951 [6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 952 954, October 1985. 954 [7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 955 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 956 Policy Specification Language (RPSL)", RFC 2622, June 1999. 958 URIs 960 [8] 962 [9] 964 [10] 967 [11] 970 [12] 972 Author's Address 974 Andrew L. Newton 975 VeriSign, Inc. 976 21355 Ridgetop Circle 977 Sterling, VA 20166 978 USA 980 Phone: +1 703 948 3382 981 EMail: anewton@verisignlabs.com; anewton@ecotroph.net 983 Appendix A. Glossary 985 o TLD: Initials for "top level domain." Referes to domains in DNS 986 [1]that are hierarchically at the level just beneath the root. 988 o ccTLD: Initials for "country code top level domain." TLD's which 989 use one of the two character country codes defined by ISO. 991 o gTLD: Initials for "generic top level domain." TLD's that do not 992 use one of the two character country codes defined by ISO. 994 o contact data: Data containing names and contact information (i.e. 995 postal addresses, phone numbers, e-mail addresses) of humans or 996 legal entities. 998 o operational data: Data necessary to the operation of networks and 999 network related services and items. 1001 o RIR: Initials for "regional Internet registry." 1003 o IRR: Initials for "Internet routing registry." 1005 o forward lookup: a DNS lookup where a domain name is resolved to an 1006 IP address. 1008 o reverse lookup: a DNS lookup where an IP address is resolved to a 1009 domain name. 1011 o mining: In the context of this document, this term is specific to 1012 data mining. This is a methodical process to obtain the contents 1013 of directory service, usually as much as possible, not relevant to 1014 any immediate need. Data mining is often not a practice welcomed 1015 by registry operators. 1017 Appendix B. Acknowledgements 1019 B.1 Forums 1021 The proceedings of the following public forums were used as input to 1022 the scope and requirements for this document: 1024 o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego, 1025 CA, USA 1027 o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, 1028 England 1030 o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA 1032 o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, 1033 USA 1035 o Third UWho Consultation; November 19, 2001; Washington, DC, USA 1037 o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic 1039 o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech 1040 Republic 1042 o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA 1044 o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands 1046 o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The 1047 Netherlands 1049 o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida 1051 o CENTR General Assembly, February 21-22, 2002; Rambouillet, France 1053 o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, 1054 Minnesota, USA 1056 B.2 Working Group 1058 This document is a work item of the Cross-Registry Internet Service 1059 Protocol (CRISP) Working Group in the Applications Area of the IETF. 1060 Discussions for this working group are held on the email list 1061 ietf-not43@lists.verisignlabs.com. To subscribe to this email list, 1062 send email to ietf-not43-request@lists.verisignlabs.com with a 1063 subject line of "subscribe". Archives of this list may be found out 1064 http://lists.verisignlabs.com/pipermail/ietf-not43/. 1066 B.3 Contributions 1068 Comments, suggestions, and feedback of significant substance have 1069 been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, 1070 Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric 1071 Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George 1072 Michaelson, and Tim Christensen. 1074 Intellectual Property Statement 1076 The IETF takes no position regarding the validity or scope of any 1077 intellectual property or other rights that might be claimed to 1078 pertain to the implementation or use of the technology described in 1079 this document or the extent to which any license under such rights 1080 might or might not be available; neither does it represent that it 1081 has made any effort to identify any such rights. Information on the 1082 IETF's procedures with respect to rights in standards-track and 1083 standards-related documentation can be found in BCP-11. Copies of 1084 claims of rights made available for publication and any assurances of 1085 licenses to be made available, or the result of an attempt made to 1086 obtain a general license or permission for the use of such 1087 proprietary rights by implementors or users of this specification can 1088 be obtained from the IETF Secretariat. 1090 The IETF invites any interested party to bring to its attention any 1091 copyrights, patents or patent applications, or other proprietary 1092 rights which may cover technology that may be required to practice 1093 this standard. Please address the information to the IETF Executive 1094 Director. 1096 Full Copyright Statement 1098 Copyright (C) The Internet Society (2003). All Rights Reserved. 1100 This document and translations of it may be copied and furnished to 1101 others, and derivative works that comment on or otherwise explain it 1102 or assist in its implementation may be prepared, copied, published 1103 and distributed, in whole or in part, without restriction of any 1104 kind, provided that the above copyright notice and this paragraph are 1105 included on all such copies and derivative works. However, this 1106 document itself may not be modified in any way, such as by removing 1107 the copyright notice or references to the Internet Society or other 1108 Internet organizations, except as needed for the purpose of 1109 developing Internet standards in which case the procedures for 1110 copyrights defined in the Internet Standards process must be 1111 followed, or as required to translate it into languages other than 1112 English. 1114 The limited permissions granted above are perpetual and will not be 1115 revoked by the Internet Society or its successors or assignees. 1117 This document and the information contained herein is provided on an 1118 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1119 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1120 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1121 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1122 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1124 Acknowledgement 1126 Funding for the RFC Editor function is currently provided by the 1127 Internet Society.