idnits 2.17.1 draft-ietf-crisp-firs-arch-01.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in ' Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 2003) is 7653 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) == Unused Reference: 'RFC1274' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'RFC2079' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'RFC2255' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1252, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-crisp-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-crisp-requirements (ref. 'CRISP-REQ') == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' ** Obsolete normative reference: RFC 1274 (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2596 (Obsoleted by RFC 3866) ** Downref: Normative reference to an Informational RFC: RFC 2798 ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 812 (Obsoleted by RFC 954, RFC 3912) Summary: 15 errors (**), 0 flaws (~~), 17 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-ietf-crisp-firs-arch-01.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 The Federated Internet Registry Service: 8 Architecture and Implementation Guide 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 RFC 2026. 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 Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 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 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the architectural framework for the 39 Federated Internet Registry Service (FIRS), a distributed service 40 for storing, locating and transferring information about Internet 41 resources using LDAPv3. 43 Table of Contents 45 1. Introduction...............................................2 46 1.1. Background..............................................3 47 1.2. Overview................................................4 48 2. Prerequisites and Terminology..............................5 49 3. Reference Example..........................................6 50 4. The FIRS Namespace.........................................8 51 4.1. The domainComponent Hierarchy...........................8 52 4.2. The inetResources Container.............................9 53 4.3. Resource-Specific Entries..............................10 54 4.4. Namespace Aliases......................................10 55 4.5. Partition Replicas.....................................11 56 5. FIRS Schema Definitions...................................12 57 5.1. Global Schema..........................................12 58 5.1.1. The inetResources schema.........................13 59 5.1.2. The inetAssociatedResources schema...............14 60 5.1.3. The referral schema..............................14 61 5.2. Resource-Specific Schema...............................14 62 6. Query Processing Behaviors................................15 63 6.1. Query Pre-Processing...................................16 64 6.2. Bootstrap Processing...................................17 65 6.3. Query Processing.......................................18 66 6.4. Query Post-Processing..................................19 67 6.4.1. Referrals........................................19 68 6.4.2. Internationalization and localization............20 69 7. Transition Issues.........................................22 70 7.1. NIC Handles............................................22 71 7.2. Change-Logs............................................23 72 8. Security Considerations...................................23 73 9. IANA Considerations.......................................26 74 10. Author's Address..........................................26 75 11. Normative References......................................26 76 12. Informational References..................................28 77 13. Acknowledgments...........................................28 78 14. Changes from Previous Versions............................29 79 15. Full Copyright Statement..................................30 81 1. Introduction 83 FIRS is intended to provide a distributed WHOIS-like information 84 service, using the LDAPv3 specifications [RFC3377] for the data- 85 formatting and query-transport functions. 87 More specifically, the principle objective behind FIRS is to offer 88 structured information about distributed Internet resources in a 89 model which reflects the federated delegations of those resources. 90 This specifically includes centralized delegations from authorized 91 governance bodies (such as DNS domains within the "com" zone), but 92 also includes delegations from authorized bodies further down the 93 delegation path (such as leaf-node DNS domain names within the 94 "example.com" zone). 96 Furthermore, the FIRS service is intended to be used with a wide 97 variety of resources. The core set of specifications define rules 98 for handling the most-common resources (DNS domains, IP addresses, 99 contact information, and so forth), but other types of resources 100 may be grafted onto the architecture as needed. By extension, FIRS 101 should be capable of providing the necessary support structure for 102 any kind of information to be stored in a global mesh of FIRS- 103 centric LDAP directories, and for the FIRS-specific clients and 104 servers to be easily extended to accommodate that data. 106 Another critical objective can be described as predictability, in 107 that FIRS-specific data should be easily accessible to a wide 108 number of applications. For example, if a network manager wants to 109 retrieve information about a particular host or network, it should 110 be easy for the management application to be extended so that the 111 FIRS data can be fetched by that application, rather than always 112 requiring the use of a FIRS-specific application. 114 Finally, the collection of specifications which define the 115 Federated Internet Registry Service (FIRS) are intended to satisfy 116 the CRISP Working Group requirements, as specified in draft-ietf- 117 crisp-requirements-05, "Cross Registry Internet Service Protocol 118 (CRISP) Requirements" [CRISP-REQ]. 120 In order to achieve these objectives, the FIRS specifications 121 collectively define an LDAP-specific application, including 122 application-specific namespaces, object classes, attributes, 123 syntaxes, queries, behavioral rules, and more. 125 1.1. Background 127 The original WHOIS service [RFC812] was provided as a front-end to 128 a centralized repository of ARPANET resources and users. Over 129 time, hundreds of WHOIS servers have been deployed across the 130 public Internet, with each server providing general information 131 about the particular network resources under the control of a 132 specific organization. 134 Unfortunately, neither [RFC812] nor any of its successors define a 135 strict set of data-typing or formatting requirements, and as a 136 result, each of the different implementations provide different 137 kinds of information in slightly different ways. Furthermore, each 138 WHOIS server operates as a self-contained entity, with no 139 standardized mechanisms to infer knowledge of any other servers, 140 meaning that WHOIS servers cannot redirect clients to other 141 servers for additional information. Another concern is that the 142 WHOIS services which are being operated today offer no means of 143 client authentication, requiring that server operators essentially 144 publish all data with a single "world-readable" permission. 145 However, this single permission conflicts with the privacy and 146 security policies of specific jurisdictions. 148 There are many other secondary issues with the WHOIS service as it 149 exists in current form. However, the largest problems are a lack 150 of standardized data formats, a lack of widely-supported referral 151 mechanisms, and a lack of privacy and security controls, as 152 described in the preceding text. 154 FIRS attempts to address these issues by defining guidelines for 155 the operation of a distributed and highly-structured WHOIS-like 156 service, using LDAPv3 for the query/response transfer service, and 157 using LDAP schema for the search inputs, answer data, and 158 redirection mechanisms. In short, the intention of this approach 159 is to provide an extensible and scalable WHOIS-like service, by 160 leveraging the inherent capabilities of LDAPv3. 162 1.2. Overview 164 The FIRS collection of specifications cumulatively define a 165 structured and distributed information service, including an 166 extensible framework and resource-specific definitions. The 167 framework defined in this document is intended to accommodate a 168 variety of different resource-types and usages, while the other 169 specifications define the technical details for the service as a 170 whole or for the different resource-types. 172 Cumulatively, the FIRS collection of specifications define the 173 following service elements: 175 * Namespace Rules. The FIRS specifications define a layered 176 namespace consisting of DNS-based delegation hierarchies, a 177 FIRS-specific container entry, and resource-specific 178 subordinate entries. 180 * Schema Definitions. The FIRS specifications reuse some 181 existing LDAP schema definitions, and also define several 182 FIRS-specific definitions, as needed. 184 * Query-Processing Rules. The FIRS specifications also reuse 185 some existing processing rules, and define several 186 additional rules as needed. Among these rules are 187 requirements for normalizing data, locating servers, 188 processing referrals, and more. 190 Some of these rules apply to the architecture as a whole, while 191 other rules apply to specific kinds of Internet resources. 193 2. Prerequisites and Terminology 195 The complete set of specifications in the FIRS collection 196 cumulative define a structured and distributed information service 197 using LDAPv3 for the data-formatting and transport functions. This 198 specification should be read in the context of the complete set of 199 specifications, which currently include the following: 201 draft-ietf-crisp-firs-arch-01, "The Federated Internet 202 Registry Service: Architecture and Implementation" (this 203 document) [FIRS-ARCH] 205 draft-ietf-crisp-firs-core-01, "The Federated Internet 206 Registry Service: Core Elements" [FIRS-CORE] 208 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 209 Domains in the Federated Internet Registry Service" 210 [FIRS-DNS] 212 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 213 Resource Records in the Federated Internet Registry 214 Service" [FIRS-DNSRR] 216 draft-ietf-crisp-firs-contact-01, "Defining and Locating 217 Contact Persons in the Federated Internet Registry Service" 218 [FIRS-CONTCT] 220 draft-ietf-crisp-firs-asn-01, "Defining and Locating 221 Autonomous System Numbers in the Federated Internet 222 Registry Service" [FIRS-ASN] 223 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 224 Address Blocks in the Federated Internet Registry Service" 225 [FIRS-IPV4] 227 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 228 Address Blocks in the Federated Internet Registry Service" 229 [FIRS-IPV6] 231 The FIRS service reuses, unites and clarifies several pre-existing 232 technologies. In order to fully understand FIRS, readers should be 233 familiar with the following technologies and specifications: 235 RFC 2247, "Using Domains in LDAP/X.500 DNs" [RFC2247] 237 RFC 2251, "Lightweight Directory Access Protocol (v3)" 238 [RFC2251] 240 RFC 2252, "Lightweight Directory Access Protocol (v3): 241 Attribute Syntax Definitions" [RFC2252] 243 RFC 2254, "The String Representation of LDAP Search 244 Filters" [RFC2254] 246 RFC 2256, "A Summary of the X.500(96) User Schema for use 247 with LDAPv3" [RFC2256] 249 RFC 2798, "Definition of the inetOrgPerson LDAP Object 250 Class" [RFC2798] 252 RFC 3296, "Named Subordinate References in Lightweight 253 Directory Access Protocol (LDAP) Directories" [RFC3296] 255 RFC 3377, "Lightweight Directory Access Protocol (v3): 256 Technical Specification" [RFC3377] 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 259 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 260 in this document are to be interpreted as described in RFC 2119. 262 3. Reference Example 264 Figure 1 below shows an example of a FIRS-specific data-set. This 265 example is referenced throughout this specification. 267 dc=example,dc=com 268 | 269 +-cn=inetResources,dc=example,dc=com 270 [top object class] 271 [inetResources object class] 272 | 273 +-attribute: inetGeneralContacts 274 | value: "admins@example.com" 275 | 276 +-cn=admins@example.com,cn=inetResources,dc=example,dc=com 277 | [top object class] 278 | [inetResources object class] 279 | [inetOrgPerson object class] 280 | | 281 | +-attribute: mail 282 | value: "admins@example.com" 283 | 284 +-cn=example.com,cn=inetResources,dc=example,dc=com 285 | [top object class] 286 | [inetResources object class] 287 | [inetDnsDomain object class] 288 | | 289 | +-attribute: inetDnsAuthServers 290 | value: "ns1.example.net" 291 | 292 +-cn=www.example.com,cn=inetResources,dc=example,dc=com 293 [top object class] 294 [inetResources object class] 295 [inetDnsDomain object class] 296 [referral object class] 297 | 298 +-attribute: inetTechContacts 299 | value: "admins@example.com" 300 | 301 +-attribute: ref 302 value: "ldap://firs.example.net/cn=inetResources, 303 dc=example,dc=net"??? 304 (1.3.6.1.4.1.7161.1.1.8:=host.example.net)" 306 Figure 1: The FIRS-specific data for Example Widgets. 308 As can be seen in Figure 1, entries use a FIRS-specific namespace 309 in conjunction with FIRS-specific schema. Meanwhile, clients use 310 FIRS-specific queries to locate and retrieve this information. 312 4. The FIRS Namespace 314 A critical aspect of FIRS is the use of an application-specific 315 namespace which is imposed on all FIRS-based resources. 317 The FIRS namespace rules facilitate the programmatic creation of 318 searches, and help to ensure predictable results. The use of a 319 private namespace also acts to segregate FIRS-related data from 320 other kinds of data which may reside on a participating server, 321 thereby giving the operator greater control over the security and 322 replication considerations for all of the data. 324 The FIRS namespace consists of three "layers", which are: 326 * A set of domainComponent relative distinguished names which 327 cumulatively identify a specific partition of the global 328 directory tree. 330 * A FIRS-specific entry which acts as a container for all of 331 the FIRS-related resource-specific child entries. 333 * The resource-specific entries which describe the resources 334 under the control of the selected partition. 336 The namespace follows a right-to-left order. 338 As an example, Figure 1 shows a DNS domain resource entry named 339 "cn=example.com,cn=inetResources,dc=example,dc=com", which refers 340 to the "example.com" domain resource within the "cn=inetResources" 341 container under the "dc=example,dc=com" directory partition. 343 4.1. The domainComponent Hierarchy 345 The top-level of the namespace uses the domainComponent naming and 346 mapping rules specified in RFC 2247 [RFC2247], which maps DNS 347 domain names to domainComponent ("dc=") relative distinguished 348 names (RDNs). The full sequence of domainComponent RDNs map to an 349 equivalent scope of authority in the DNS namespace, with the full 350 sequence of RDNs cumulatively representing the root of a partition 351 in the LDAP directory tree. 353 In this model, a sequence of domainComponent RDNs map to a domain 354 name in the global DNS hierarchy, with the FIRS partitions 355 providing scopes of authority in the global FIRS database of 356 distributed partitions. Furthermore, the SRV resource records 357 associated with those DNS domains also provide a useful mechanism 358 for locating the authoritative LDAP servers associated with any 359 particular resource in the global FIRS directory database. 361 Since the partition roots determine the scope of control over a 362 set of resources, partitions which overlap also have overlapping 363 scopes of control. For example, the "dc=com" and 364 "dc=example,dc=com" partitions can both provide information about 365 the "www.example.com" domain name resource. In order to reduce the 366 amount of ambiguity which is naturally present in this kind of 367 model, FIRS defines multiple bootstrapping models and also defines 368 the default model which should be used for any given resource. For 369 example, queries for centrally-delegated resources are supposed to 370 ask the top-level partition for information about those resources, 371 while queries for user-managed resources are supposed to ask the 372 leaf-node partition for information about those resources. 374 For example, Figure 1 shows the directory partition of 375 "dc=example,dc=com" which maps to the "example.com" scope of 376 authority from the DNS hierarchy, with the "dc=example,dc=com" 377 sequence representing the root of a partition in the globally 378 distributed directory database. 380 4.2. The inetResources Container 382 This specification requires the use of a mandatory LDAP container 383 entry with the RDN of "cn=inetResources", which MUST exist at the 384 root of every directory partition that provides FIRS services. All 385 publically-accessible resource-specific entries MUST be stored in 386 the "cn=inetResources" container entry. 388 The primary motivation for this naming rule is for predictability, 389 in that it allows searches to be formed programmatically (a search 390 base for resources in "dc=example,dc=com" can be programmatically 391 formed as "cn=inetResources,dc=example,dc=com", for example). 392 Furthermore, the use of a single container entry for all of an 393 organization's FIRS-related resources allows that branch of the 394 directory database to be managed independently of other entries on 395 the server, which facilitates better operational security and 396 replication controls. 398 All told, the use of the inetResources container is important 399 enough to justify the MANDATORY usage of this naming syntax. 401 4.3. Resource-Specific Entries 403 The FIRS collection of specifications define several Internet 404 resource types, each of which have their own naming rules. 405 However, each resource type follows a consistent naming principle, 406 in that each specific resource has an RDN which uniquely 407 identifies that resource within the inetResources container entry. 409 For example, Figure 1 shows an entry for the "www.example.com" 410 domain name resource in the "cn=inetResources" container of the 411 "dc=example,dc=com" partition, and also shows an entry for the 412 "admins@example.com" contact resource in that same container and 413 partition. Although the naming syntax is different for each 414 resource type, the naming rules are consistent and facilitate 415 predictable usage. 417 The naming rules for each of the distinct resource type are 418 provided in the documents which govern those resource types. 420 4.4. Namespace Aliases 422 FIRS allows entries to alias for other entries through the use of 423 referrals. In this model, an entry exists which will match against 424 searches for the queried data, but the attributes associated with 425 that entry indicate that some other entry should also be queried. 427 Referrals represent one of the strongest capabilities of the FIRS 428 architecture, in that they allow for a significant variety of 429 cross-referencing among entries. For example, referrals can be 430 used to point an inetResources container entry in one partition to 431 another inetResources container entry in another partition, 432 allowing multiple partitions to effectively share a single 433 partition (this is useful when organizations manage multiple 434 networks or domains, and wish to consolidate their management). As 435 another example, referrals can also be used to create placeholder 436 entries for specific resources (such as a web server) which only 437 exist as referrals for resources which are managed in other 438 partitions (such as a web-hosting server at an ISP), with both 439 entries providing information about that resource. 441 This latter example can be seen in Figure 1, which shows an entry 442 for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which 443 provides a referral to the "cn=host.example.net" entry at 444 "cn=inetResources,dc=example,dc=net". Queries for the local entry 445 would be answered with the locally-available information and then 446 redirected to the referral target where additional information 447 could be retrieved. 449 FIRS supports two different kinds of referrals, which are 450 subordinate reference referrals and continuation reference 451 referrals. Subordinate reference referrals indicate that the 452 search base used in the query only exists as an alias to another 453 partition or entry, meaning that the entire query must be 454 restarted in order for any answer data to be retrieved. Meanwhile, 455 continuation reference referrals indicate that some answer data is 456 available, but that more information is available at some other 457 location, and that the client should start new queries in order to 458 retrieve all of the information. 460 Referrals are provided as URLs. FIRS specifically requires the use 461 of LDAP URLs in order to ensure predictable automated processing. 462 Refer to section 6.4.1 for a brief discussion on how these URLs 463 are processed by FIRS clients. 465 4.5. Partition Replicas 467 All directory partitions which provide data for global Internet 468 resources SHOULD be replicated across two or more servers. Each of 469 the authoritative LDAP servers for the managed resource MUST be 470 specified with a unique DNS SRV resource record for the domain 471 name associated with the top-level resource assignment space. 473 Directory partitions which serve multiple organizations SHOULD 474 also be replicated. For example, an ISP which provides FIRS 475 services for their customers SHOULD also follow these same rules, 476 since outages of those servers will affect multiple parties. Leaf- 477 node directory partitions associated with an user-managed resource 478 MAY be replicated, and are encouraged to do so. 480 Similarly, any referral URLs which include host identifier 481 elements SHOULD provide multiple URLs, each of which identify 482 different hosts. For leaf-node referrals and labeledURI 483 references, this behavior MAY be relaxed, although it is still 484 encouraged. 486 Note that the most effective replication strategy will be for 487 entities to replicate their directory partitions with the 488 delegation parents, as this will allow queries for those resources 489 to be processed by the parent servers (thereby eliminating the 490 need for referral queries). In many cases, this will not be 491 feasible (the servers for the "dc=com" directory partition cannot 492 be expected to host replicas of every subordinate directory 493 partition), but it is encouraged where practical. 495 It is also expected that certain servers will be configured to 496 serve as multi-replica masters, effectively acting as large-scale 497 caching servers for many different resources. When used in 498 conjunction with the targeted bootstrap model described in section 499 6.4.1, this will allow clients to retrieve a significant amount of 500 information without having to pursue a large number of referrals 501 or redirects. This usage is expected and endorsed. 503 Finally, it is important to recognize that the LDAP specifications 504 do not currently provide cache timers or any other mechanisms 505 which can indicate how accurate or timely any replicas may be. 507 5. FIRS Schema Definitions 509 Another critical aspect of FIRS is the use of well-known schema, 510 including object classes, attributes, syntaxes and matching 511 filters. Some of the schema definitions are for the global FIRS 512 service and are usable by all entries (including resource-specific 513 entries), while others are specific to particular resource-types. 515 Wherever any suitable pre-existing schema definitions are 516 available they should be reused, since reuse facilitates 517 integration with other LDAP applications. 519 5.1. Global Schema 521 There are three global schema definitions which can be used by any 522 of the entries within FIRS. These include: 524 * The "inetResources" master schema. All FIRS-related entries 525 (including the inetResources container entry and all of the 526 resource-specific subordinate entries) MUST use the 527 inetResources structural object class and schema 528 definitions defined in [FIRS-CORE]. The inetResources 529 object class defines a variety of general-purpose 530 attributes which are useful for general information about 531 an organization and its resources. 533 * Associated resources. All FIRS-related entries MAY use the 534 "inetAssociatedResources" auxiliary object class and schema 535 definitions defined in [FIRS-CORE]. This object class 536 provides cross-reference pointer attributes which allow an 537 entry to reference other resources which may be of interest 538 to the user. 540 * Referral pointers. All FIRS-related entries MAY use the 541 "referral" object class and schema definitions defined in 542 [RFC3296]. This object class allows an entry to exist as a 543 referral source, with queries for that resource being 544 redirected to the referral target. Refer to section 4.4 for 545 a discussion on the different kinds of referral mechanisms 546 offered by FIRS, and section 6.4.1 for a discussion on the 547 FIRS referral-processing mechanisms. 549 Figure 1 shows that all of the entries within and including the 550 "cn=inetResources" container entry have the inetResources object 551 class defined. Meanwhile, each of the resource-specific entries in 552 that example also have their own resource-specific object classes, 553 while the "cn=www.example.com" resource-specific entry also has 554 the referral object class defined. 556 5.1.1. The inetResources schema 558 The inetResources object class is intended to provide summary 559 information about a collection of resources under the control of a 560 single organization or management body. Since this object class is 561 also inherited by the resource-specific object classes, these 562 attributes can be defined at each of the subordinate entries if a 563 global set of attribute values is undesirable or unfeasible. 565 Since multiple directory partitions can use subordinate reference 566 referrals to share a single common inetResources entry, it is 567 important for the data to be applicable to all of the entries 568 which refer to it. For example, it would be effective for a small 569 private company to use a shared set of inetResources attributes 570 for their DNS domain names and IP network blocks, but it would 571 probably be counter-productive for a global ISP to share contact 572 data across all of their hosted domains and routed networks. If 573 separate contacts are required for each resource, the contact data 574 should be specified within each entry, rather than being linked to 575 the inetResources entry. 577 The inetResources object class provides several multi-valued 578 contact-related attributes for a variety of well-known 579 administrative roles. This model allows the inetResources entry 580 and each of the subordinate managed resources to share a common 581 set of administrative roles, or to have unique roles for each 582 resource, as seen fit by the managing entity. 584 5.1.2. The inetAssociatedResources schema 586 The inetAssociatedResources object class defines attributes which 587 are useful for providing general-purpose cross-referencing 588 information with other resources. For example, a contact entry can 589 list IPv4 networks or DNS domains as associated resources, thereby 590 providing a simplistic cross-reference mechanism between an 591 administrator and the resource he manages. In short, any resource 592 can be associated with any other resource through the use of this 593 object class. 595 5.1.3. The referral schema 597 The referral object class is used to redirect queries to other 598 entries programmatically. This object class and its associated 599 schema and rules provide the backbone of the aliasing mechanisms 600 discussed in section 4.4. 602 5.2. Resource-Specific Schema 604 In addition to the global schema definitions, each of the 605 resource-specific entries in FIRS MUST use the resource-specific 606 schema definitions defined for use with that specific resource 607 type. These object classes are defined in the specifications which 608 govern the different resource-types. These include: 610 * DNS domains. Every domain name resource entry MUST use the 611 inetDnsDomain object class and schema definitions defined 612 in [FIRS-DNS]. These entries can refer to zone delegations, 613 host-specific entries, reverse-lookup pointer entries, or 614 any other domain name. 616 * DNS resource-records. Any domain name resource MAY use the 617 inetDnsRR object class and schema definitions defined in 618 [FIRS-DNSRR]. The inetDnsRR object class defines a single 619 optional attribute for storing multiple DNS resource 620 records as supplemental data to a domain name entry. 622 * IPv4 address blocks. Every IPv4 address block resource MUST 623 use the inetIpv4Network object class and schema definitions 624 defined in [FIRS-IPV4]. Entries can refer to entire 625 networks or to single hosts, as needed. 627 * IPv6 address blocks. Every IPv6 address block resource MUST 628 use the inetIpv6Network object class and schema definitions 629 defined in [FIRS-IPV6]. Entries can refer to entire 630 networks or to single hosts, as needed. 632 * Autonomous system numbers. Every autonomous system number 633 resource MUST use the inetAsNumber object class and schema 634 definitions defined in [FIRS-ASN]. 636 * Contacts. Every contact entry MUST use the inetOrgPerson 637 object class defined in [RFC2798], but MUST also use the 638 additional schema definitions defined in [FIRS-CONTCT]. 640 As was discussed in section 5.1, each resource-specific entry MAY 641 exist as a referral source, or MAY have attributes which refer to 642 additional (related) resources. 644 6. Query Processing Behaviors 646 Another critical aspect to FIRS is the query-processing behavioral 647 rules which govern the ways in which a client parses an input 648 string, locates a server which is authoritative for the resource 649 being queried, generates LDAPv3 queries, and processes the 650 resulting answer data. More specifically: 652 * Query pre-processing. Portions of this process require the 653 client to determine the type of resource being queried for, 654 and to determine the initial partition which should be used 655 for the query. Since this process is different for each 656 particular resource-type, the rules which govern this 657 behavior are defined in each of the resource-specific 658 specifications. 660 * Bootstrap processing. Once a resource-type and partition 661 have been determined, the client must locate the LDAP 662 servers which are authoritative for that partition. [FIRS- 663 CORE] defines three different bootstrap models that clients 664 can use as part of this process, while each of the 665 resource-specific specifications define which of the models 666 are to be used for each particular resource-type. 668 * Query processing. Once a server has been located, the 669 client must submit the LDAP query which was formed during 670 the pre-preprocessing phase. [FIRS-CORE] defines certain 671 LDAPv3 query parameters which all FIRS clients MUST conform 672 with, while the resource-specific specifications define 673 resource-specific matching rules. 675 * Query post-processing. Response data frequently needs to be 676 further processed. For example, referrals may need to be 677 processed, or some kinds of data may need to be localized. 678 These mechanisms and their behavioral rules are defined in 679 [FIRS-CORE], while the resource-specific specifications may 680 also describe supplemental rules. 682 Each of these phases are discussed in more detail below. 684 6.1. Query Pre-Processing 686 Client input is generally limited to a single well-formed unit of 687 data, such as a domain name ("example.com") or an email address 688 ("admins@example.com"), and this single piece of information must 689 be used to subsequently build a fully-formed LDAPv3 query, 690 including the assertion value, the search base, the matching 691 filter, and so forth. All of these steps are part of the pre- 692 processing phase. 694 Although the exact sequence of steps will vary according to the 695 resource-type being queried, there are some commonalities between 696 each of them. Among these steps: 698 * Determine the resource type. Different kinds of resources 699 have different processing steps, validation mechanisms, and 700 so forth, each of which require that the resource-type be 701 appropriately identified. Clients MAY use any mechanisms 702 necessary to force this determination. 704 * Validate and normalize the data. In all cases, the input 705 data MUST be validated and normalized according to the 706 syntax rules defined in the specification which governs the 707 resource-type. As an example of this step, queries for 708 internationalized domain names must be validated and 709 normalized into a canonical UTF-8 [RFC2279] form before any 710 other steps can be taken. Similarly, IPv6 addresses are 711 required to conform to specific syntax rules, and input 712 address may need to be expanded or compressed in order to 713 comply with the syntax requirements. 715 * Determine the authoritative directory partition for the 716 named resource. In most cases, the authoritative partition 717 will be a variation of the input query string, but this is 718 not always the case. For example, the default partition for 719 an email address will be extrapolated from the domain 720 component of the email address itself, while the 721 authoritative partition for an ASN uses a reserved 722 (special-purpose) domain name. In some cases, the 723 authoritative partition may change during the subsequent 724 query-processing steps. 726 * Determine the search base for the query. Each resource type 727 has resource-specific query-processing rules which will 728 dictate how the authoritative partitions are mapped to the 729 search base. In some cases, the cn=inetResources container 730 entry in the authoritative partition will be used "as-is", 731 while in other cases, the cn=inetResources container entry 732 in a delegation parent of the authoritative partition will 733 be used instead. In some cases, the search base may change 734 during subsequent query-processing steps. 736 * Determine the assertion value for the query. The assertion 737 value will usually be the normalized form of the input 738 query. In some cases, the assertion value may change during 739 subsequent query-processing steps. 741 * Determine the matching filter. Each resource-type has its 742 own matching filter rules. For example, contact entries are 743 matched with a simple equalityMatch comparison, while in 744 other cases the matching filter will be an extensibleMatch 745 which is peculiar to the resource-type in use. 747 Once all of the pre-processing steps have been successfully 748 completed, the client will have to locate an LDAPv3 server which 749 is authoritative for the search base before it can submit the 750 query. This process is described in section 6.2 below. 752 6.2. Bootstrap Processing 754 The bootstrap process uses DNS queries to locate the LDAP servers 755 which should be used for a query. However, since different kinds 756 of resources are managed through different delegation models, 757 there are also different bootstrap models which have to be used to 758 perform this process. 760 FIRS supports three different bootstrap models, which are: 762 * Targeted. The "targeted" bootstrap model has the client 763 attempting to locate the LDAP servers associated with a 764 specific domain name, such as a domain name which may be 765 returned as referrals or URLs. If no servers can be found, 766 the client exits the query. 768 * Top-down. The "top-down" bootstrap model has the client 769 attempting to locate the LDAP servers associated with a 770 top-level partition in the delegation path to the 771 authoritative partition. If no servers can be found for the 772 top-level domain, the client exits the query. 774 * Bottom-up. The "bottom-up" bootstrap model has the client 775 attempting to locate the LDAP servers associated with the 776 authoritative partition itself. If no servers can be found 777 for that partition, the authoritative partition is reset to 778 the immediate parent in the delegation hierarchy and new 779 DNS queries are issued, with this process repeating until 780 some servers are found or there are no more partitions in 781 the delegation path which can be queried. 783 Each of the models are appropriate to different usages. For 784 example, The targeted model is most useful when a particular piece 785 of data is presumed to exist at a pre-determined location. 786 Meanwhile, the top-down model is best suited for searches about 787 global resources which are centrally managed and delegated (such 788 as IP addresses and DNS domains), and where centrally-managed 789 delegation information is critical. Finally, the bottom-up model 790 is most appropriate for resources which are not centrally 791 delegated and managed (such as contact information). 793 6.3. Query Processing 795 Once an LDAP server has been located, the LDAPv3 query is 796 submitted to that server. 798 Most of the values for the query will have been collected during 799 the pre-processing phase, although [FIRS-CORE] defines some rules 800 which govern all queries. For example, [FIRS-CORE] specifies a 801 maximum time limit of 60 seconds for all queries in order to 802 prevent runaway searches which match all entries. 804 [FIRS-CORE] also allows for authentication and access controls, in 805 that FIRS servers are allowed to limit the depth and breadth of 806 information that they provide to a specific client based on a 807 variety of factors, including the level of authenticated access. 809 Another consideration which can arise during this phase of the 810 process is protocol and schema versioning considerations. These 811 mechanisms are already existent in the LDAPv3 specifications, and 812 their usage is encouraged by [FIRS-CORE]. 814 6.4. Query Post-Processing 816 Once a query has been submitted and processed, the server should 817 return answer data or some kind of referral, or possibly both. In 818 general, FIRS clients are expected to display all of the answer 819 data and process all of the referrals, although there are specific 820 considerations which must be taken into account. In particular, 821 there are considerations for handling the different kinds of 822 referrals, and there are localizations issues for specific kinds 823 of attribute data. 825 6.4.1. Referrals 827 As was discussed in section 4.4, there are two kinds of referral 828 mechanisms which are used with FIRS, which are subordinate 829 reference referrals and continuation reference referrals. More 830 specifically: 832 * Subordinate reference referrals. Subordinate reference 833 referrals are returned when the search base specified in a 834 query exists as a referral to some other entry. This 835 condition means that the current search operation cannot 836 proceed, and that the search MUST be restarted using the 837 search base specified in the referral message. 839 Any of the FIRS-specific entries MAY be defined as 840 subordinate reference referrals, although they are 841 typically only used when the inetResources container entry 842 in a partition is an alias for an inetResources container 843 entry in another partition. Subordinate reference referrals 844 and their schema are defined in [RFC3296] although there 845 are additional restrictions placed on their usage as 846 described in [FIRS-CORE]. 848 * Continuation reference referrals. Continuation reference 849 referrals are returned when a search operation has been 850 successfully processed by the queried server, but the 851 answer data also includes referrals to other entries. This 852 condition means that the current search operation has 853 succeeded, but that additional searches SHOULD be started 854 for all of the known answer data to be retrieved. 856 These referrals are often provided as supplemental data to 857 an answer set, although this is not required (a 858 continuation reference referral can be the only response, 859 but it won't be the only response in the common case). 860 Continuation reference referrals and their schema are also 861 defined in [RFC3296], with additional restrictions placed 862 on their usage as described in [FIRS-CORE]. 864 Whenever a referral is received in response to a query, the client 865 is required to display any answer data which has also been 866 received and then process the referral. 868 LDAP referrals can use any kind of URL, although FIRS specifically 869 requires the use of LDAP URLs. The client is required to parse the 870 resulting URL for a host identifier, port number, search base, and 871 assertion value elements, and then use these elements to construct 872 and issue new queries. 874 Note that [RFC2251] defines a superior reference referral which is 875 used as a "default referral" for out-of-scope searches. However, 876 FIRS specifically excludes support for superior reference 877 referrals. Any superior reference referrals which are encountered 878 as part of this service are to be treated as errors. 880 6.4.2. Internationalization and localization 882 The FIRS model uses the internationalization and localization 883 services which are inherent in LDAPv3. In many cases, this native 884 support is sufficient to accommodate internationalization and 885 localization considerations. However, there are several cases 886 where additional and explicit support is required. 888 For example, the domainComponent attribute is specifically 889 restricted to seven-bit character codes, and is traditionally 890 interpreted as simple [US-ASCII]. This is problematic with 891 internationalized domain names and the domainComponent attributes 892 derived from them, since these attribute sequences are used in 893 partition identifiers, search bases, and numerous other areas. In 894 order to ensure interoperability, all DNS domain names which are 895 mapped to domainComponent attributes MUST be reduced to their 896 ASCII-compatible form using the ToASCII process defined in 897 [RFC3490] before they are used for domainComponent sequences. 899 Similarly, although DNS is technically capable of storing eight- 900 bit code-point values, the operational rules which govern DNS do 901 not support this usage for domain names which are used as host 902 identifiers (and this includes zone delegations). As a result, 903 internationalized domain names which are to be used for SRV or A 904 resource record lookups MUST be reduced to their ASCII-compatible 905 form using the ToASCII process defined in [RFC3490] before these 906 DNS queries are issued. 908 In those cases where entries or attributes use normalized UTF-8 909 sequences inside of FIRS (specifically domain names and email 910 addresses), FIRS clients SHOULD offer ASCII-compatible versions of 911 those sequences, using the ToASCII process defined in [RFC3490]. 912 This will ensure that clients are able to use these sequences with 913 legacy (pre-IDNA) applications directly. For example, if an entry 914 displays an inetAssociatedDomains attribute, the domain names in 915 that attribute should be displayed in their default UTF-8 form 916 (assuming that the client's operating system and application 917 allows it), but should also be made available in their ASCII- 918 compatible form (either as a clipboard option, command-line 919 option, or some other user-selectable switch) in order to allow 920 the data to be passed to a legacy application in a form which is 921 understandable by that application. 923 Attribute names are fixed, and can therefore be localized easily. 924 As such, clients MAY choose to convert attribute names into a 925 language appropriate to the local user for display purposes if 926 this is desirable. However, clients MUST NOT localize attribute 927 names which are used for query input. For example, clients MUST 928 NOT convert "cn=" or "dc=" relative distinguished labels into a 929 language-specific mapping and then use the mapped versions of 930 these labels for assertion values in a subsequent query. 932 RFC 2277 [RFC2277] requires free-text data to be tagged with 933 language tags. RFC 2596 [RFC2596] defines a mechanism for storing 934 language tags and language-specific attribute values, and these 935 mechanisms SHOULD be supported by FIRS clients and servers. For 936 example, an organization name could be provided in English and 937 Arabic, with the language tags allowing the client to display the 938 appropriate attribute value instance based on the locale settings 939 of the user. 941 International postal regulations generally require that the 942 recipient address on an envelope be provided in a language and 943 charset which is native to the recipient's country, with the 944 exception of the destination country name which should be provided 945 in a language and charset that is native to the sender's country. 946 This model ensures that the sender's post office will be able to 947 route the mail to the recipient's country, while also ensuring 948 that the destination country's post office will be able to perform 949 local delivery. In order to facilitate this usage, the country 950 attribute value MAY (encouraged) be localized to the local user's 951 nomenclature for a country, but other postal address information 952 SHOULD NOT be localized. 954 Notwithstanding the above, it is ENCOURAGED that contact names be 955 provided in English forms in order to facilitate inter-party 956 communications, using the mechanisms offered by [RFC2596]. For 957 example, the default contact entry for a person in Japan SHOULD be 958 provided in the native form for that person, but an English form 959 is also ENCOURAGED in order to allow non-Japanese users to 960 properly address that person in subsequent communications. As 961 stated in the preceding paragraph however, any postal 962 communications for that person SHOULD use the native-language 963 representation (at least on the envelope) in order to facilitate 964 the delivery of postal mail. 966 Time and date strings in LDAP use the generalizedTime syntax, 967 making them predictable and easily convertible if necessary. As 968 such, dates MAY be localized for display purposes by client 969 applications as necessary. 971 Finally, clients must recognize that some URL data is likely to be 972 escaped, using at least one of the multiple rules which affect 973 URLs and resource-specific data. For example, a URL which contains 974 a domain name resource could theoretically have been escaped with 975 three or four different syntax rules, and clients MUST be prepared 976 to decode these URLs appropriately. 978 7. Transition Issues 980 There are a handful of areas where FIRS does not fully compare 981 with all of the existing WHOIS service offerings. These areas are 982 discussed in more detail below. 984 7.1. NIC Handles 986 Legacy NIC handles in existing databases can be accommodated using 987 two possible mechanisms: 989 * NIC handle output in legacy WHOIS systems may be replaced 990 with email addresses for the contacts. This option 991 facilitates faster coalescence around the FIRS system. 993 * NIC handles can be converted into locally-scoped email 994 addresses. For example, the NIC handle of EH26 on Network 995 Solutions' WHOIS server could be replaced with the locally- 996 scoped email address of "ehall@whois.netsol.com" or some 997 variation thereof. 999 Of the two mechanisms described above, the former is preferred. 1001 7.2. Change-Logs 1003 Several WHOIS services provide pseudo change-logs in their 1004 response data, listing each unique modification event which has 1005 occurred for a particular resource. For example, RIPE and some of 1006 its member ccTLDs provide WHOIS output which includes a series of 1007 "changed" fields that itemize every modification event ("updated", 1008 "added", etc.), the modifier, and the modification date, which 1009 cumulatively act as a change-log for the resource in question. 1011 Organizations are certainly free to maintain this information on 1012 their internal systems (and are even encouraged to do so). 1013 However, this information is not necessary for public view of the 1014 data in the FIRS service. Where the auditing information will be 1015 required, a format which is more suitable to legal review will 1016 also be required. 1018 Organizations who wish to make change-log information available to 1019 the public should use an LDAP schema for this purpose. An initial 1020 schema has been developed for this purpose and is available at 1021 http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt. However, 1022 this schema has not yet been proposed as a standards-track effort, 1023 and should only be used as a starting point for other development. 1025 8. Security Considerations 1027 The FIRS collection of specifications describe an application of 1028 the LDAPv3 protocol, and as such it inherits the security 1029 considerations associated with LDAPv3, as described in section 7 1030 of [RFC2251]. 1032 By nature, LDAP is a read-write protocol, while the legacy WHOIS 1033 service has always been a read-only service. As such, there are 1034 significant risks associated with allowing unintended updates by 1035 unauthorized third-parties. Moreover, allowing the FIRS service to 1036 update the underlying delegation databases could result in network 1037 resources being stolen from their lawful operators. For example, 1038 if the LDAP front-end had update access to a domain delegation 1039 database, a malicious third-party could theoretically take 1040 ownership of that domain by exploiting an authentication weakness, 1041 thereby causing ownership of the domain to be changed to another 1042 party. For this reason, it is imperative that the FIRS service not 1043 be allowed to make critical modifications to delegated resources 1044 without ensuring that all possible precautions have been taken. 1046 The query processing models described in this document make use of 1047 DNS lookups in order to locate the LDAP servers associated with a 1048 particular resource. DNS is susceptible to certain attacks and 1049 forgeries which may be used to redirect clients to LDAP servers 1050 which are not authoritative for the resource in question. 1052 This document provides multiple query models which will cause the 1053 same query to be answered by different servers (one would be 1054 processed by a delegation entity, while another would be processed 1055 by an operational entity). As a result, each of the servers may 1056 provide different information, depending upon the query type that 1057 was originally selected. 1059 Some operators may choose to purposefully provide misleading or 1060 erroneous information in an effort to avoid responsibility for bad 1061 behavior. In addition, there are likely to be sporadic operator 1062 errors which will result in confusing or erroneous answers. 1064 Neither this specification nor the LDAPv3 protocol currently 1065 provide cache timers or any other mechanisms which can indicate 1066 how accurate or timely any replicas may be. As a result, it is 1067 possible for a replica to become significantly outdated, even to 1068 the point of containing wholesale errors. 1070 For all of the reasons listed above, it is essential that 1071 applications and end-users not make critical decisions based on 1072 the information provided by the FIRS service without having reason 1073 to believe the veracity of the information. Users should limit 1074 unknown or untrusted information to routine purposes. 1076 Despite these disclaimers, however, it is very likely that the 1077 information presented through the FIRS service will be used for 1078 many operational and problem-resolution purposes. In order to 1079 ensure the veracity of the information, a minimal set of 1080 operational guidelines are provided herein. For the most part, 1081 these rules are designed to prevent unauthorized modifications to 1082 the data. 1084 Note that these rules only apply to data which is willingly 1085 provided; no data is required to be entered, but where the data is 1086 provided, it SHOULD be validated as accurate on entry, and it MUST 1087 be secured against unauthorized modifications. 1089 * The inetResources container entry and all of the resource- 1090 specific subordinate entries within every public DIT that 1091 provides FIRS resources SHOULD have anonymous read-only 1092 access permissions, and SHOULD NOT have anonymous add, 1093 delete or modify permissions. 1095 * With the exception of contact-related attributes from the 1096 inetOrgPerson object class, each attribute MAY have 1097 whatever restrictions are necessary in order to suit local 1098 security policies, government regulations or personal 1099 privacy concerns. When the inetOrgPerson object class is 1100 used to provide contact details, the mail attribute MUST be 1101 defined, SHOULD be valid, SHOULD have read-only anonymous 1102 access, and SHOULD NOT have anonymous add, delete or modify 1103 permissions. 1105 By using the inetOrgPerson object class, it is expected 1106 that existing contact-related entries can be reused. If 1107 reusing these entries is undesirable or unfeasible, entries 1108 with the necessary access SHOULD be made available. 1110 Note that contact pointers are entirely optional and are 1111 not required to exist. However, where they exist, they MUST 1112 comply with the above requirements. 1114 * End-users and implementers SHOULD provide anonymous access 1115 to the creatorsName, createTimestamp, modifiersName and 1116 modifyTimestamp operational attributes associated with each 1117 entry in the inetResources branch, since this information 1118 is useful for determining the age of the information. 1120 * Server administrators MAY define additional add, delete or 1121 modify permissions for authenticated users, using any 1122 LDAPv3 authentication mechanisms they wish. In particular, 1123 delegation entities MAY provide for the remote management 1124 of delegated resources (such as assigning modification 1125 privileges to the managers of a particular delegated domain 1126 or address block), although this is entirely optional, and 1127 is within the sole discretion of the delegation body. 1129 Finally, there are physical security issues associated with any 1130 service which provides physical addressing and delivery 1131 information. Although organizations are generally encouraged to 1132 provide as much information as they feel comfortable with, no 1133 information is required. 1135 9. IANA Considerations 1137 The FIRS collection of specifications define an application of the 1138 LDAPv3 protocol rather than a new Internet application protocol. 1139 As such, there are no protocol-related IANA considerations. 1141 However, the FIRS collection of specifications do define several 1142 LDAP schema elements, including object classes, attributes, 1143 syntaxes and extensibleMatch filters, and these elements should be 1144 assigned OID values from the IANA branch. Furthermore, some of the 1145 specifications define their own status codes as attribute values, 1146 and IANA is expected to maintain the code-point mapping values 1147 associated with these attributes. 1149 Finally, some of the specifications also describe public DNS and 1150 LDAP servers and data. It is expected that IANA will see to the 1151 establishment and maintenance of these servers and data. 1153 10. Author's Address 1155 Eric A. Hall 1156 ehall@ehsco.com 1158 11. Normative References 1160 [CRISP-REQ] Newton, A. "Cross Registry Internet Service 1161 Protocol (CRISP) Requirements", draft-ietf- 1162 crisp-requirements-05, May 2003. 1164 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 1165 Service: Architecture and Implementation 1166 Guide", draft-ietf-crisp-firs-arch-01, May 1167 2003. 1169 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 1170 System Numbers in the Federated Internet 1171 Registry Service", draft-ietf-crisp-firs-asn- 1172 01, May 2003. 1174 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 1175 Persons in the Federated Internet Registry 1176 Service", draft-ietf-crisp-firs-contact-01, 1177 May 2003. 1179 [FIRS-CORE] Hall, E. "The Federated Internet Registry 1180 Service: Core Elements", draft-ietf-crisp- 1181 firs-core-01, May 2003. 1183 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 1184 the Federated Internet Registry Service", 1185 draft-ietf-crisp-firs-dns-01, May 2003. 1187 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 1188 Records in the Federated Internet Registry 1189 Service", draft-ietf-crisp-firs-dnsrr-01, May 1190 2003. 1192 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 1193 Blocks in the Federated Internet Registry 1194 Service", draft-ietf-crisp-firs-ipv4-01, May 1195 2003. 1197 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 1198 Blocks in the Federated Internet Registry 1199 Service", draft-ietf-crisp-firs-ipv6-01, May 1200 2003. 1202 [RFC1274] Barker, P., and Kille, S. "The COSINE and 1203 Internet X.500 Schema", RFC 1274, November 1204 1991. 1206 [RFC2079] Smith, M. "Definition of an X.500 Attribute 1207 Type and an Object Class to Hold Uniform 1208 Resource Identifiers (URIs)", RFC 2079, 1209 January 1997. 1211 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 1212 and Sataluri, S. "Using Domains in LDAP/X.500 1213 DNs", RFC 2247, January 1998. 1215 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 1216 ISO 10646", RFC 2279, January 1998. 1218 [RFC2251] Wahl, M., Howes, T., and Kille, S. 1219 "Lightweight Directory Access Protocol (v3)", 1220 RFC 2251, December 1997. 1222 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 1223 S. "Lightweight Directory Access Protocol 1224 (v3): Attribute Syntax Definitions", RFC 2252, 1225 December 1997. 1227 [RFC2253] Wahl, M., Kille, S., and Howes, T. 1228 "Lightweight Directory Access Protocol (v3): 1229 UTF-8 String Representation of DNs", RFC 2253, 1230 December 1997. 1232 [RFC2254] Howes, T. "The String Representation of LDAP 1233 Search Filters", RFC 2254, December 1997. 1235 [RFC2255] Howes, T., and Smith, M. "The LDAP URL 1236 Format", RFC 2255, December 1997. 1238 [RFC2256] Wahl, M. "A Summary of the X.500(96) User 1239 Schema for use with LDAPv3", RFC 2256, 1240 December 1997. 1242 [RFC2277] Alvestrand, H. "IETF Policy on Character Sets 1243 and Languages", BCP 18, RFC 2277, January 1244 1998. 1246 [RFC2308] Andrews, M. "Negative Caching of DNS Queries 1247 (DNS NCACHE)", RFC 2308, March 1998. 1249 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 1250 in LDAP", RFC 2596, May 1999. 1252 [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A 1253 DNS RR for specifying the location of services 1254 (DNS SRV)", RFC 2782, February 2000. 1256 [RFC2798] Smith, M. "Definition of the inetOrgPerson 1257 LDAP Object Class", RFC 2798, April 2000. 1259 [RFC3296] Zeilenga, K. "Named Subordinate References in 1260 Lightweight Directory Access Protocol (LDAP) 1261 Directories", RFC 3296, July 2002. 1263 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 1264 Directory Access Protocol (v3): Technical 1265 Specification", RFC 3377, September 2002. 1267 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 1268 "Internationalizing Domain Names in 1269 Applications (IDNA)", RFC 3490, March 2003. 1271 [US-ASCII] Cerf, V. "ASCII format for Network 1272 Interchange", RFC 20, October 1969. 1274 12. Informational References 1276 [RFC812] Harrenstien, K., and White, V. 1277 "NICNAME/WHOIS", RFC 812, March 1982. 1279 13. Acknowledgments 1280 Funding for the RFC editor function is currently provided by the 1281 Internet Society. 1283 Portions of this document were funded by Verisign Labs. 1285 The first version of this specification was co-authored by Andrew 1286 Newton of Verisign Labs, and subsequent versions continue to be 1287 developed with his active participation. 1289 14. Changes from Previous Versions 1291 draft-ietf-crisp-firs-arch-01: 1293 * Several clarifications and corrections have been made. 1295 draft-ietf-crisp-firs-arch-00: 1297 * Restructured document set, separating the architectural 1298 discussion from the technical descriptions. 1300 * Consolidated the security discussions. 1302 draft-ietf-crisp-lw-core-00: 1304 * As a result of the formation of the CRISP working group, 1305 the original monolithic document has been broken into 1306 multiple documents, with draft-ietf-crisp-lw-core 1307 describing the core service, while related documents 1308 describe the per-resource schema and access mechanisms. 1310 * References to the ldaps: URL scheme have been removed, 1311 since there is no standards-track specification for the 1312 ldaps: scheme. 1314 * An acknowledgements section was added. 1316 draft-hall-ldap-whois-01: 1318 * The "Objectives" section has been removed. [ir-dir-req] is 1319 now being used as the guiding document for this service. 1321 * Several typographical errors have been fixed. 1323 * Some unnecessary text has been removed. 1325 * Figures changed to show complete sets of object classes, to 1326 improve inheritance visibility. 1328 * Clarified the handling of reverse-lookup domains (zones 1329 within the in-addr.arpa portion of the DNS hierarchy) in 1330 the inetDnsDomain object class reference text. 1332 * Referrals now use regular LDAP URLs (multiple responses 1333 with explicit hostnames and port numbers). Prior editions 1334 of this specification used LDAP SRV resource records for 1335 all referrals. 1337 * The delegation status codes used by the 1338 inetDnsDelegationStatus, inetIpv4DelegationStatus, 1339 inetIpv6DelegationStatus and inetAsnDelegationStatus 1340 attributes have been condensed to a more logical set. 1342 * Added an inetDnsAuthServers attribute for publishing the 1343 authoritative DNS servers associated with a domain. NOTE 1344 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 1345 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 1346 ATTRIBUTES. 1348 * Added an inetGeneralDisclaimer attribute for publishing 1349 generalized disclaimers. 1351 * Added the inetAssociatedResources auxiliary object class 1352 for defining associated resources, and moved some of the IP 1353 addressing and ASN attributes to the new object class. 1355 * Several attributes had their OIDs changed. NOTE THAT THIS 1356 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1357 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1359 15. Full Copyright Statement 1361 Copyright (C) The Internet Society (2003). All Rights Reserved. 1363 This document and translations of it may be copied and furnished 1364 to others, and derivative works that comment on or otherwise 1365 explain it or assist in its implementation may be prepared, 1366 copied, published and distributed, in whole or in part, without 1367 restriction of any kind, provided that the above copyright notice 1368 and this paragraph are included on all such copies and derivative 1369 works. However, this document itself may not be modified in any 1370 way, such as by removing the copyright notice or references to the 1371 Internet Society or other Internet organizations, except as needed 1372 for the purpose of developing Internet standards in which case the 1373 procedures for copyrights defined in the Internet Standards 1374 process must be followed, or as required to translate it into 1375 languages other than English. 1377 The limited permissions granted above are perpetual and will not 1378 be revoked by the Internet Society or its successors or assigns. 1380 This document and the information contained herein is provided on 1381 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1382 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1383 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1384 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.