idnits 2.17.1 draft-ietf-crisp-internet-resource-number-req-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 : ---------------------------------------------------------------------------- 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 (July 25, 2003) is 7581 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. '3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 954 (ref. '5') (Obsoleted by RFC 3912) == Outdated reference: A later version (-06) exists of draft-ietf-crisp-requirements-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Listman, Editor 3 Internet-Draft American Registry for Internet Numbers 4 Expires: January 25, 2004 July 25, 2003 6 Cross Registry Internet Service Protocol (CRISP) Internet Resource 7 Number Requirements 8 draft-ietf-crisp-internet-resource-number-req-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 25, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 Internet registries expose administrative and operational data via 40 varying directory services. This document defines functional 41 requirements for the directory services of Internet resource number 42 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 Regional Internet Registries . . . . . . . . . . . . . . 6 52 2.2 Other Internet Registries . . . . . . . . . . . . . . . 6 53 3. Functional Requirements . . . . . . . . . . . . . . . . 7 54 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . 7 56 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . 7 57 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . 7 58 3.1.3.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 7 59 3.1.3.2 Service Description . . . . . . . . . . . . . . . . . . 8 60 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . 8 61 3.1.4.1 Protocol Requirements . . . . . . . . . . . . . . . . . 8 62 3.1.4.2 Service Description . . . . . . . . . . . . . . . . . . 8 63 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . 8 64 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . 9 65 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . 9 66 3.1.7.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 9 67 3.1.7.2 Service Description . . . . . . . . . . . . . . . . . . 9 68 3.1.8 Authentication Distribution . . . . . . . . . . . . . . 9 69 3.1.8.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 9 70 3.1.8.2 Service Description . . . . . . . . . . . . . . . . . . 9 71 3.1.9 Base Error Responses . . . . . . . . . . . . . . . . . . 9 72 3.1.10 Query Distribution . . . . . . . . . . . . . . . . . . . 10 73 3.1.10.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 10 74 3.1.10.2 Service Description . . . . . . . . . . . . . . . . . . 10 75 3.1.11 Protocol and Schema Versioning . . . . . . . . . . . . . 10 76 3.1.11.1 Protocol Requirements . . . . . . . . . . . . . . . . . 10 77 3.1.11.2 Service Description . . . . . . . . . . . . . . . . . . 10 78 3.2 Internet Resource Number Specific Functions . . . . . . 10 79 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.2.1.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 11 81 3.2.1.2 Service Description . . . . . . . . . . . . . . . . . . 11 82 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.2.2.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 11 84 3.2.2.2 Service Description . . . . . . . . . . . . . . . . . . 12 85 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . 12 86 3.2.3.1 Protocol Requirements . . . . . . . . . . . . . . . . . 12 87 3.2.3.1.1 IP Address Network Return Values . . . . . . . . . . . . 12 88 3.2.3.1.2 Autonomous System Return Values . . . . . . . . . . . . 13 89 3.2.3.1.3 Contact Return Values . . . . . . . . . . . . . . . . . 13 90 3.2.3.1.4 Organization Return Values . . . . . . . . . . . . . . . 13 91 3.2.3.2 Service Description . . . . . . . . . . . . . . . . . . 14 92 3.2.4 Result Set Limits . . . . . . . . . . . . . . . . . . . 14 93 3.2.4.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 14 94 3.2.4.2 Service Description . . . . . . . . . . . . . . . . . . 14 95 3.2.5 Distribution for Internet Resource Number 96 Registry Types . . . . . . . . . . . . . . . . . . . . . 14 97 3.2.5.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 14 98 3.2.5.2 Service Description . . . . . . . . . . . . . . . . . . 15 99 3.2.6 Data Omission . . . . . . . . . . . . . . . . . . . . . 15 100 3.2.6.1 Protocol Requirement . . . . . . . . . . . . . . . . . . 15 101 3.2.6.2 Service Description . . . . . . . . . . . . . . . . . . 15 102 3.2.7 Internationalization . . . . . . . . . . . . . . . . . . 15 103 3.2.8 Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 104 4. Feature Requirements . . . . . . . . . . . . . . . . . . 17 105 4.1 Client Authentication . . . . . . . . . . . . . . . . . 17 106 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . 17 107 4.4 Structured Queries and Responses . . . . . . . . . . . . 17 108 5. Internationalization Considerations . . . . . . . . . . 18 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . 19 110 7. Security Considerations . . . . . . . . . . . . . . . . 20 111 Normative References . . . . . . . . . . . . . . . . . . 21 112 Informative References . . . . . . . . . . . . . . . . . 22 113 Appendix A. Glossary . . . . . . . . . . . . . . . . . . 23 114 Appendix B. Acknowledgements . . . . . . . . . . . . . . 24 115 B.1 Working Group . . . . . . . . . . . . . . . . . . . 24 116 B.2 Contributions . . . . . . . . . . . . . . . . . . . 24 117 Intellectual Property Statement . . . . . . . . . . . . 25 118 Full Copyright Statement . . . . . . . . . . . . . . . . 25 119 Acknowledgement . . . . . . . . . . . . . . . . . . . . 26 121 1. Introduction 123 1.1 Background 125 The expansion and growth of the Internet has seen the registry 126 function of a traditionally centralized and managed Network 127 Information Center become the responsibility of various autonomous, 128 functionally disparate, and globally distributed Internet registries. 129 With the broadening number of Internet registries, the uses of their 130 administrative directory services have expanded from the original and 131 traditional use of the whois [5] protocol to include the use of whois 132 outside the scope of its specification, formal and informal 133 definitions of syntax, undocumented security mechanisms, the use of 134 other protocols, such as rwhois [4], to fulfill other needs, and 135 proposals for the use of other technologies such as LDAP [3] and XML. 137 1.2 Requirements Scope 139 The scope of the requirements captured in this document relate to the 140 directory services of Internet resource number registries and their 141 related communities (Section 2.1 and Section 2.2). Additional 142 communities are described in the Cross Registry Internet Service 143 Protocol (CRISP) Requirements draft [6]. These requirements are not 144 specific to any protocol. Terms used in the definition of the 145 requirements in this document may be found in the glossary 146 (Appendix A). 148 The scope of the requirements in this document is also restricted to 149 access of data from Internet registries. Requirements for 150 modification, addition, or provisioning of data in Internet 151 registries are out of scope. 153 1.3 Requirements Specification 155 The requirements captured in this document are for the purpose of 156 designing technical specifications. The words used in this document 157 for compliance with RFC2119 [2] do not reference or specify policy 158 and speak only to the capabilities in the derived technology. For 159 instance, this document may say that the protocol "MUST" support 160 certain features. An actual service operator is always free to 161 disable it (and then to return an error such as "permission denied".) 163 Requirements in this document specifying the capabilities of the 164 protocol required for proper interaction between a client and a 165 server will be specified with the "MUST/SHOULD" language of RFC2119 166 [2]. This document also contains language relating to the 167 interaction of a client with multiple servers to form a coherent, 168 cross-network service. Such service requirements will not be 169 described using RFC2119 language. 171 While individual servers/service operators may not support all 172 features that the protocol can support, they must respect the 173 semantics of the protocol queries and responses. For example, a 174 server should not return referrals if it does not have referent data. 176 2. Internet Registry Communities 178 The Internet registries are composed of various communities which 179 provide scope for the requirements in this document. This document 180 describes those communities specifically involved with Internet 181 resource number registration. Other communities are described in the 182 Cross Registry Internet Service Protocol (CRISP) Requirements draft 183 [6]. These descriptions are provided in this document for 184 informational purposes only. 186 2.1 Regional Internet Registries 188 Regional Internet Registries (RIRs) administer the allocation of IP 189 address space and autonomous system numbers. Each RIR serves 190 specific geographic regions, and collectively they service the entire 191 Internet. Each RIR is a membership-based, non-profit organization 192 that facilitates and implements addressing policy based on the 193 direction of their regional community. 195 2.2 Other Internet Registries 197 Local Internet Registries (LIRs), National Internet Registries (NIRs) 198 and Internet Service Providers (ISPs) are registries of the RIRs and 199 coordinate the same functions of the RIRs for smaller, more specific 200 geographic regions, sovereign nations, localities, and business 201 regions. 203 3. Functional Requirements 205 Functional requirements describe an overall need or process for which 206 the directory service is used by an Internet registry to fulfill its 207 obligations to provide information about their customers, members and 208 the resources they hold. This section describes requirements in the 209 manner specified in Section 1.3. 211 3.1 Base Functions 213 This section describes basic directory service protocol requirements 214 for Internet registries. Additional requirements, specific to 215 Internet resource number registries, are described in Internet 216 Resource Number Specific Functions (Section 3.2). 218 3.1.1 Mining Prevention 220 In order to prevent the inappropriate acquisition of data from an 221 Internet registry's directory service, servers may limit the amount 222 of data that may be returned in a fixed time period from a server to 223 a client. This will most likely be especially true for anonymous 224 access uses (see Section 3.1.4). 226 The limits placed on differing types of data or applied depending 227 upon access status will most likely differ from server to server 228 based on policy and need. Support for varying service models in the 229 effort to limit data and prevent data mining may or may not have a 230 direct impact on the client-to-server protocol, but MUST NOT be 231 prevented by the protocol. 233 3.1.2 Minimal Technical Reinvention 235 The protocol MUST NOT employ unique technology solutions for all 236 aspects and layers above the network and transport layers and SHOULD 237 make use of existing technology standards where applicable. The 238 protocol MUST employ the use of network and transport layer standards 239 as defined by the Internet Engineering Task Force. The protocol MUST 240 define one or more transport mechanisms for mandatory implementation. 242 3.1.3 Standard and Extensible Schemas 244 3.1.3.1 Protocol Requirement 246 The protocol MUST contain standard schemas for the exchange of data 247 needed to implement the functionality in this document. In addition, 248 there MUST be a means to allow the use of schemas not defined by the 249 needs of this document. Both types of schemas MUST use the same 250 schema language. The schemas MUST be able to express data elements 251 with identifying tags for the purpose of localization of the meaning 252 of the identifying tags. 254 3.1.3.2 Service Description 256 The client-to-server protocol must define a standard set of data 257 structures or schemas to be used when exchanging information. It 258 must also possess the ability to allow for the use of newer data 259 structures that are currently nor foreseen by this specification. In 260 both cases, the description and specification of both types of data 261 structures or schemas must be done in the same way (i.e. the same 262 schema language). 264 The schemas must also be capable of "tagging" data with a unique 265 identifier. This identifier can then be used to localize the name of 266 that type of data. For instance, a piece of data may have the value 267 "Bob" and its type identified with the number "5.1". Client software 268 could use this to display "Name: Bob" in an English locale or 269 "Nombre: Bob" in a Spanish locale. 271 3.1.4 Level of Access 273 3.1.4.1 Protocol Requirement 275 The protocol MUST NOT prohibit an operator from granularly assigning 276 multiple types of access to data according to the policies of the 277 operator. The protocol MUST provide an authentication mechanism and 278 MUST NOT prohibit an operator from granting types of access based on 279 authentication. 281 The protocol MUST provide an anonymous access mechanism that may be 282 turned on or off based on the policy of an operator. 284 3.1.4.2 Service Description 286 Server operators may offer varying degrees of access depending on 287 policy and need. The following are some examples: 289 o users may be allowed access only to data for which they have a 290 relationship 292 o unauthenticated or anonymous access status may not yield any 293 contact information 295 o full access may be granted to a special group of authenticated 296 users 298 The types of access allowed by a server will most likely vary from 299 one operator to the next. 301 3.1.5 Client Processing 303 The protocol MUST be capable of allowing machine parsable requests 304 and responses. 306 3.1.6 Entity Referencing 308 There MUST be a mechanism for an entity contained within a server to 309 be referenced uniquely by an entry in another server. 311 3.1.7 Decentralization 313 3.1.7.1 Protocol Requirement 315 The protocol MUST NOT require the aggregation of data to a central 316 repository, server, or entity. The protocol MUST NOT require 317 aggregation of data indexes or hints to a central repository, server, 318 or entity. 320 3.1.7.2 Service Description 322 Some server operators may have a need to coordinate service in a mesh 323 or some other framework with other server operators. However, the 324 ability to operate a CRISP compliant server must not require this. 326 3.1.8 Authentication Distribution 328 3.1.8.1 Protocol Requirement 330 The protocol MUST NOT require any Internet registry to participate in 331 any authentication system. The protocol MUST NOT prohibit the 332 participation by an Internet registry in federated, distributed 333 authentication systems. 335 3.1.8.2 Service Description 337 Some server operators may have a need to delegate authentication to 338 another party or participate in a system where authentication 339 information is distributed. However, the ability to operate a CRISP 340 compliant server must not require this. 342 3.1.9 Base Error Responses 344 The protocol MUST be capable of returning the following types of non- 345 result or error responses to all lookups and searches: 347 o permission denied - a response indicating that the search or 348 lookup has failed due to insufficient authorization. 350 o not found - the desired results do not exist. 352 o insufficient resources - the search or lookup requires resources 353 that cannot be allocated. 355 3.1.10 Query Distribution 357 3.1.10.1 Protocol Requirement 359 The protocol MUST NOT prohibit a server from participating in a query 360 distribution system. 362 3.1.10.2 Service Description 364 For lookups and searches requiring distribution of queries, the 365 client must be allowed to distribute these queries among the 366 participants in an established mesh of server operators. It is not a 367 requirement that the protocol enable the discovery of servers, but 368 cooperating servers should be able to intelligently handle 369 distribution with its established mesh. Individual server operators 370 will respond to all queries received according to their policies for 371 authentication, privacy, and performance. 373 However, the ability to operate a CRISP compliant server must not 374 require the participation in any query distribution system. 376 3.1.11 Protocol and Schema Versioning 378 3.1.11.1 Protocol Requirements 380 The protocol MUST provide a means by which the end-systems can either 381 identify or negotiate over the protocol version to be used for any 382 query or set of queries. 384 All resource-specific schemas MUST provide version identifier 385 attributes which uniquely and unambiguously identifies the version of 386 the schema being returned in the answer set to a query. 388 3.1.11.2 Service Description 390 The service should allow end-systems using different protocol 391 versions to fallback to a mutually supported protocol version. If 392 this is not possible, the service must provide a meaningful error 393 which indicates that this is the specific case. 395 The service must suggest negotiation and/or recovery mechanisms for 396 clients to use when an unknown schema version is received. 398 3.2 Internet Resource Number Specific Functions 400 These functions describe requirements specifically needed by Regional 401 Internet Registries (Section 2.1). No compliant server operator is 402 required to support the functions required by every registry type. 404 3.2.1 Lookups 405 Lookups are queries by unique identifiers resulting in zero or one 406 match. 408 3.2.1.1 Protocol Requirement 410 The protocol MUST be able to query for information relating to the 411 following kinds of objects: 413 1. IPv4 network address(es) 415 2. IPv6 network address(es) 417 3. Autonomous system number(s) 419 4. Contact 421 5. Organization 423 See Section 3.2.3 for the requirements regarding the expected return 424 values. 426 3.2.1.2 Service Description 428 These lookups are all single index queries, have a unique identifier 429 and should produce zero or only one entity. 431 Depending on the policy and need of an Internet registry, a server 432 operator may not allow all or any of these lookups to return part or 433 all of the information. See Section 3.2.3. 435 3.2.2 Searches 437 Searches are queries by attributes that may not be unique resulting 438 in zero, one or many matches. 440 3.2.2.1 Protocol Requirement 442 The protocol MUST contain the following search functions: 444 1. IPv4 address search given one or more contiguous IP address 445 numbers. This search SHOULD allow for both exact matching and 446 nested matching. 448 2. IPv6 address search given one or more contiguous IP address 449 numbers. This search SHOULD allow for both exact matching and 450 nested matching. 452 3. Autonomous system number search given one or more contiguous 453 numbers. This search SHOULD allow for both exact matching and 454 nested matching. 456 4. Contact search by either exact name or partial name matching. 458 5. Organization search by either exact name or partial name matching. 460 See Section 3.2.3 for the requirements regarding the expected return 461 values. 463 3.2.2.2 Service Description 465 These searches may be multi-index queries and may produce zero, one 466 or many entities. 468 Depending on the policy and need of an Internet registry, a server 469 operator may not allow all or any of these searches to return part or 470 all of the information. See Section 3.1.4. Access to information 471 resulting from these searches may also be limited, depending on 472 policy, by quantity. Section 3.2.5 describes these types of 473 restrictions. 475 Some Internet registries may also be participating in a query 476 distribution system. See Section 3.1.10. 478 3.2.3 Information Sets 480 3.2.3.1 Protocol Requirements 482 The data sets for networks, autonomous systems, contacts, and 483 organizations MUST be able to express and represent the attributes 484 and allowable values of registered Internet resource number 485 registration and provisioning protocols. 487 The data set for networks, autonomous systems, organizations and 488 contacts MUST be able to express arbitrary textual information for 489 extensions on an individual operator basis. Examples of such 490 information are authorized use policies, extended status 491 notifications, marketing/for sale notices, and URI references to 492 other sources. 494 3.2.3.1.1 IP Address Network Return Values 496 The schema MUST be capable of expressing the following information 497 for IP address networks: 499 o range of IP addresses 501 o network type, for example, allocated or assigned 503 o contacts and the function/role served 505 o organization holding the address space 506 o reverse delegation information 508 o last updated date 510 o registry delegating the address space 512 3.2.3.1.2 Autonomous System Return Values 514 The schema MUST be capable of expressing the following information 515 for autonomous systems: 517 o range of autonomous system number(s) 519 o contacts and function/role served 521 o organization holding the resource 523 o last updated date 525 o registry delegating the resource 527 3.2.3.1.3 Contact Return Values 529 The schema MUST be capable of expressing the following information 530 for contacts: 532 o name of contact 534 o unique identifier 536 o postal address including country code 538 o telephone number(s), extension(s), and type 540 o e-mail address(es) 542 o last updated date 544 3.2.3.1.4 Organization Return Values 546 The schema MUST be capable of expressing the following information 547 for organizations: 549 o name of organization 551 o unique identifier 553 o postal address including country code 555 o contacts and function/role served 556 o last updated date 558 3.2.3.2 Service Description 559 It is not expected that every Internet registry supply all of the 560 information spelled out above, however the schemas employed by the 561 protocol must be capable of expressing this information should a 562 registry need to provide it. 564 The following sections describe requirements relative to the use of 565 schemas with respect to individual registry need and policy: 567 o Section 3.2.6 569 o Section 3.2.4 571 o Section 3.1.4 573 o Section 3.1.1 575 3.2.4 Result Set Limits 577 3.2.4.1 Protocol Requirement 579 The protocol MUST contain a feature, used at the discretion of a 580 server operator, to allow a server to express to a client a limit on 581 the number of results from searches and lookups. When returning 582 result sets, the protocol MUST be able to make the following 583 distinctions: 585 1. an empty result set. 587 2. a result set truncated for the purpose of improving performance 588 bottlenecks. 590 3. a result set truncated to comply with Section 3.1.1 592 3.2.4.2 Service Description 594 Client software will operate more usefully if it can understand 595 reasons for the truncation of result sets. Of course, some Internet 596 registries may not be able to expose their policies for the limiting 597 of result sets, but, when it is possible, clients will have a better 598 operational view. This may eliminate re-queries and other repeated 599 actions that are not desirable. 601 3.2.5 Distribution for Internet Resource Number Registry Types 603 3.2.5.1 Protocol Requirement 605 The protocol MUST NOT prohibit the distribution of data to exclude 606 any of the registry types stated in Section 2. The protocol MUST be 607 capable of expressing referrals and entity references between the 608 various registry types described in Section 2. 610 3.2.5.2 Service Description 612 An RIR will allocate IP address space to those registration entities 613 described in Section 2.2. These entities may be given the option to 614 store utilization within the RIR database, or establish their own 615 server to be referenced as needed. If the entity establishes their 616 own server, it must comple with the requirements of this document. 618 3.2.6 Data Omission 620 3.2.6.1 Protocol Requirement 622 When a value in an answer to a query cannot be given due to policy 623 constraints, the protocol MUST be capable of expressing the value in 624 one of three ways: 626 1. complete omission of the value without explanation 628 2. an indication that the value cannot be given due to insufficient 629 authorization 631 3. an indication that the value cannot be given due to privacy 632 constraints regardless of authorization status 634 The protocol MAY define other values for this purpose, but MUST 635 define values defined above at a minimum. 637 3.2.6.2 Service Description 639 Internet registries will have varying constraints regarding their 640 ability to expose certain types of data. Server operators must have 641 the ability to accommodate this need while client software will be 642 more useful when provided with proper explanations. Therefore, 643 depending on policy, a server operator has a choice between not 644 returning the data at all, signaling a permission error, or 645 indicating a privacy constraint. 647 3.2.7 Internationalization 649 The schema defining Internet number related resources MUST conform to 650 RFC 2277 [1] regarding textual data. In particular, the schema MUST 651 be able to indicate the charset and language in use with unstructured 652 textual data. 654 The protocol MAY be able to support multiple representations of 655 contact data, with these representations complying with the 656 requirements in Section 3.2.3. The protocol MUST be able to provide 657 contact data in UTF-8 and SHOULD be able to provide contact data in 658 US-ASCII, other character sets, and capable of specifying the 659 language of the data. 661 3.2.8 Privacy 663 The following sections describe requirements related to the privacy 664 of the data stored in the database: 666 o Section 3.1.4 668 o Section 3.1.1 670 4. Feature Requirements 672 Feature requirements describe the perceived need derived from the 673 functional requirements for specific technical criteria of the 674 directory service. This section describes requirements in the manner 675 specified in Section 1.3. 677 4.1 Client Authentication 679 Entities accessing the service (users) MUST be provided a mechanism 680 for passing credentials to a server for the purpose of 681 authentication. The protocol MUST provide a mechanism capable of 682 employing many authentication types and capable of extension for 683 future authentication types. 685 4.2 Referrals 687 To distribute queries for search continuations and to issue entity 688 references, the protocol MUST provide a referral mechanism. 690 4.3 Common Referral Mechanism 692 To distribute queries for search continuations and to issue entity 693 references, the protocol MUST define a common referral scheme and 694 syntax. 696 4.4 Structured Queries and Responses 698 To provide for machine consumption as well as human consumption, the 699 protocol MUST employ structured queries and responses. 701 5. Internationalization Considerations 703 Requirements defined in this document MUST consider the best 704 practices spelled out in [1]. 706 6. IANA Considerations 708 IANA consideration for any service meeting these requirements will 709 depend upon the technologies chosen and MUST be specified by any 710 document describing such a service. 712 7. Security Considerations 714 This document contains requirements for the validation of 715 authenticated entities and the access of authenticated entities 716 compared with the access of non-authenticated entities. This 717 document does not define the mechanism for validation of 718 authenticated entities. Requirements defined in this document MUST 719 allow for the implementation of this mechanism according best common 720 practices. 722 The requirement in Section 3.1.4 must be weighed against other 723 requirements specifying search or lookup capabilities. 725 This document contains requirements for referrals and entity 726 references. Client implementations based on these requirements 727 SHOULD take proper care in the safe-guarding of credential 728 information when resolving referrals or entity references according 729 to best common practices. 731 This document contains requirements for the distribution of queries 732 among a mesh of participating service providers. Protocols proposed 733 to meet these requirements must be able to protect against the use of 734 that distribution system as a vector of distributed denial of service 735 attacks or unauthorized data mining. 737 Normative References 739 [1] Alvestrand, H., "IETF Policy on Character Sets and Languages", 740 BCP 18, RFC 2277, January 1998. 742 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 743 Levels", BCP 14, RFC 2119, March 1997. 745 Informative References 747 [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 748 Protocol (v3)", RFC 2251, December 1997. 750 [4] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. 751 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, 752 June 1997. 754 [5] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 755 954, October 1985. 757 [6] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 758 Requirements", draft-ietf-crisp-requirements-05, May 2003. 760 Editor's Address 762 Virginia Listman 763 American Registry for Internet Numbers 764 3635 Concorde Parkway, Suite 200 765 Chantilly, VA 20151 766 USA 768 Phone: +1 703 227 9870 769 EMail: ginny@arin.net 771 Appendix A. Glossary 773 o contact data: Data containing names and contact information (i.e. 774 postal addresses, phone numbers, e-mail addresses) of humans or 775 legal entities. 777 o operational data: Data necessary to the operation of networks and 778 network related services and items. 780 o RIR: Initials for "regional Internet registry." 782 o mining: In the context of this document, this term is specific to 783 data mining. This is a methodical process to obtain the contents 784 of directory service, usually as much as possible, not relevant to 785 any immediate operational Internet need. Data mining is often not 786 a practice welcomed by registry operators. 788 Appendix B. Acknowledgements 790 B.1 Working Group 792 This document is a work item of the Cross-Registry Internet Service 793 Protocol (CRISP) Working Group in the Applications Area of the IETF. 794 Discussions for this working group are held on the email list ietf- 795 not43@lists.verisignlabs.com. To subscribe to this email list, send 796 email to ietf-not43-request@lists.verisignlabs.com with a subject 797 line of "subscribe". Archives of this list may be found out 798 http://lists.verisignlabs.com/pipermail/ietf-not43/. 800 B.2 Contributions 802 The contents of this document are the compiled requirements of the 803 four existing Regional Internet Registries: Asia Pacific Network 804 Information Centre (APNIC), the American Registry for Internet 805 Numbers (ARIN), the Latin American and Caribbean Internet Address 806 Registry (LACNIC) and Reseaux IP Europeens Network Coordination 807 Centre (RIPE NCC). 809 Specific comments, suggestions, and feedback of significant 810 substance have been provided by Tim Christensen, Shane Kerr, George 811 Michaelson, Cathy Murphy and Frederico Neves. 813 Intellectual Property Statement 815 The IETF takes no position regarding the validity or scope of any 816 intellectual property or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; neither does it represent that it 820 has made any effort to identify any such rights. Information on the 821 IETF's procedures with respect to rights in standards-track and 822 standards-related documentation can be found in BCP-11. Copies of 823 claims of rights made available for publication and any assurances of 824 licenses to be made available, or the result of an attempt made to 825 obtain a general license or permission for the use of such 826 proprietary rights by implementers or users of this specification can 827 be obtained from the IETF Secretariat. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights which may cover technology that may be required to practice 832 this standard. Please address the information to the IETF Executive 833 Director. 835 Full Copyright Statement 837 Copyright (C) The Internet Society (2003). All Rights Reserved. 839 This document and translations of it may be copied and furnished to 840 others, and derivative works that comment on or otherwise explain it 841 or assist in its implementation may be prepared, copied, published 842 and distributed, in whole or in part, without restriction of any 843 kind, provided that the above copyright notice and this paragraph are 844 included on all such copies and derivative works. However, this 845 document itself may not be modified in any way, such as by removing 846 the copyright notice or references to the Internet Society or other 847 Internet organizations, except as needed for the purpose of 848 developing Internet standards in which case the procedures for 849 copyrights defined in the Internet Standards process must be 850 followed, or as required to translate it into languages other than 851 English. 853 The limited permissions granted above are perpetual and will not be 854 revoked by the Internet Society or its successors or assignees. 856 This document and the information contained herein is provided on an 857 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 858 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 859 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 860 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 861 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 863 Acknowledgement 864 Funding for the RFC Editor function is currently provided by the 865 Internet Society.