idnits 2.17.1 draft-ietf-crisp-firs-arch-02.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 (July 2003) is 7584 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) == Missing Reference: 'LDAP' is mentioned on line 768, but not defined == Unused Reference: 'FIRS-ARCH' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'RFC2255' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1255, 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-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' ** 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 2279 (Obsoleted by RFC 3629) ** 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: 14 errors (**), 0 flaws (~~), 15 warnings (==), 12 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-02.txt July 2003 4 Expires: February, 2004 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...............................................3 46 1.1. Background..............................................3 47 1.2. Objectives..............................................4 48 1.3. Overview................................................4 49 2. Prerequisites and Terminology..............................5 50 3. Reference Example..........................................6 51 4. The FIRS Namespace.........................................7 52 4.1. The domainComponent Hierarchy...........................7 53 4.2. The inetResources Container.............................8 54 4.3. Resource-Specific Entries...............................9 55 4.4. Namespace Aliases.......................................9 56 4.5. Partition Replicas.....................................10 57 5. FIRS Schema Definitions...................................11 58 5.1. Global Schema..........................................11 59 5.1.1. The inetResources schema.........................12 60 5.1.2. The inetAssociatedResources schema...............13 61 5.1.3. The referral schema..............................13 62 5.2. Resource-Specific Schema...............................13 63 6. Query Processing Behaviors................................14 64 6.1. Query Pre-Processing...................................15 65 6.2. Bootstrap Processing...................................16 66 6.3. Query Processing.......................................17 67 6.4. Query Post-Processing..................................18 68 6.4.1. Referrals........................................19 69 6.4.2. Internationalization and localization............20 70 7. Transition Issues.........................................22 71 7.1. NIC Handles............................................22 72 7.2. Change-Logs............................................23 73 7.3. Legacy System Support..................................23 74 8. Security Considerations...................................24 75 9. IANA Considerations.......................................26 76 10. Normative References......................................27 77 11. Informational References..................................29 78 12. Changes from Previous Versions............................29 79 13. Author's Address..........................................31 80 14. Acknowledgments...........................................31 81 15. Full Copyright Statement..................................31 82 1. Introduction 84 FIRS is intended to provide a distributed WHOIS-like information 85 service, using the LDAPv3 specifications [RFC3377] for the data- 86 formatting and query-transport functions. 88 1.1. Background 90 The original WHOIS service [RFC812] was provided as a front-end to 91 a centralized repository of ARPANET resources and users. Over 92 time, hundreds of WHOIS servers have been deployed across the 93 public Internet, with each server providing general information 94 about the particular network resources under the control of a 95 specific organization. 97 Unfortunately, neither [RFC812] nor any of its successors define a 98 strict set of data-typing or formatting requirements, and as a 99 result, each of the different implementations provide different 100 kinds of information in slightly different ways. Furthermore, each 101 WHOIS server operates as a self-contained entity, with no 102 standardized mechanisms to infer knowledge of any other servers, 103 meaning that WHOIS servers cannot redirect clients to other 104 servers for additional information. Another concern is that the 105 WHOIS services which are being operated today offer no means of 106 client authentication, requiring that server operators essentially 107 publish all data with a single "world-readable" permission even 108 though this single permission often conflicts with the privacy and 109 security policies of specific jurisdictions. 111 There are many other secondary issues with the WHOIS service as it 112 exists in current form. However, the largest problems are a lack 113 of standardized data formats, a lack of widely-supported referral 114 mechanisms, and a lack of privacy and security controls, as 115 described in the preceding text. 117 FIRS attempts to address these issues by defining guidelines for 118 the operation of a distributed and highly-structured WHOIS-like 119 service, using LDAPv3 for the query/response transfer service, and 120 using LDAP schema for the search inputs, answer data, and 121 redirection mechanisms. In short, the intention of this approach 122 is to provide an extensible and scalable WHOIS-like service by 123 leveraging the inherent capabilities of LDAPv3. 125 1.2. Objectives 127 The principle objective behind FIRS is to offer structured 128 information about distributed Internet resources in a model which 129 reflects the federated delegations of those resources. This 130 specifically includes centralized delegations from authorized 131 governance bodies (such as DNS domains under top-level domains), 132 but also includes delegations from authorized bodies further down 133 the delegation path (such as leaf-node DNS domain names within the 134 "corp.example.com" zone). 136 Furthermore, the FIRS service is intended to be used with a wide 137 variety of resources. The core set of specifications define rules 138 for handling the most-common resources (DNS domains, IP addresses, 139 contact information, and so forth), but other types of resources 140 may be grafted onto the architecture as needed. By extension, FIRS 141 should be capable of providing the necessary support structure for 142 any kind of information to be stored in a global mesh of FIRS- 143 centric LDAP directories, and for the FIRS-specific clients and 144 servers to be easily extended to accommodate that data. 146 Another critical objective is integration support, in that FIRS- 147 specific data should be easily accessible to a wide number of 148 applications. For example, if a network manager needs to retrieve 149 information about a particular host or network which is displayed 150 in a management application, it should be easy for that 151 application to be extended so that the FIRS data can be fetched by 152 that application, rather than always requiring the use of a FIRS- 153 specific application. 155 Finally, the collection of specifications which define the 156 Federated Internet Registry Service (FIRS) are intended to satisfy 157 the CRISP Working Group requirements, as specified in draft-ietf- 158 crisp-requirements-05, "Cross Registry Internet Service Protocol 159 (CRISP) Requirements" [CRISP-REQ]. 161 1.3. Overview 163 In order to achieve the stated objectives, the FIRS specifications 164 collectively define an LDAP-specific application, including 165 application-specific namespaces, object classes, attributes, 166 syntaxes, matching filters, behavioral rules, and more. The 167 framework defined in this document is intended to accommodate the 168 specific resource-types and usages, while the other specifications 169 define the technical details for the service as a whole or for the 170 unique 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 that set, which 199 currently includes [FIRS-CORE], [FIRS-DNS], [FIRS-DNSRR], 200 [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. 202 In order to fully understand FIRS, readers should be familiar with 203 [RFC2247], [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2256], 204 [RFC2798], [RFC3296]and [RFC3377]. 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 207 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 208 in this document are to be interpreted as described in RFC 2119. 210 3. Reference Example 212 Figure 1 below shows an example of a FIRS-specific data-set. This 213 example is referenced throughout this specification. 215 dc=example,dc=com 216 | 217 +-cn=inetResources,dc=example,dc=com 218 [top object class] 219 [inetResources object class] 220 | 221 +-attribute: inetGeneralContacts 222 | value: "admins@example.com" 223 | 224 +-cn=admins@example.com,cn=inetResources,dc=example,dc=com 225 | [top object class] 226 | [inetResources object class] 227 | [inetOrgPerson object class] 228 | | 229 | +-attribute: mail 230 | value: "admins@example.com" 231 | 232 +-cn=example.com,cn=inetResources,dc=example,dc=com 233 | [top object class] 234 | [inetResources object class] 235 | [inetDnsDomain object class] 236 | | 237 | +-attribute: inetDnsAuthServers 238 | value: "ns1.example.net" 239 | 240 +-cn=www.example.com,cn=inetResources,dc=example,dc=com 241 [top object class] 242 [inetResources object class] 243 [inetDnsDomain object class] 244 [referral object class] 245 | 246 +-attribute: inetTechContacts 247 | value: "admins@example.com" 248 | 249 +-attribute: ref 250 value: "ldap://firs.example.net/cn=inetResources, 251 dc=example,dc=net"??? 252 (1.3.6.1.4.1.7161.1.1.8:=host.example.net)" 254 Figure 1: The FIRS-specific data for Example Widgets. 256 As can be seen in Figure 1, entries use a FIRS-specific namespace 257 in conjunction with FIRS-specific schema. FIRS clients use FIRS- 258 specific queries to navigate and retrieve the data, as needed. 260 4. The FIRS Namespace 262 A critical aspect of FIRS is the use of an application-specific 263 namespace which is imposed on all FIRS-based resources. The FIRS 264 namespace rules facilitate the programmatic creation of searches, 265 and help to ensure predictable results. 267 The FIRS namespace consists of three "layers", which are: 269 * A set of domainComponent relative distinguished names which 270 cumulatively identify a specific partition of the global 271 directory tree. 273 * A FIRS-specific container entry which segregates the 274 resource-specific child entries from other LDAP data. 276 * The resource-specific entries which describe the managed 277 resources in the selected partition. 279 The namespace follows a right-to-left order. 281 As an example, Figure 1 shows a DNS domain resource entry named 282 "cn=example.com,cn=inetResources,dc=example,dc=com", which refers 283 to the "example.com" domain resource within the "cn=inetResources" 284 container under the "dc=example,dc=com" directory partition. 286 4.1. The domainComponent Hierarchy 288 The top-level of the namespace uses the domainComponent naming and 289 mapping rules specified in RFC 2247 [RFC2247], which maps DNS 290 domain names to domainComponent ("dc=") relative distinguished 291 names (RDNs). The full sequence of domainComponent RDNs 292 cumulatively represents a partition in the LDAP directory tree. 294 In this model, a sequence of domainComponent RDNs map to a domain 295 name in the global DNS hierarchy, with a FIRS partition having an 296 identical scope of authority as its domain name counterpart. 297 Furthermore, the SRV resource records associated with those DNS 298 domains also provide a mechanism for locating the authoritative 299 LDAP servers associated with any particular resource in the global 300 FIRS directory database. 302 Since the partition roots determine the scope of control over a 303 set of resources, partitions which overlap also have overlapping 304 scopes of control. For example, the "dc=com" and 305 "dc=example,dc=com" partitions can both provide information about 306 the "www.example.com" domain name resource. In order to reduce the 307 amount of ambiguity which is naturally present in this kind of 308 model, FIRS defines multiple bootstrapping models and also defines 309 the default model which should be used for any given resource. For 310 example, queries for centrally-delegated resources are supposed to 311 ask the top-level partition for information about those resources, 312 while queries for user-managed resources are supposed to ask the 313 leaf-node partition for information about those resources. 315 Figure 1 shows the directory partition of "dc=example,dc=com" 316 which maps to the "example.com" scope of authority from the DNS 317 hierarchy, with the "dc=example,dc=com" sequence representing a 318 distinct partition in the globally distributed directory database. 320 Note that each of the specifications which govern particular kinds 321 of resources define their own partition-mapping rules, using 322 different portions of the DNS hierarchy. Specifications are 323 explicitly allowed to use whatever portion of the DNS namespace 324 they wish for this service, but the absolute binding between 325 partitions and DNS domains MUST be preserved in all cases. If an 326 organization chooses to offer a private list of resources (such as 327 advertising a list of networks which have been compromised), that 328 organization is free to map the application-specific partition to 329 any domain name it chooses (note that the use of SRV resource 330 records for location information ensures that only a domain name 331 under the control of a willing party can be used). 333 4.2. The inetResources Container 335 This specification requires the use of a mandatory LDAP container 336 entry with the RDN of "cn=inetResources", which MUST exist at the 337 root of every directory partition that provides FIRS services. All 338 publicly-accessible resource-specific FIRS-related entries MUST be 339 stored in the "cn=inetResources" container entry. 341 The primary motivation for this naming rule is for predictability, 342 in that it allows searches to be formed programmatically (a search 343 base for resources in "dc=example,dc=com" can be programmatically 344 formed as "cn=inetResources,dc=example,dc=com", for example). 345 Furthermore, the use of a single container entry for all of an 346 organization's FIRS-related resources allows that branch of the 347 directory database to be managed independently of other entries on 348 the server, which facilitates better operational security and 349 replication controls. 351 All told, the use of the inetResources container is important 352 enough to justify the MANDATORY usage of this naming syntax. 354 4.3. Resource-Specific Entries 356 The FIRS collection of specifications define several Internet 357 resource types, each of which have their own naming rules. 358 However, each resource type follows a consistent naming principle, 359 in that each specific resource has an RDN which uniquely 360 identifies that resource within the inetResources container entry. 362 For example, Figure 1 shows an entry for the "www.example.com" 363 domain name resource in the "cn=inetResources" container of the 364 "dc=example,dc=com" partition, and also shows an entry for the 365 "admins@example.com" contact resource in that same container and 366 partition. Although the naming syntax is different for each 367 resource type, the naming rules are consistent and facilitate 368 predictable usage. 370 The naming rules for each of the distinct resource type are 371 provided in the documents which govern those resource types. 373 4.4. Namespace Aliases 375 FIRS allows entries to alias for other entries through the use of 376 referrals. Referrals represent one of the strongest capabilities 377 of the FIRS architecture, in that they allow for a significant 378 variety of cross-referencing among entries. For example, referrals 379 can be used to point an inetResources container entry in one 380 partition to another inetResources container entry in another 381 partition, allowing multiple partitions to effectively share a 382 single partition (this is useful when organizations manage 383 multiple networks or domains, and wish to consolidate their 384 management). As another example, referrals can also be used to 385 create placeholder entries for specific resources (such as a web 386 server), with that entry only existing as a referral for a 387 resource which is managed in another partition (such as a web- 388 hosting server at an ISP), with both entries providing information 389 about that resource. 391 This latter example can be seen in Figure 1, which shows an entry 392 for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which 393 provides a referral to the "cn=host.example.net" entry at 394 "cn=inetResources,dc=example,dc=net". Queries for the local entry 395 would be answered with the locally-available information and then 396 redirected to the referral target where additional information 397 could be retrieved. 399 FIRS supports two different kinds of referrals, which are 400 subordinate reference referrals and continuation reference 401 referrals. Subordinate reference referrals indicate that the 402 search base used in the query only exists as an alias to another 403 partition or entry, meaning that the entire query must be 404 restarted in order for any answer data to be retrieved. Meanwhile, 405 continuation reference referrals indicate that some answer data is 406 available, but that more information is available at some other 407 location, and that the client should start new queries in order to 408 retrieve all of the information. 410 Referrals are provided as URLs. FIRS specifically requires the use 411 of LDAP URLs in order to ensure predictable automated processing. 412 Refer to section 6.4.1 for a brief discussion on how these URLs 413 are processed by FIRS clients. 415 4.5. Partition Replicas 417 All directory partitions which provide data for global Internet 418 resources SHOULD be replicated across two or more servers. Each of 419 the authoritative LDAP servers for the managed resource MUST be 420 specified with a unique DNS SRV resource record. 422 Directory partitions which serve multiple organizations SHOULD 423 also be replicated. For example, an ISP which provides FIRS 424 services for their customers SHOULD also follow these same rules, 425 since outages of those servers will affect multiple parties. Leaf- 426 node directory partitions associated with user-managed resources 427 MAY replicate their partitions, but are not required to do so. 429 Note that the most effective replication strategy will be for 430 entities to replicate their directory partitions with their 431 delegation parents, as this will allow queries for those resources 432 to be processed by the parent servers (thereby eliminating the 433 need for an immediate referral). In many cases, this will not be 434 feasible (the servers for the "dc=com" directory partition cannot 435 be expected to host replicas of every subordinate directory 436 partition), but it is encouraged where practical. 438 It is also expected that certain servers will be configured to 439 serve as multi-replica masters, effectively acting as large-scale 440 caching servers for many different resources. When used in 441 conjunction with the targeted bootstrap model described in section 442 6.4.1, this will allow clients to retrieve a significant amount of 443 information without having to pursue a large number of referrals 444 or redirects. This usage is expected and endorsed. 446 Note that the LDAP specifications do not currently provide cache 447 timers or any other mechanisms which can indicate how accurate or 448 timely any replicas may be. It is important for replicas to be 449 synchronized frequently in order to avoid problems that may result 450 from replicas going stale. 452 Further towards the objectives of reliability and redundancy, any 453 referral URLs which include host identifier elements SHOULD 454 provide multiple URLs, each of which identify different hosts. For 455 leaf-node referrals and labeledURI [RFC2079] references, this 456 behavior MAY be relaxed. Note that a host identifier MAY resolve 457 to multiple addresses, and secondary IP addresses SHOULD be used 458 if one of the addresses fails; clients SHOULD NOT give up on a 459 host simply because one of its IP addresses appears to be 460 unreachable. 462 5. FIRS Schema Definitions 464 Another critical aspect of FIRS is the use of well-known schema, 465 including object classes, attributes, syntaxes and matching 466 filters. Some of the schema definitions are for the global FIRS 467 service and are usable by all entries (including resource-specific 468 entries), while others are specific to particular resource-types. 470 For new services, pre-existing schema definitions SHOULD be reused 471 if they are suitable, since this facilitates integration with 472 other LDAP applications. 474 5.1. Global Schema 476 There are three global schema definitions which can be used by any 477 of the entries within FIRS. These include: 479 * The "inetResources" master schema. All FIRS-related entries 480 (including the inetResources container entry and all of the 481 resource-specific subordinate entries) MUST use the 482 inetResources structural object class and schema 483 definitions defined in [FIRS-CORE]. The inetResources 484 object class defines a variety of general-purpose 485 attributes which are useful for general information about 486 an organization and its resources. 488 * Associated resources. All FIRS-related entries MAY use the 489 "inetAssociatedResources" auxiliary object class and schema 490 definitions defined in [FIRS-CORE]. This object class 491 provides cross-reference pointer attributes which allow an 492 entry to reference other resources which may be of interest 493 to other users or applications. 495 * Referral pointers. All FIRS-related entries MAY use the 496 "referral" object class and schema definitions defined in 497 [RFC3296]. This object class allows an entry to exist as a 498 referral source, with queries for that resource being 499 redirected to the referral target. Refer to section 4.4 for 500 a discussion on the different kinds of referral mechanisms 501 offered by FIRS, and section 6.4.1 for a discussion on the 502 FIRS referral-processing mechanisms. 504 Figure 1 shows that all of the entries within and including the 505 "cn=inetResources" container entry have the inetResources object 506 class defined. Meanwhile, each of the resource-specific entries in 507 that example also have their own resource-specific object classes, 508 while the "cn=www.example.com" resource-specific entry also has 509 the referral object class defined. 511 5.1.1. The inetResources schema 513 The inetResources object class is intended to provide summary 514 information about a collection of resources under the control of a 515 single organization or management body. Since this object class is 516 also inherited by the resource-specific object classes, these 517 attributes can be defined at each of the subordinate entries if a 518 global set of attribute values is undesirable or unfeasible. 520 Since multiple directory partitions can use subordinate reference 521 referrals to share a single common inetResources entry, it is 522 important for the data to be applicable to all of the entries 523 which refer to it. For example, it would be effective for a small 524 private company to use a shared set of inetResources attributes 525 for their DNS domain names and IP network blocks, but it would 526 probably be counter-productive for a global ISP to share contact 527 data across all of their hosted domains and routed networks. If 528 separate contacts are required for each resource, the contact data 529 should be specified within each entry, rather than being linked to 530 the inetResources entry. 532 The inetResources object class provides several multi-valued 533 contact-related attributes for a variety of well-known 534 administrative roles. This model allows the inetResources entry 535 and each of the subordinate managed resources to share a common 536 set of administrative roles, or to have unique roles for each 537 resource, as seen fit by the managing entity. 539 5.1.2. The inetAssociatedResources schema 541 The inetAssociatedResources object class defines attributes which 542 are useful for providing general-purpose cross-referencing 543 information with other resources. For example, a contact entry can 544 list IPv4 networks or DNS domains as associated resources, thereby 545 providing a simplistic cross-reference mechanism between an 546 administrator and the resources he manages. In short, any of the 547 common resource types can be associated with any other resource 548 through the use of this object class. 550 5.1.3. The referral schema 552 The referral object class is used to redirect queries to other 553 entries programmatically. This object class and its associated 554 schema and rules provide the backbone of the aliasing mechanisms 555 discussed in section 4.4. 557 5.2. Resource-Specific Schema 559 In addition to the global schema definitions, each of the 560 resource-specific entries in FIRS MUST use the resource-specific 561 schema definitions defined for use with that specific resource 562 type. These object classes are defined in the specifications which 563 govern the different resource-types. These include: 565 * DNS domains. Every domain name resource entry MUST use the 566 inetDnsDomain object class and schema definitions defined 567 in [FIRS-DNS]. These entries can refer to zone delegations, 568 host-specific entries, reverse-lookup pointer entries, or 569 any other domain name. 571 * DNS resource-records. Any domain name resource MAY use the 572 inetDnsRR object class and schema definitions defined in 573 [FIRS-DNSRR]. The inetDnsRR object class defines a single 574 optional attribute for storing multiple DNS resource 575 records as supplemental data to a domain name entry. 577 * IPv4 address blocks. Every IPv4 address block resource MUST 578 use the inetIpv4Network object class and schema definitions 579 defined in [FIRS-IPV4]. Entries can refer to entire 580 networks or to single hosts, as needed. 582 * IPv6 address blocks. Every IPv6 address block resource MUST 583 use the inetIpv6Network object class and schema definitions 584 defined in [FIRS-IPV6]. Entries can refer to entire 585 networks or to single hosts, as needed. 587 * Autonomous system numbers. Every autonomous system number 588 resource MUST use the inetAsNumber object class and schema 589 definitions defined in [FIRS-ASN]. 591 * Contacts. Every contact entry MUST use the inetOrgPerson 592 object class defined in [RFC2798], but MUST also use the 593 additional schema definitions defined in [FIRS-CONTCT]. 595 As was discussed in section 5.1, each resource-specific entry MAY 596 exist as a referral source, or MAY have attributes which refer to 597 additional (related) resources. 599 6. Query Processing Behaviors 601 Another critical aspect to FIRS is the query-processing behavioral 602 rules which govern the ways in which a client parses an input 603 string, locates a server which is authoritative for the resource 604 being queried, generates LDAPv3 queries, and processes the 605 resulting answer data. More specifically: 607 * Query pre-processing. Portions of this process require the 608 client to determine the type of resource being queried for, 609 and to determine the initial partition which should be used 610 for the query. Since this process is different for each 611 particular resource-type, the rules which govern this 612 behavior are defined in each of the resource-specific 613 specifications. 615 * Bootstrap processing. Once a resource-type and partition 616 have been determined, the client must locate the LDAP 617 servers which are authoritative for that partition. [FIRS- 618 CORE] defines three different bootstrap models that clients 619 can use as part of this process, while each of the 620 resource-specific specifications define which of the models 621 are to be used for each particular resource-type. 623 * Query processing. Once a server has been located, the 624 client must submit the LDAP query which was formed during 625 the pre-preprocessing phase. [FIRS-CORE] defines certain 626 LDAPv3 query parameters which all FIRS clients MUST conform 627 with, while the resource-specific specifications define 628 resource-specific matching rules. 630 * Query post-processing. Response data frequently needs to be 631 further processed. For example, referrals may need to be 632 processed, or some kinds of data may need to be localized. 633 These mechanisms and their behavioral rules are defined in 634 [FIRS-CORE], while the resource-specific specifications may 635 also describe supplemental rules. 637 Each of these phases are discussed in more detail below. 639 6.1. Query Pre-Processing 641 Client input is generally limited to a single well-formed unit of 642 data, such as a domain name ("example.com") or an email address 643 ("admins@example.com"), and this single piece of information must 644 be used to subsequently build a fully-formed LDAPv3 query, 645 including the assertion value, the search base, the matching 646 filter, and so forth. All of these steps are part of the pre- 647 processing phase. 649 Although the exact sequence of steps will vary according to the 650 resource-type being queried, there are some commonalities between 651 each of them. Among these steps: 653 * Determine the resource type. Different kinds of resources 654 have different processing steps, validation mechanisms, and 655 so forth, each of which require that the resource-type be 656 appropriately identified. Clients MAY use any mechanisms 657 necessary to force this determination. 659 * Validate and normalize the data. In all cases, the input 660 data MUST be validated and normalized according to the 661 syntax rules defined in the specification which governs the 662 resource-type. As an example of this step, queries for 663 internationalized domain names must be validated and 664 normalized into a canonical UTF-8 [RFC2279] form before any 665 other steps can be taken. Similarly, IP addresses are 666 required to conform to specific syntax rules, with the 667 input address possibly being expanded or compressed so as 668 to comply with the syntax requirements. 670 * Determine the authoritative directory partition for the 671 named resource. In most cases, the authoritative partition 672 will be a variation of the input query string, but this is 673 not always the case. For example, the default partition for 674 an email address will be extrapolated from the domain 675 component of the email address itself, while the 676 authoritative partition for an autonomous system number 677 uses a reserved (special-purpose) domain name. In some 678 cases, the authoritative partition may change during the 679 subsequent query-processing steps. 681 * Determine the search base for the query. Each resource type 682 has resource-specific query-processing rules which will 683 dictate how the authoritative partitions are mapped to the 684 search base. In some cases, the cn=inetResources container 685 entry in the authoritative partition will be used "as-is", 686 while in other cases, the cn=inetResources container entry 687 in a delegation parent of the authoritative partition will 688 be used instead. In some cases, the search base may change 689 during subsequent query-processing steps. 691 * Determine the assertion value for the query. The assertion 692 value will usually be the normalized form of the input 693 query. In some cases, the assertion value may change during 694 subsequent query-processing steps. 696 * Determine the matching filter. Each resource-type has its 697 own matching filter rules. For example, contact entries are 698 matched with a simple equalityMatch comparison, while in 699 other cases the matching filter will be an extensibleMatch 700 which is peculiar to the resource-type in use. 702 Once all of the pre-processing steps have been successfully 703 completed, the client will have to locate an LDAPv3 server which 704 is authoritative for the search base before it can submit the 705 query. This process is described in section 6.2 below. 707 6.2. Bootstrap Processing 709 The bootstrap process uses DNS queries to locate the LDAP servers 710 which should be used for a query. However, since different kinds 711 of resources are managed through different delegation models, 712 there are also different bootstrap models which have to be used to 713 perform this process. 715 FIRS supports three different bootstrap models, which are: 717 * Targeted. The "targeted" bootstrap model has the client 718 attempting to locate the LDAP servers associated with a 719 specific domain name, such as a domain name which may be 720 returned as referrals or URLs. If no servers can be found 721 at that domain name, the client exits the query. 723 * Top-down. The "top-down" bootstrap model has the client 724 attempting to locate the LDAP servers associated with a 725 top-level partition in the delegation path to the 726 authoritative partition, and then following any subsequent 727 LDAP referrals which may be returned. If no servers can be 728 found for the top-level domain, the client exits the query. 730 * Bottom-up. The "bottom-up" bootstrap model has the client 731 attempting to locate the LDAP servers associated with the 732 authoritative partition itself. If no servers can be found 733 for that partition, the authoritative partition is reset to 734 the immediate parent in the delegation hierarchy and new 735 DNS queries are issued, with this process repeating until a 736 server is found or there are no more domains in the 737 delegation path which can be queried. 739 Each of the models are appropriate to different usages. For 740 example, The targeted model is most useful when a particular piece 741 of data is presumed to exist at a pre-determined location. 742 Meanwhile, the top-down model is best suited for searches about 743 global resources which are centrally managed and delegated (such 744 as IP addresses and DNS domains), and where centrally-managed 745 delegation information is critical. Finally, the bottom-up model 746 is most appropriate for resources which are managed at a leaf-node 747 (such as contact information). 749 6.3. Query Processing 751 Once an LDAP server has been located, the LDAPv3 query is 752 submitted to that server. 754 Most of the values for the query will have been collected during 755 the pre-processing phase, although [FIRS-CORE] defines some rules 756 which govern all queries. For example, [FIRS-CORE] specifies a 757 maximum time limit of 60 seconds for queries (among other similar 758 kinds of restrictions) in order to prevent runaway searches which 759 would otherwise match all entries. 761 [FIRS-CORE] also allows for authentication and access controls, in 762 that FIRS servers are allowed to limit the depth and breadth of 763 information that they provide to a specific client based on a 764 variety of factors, including the level of authenticated access. 766 Another consideration which can arise during this phase of the 767 process is protocol and schema versioning considerations. The 768 [LDAP] specifications already define mechanisms for protocol 769 version negotiation, and the use of these mechanisms is endorsed 770 and encouraged in [FIRS-CORE]. 772 Schema and capability negotiation is handled through the use of a 773 "firsVersion" control (as defined in [FIRS-CORE]), which provides 774 a list of the FIRS-specific object classes that are supported by 775 the target server. If a server advertises support for any of the 776 FIRS-specific object classes, then the server also commits to 777 supporting all of the attributes and matching filters associated 778 with that object class. Clients can then use this information to 779 determine whether or not the current server is using the same 780 schema as the client. 782 The client MAY also use this information to determine whether or 783 not it will need to construct its own queries. Since it is 784 somewhat likely that a particular server will not support all of 785 the mechanisms required by the complete FIRS model (especially 786 including all of the extended matching filters), then the client 787 can use this information to determine if it needs to construct its 788 own extended queries locally. Refer to the resource-specific 789 documents for more information on this process. 791 6.4. Query Post-Processing 793 Once a query has been submitted and processed, the server will 794 return answer data or some kind of referral, or possibly both. In 795 general, FIRS clients are expected to display all of the answer 796 data and process all of the referrals, although there are specific 797 considerations which must be taken into account. In particular, 798 there are considerations for handling the different kinds of 799 referrals, and there are localizations issues for specific kinds 800 of attribute data. 802 6.4.1. Referrals 804 As was discussed in section 4.4, there are two kinds of referral 805 mechanisms which are used with FIRS, which are subordinate 806 reference referrals and continuation reference referrals. More 807 specifically: 809 * Subordinate reference referrals. Subordinate reference 810 referrals are returned when the search base specified in a 811 query exists as a referral to some other entry. This 812 condition means that the current search operation cannot 813 proceed, and that the search MUST be restarted using the 814 search base specified in the referral message. 816 Any of the FIRS-specific entries MAY be defined as 817 subordinate reference referrals, although they are 818 typically only used when the inetResources container entry 819 in a partition is an alias for an inetResources container 820 entry in another partition. Subordinate reference referrals 821 and their schema are defined in [RFC3296] although there 822 are additional restrictions placed on their usage as 823 described in [FIRS-CORE]. 825 * Continuation reference referrals. Continuation reference 826 referrals are returned when a search operation has been 827 successfully processed by the queried server, but the 828 answer data also includes referrals to other entries. This 829 condition means that the current search operation has 830 succeeded, but that additional searches SHOULD be started 831 in order for all of the answer data to be retrieved. 833 These referrals are often provided as supplemental data to 834 an answer set, although this is not required (a 835 continuation reference referral can be the only response, 836 but it won't be the only response in the common case). 837 Continuation reference referrals and their schema are also 838 defined in [RFC3296], with additional restrictions placed 839 on their usage as described in [FIRS-CORE]. 841 Whenever a referral is received in response to a query, the client 842 is required to display any answer data which has also been 843 received and then process the referral. 845 LDAP referrals can use any kind of URL, although FIRS specifically 846 requires the use of LDAP URLs. The client is required to parse the 847 resulting URL for a host identifier, port number, search base, and 848 assertion value elements, and then use these elements to construct 849 and issue new queries. 851 Note that [RFC2251] defines a superior reference referral which is 852 used as a "default referral" for out-of-scope searches. However, 853 FIRS specifically excludes support for superior reference 854 referrals. Any superior reference referrals which are encountered 855 as part of this service are to be treated as errors. 857 6.4.2. Internationalization and localization 859 The FIRS model uses the internationalization and localization 860 services which are inherent in LDAPv3. In many cases, this native 861 support is sufficient to accommodate internationalization and 862 localization considerations. However, there are several cases 863 where additional and explicit support is required. 865 For example, the domainComponent attribute is specifically 866 restricted to seven-bit character codes, and is traditionally 867 interpreted as simple [US-ASCII]. This is problematic with 868 internationalized domain names and the domainComponent attributes 869 derived from them, since these attribute sequences are used in 870 partition identifiers, search bases, and numerous other areas. In 871 order to ensure interoperability, all DNS domain names which are 872 mapped to domainComponent attributes MUST be reduced to their 873 ASCII-compatible form using the ToASCII process defined in 874 [RFC3490] before they are used for domainComponent sequences. 876 Similarly, although DNS is technically capable of storing eight- 877 bit code-point values, the operational rules which govern DNS do 878 not support this usage for domain names which are used as host 879 identifiers (and this includes zone delegations). As a result, 880 internationalized domain names which are to be used for DNS 881 lookups (such as queries for SRV resource records) MUST be reduced 882 to their ASCII-compatible form using the ToASCII process defined 883 in [RFC3490] before these queries are issued. 885 In those cases where entries or attributes use normalized UTF-8 886 sequences inside of FIRS (specifically domain names and email 887 addresses), FIRS clients SHOULD offer ASCII-compatible versions of 888 those sequences, using the ToASCII process defined in [RFC3490]. 889 This will ensure that clients are able to use these sequences with 890 legacy (pre-IDNA) applications directly. For example, if an entry 891 displays an inetAssociatedDomains attribute, the domain names in 892 that attribute should be displayed in their default UTF-8 form 893 (assuming that the client's operating system and application 894 allows it), but should also be made available in their ASCII- 895 compatible form (either as a clipboard option, command-line 896 option, or some other user-selectable switch) in order to allow 897 the data to be passed to a legacy application in a form which is 898 understandable by the legacy application. 900 Attribute names are fixed, and can therefore be localized easily. 901 As such, clients MAY choose to convert attribute names into a 902 language appropriate to the local user for display purposes if 903 this is desirable. However, clients MUST NOT localize attribute 904 names which are used for query input. For example, clients MUST 905 NOT convert "cn=" or "dc=" relative distinguished labels into a 906 language-specific mapping and then use the mapped versions of 907 these labels for assertion values in a subsequent query. 909 RFC 2277 [RFC2277] requires free-text data to be tagged with 910 language tags. RFC 2596 [RFC2596] defines a mechanism for storing 911 language tags and language-specific attribute values in LDAPv3, 912 and these mechanisms SHOULD be supported by FIRS clients and 913 servers. For example, an organization name could be provided in 914 English and Arabic, with the language tags allowing the client to 915 display the appropriate attribute value instance based on the 916 locale settings of the user. 918 International postal regulations generally require that the 919 recipient address on an envelope be provided in a language and 920 charset which is native to the recipient's country, with the 921 exception of the destination country name which should be provided 922 in a language and charset that is native to the sender's country. 923 This model ensures that the sender's post office will be able to 924 route the mail to the recipient's country, while also ensuring 925 that the destination country's post office will be able to perform 926 local delivery. In order to facilitate this usage, the country 927 attribute value SHOULD be localized to the local user's 928 nomenclature for that country, but other postal address data 929 SHOULD NOT be localized. 931 Notwithstanding the above, contact names SHOULD be provided in 932 English in order to facilitate inter-party communications, using 933 the mechanisms offered by [RFC2596]. For example, the default 934 contact entry for a person in Japan SHOULD be provided in the 935 native form for that person, but an English form SHOULD also be 936 provided in order to allow non-Japanese users to properly address 937 that person in subsequent communications. As stated in the 938 preceding paragraph however, any postal communications for that 939 person SHOULD use the native-language representation (at least on 940 the envelope) in order to facilitate delivery. 942 Time and date strings in LDAP use the generalizedTime syntax, 943 making them predictable and easily convertible if necessary. As 944 such, dates MAY be localized for display purposes by client 945 applications as necessary. 947 Finally, clients must recognize that some URL data is likely to be 948 escaped, using at least one of the multiple rules which affect 949 URLs and resource-specific data. For example, a URL which contains 950 a domain name resource could theoretically have been escaped with 951 three or four different syntax rules, and clients MUST be prepared 952 to decode these URLs appropriately. 954 7. Transition Issues 956 There are a handful of areas where FIRS does not fully compare 957 with all of the existing WHOIS service offerings. These areas are 958 discussed in more detail below. 960 7.1. NIC Handles 962 Legacy NIC handles in existing databases can be accommodated using 963 two possible mechanisms: 965 * NIC handle output in legacy WHOIS systems may be replaced 966 with email addresses for the contacts, using mail domain 967 elements which refer to the operator's domain. For example, 968 the NIC handle of EH26 on Network Solutions' WHOIS server 969 could be replaced with "eh26@firs.netsol.com" or similar. 970 This approach causes lookups for that email address to be 971 directed towards the operator's FIRS servers, and 972 facilitates fast coalescence around the FIRS system. 974 * Use the inetPrivateIdentifier attribute defined in [FIRS- 975 CORE]. This option provides a simple text string which can 976 be used for private identifiers, but provides no 977 integration with FIRS, other than allowing for attribute 978 value searches. 980 Of the two mechanisms described above, the former is preferred. 982 7.2. Change-Logs 984 Several WHOIS services provide pseudo change-logs in their 985 response data, listing each unique modification event which has 986 occurred for a particular resource. For example, RIPE and some of 987 the ccTLDs provide WHOIS output which includes a series of 988 "changed" fields that itemize every modification event ("updated", 989 "added", etc.), the modifier, and the modification date, which 990 cumulatively act as a change-log for the resource in question. 992 Organizations are certainly free to maintain this information on 993 their internal systems. However, this information is not necessary 994 for public view of the data in the FIRS service. Furthermore, 995 where auditing of this information will be required, a format 996 which is suitable to legal review will also be required. 998 Organizations who wish to make change-log information available 999 should use an auxiliary LDAP schema for this purpose. An initial 1000 schema is available at http://www.ehsco.com/misc/draft-hall-ldap- 1001 audit-00.txt, although it has not been proposed as a standards- 1002 track effort, and should only be used as a starting point for 1003 other development. 1005 7.3. Legacy System Support 1007 Organizations which already provide WHOIS services over TCP port 1008 43 have several migration options. At the lowest extreme, these 1009 organizations can continue to use and support those systems as-is, 1010 without any modifications. However, other organizations may choose 1011 to implement a FIRS client in a text-based application (such as a 1012 Perl script), with that application accepting typical queries over 1013 the legacy TCP/43 port, processing those queries through FIRS, and 1014 returning answer data back to the legacy WHOIS client. Another 1015 approach is described in draft-newton-whois-crisp-cohabitation- 1016 00.txt, which advocates the use of NAPTR and SRV resource records 1017 to redirect legacy clients to FIRS servers. 1019 A similar range of options are available for back-end database 1020 integration. Organizations who do not wish to align their back-end 1021 databases to the LDAP/FIRS model can use basic scripts to generate 1022 LDIF files on a suitable schedule, and then populate their LDAP 1023 servers with this data. Meanwhile, other organizations may choose 1024 to provide an LDAP front-end to an existing database, while other 1025 organizations may choose to use a single LDAP repository for all 1026 of their applications. 1028 In general terms, FIRS does not require or endorse any of these 1029 mechanisms, and they are only presented here so that operators are 1030 aware of the options. 1032 8. Security Considerations 1034 The FIRS collection of specifications describe an application of 1035 the LDAPv3 protocol, and as such it inherits the security 1036 considerations associated with LDAPv3, as described in section 7 1037 of [RFC2251]. 1039 By nature, LDAP is a read-write protocol. As such, there are 1040 significant risks associated with unintentionally allowing 1041 unauthorized third-parties to update the underlying data. 1042 Moreover, allowing FIRS clients to update delegation data could 1043 result in network resources being stolen from their lawful 1044 operators. For example, if the LDAP front-end had update access to 1045 a domain delegation database, a malicious third-party could 1046 theoretically take ownership of a domain by exploiting an 1047 authentication weakness, thereby causing ownership of the domain 1048 to be changed to another party. For this reason, it is imperative 1049 that the FIRS service not be allowed to make critical 1050 modifications to delegated resources without ensuring that all 1051 possible precautions have been taken, potentially including strong 1052 authentication and encryption practices. 1054 The query processing models described in these documents make use 1055 of DNS lookups in order to locate the LDAP servers associated with 1056 a particular resource. DNS is susceptible to certain attacks and 1057 forgeries which may be used to redirect clients to LDAP servers 1058 which are not authoritative for the resource in question. 1060 This document provides multiple query models which will cause the 1061 same query to be answered by different servers (one would be 1062 processed by a delegation entity, while another would be processed 1063 by an operational entity). As a result, each of the servers may 1064 provide different information, depending upon the query type that 1065 was originally selected. 1067 Some operators may choose to purposefully provide misleading or 1068 erroneous information in an effort to avoid responsibility for bad 1069 behavior. In addition, there are likely to be sporadic operator 1070 errors which will result in confusing or erroneous answers. 1072 Neither this specification nor the LDAPv3 protocol currently 1073 provide cache timers or any other mechanisms which can indicate 1074 how accurate or timely any replicas may be. As a result, it is 1075 possible for a replica to become significantly outdated, even to 1076 the point of containing wholesale errors. 1078 For all of the reasons listed above, it is essential that 1079 applications and end-users not make critical decisions based on 1080 the information provided by the FIRS service without having reason 1081 to believe the veracity of the information. Users should limit 1082 unknown or untrusted information to routine purposes. 1084 Despite these disclaimers, however, it is very likely that the 1085 information presented through the FIRS service will be used for 1086 many operational and problem-resolution purposes. In order to 1087 ensure the veracity of the information, a minimal set of 1088 operational guidelines are provided herein. For the most part, 1089 these rules are designed to prevent unauthorized modifications to 1090 the data. 1092 Note that these rules only apply to data which is willingly 1093 provided; no data is required to be entered, but where the data is 1094 provided, it SHOULD be validated as accurate on entry, and it MUST 1095 be secured against unauthorized modifications. 1097 * The inetResources container entry and all of the resource- 1098 specific subordinate entries within every public DIT that 1099 provides FIRS resources SHOULD have anonymous read-only 1100 access permissions, and MUST NOT have anonymous add, delete 1101 or modify permissions. 1103 * With the exception of contact-related attributes from the 1104 inetOrgPerson object class, each attribute MAY have 1105 whatever restrictions are necessary in order to suit local 1106 security policies, government regulations or personal 1107 privacy concerns. When the inetOrgPerson object class is 1108 used to provide contact details, the mail attribute MUST be 1109 defined, SHOULD be valid, SHOULD have anonymous read-only 1110 access, and MUST NOT have anonymous add, delete or modify 1111 permissions. 1113 By using the inetOrgPerson object class, it is expected 1114 that existing contact-related entries can be reused. If 1115 reusing these entries is undesirable or unfeasible, entries 1116 with the necessary access SHOULD be made available. 1118 * End-users and implementers SHOULD provide anonymous access 1119 to the creatorsName, createTimestamp, modifiersName and 1120 modifyTimestamp operational attributes associated with each 1121 entry in the inetResources branch, since this information 1122 is useful for determining the age of the underlying data. 1124 * Server operators MAY define additional add, delete or 1125 modify permissions for authenticated users, using any 1126 LDAPv3 authentication mechanisms they wish. In particular, 1127 delegation entities MAY provide for the remote management 1128 of delegated resources (such as assigning modification 1129 privileges to the managers of a particular delegated domain 1130 or address block), although this is entirely optional, and 1131 is within the sole discretion of the delegation body. 1133 * In the general case, server operators SHOULD NOT offer 1134 clear-text authentication mechanisms over unencrypted 1135 connections. 1137 Finally, there are physical security issues associated with any 1138 service which provides physical addressing and delivery 1139 information. 1141 In summary, organizations MAY provide as much data as possible, 1142 although no information is required. 1144 9. IANA Considerations 1146 The FIRS collection of specifications define an application of the 1147 LDAPv3 protocol rather than a new Internet application protocol. 1148 As such, there are no protocol-related IANA considerations. 1150 However, the FIRS collection of specifications do define several 1151 LDAP schema elements, including object classes, attributes, 1152 syntaxes and extensibleMatch filters, and these elements should be 1153 assigned OID values from the IANA branch. Furthermore, some of the 1154 specifications define their own status codes as attribute values, 1155 and IANA is expected to maintain the code-point mapping values 1156 associated with these attributes. 1158 Finally, some of the specifications also describe public DNS and 1159 LDAP servers and data. It is expected that IANA will see to the 1160 establishment and maintenance of these servers and data. 1162 10. Normative References 1164 [CRISP-REQ] Newton, A. "Cross Registry Internet Service 1165 Protocol (CRISP) Requirements", draft-ietf- 1166 crisp-requirements-05, July 2003. 1168 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 1169 Service: Architecture and Implementation 1170 Guide", draft-ietf-crisp-firs-arch-02, July 1171 2003. 1173 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 1174 System Numbers in the Federated Internet 1175 Registry Service", draft-ietf-crisp-firs-asn- 1176 02, July 2003. 1178 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 1179 Persons in the Federated Internet Registry 1180 Service", draft-ietf-crisp-firs-contact-02, 1181 July 2003. 1183 [FIRS-CORE] Hall, E. "The Federated Internet Registry 1184 Service: Core Elements", draft-ietf-crisp- 1185 firs-core-02, July 2003. 1187 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 1188 the Federated Internet Registry Service", 1189 draft-ietf-crisp-firs-dns-02, July 2003. 1191 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 1192 Records in the Federated Internet Registry 1193 Service", draft-ietf-crisp-firs-dnsrr-02, July 1194 2003. 1196 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 1197 Blocks in the Federated Internet Registry 1198 Service", draft-ietf-crisp-firs-ipv4-02, July 1199 2003. 1201 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 1202 Blocks in the Federated Internet Registry 1203 Service", draft-ietf-crisp-firs-ipv6-02, July 1204 2003. 1206 [ISO10646] "ISO/IEC 10646-1:2000. International Standard 1207 -- Information technology -- Universal 1208 Multiple-Octet Coded Character Set (UCS) -- 1209 Part 1: Architecture and Basic Multilingual 1210 Plane" 1212 [RFC2079] Smith, M. "Definition of an X.500 Attribute 1213 Type and an Object Class to Hold Uniform 1214 Resource Identifiers (URIs)", RFC 2079, 1215 January 1997. 1217 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 1218 and Sataluri, S. "Using Domains in LDAP/X.500 1219 DNs", RFC 2247, January 1998. 1221 [RFC2251] Wahl, M., Howes, T., and Kille, S. 1222 "Lightweight Directory Access Protocol (v3)", 1223 RFC 2251, December 1997. 1225 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 1226 S. "Lightweight Directory Access Protocol 1227 (v3): Attribute Syntax Definitions", RFC 2252, 1228 December 1997. 1230 [RFC2253] Wahl, M., Kille, S., and Howes, T. 1231 "Lightweight Directory Access Protocol (v3): 1232 UTF-8 String Representation of DNs", RFC 2253, 1233 December 1997. 1235 [RFC2254] Howes, T. "The String Representation of LDAP 1236 Search Filters", RFC 2254, December 1997. 1238 [RFC2255] Howes, T., and Smith, M. "The LDAP URL 1239 Format", RFC 2255, December 1997. 1241 [RFC2256] Wahl, M. "A Summary of the X.500(96) User 1242 Schema for use with LDAPv3", RFC 2256, 1243 December 1997. 1245 [RFC2277] Alvestrand, H. "IETF Policy on Character Sets 1246 and Languages", BCP 18, RFC 2277, January 1247 1998. 1249 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 1250 ISO 10646", RFC 2279, January 1998. 1252 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 1253 in LDAP", RFC 2596, May 1999. 1255 [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A 1256 DNS RR for specifying the location of services 1257 (DNS SRV)", RFC 2782, February 2000. 1259 [RFC2798] Smith, M. "Definition of the inetOrgPerson 1260 LDAP Object Class", RFC 2798, April 2000. 1262 [RFC3296] Zeilenga, K. "Named Subordinate References in 1263 Lightweight Directory Access Protocol (LDAP) 1264 Directories", RFC 3296, July 2002. 1266 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 1267 Directory Access Protocol (v3): Technical 1268 Specification", RFC 3377, September 2002. 1270 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 1271 "Internationalizing Domain Names in 1272 Applications (IDNA)", RFC 3490, March 2003. 1274 [US-ASCII] Cerf, V. "ASCII format for Network 1275 Interchange", RFC 20, October 1969. 1277 11. Informational References 1279 [RFC812] Harrenstien, K., and White, V. 1280 "NICNAME/WHOIS", RFC 812, March 1982. 1282 12. Changes from Previous Versions 1284 draft-ietf-crisp-firs-arch-02: 1286 * Several clarifications and corrections have been made. 1288 draft-ietf-crisp-firs-arch-01: 1290 * Several clarifications and corrections have been made. 1292 draft-ietf-crisp-firs-arch-00: 1294 * Restructured document set, separating the architectural 1295 discussion from the technical descriptions. 1297 * Consolidated the security discussions. 1299 draft-ietf-crisp-lw-core-00: 1301 * As a result of the formation of the CRISP working group, 1302 the original monolithic document has been broken into 1303 multiple documents, with draft-ietf-crisp-lw-core 1304 describing the core service, while related documents 1305 describe the per-resource schema and access mechanisms. 1307 * References to the ldaps: URL scheme have been removed, 1308 since there is no standards-track specification for the 1309 ldaps: scheme. 1311 * An acknowledgements section was added. 1313 draft-hall-ldap-whois-01: 1315 * The "Objectives" section has been removed. [ir-dir-req] is 1316 now being used as the guiding document for this service. 1318 * Several typographical errors have been fixed. 1320 * Some unnecessary text has been removed. 1322 * Figures changed to show complete sets of object classes, to 1323 improve inheritance visibility. 1325 * Clarified the handling of reverse-lookup domains (zones 1326 within the in-addr.arpa portion of the DNS hierarchy) in 1327 the inetDnsDomain object class reference text. 1329 * Referrals now use regular LDAP URLs (multiple responses 1330 with explicit hostnames and port numbers). Prior editions 1331 of this specification used LDAP SRV resource records for 1332 all referrals. 1334 * The delegation status codes used by the 1335 inetDnsDelegationStatus, inetIpv4DelegationStatus, 1336 inetIpv6DelegationStatus and inetAsnDelegationStatus 1337 attributes have been condensed to a more logical set. 1339 * Added an inetDnsAuthServers attribute for publishing the 1340 authoritative DNS servers associated with a domain. NOTE 1341 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 1342 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 1343 ATTRIBUTES. 1345 * Added an inetGeneralDisclaimer attribute for publishing 1346 generalized disclaimers. 1348 * Added the inetAssociatedResources auxiliary object class 1349 for defining associated resources, and moved some of the IP 1350 addressing and ASN attributes to the new object class. 1352 * Several attributes had their OIDs changed. NOTE THAT THIS 1353 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1354 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1356 13. Author's Address 1358 Eric A. Hall 1359 ehall@ehsco.com 1361 14. Acknowledgments 1363 Funding for the RFC editor function is currently provided by the 1364 Internet Society. 1366 Portions of this document were funded by VeriSign Labs. 1368 The first version of this specification was co-authored by Andrew 1369 Newton of VeriSign Labs, and subsequent versions continue to be 1370 developed with his active participation. Edward Lewis and Peter 1371 Gietz also contributed significant feedback to this specification 1372 in the later stages of its developments. 1374 15. Full Copyright Statement 1376 Copyright (C) The Internet Society (2003). All Rights Reserved. 1378 This document and translations of it may be copied and furnished 1379 to others, and derivative works that comment on or otherwise 1380 explain it or assist in its implementation may be prepared, 1381 copied, published and distributed, in whole or in part, without 1382 restriction of any kind, provided that the above copyright notice 1383 and this paragraph are included on all such copies and derivative 1384 works. However, this document itself may not be modified in any 1385 way, such as by removing the copyright notice or references to the 1386 Internet Society or other Internet organizations, except as needed 1387 for the purpose of developing Internet standards in which case the 1388 procedures for copyrights defined in the Internet Standards 1389 process must be followed, or as required to translate it into 1390 languages other than English. 1392 The limited permissions granted above are perpetual and will not 1393 be revoked by the Internet Society or its successors or assigns. 1395 This document and the information contained herein is provided on 1396 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1397 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1398 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1399 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.