idnits 2.17.1 draft-ietf-crisp-firs-arch-00.txt: -(1144): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 7623 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 995, but no explicit reference was found in the text == Unused Reference: 'RFC2079' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'RFC2255' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1042, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1274 (Obsoleted by RFC 4524) ** 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) == 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-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' -- Obsolete informational reference (is this intentional?): RFC 812 (Obsoleted by RFC 954, RFC 3912) Summary: 14 errors (**), 0 flaws (~~), 18 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-00.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 2.1. Reference Example......................................6 50 3. The FIRS Namespace........................................8 51 3.1. The domainComponent Hierarchy..........................8 52 3.2. The inetResources Container............................9 53 3.3. Resource-Specific Entries..............................9 54 3.4. Namespace Aliases.....................................10 55 4. FIRS Schema Definitions..................................11 56 4.1. Global Schema Definitions.............................11 57 4.2. Resource-Specific Schema Definitions..................12 58 5. Query Processing Behaviors...............................13 59 5.1. Query Pre-Processing..................................13 60 5.2. Bootstrap Processing..................................15 61 5.3. Query Processing......................................16 62 5.4. Query Post-Processing.................................16 63 5.4.1. Referrals.......................................17 64 5.4.2. Internationalization and localization...........18 65 6. Transition Issues........................................19 66 6.1. NIC Handles...........................................20 67 6.2. Change-Logs...........................................20 68 7. Security Considerations..................................20 69 8. IANA Considerations......................................23 70 9. Author's Address.........................................23 71 10. Normative References.....................................23 72 11. Informational References.................................26 73 12. Acknowledgments..........................................26 74 13. Changes from Previous Versions...........................26 75 14. Full Copyright Statement.................................28 77 1. Introduction 78 FIRS is intended to provide a distributed WHOIS-like information 79 service, using the LDAPv3 specifications [RFC3377] for the data- 80 formatting and query-transport functions. 82 More specifically, the principle objective behind FIRS is to offer 83 structured information about distributed Internet resources in a 84 model which reflects the federated delegations of those resources. 85 This specifically includes centralized delegations from authorized 86 governance bodies (such as DNS domains within the "com" zone), but 87 also includes delegations from authorized bodies further down the 88 delegation path (such as leaf-node DNS domain names within the 89 "example.com" zone). 91 Furthermore, the FIRS service is intended to be used with a wide 92 variety of resources. The core set of specifications define rules 93 for handling the most-common resources (DNS domains, IP addresses, 94 contact information, and so forth), but other types of resources 95 may be grafted onto the architecture as needed. By extension, FIRS 96 should be capable of providing the necessary support structure for 97 any kind of information to be stored in a global mesh of FIRS- 98 centric LDAP directories, and for the FIRS-specific clients and 99 servers to be easily extended to accommodate that data. 101 Another critical objective can be described as predictability, in 102 that FIRS-specific data should be easily accessible to a wide 103 number of applications. For example, if a network manager wants to 104 retrieve information about a particular host or network, it should 105 be easy for the management application to be extended so that the 106 FIRS data can be fetched by that application, rather than always 107 requiring the use of a FIRS-specific application. 109 Finally, the collection of specifications which define the 110 Federated Internet Registry Service (FIRS) are intended to satisfy 111 the CRISP Working Group requirements, as specified in draft-ietf- 112 crisp-requirements-05, "Cross Registry Internet Service Protocol 113 (CRISP) Requirements" [CRISP-REQ]. 115 In order to achieve these objectives, the FIRS specifications 116 collectively define an LDAP-specific application, including 117 application-specific namespaces, object classes, attributes, 118 syntaxes, queries, behavioral rules, and more. 120 1.1. Background 121 The original WHOIS service [RFC812] was provided as a front-end to 122 a centralized repository of ARPANET resources and users. Over 123 time, hundreds of WHOIS servers have been deployed across the 124 public Internet, with each server providing general information 125 about the particular network resources under the control of a 126 specific organization. 128 Unfortunately, neither [RFC812] nor any of its successors define a 129 strict set of data-typing or formatting requirements, and as a 130 result, each of the different implementations provide different 131 kinds of information in slightly different ways. Furthermore, each 132 WHOIS server operates as a self-contained entity, with no 133 standardized mechanisms to infer knowledge of any other servers, 134 meaning that WHOIS servers cannot redirect clients to other 135 servers for additional information. Another concern is that the 136 WHOIS services which are being operated today offer no means of 137 client authentication, requiring that server operators essentially 138 publish all data with a single "world-readable" permission. 139 However, this single permission conflicts with the privacy and 140 security policies of specific jurisdictions. 142 There are many other secondary issues with the WHOIS service as it 143 exists in current form. However, the largest problems are a lack 144 of standardized data formats, a lack of widely-supported referral 145 mechanisms, and a lack of privacy and security controls, as 146 described in the preceding text. 148 FIRS attempts to address these issues by defining guidelines for 149 the operation of a distributed and highly-structured WHOIS-like 150 service, using LDAPv3 for the query/response transfer service, and 151 using LDAP schema for the search inputs, answer data, and 152 redirection mechanisms. In short, the intention of this approach 153 is to provide an extensible and scalable WHOIS-like service, by 154 leveraging the inherent capabilities of LDAPv3. 156 1.2. Overview 157 The FIRS collection of specifications cumulatively define a 158 structured and distributed information service, including an 159 extensible framework and resource-specific definitions. The 160 framework defined in this document is intended to accommodate a 161 variety of different resource-types and usages, while the other 162 specifications define the technical details for the service as a 163 whole or for the different resource-types. 165 Cumulatively, the FIRS collection of specifications define the 166 following service elements: 168 * Namespace Rules. The FIRS specifications define a layered 169 namespace consisting of DNS-based delegation hierarchies, a 170 FIRS-specific container entry, and resource-specific 171 subordinate entries. 173 * Schema Definitions. The FIRS specifications reuse some 174 existing LDAP schema definitions, and also define several 175 FIRS-specific definitions, as needed. 177 * The FIRS specifications also reuse some existing processing 178 rules, and define several additional rules as needed. Among 179 these rules are requirements for normalizing data, locating 180 servers, processing referrals, and more. 182 Some of these rules apply to the architecture as a whole, while 183 other rules apply to specific kinds of Internet resources. 185 2. Prerequisites and Terminology 186 The complete set of specifications in the FIRS collection 187 cumulative define a structured and distributed information service 188 using LDAPv3 for the data-formatting and transport functions. This 189 specification should be read in the context of the complete set of 190 specifications, which currently include the following: 192 draft-ietf-crisp-firs-arch-00, "The Federated Internet 193 Registry Service: Architecture and Implementation" (this 194 document) [FIRS-ARCH] 196 draft-ietf-crisp-firs-core-00, "The Federated Internet 197 Registry Service: Core Elements" [FIRS-CORE] 199 draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS 200 Domains in the Federated Internet Registry Service" 201 [FIRS-DNS] 203 draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS 204 Resource Records in the Federated Internet Registry 205 Service" [FIRS-DNSRR] 207 draft-ietf-crisp-firs-contact-00, "Defining and Locating 208 Contact Persons in the Federated Internet Registry Service" 209 [FIRS-CONTCT] 211 draft-ietf-crisp-firs-asn-00, "Defining and Locating 212 Autonomous System Numbers in the Federated Internet 213 Registry Service" [FIRS-ASN] 215 draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 216 Address Blocks in the Federated Internet Registry Service" 217 [FIRS-IPV4] 219 draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 220 Address Blocks in the Federated Internet Registry Service" 221 [FIRS-IPV6] 222 The FIRS service reuses, unites and clarifies several pre-existing 223 technologies. In order to fully understand FIRS, readers should be 224 familiar with the following technologies and specifications: 226 RFC 2247, "Using Domains in LDAP/X.500 DNs" [RFC2247] 228 RFC 2251, "Lightweight Directory Access Protocol (v3)" 229 [RFC2251] 231 RFC 2252, "Lightweight Directory Access Protocol (v3): 232 Attribute Syntax Definitions" [RFC2252] 234 RFC 2254, "The String Representation of LDAP Search 235 Filters" [RFC2254] 237 RFC 2256, "A Summary of the X.500(96) User Schema for use 238 with LDAPv3" [RFC2256] 240 RFC 2798, "Definition of the inetOrgPerson LDAP Object 241 Class" [RFC2798] 243 RFC 3296, "Named Subordinate References in Lightweight 244 Directory Access Protocol (LDAP) Directories" [RFC3296] 246 RFC 3377, "Lightweight Directory Access Protocol (v3): 247 Technical Specification" [RFC3377] 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 250 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 251 in this document are to be interpreted as described in RFC 2119. 253 2.1. Reference Example 254 Figure 1 below shows an example of a FIRS-specific data-set. This 255 example is referenced throughout this specification. 257 dc=example,dc=com 258 | 259 +-cn=inetResources,dc=example,dc=com 260 [top object class] 261 [inetResources object class] 262 | 263 +-attribute: inetGeneralContacts 264 | value: "admins@example.com" 265 | 266 +-cn=admins@example.com,cn=inetResources,dc=example,dc=com 267 | [top object class] 268 | [inetResources object class] 269 | [inetOrgPerson object class] 270 | | 271 | +-attribute: mail 272 | value: "admins@example.com" 273 | 274 +-cn=example.com,cn=inetResources,dc=example,dc=com 275 | [top object class] 276 | [inetResources object class] 277 | [inetDnsDomain object class] 278 | | 279 | +-attribute: inetDnsAuthServers 280 | value: "ns1.example.net" 281 | 282 +-cn=www.example.com,cn=inetResources,dc=example,dc=com 283 [top object class] 284 [inetResources object class] 285 [inetDnsDomain object class] 286 [referral object class] 287 | 288 +-attribute: inetTechContacts 289 | value: "admins@example.com" 290 | 291 +-attribute: ref 292 value: "ldap://firs.example.net/cn=inetResources, 293 dc=example,dc=net"??? 294 (1.3.6.1.4.1.7161.1.1.8:=host.example.net)" 296 Figure 1: The FIRS-specific data for Example Widgets. 298 As can be seen in Figure 1, the entries use a FIRS-specific 299 namespace in conjunction with FIRS-specific schema, which clients 300 can use to generate FIRS-specific queries. 302 3. The FIRS Namespace 303 A critical aspect of FIRS is the use of an application-specific 304 namespace which is imposed on all FIRS-based resources. 306 The FIRS namespace rules facilitate the programmatic creation of 307 lookups and searches, and ensure predictable results. The use of a 308 private namespace also help to segregate FIRS-related data from 309 other kinds of data which may reside on any participating server. 311 The FIRS namespace consists of three "layers", which are: 313 * A set of domainComponent relative distinguished names which 314 cumulatively identify a specific partition of the global 315 directory tree. 317 * A FIRS-specific entry which acts as a container for all of 318 the FIRS-related resource-specific child entries. 320 * The resource-specific child entries which collectively 321 contain detailed information about the resources under the 322 control of the selected partition. 324 The namespace follows a right-to-left order. 326 As an example, Figure 1 shows an DNS domain resource entry named 327 "cn=example.com,cn=inetResources,dc=example,dc=com", which refers 328 to the "example.com" domain resource within the "cn=inetResources" 329 container under the "dc=example,dc=com" directory partition. 331 3.1. The domainComponent Hierarchy 332 The top-level of the namespace uses the domainComponent naming and 333 mapping rules specified in RFC 2247 [RFC2247], which maps DNS 334 domain names to domainComponent ("dc=") relative distinguished 335 names (RDNs). The full sequence of domainComponent RDNs map to an 336 equivalent scope of authority in the DNS namespace, and 337 cumulatively represent the root of a partition of the global LDAP 338 directory space. For example, Figure 1 shows the directory 339 partition of "dc=example,dc=com" which maps to the "example.com" 340 scope of authority from the DNS hierarchy. 342 3.2. The inetResources Container 343 This specification requires the use of a mandatory LDAP container 344 entry with the RDN of "cn=inetResources", which MUST exist at the 345 root of every directory database that provides FIRS services. All 346 publically-accessible resource-specific entries MUST be stored in 347 the cn=inetResources container entry. 349 The primary motivation for this naming rule is for predictability, 350 in that it allows searches to be formed programmatically (a search 351 base for resources in "dc=example,dc=com" can be programmatically 352 formed as "cn=inetResources,dc=example,dc=com", for example). 353 Furthermore, the use of a single container entry for all of an 354 organization's Internet resources allows that branch of the 355 directory database to be managed independently of other entries on 356 the server, which facilitates better operational security, and 357 also allows for the outsourcing of a FIRS container through the 358 use a single referral. 360 All told, the use of the inetResources container is important 361 enough to justify the MANDATORY usage of this naming syntax. 363 3.3. Resource-Specific Entries 364 The FIRS collection of specifications define several Internet 365 resource types, each of which have their own naming rules. 366 However, each resource type follows a consistent naming principle, 367 in that each specific resource has an RDN which uniquely 368 identifies that resource within the inetResources container entry. 370 For example, Figure 1 shows an entry for the "www.example.com" 371 domain name resource stored in the "dc=example,dc=com" directory 372 context, with a fully-qualified distinguished name (FQDN) of 373 "cn=www.example.com,cn=inetResources,dc=example,dc=com", and also 374 shows an entry for the "admins@example.com" contact resource with 375 the FQDN "admins@example.com,cn=inetResources,dc=example,dc=com". 376 Although the relative naming syntax is different for each resource 377 type, the syntax is consistent and predictable. 379 The naming rules for each of the distinct resource type are 380 provided in the documents which govern those resource types. 382 3.4. Namespace Aliases 383 FIRS allows entries to alias for other entries through the use of 384 referrals. In this model, an entry exists which will match against 385 searches for the queried data, but the attributes associated with 386 that entry indicate that some other entry should also be queried. 388 Referrals represent one of the strongest capabilities of the FIRS 389 architecture, in that they allow for a significant variety of 390 cross-referencing among entries. For example, referrals can be 391 used to point an inetResources container entry in one partition to 392 another inetResources container entry in another partition, 393 allowing multiple partitions to effectively share a single 394 partition (this is useful when organizations manage multiple 395 networks or domains, and wish to consolidate their management). As 396 another example, referrals can also be used to create placeholder 397 entries for specific resources (such as a web server) which only 398 exist as referrals for resources which are managed in other 399 partitions (such as a web-hosting server at an ISP), with both 400 entries providing information about that resource. 402 This latter example can be seen in Figure 1, which shows an entry 403 for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which 404 provides a referral to the "cn=host.example.net" entry at 405 "cn=inetResources,dc=example,dc=net". Queries for the local entry 406 would be answered with the locally-available information and then 407 redirected to the referral target where additional information 408 could be retrieved. 410 FIRS supports two different kinds of referrals, which are 411 subordinate reference referrals and continuation reference 412 referrals. Subordinate reference referrals indicate that the 413 search base used in the query only exists as an alias to another 414 partition or entry, meaning that the entire query must be 415 restarted in order for any answer data to be retrieved. Meanwhile, 416 continuation reference referrals indicate that some answer data is 417 available, but that more information is available at some other 418 location, and that the client should start new queries in order to 419 retrieve all of the information. 421 Referrals are provided as URLs. FIRS specifically requires the use 422 of LDAP URLs in order to ensure predictable automated processing. 423 Refer to section 5.4.1 for a brief discussion on how these URLs 424 are processed by FIRS clients. 426 4. FIRS Schema Definitions 427 Another critical aspect of FIRS is the use of well-known schema, 428 including object classes, attributes, syntaxes and matching 429 filters. Some of the schema definitions are for the global FIRS 430 service (and are usable by all entries, including resource- 431 specific entries), while others are specific to particular 432 resource-types. Where suitable pre-existing schema definitions are 433 available, they are reused to facilitate integration with other 434 LDAP applications. 436 4.1. Global Schema Definitions 437 There are three global schema definitions which can be used by any 438 of the entries within the FIRS database. These include: 440 * The "inetResources" master schema. All FIRS-related entries 441 (including the inetResources container entry and all of the 442 resource-specific subordinate entries) MUST use the 443 inetResources structural object class and schema 444 definitions defined in [FIRS-CORE]. The inetResources 445 object class defines a variety of optional general-purpose 446 attributes which are useful for describing an organization 447 or the resources under its control. 449 * Associated resources. All FIRS-related entries MAY use the 450 "inetAssociatedResources" auxiliary object class and schema 451 definitions defined in [FIRS-CORE]. This object class 452 provides cross-reference pointer attributes which allow an 453 entry to reference other entries which may be of interest 454 to the user. 456 * Referral pointers. All FIRS-related entries MAY use the 457 "referral" object class and schema definitions defined in 458 [RFC3296]. This object class allows an entry to exist as a 459 referral source, with queries for that resource being 460 redirected to the referral target. Refer to section 5.4.1 461 for a discussion on the different kinds of referral and 462 reference mechanisms offered by FIRS. 464 Figure 1 shows that all of the entries within and including the 465 "cn=inetResources" container entry have the inetResources object 466 class defined, and that the "cn=www.example.com" resource-specific 467 entry also has the referral object class defined. Each of the 468 resource-specific entries in that example also have their own 469 resource-specific object classes. 471 4.2. Resource-Specific Schema Definitions 472 In addition to the global schema definitions, each of the 473 resource-specific entry in FIRS MUST use the resource-specific 474 schema definitions defined for use with that specific resource 475 type. These object classes are defined in the specifications which 476 govern the different resource-types. These include: 478 * DNS domains. Every domain name resource entry MUST use the 479 inetDnsDomain object class and schema definitions defined 480 in [FIRS-DNS]. These entries can refer to sub-domain 481 delegations, host-specific entries, reverse-lookup entries, 482 or any other domain name resource, as needed. 484 * DNS resource-records. Any domain name resource MAY use the 485 inetDnsRR object class and schema definitions defined in 486 [FIRS-DNSRR]. The inetDnsRR object class defines a single 487 optional attribute for storing multiple DNS resource 488 records as supplemental data to a domain name entry. 490 * IPv4 address blocks. Every IPv4 network block entry MUST 491 use the inetIpv4Network object class and schema definitions 492 defined in [FIRS-IPV4]. Entries can refer to entire network 493 blocks or single hosts, as needed. 495 * IPv6 address blocks. Every IPv6 network block entry MUST 496 use the inetIpv6Network object class and schema definitions 497 defined in [FIRS-IPV6]. Entries can refer to entire network 498 blocks or single hosts, as needed. 500 * Autonomous system numbers. Every autonomous system number 501 entry MUST use the inetAsNumber object class and schema 502 definitions defined in [FIRS-ASN]. 504 * Contacts. Every contact entry MUST use the inetOrgPerson 505 object class defined in [RFC2798], as well as the schema 506 definitions defined in [FIRS-CONTCT]. 508 As was discussed in section 4.1, each resource-specific entry MAY 509 exist as a referral source, or MAY have attributes which refer to 510 additional (related) entries. 512 5. Query Processing Behaviors 513 Another critical aspect to FIRS is the query-processing behavior. 514 These rules govern the ways in which a client parses a query, 515 locates a server which is authoritative for the resource being 516 queried, generates LDAPv3 queries, and processes any resulting 517 referrals. More specifically: 519 * Query pre-processing. The first step is for the client to 520 prepare the query. Portions of this process require the 521 client to determine the type of resource being queried for, 522 and to determine the initial partition which should be used 523 for the query. Since this process is different for each 524 particular resource-type, the rules which govern this 525 behavior are defined in each of the resource-specific 526 specifications. 528 * Bootstrap processing. Once a partition has been determined, 529 the client must locate the LDAP servers which are 530 authoritative for the resource in question. [FIRS-CORE] 531 defines three different bootstrap models that clients can 532 use as part of this process, while each of the resource- 533 specific specifications define which of the models are to 534 be used for each particular resource-type. 536 * Query processing. Once a server has been located, the 537 client must submit the LDAP query which was formed during 538 the pre-preprocessing phase. [FIRS-CORE] defines certain 539 LDAPv3 query parameters which all FIRS clients MUST conform 540 with, while the resource-specific specifications may also 541 define additional parameters. 543 * Query post-processing. FIRS explicitly supports several 544 different types of LDAP referral and redirection 545 mechanisms, any of which may result in the client 546 application restarting the query or initiating a brand-new 547 query. These mechanisms and their behavioral rules are 548 defined in [FIRS-CORE]. 550 Each of these phases are discussed in more detail below. 552 5.1. Query Pre-Processing 553 Client input is generally provided as a single well-formed unit of 554 data, such as a domain name ("example.com") or an email address 555 ("admins@example.com"). Since this information is typically all 556 that's provided, it must be used to subsequently build a fully- 557 formed LDAPv3 query, including the assertion value, the search 558 base, the matching filter, and so forth. All of these steps are 559 part of the pre-processing phase. 561 Although the exact sequence of steps will vary according to the 562 resource-type being queried, there are some commonalities between 563 each of them. Among these steps: 565 * Determine the resource type. Different kinds of resources 566 have different processing steps, validation mechanisms, and 567 so forth, each of which require that the resource-type be 568 appropriately identified. Clients MAY use any mechanisms 569 necessary to force this determination. 571 * Validate and normalize the data. In all cases, the input 572 data MUST be validated and normalized according to the 573 syntax rules defined in the specification which governs the 574 resource-type. As an example of this step, queries for 575 internationalized domain names must be normalized into a 576 UTF-8 form before any other steps can be taken, with the 577 domain name being validated as part of the normalization 578 process. Similarly, IPv6 addresses are required to conform 579 to specific syntax rules, and input address may need to be 580 expanded or compressed in order to comply these syntax 581 requirements. 583 * Determine the appropriate directory partition for the 584 query. Different kinds of resources have different default 585 choices. In most cases, the appropriate partition will be a 586 variation of the input query string, but this is not always 587 the case. For example, the default partition for an email 588 address will be the domain component of the email address 589 itself, while the default partition for an ASN is a 590 reserved (special-purpose) domain name. In some cases, the 591 selected partition may change as a result of errors or 592 referrals encountered during later phases of the process. 594 * Determine the search base for the query. In most cases, the 595 search base will refer to the inetResources container entry 596 within the partition which was determined in the prior 597 step, with these elements being combined into an FQDN. In 598 some cases, the search base may need to be changed as a 599 result of referrals encountered during later phases of the 600 process. 602 * Determine the assertion value for the query. The assertion 603 value will usually be the normalized form of the input 604 query. In some cases, the assertion value may need to be 605 changed as a result of referrals encountered during later 606 phases of the process. 608 * Determine the matching filter. Each resource-type has its 609 own matching filter rules. In some cases, the matching 610 filter will be a simple equalityMatch comparison, while in 611 other cases the matching filter will be an extensibleMatch 612 which is peculiar to the resource-type in use. 614 Once all of the pre-processing steps have been successfully 615 completed, the client must attempt to locate an LDAPv3 server 616 which is authoritative for that resource. This process is 617 described in section 5.2 below. 619 5.2. Bootstrap Processing 620 The bootstrap process uses DNS queries for SRV resource records 621 associated with the selected directory partition. However, since 622 different kinds of resources are managed through different 623 delegation models, there are also different bootstrap models which 624 have to be used to perform this process. 626 FIRS supports three different bootstrap models, which are: 628 * Targeted. The "targeted" bootstrap model has the client 629 attempting to locate the LDAP servers associated with a 630 absolute domain name, such as a domain name which may be 631 returned as referrals or URLs. If no servers can be found, 632 the client exits the query. 634 * Top-down. The "top-down" bootstrap model has the client 635 attempting to locate the LDAP servers associated with a 636 top-level domain (such as trying to locate the LDAP servers 637 associated with the "com" domain for an original query of 638 "www.example.com"). If no servers can be found for the top- 639 level domain, the client exits the query. 641 * Bottom-up. The "bottom-up" bootstrap model has the client 642 attempting to locate the LDAP servers associated with the 643 leaf-node domain (such as trying to locate any LDAP servers 644 associated with the "www.example.com" domain specifically). 645 If no servers can be found for that domain name, the 646 directory partition is reset to its immediate parent and 647 the DNS query is resubmitted with that new scope. This 648 process continues until no more domains can be trimmed. 650 Each of the models are appropriate to different usages. For 651 example, The targeted model is most useful with pointer data 652 gleaned through URLs and other fixed sources, where the data is 653 presumed to exist at a pre-determined location. Meanwhile, the 654 top-down model is best suited for searches about global resources 655 which are centrally managed and delegated (such as IP addresses 656 and DNS domains), and where centrally-managed delegation 657 information is critical. Finally, the bottom-up model is most 658 appropriate for those resources which are managed by the end-users 659 directly (such as contact information, DNS resource records, and 660 so forth), and which are not typically managed from a centralized 661 delegation authority. 663 Once the bootstrap process has resulted in an authoritative LDAP 664 server being located for the partition in question, the remainder 665 of the query process is consistent. 667 5.3. Query Processing 668 Once an LDAP server has been located, the LDAPv3 query is 669 submitted to that server. 671 Most of the values for the query will have been collected during 672 the pre-processing phase, although [FIRS-CORE] defines some rules 673 which govern all queries. For example, [FIRS-CORE] specifies a 674 maximum time limit of 60 seconds for all queries in order to 675 prevent runaway searches which match all entries. 677 [FIRS-CORE] also allows for authentication and access controls, in 678 that FIRS servers are allowed to limit the depth and breadth of 679 information that they provide to a specific client based on the 680 level of authenticated access. 682 Another consideration which can arise during this phase of the 683 process is protocol and schema versioning considerations. These 684 mechanisms are already existent in the LDAPv3 specifications, and 685 their usage is encouraged by [FIRS-CORE]. 687 5.4. Query Post-Processing 688 Once a query has been submitted and processed, the server should 689 return answer data or some kind of referral, or possibly both. In 690 general, FIRS clients are expected to display all of the answer 691 data and process all of the referrals, although there are specific 692 considerations which must be taken into account. In particular, 693 there are considerations for handling the different kinds of 694 referrals, and there are localizations issues for specific kinds 695 of attribute data. 697 5.4.1. Referrals 698 As was discussed in section 3.4, there are two kinds of referral 699 mechanisms which are used with FIRS, which are subordinate 700 reference referrals and continuation reference referrals. More 701 specifically: 703 * Subordinate reference referrals. Subordinate reference 704 referrals are returned when the search base specified in a 705 query exists as a referral to some other entry. This 706 condition means that the current search operation cannot 707 proceed, and that the search MUST be restarted. Any of the 708 FIRS-specific entries MAY be defined as subordinate 709 reference referrals, although they are typically only used 710 when the inetResources container entry in a partition is an 711 alias for an inetResources container entry in another 712 partition. Subordinate reference referrals and their schema 713 are defined in RFC 3296 [RFC3296] although there are 714 additional restrictions placed on their usage as described 715 in [FIRS-CORE]. 717 * Continuation reference referrals. Continuation reference 718 referrals are returned when a search operation has been 719 successfully processed by the queried server, but the 720 answer data also includes referrals to other entries. These 721 referrals are often provided as supplemental data to an 722 answer set, although this is not required (a continuation 723 reference referral can be the only response, but it won't 724 be the only response in the common case). This condition 725 means that the current search operation has partially 726 succeeded, but that additional searches SHOULD be started 727 in order for all of the answer data to be. Continuation 728 reference referrals and their schema are also defined in 729 [RFC3296], with additional restrictions placed on their 730 usage as described in [FIRS-CORE]. 732 Whenever a referral is received in response to a query, the client 733 MUST display any answer data which has been received and then 734 process the referral. As part of this process, the client MUST 735 parse the URL for the host identifier, port number, search base, 736 and assertion value (if these are provided), and then construct 737 and issue new queries using these values. 739 Note that RFC 2251 [RFC2251] defines a superior reference referral 740 which is used as a "default referral" for out-of-scope searches. 741 However, FIRS specifically excludes support for superior reference 742 referrals. Any superior reference referrals which are encountered 743 as part of this service are to be treated as errors. 745 5.4.2. Internationalization and localization 746 The FIRS model uses the internationalization and localization 747 services provided by LDAPv3. In this regard, FIRS clients do not 748 need to implement any special services in order to process and 749 display internationalized attribute data if those attribute types 750 already provide direct support for internationalized data. 751 However, there are several instances where this is not the case. 753 The areas where specific considerations have been made to fully 754 accommodate internationalization and localization concerns are 755 described below. 757 * The domainComponent attribute is restricted to [US-ASCII]. 758 This is problematic with internationalized domain names and 759 their use in directory information trees, search bases, and 760 so forth. In order to ensure interoperability, this 761 specification requires all DNS domain names which are 762 mapped to domainComponent attributes to be normalized and 763 reduced to their ASCII-compatible form using the "ToASCII" 764 process defined in [RFC3490] before these sequences are 765 stored in the directory or used in LDAPv3 messages. 767 * DNS is technically capable of storing eight-bit codepoint 768 values, although the operational rules which govern DNS do 769 not support this usage. As a result, internationalized 770 domain names which are used for SRV or A resource record 771 lookups MUST be normalized and reduced to their ASCII- 772 compatible form using the "ToASCII" process defined in 773 [RFC3490] before these queries are issued. 775 * Some URLs may need to be escaped in order to accommodate 776 internationalized strings (the rules and requirements for 777 this process are defined in the specifications which govern 778 each kind of URL). 780 * RFC 2277 [RFC2277] requires that free-text data must be 781 accompanied with language tags. RFC 2596 [RFC2596] defines 782 a mechanism for storing language tags and language-specific 783 attribute values, and these mechanisms SHOULD be supported 784 by FIRS clients and servers. For example, an organization 785 name could be provided in English and Arabic, with the 786 language tags allowing the client application to view the 787 appropriate attribute value instance, if both the client 788 and the server support the mechanisms defined in RFC 2596. 789 Note that attribute values which contain structured data 790 (even if there is no structure in LDAP) do not necessarily 791 benefit from language tags. Examples of the latter include 792 the labeledURI and mail attributes, which do not typically 793 have multiple linguistic representations. 795 * Time and date strings usually use the generalizedTime 796 syntax, making them predictable. Dates MAY be localized for 797 display purposes by client applications as necessary. 799 * Attribute names are static and well-known, and are 800 therefore easily localized. As such, clients MAY choose to 801 convert attribute names in a language appropriate to the 802 local user for display purposes where it is safe to do so. 803 However, clients MUST NOT localize attribute names which 804 are used for query input. Specific examples of the latter 805 would be converting "cn=" or "dc=" relative distinguished 806 labels into some other language. 808 * International postal regulations generally require that the 809 recipient address be provided in a language and charset 810 which is native to the recipient's country, with the 811 exception of the destination country code which should be 812 provided in a language and charset that is native to the 813 sender's country (this allows the sender's post office to 814 route the mail to the recipient's country, while allowing 815 the destination country to perform local delivery). In 816 order to facilitate this usage, the country attribute value 817 MAY (encouraged) be localized to the local user's 818 nomenclature for a country, but other postal address 819 information SHOULD NOT be localized. 821 6. Transition Issues 822 There are a handful of areas where the proposed service does not 823 fully match with all of the existing WHOIS service offerings. 824 These areas are discussed in more detail below. 826 6.1. NIC Handles 827 Legacy NIC handles in existing databases can be accommodated using 828 two possible mechanisms: 830 * NIC handle output in legacy WHOIS systems may be replaced 831 with email addresses for the contacts. This option 832 facilitates faster coalescence around the FIRS system. 834 * NIC handles can be converted into locally-scoped email 835 addresses. For example, the NIC handle of EH26 on Network 836 Solutions' WHOIS server could be replaced with the locally- 837 scoped email address of "ehall@whois.netsol.com" or some 838 variation thereof. 840 Of the two mechanisms described above, the former is preferred. 842 6.2. Change-Logs 843 Several WHOIS services provide pseudo change-logs in their 844 response data, listing each unique modification event which has 845 occurred for a particular resource. For example, RIPE and some of 846 its member ccTLDs provide WHOIS output which includes a series of 847 "changed" fields that itemize every modification event ("updated", 848 "added", etc.), the modifier, and the modification date, which 849 cumulatively act as a change-log for the resource in question. 851 Organizations are certainly free to maintain this information on 852 their internal systems (and are even encouraged to do so). 853 However, this information is not necessary for public view of the 854 data in the FIRS service. Where the auditing information will be 855 required, a format which is more suitable to legal review will 856 also be required. 858 Organizations who wish to publish change-log information should 859 develop a common schema for this purpose. An initial demonstration 860 schema has been developed by the author and is available at 861 http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt 863 7. Security Considerations 864 The FIRS collection of specifications describe an application of 865 the LDAPv3 protocol, and as such it inherits the security 866 considerations associated with LDAPv3, as described in section 7 867 of [RFC2251]. 869 By nature, LDAP is a read-write protocol, while the legacy WHOIS 870 service has always been a read-only service. As such, there are 871 significant risks associated with allowing unintended updates by 872 unauthorized third-parties. Moreover, allowing the FIRS service to 873 update the underlying delegation databases could result in network 874 resources being stolen from their lawful operators. For example, 875 if the LDAP front-end had update access to a domain delegation 876 database, a malicious third-party could theoretically take 877 ownership of that domain by exploiting an authentication weakness, 878 thereby causing ownership of the domain to be changed to another 879 party. For this reason, it is imperative that the FIRS service not 880 be allowed to make critical modifications to delegated resources 881 without ensuring that all possible precautions have been taken. 883 The query processing models described in this document make use of 884 DNS lookups in order to locate the LDAP servers associated with a 885 particular resource. DNS is susceptible to certain attacks and 886 forgeries which may be used to redirect clients to LDAP servers 887 which are not authoritative for the resource in question. 889 This document provides multiple query models which will cause the 890 same query to be answered by different servers (one would be 891 processed by a delegation entity, while another would be processed 892 by an operational entity). As a result, each of the servers may 893 provide different information, depending upon the query type that 894 was originally selected. 896 Some operators may choose to purposefully provide misleading or 897 erroneous information in an effort to avoid responsibility for bad 898 behavior. In addition, there are likely to be sporadic operator 899 errors which will result in confusing or erroneous answers. 901 Neither this specification nor the LDAPv3 protocol currently 902 provide cache timers or any other mechanisms which can indicate 903 how accurate or timely any replicas may be. As a result, it is 904 possible for a replica to become significantly outdated, even to 905 the point of containing wholesale errors. 907 For all of the reasons listed above, it is essential that 908 applications and end-users not make critical decisions based on 909 the information provided by the FIRS service without having reason 910 to believe the veracity of the information. Users should limit 911 unknown or untrusted information to routine purposes. 913 Despite these disclaimers, however, it is very likely that the 914 information presented through the FIRS service will be used for 915 many operational and problem-resolution purposes. In order to 916 ensure the veracity of the information, a minimal set of 917 operational guidelines are provided herein. For the most part, 918 these rules are designed to prevent unauthorized modifications to 919 the data. 921 Note that these rules only apply to data which is willingly 922 provided; no data is required to be entered, but where the data is 923 provided, it SHOULD be validated as accurate on entry, and it MUST 924 be secured against unauthorized modifications. 926 * The inetResources container entry and all of the resource- 927 specific subordinate entries within every public DIT that 928 provides FIRS resources SHOULD have anonymous read-only 929 access permissions, and SHOULD NOT have anonymous add, 930 delete or modify permissions. 932 * With the exception of contact-related attributes from the 933 inetOrgPerson object class, each attribute MAY have 934 whatever restrictions are necessary in order to suit local 935 security policies, government regulations or personal 936 privacy concerns. When the inetOrgPerson object class is 937 used to provide contact details, the mail attribute MUST be 938 defined, SHOULD be valid, SHOULD have read-only anonymous 939 access, and SHOULD NOT have anonymous add, delete or modify 940 permissions. 942 By using the inetOrgPerson object class, it is expected 943 that existing contact-related entries can be reused. If 944 reusing these entries is undesirable or unfeasible, entries 945 with the necessary access SHOULD be made available. 947 Note that contact pointers are entirely optional and are 948 not required to exist. However, where they exist, they MUST 949 comply with the above requirements. 951 * End-users and implementers SHOULD provide anonymous access 952 to the creatorsName, createTimestamp, modifiersName and 953 modifyTimestamp operational attributes associated with each 954 entry in the inetResources branch, since this information 955 is useful for determining the age of the information. 957 * Server administrators MAY define additional add, delete or 958 modify permissions for authenticated users, using any 959 LDAPv3 authentication mechanisms they wish. In particular, 960 delegation entities MAY provide for the remote management 961 of delegated resources (such as assigning modification 962 privileges to the managers of a particular delegated domain 963 or address block), although this is entirely optional, and 964 is within the sole discretion of the delegation body. 966 Finally, there are physical security issues associated with any 967 service which provides physical addressing and delivery 968 information. Although organizations are generally encouraged to 969 provide as much information as they feel comfortable with, no 970 information is required. 972 8. IANA Considerations 973 The FIRS collection of specifications define an application of the 974 LDAPv3 protocol rather than a new Internet application protocol. 975 As such, there are no protocol-related IANA considerations. 977 However, the FIRS collection of specifications do define several 978 LDAP schema elements, including object classes, attributes, 979 syntaxes and extensibleMatch filters, and these elements should be 980 assigned OID values from the IANA branch. Furthermore, some of the 981 specifications define their own status codes as attribute values, 982 and IANA is expected to maintain the code-point mapping values 983 associated with these attributes. 985 Finally, some of the specifications also describe public DNS and 986 LDAP data (including SRV resource records and LDAPv3 referrals). 987 It is expected that IANA will see to the establishment and 988 maintenance of these servers and data. 990 9. Author's Address 991 Eric A. Hall 992 ehall@ehsco.com 994 10. Normative References 995 [RFC1274] Barker, P., and Kille, S. "The COSINE and 996 Internet X.500 Schema", RFC 1274, November 997 1991. 999 [RFC2079] Smith, M. "Definition of an X.500 Attribute 1000 Type and an Object Class to Hold Uniform 1001 Resource Identifiers (URIs)", RFC 2079, 1002 January 1997. 1004 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 1005 and Sataluri, S. "Using Domains in LDAP/X.500 1006 DNs", RFC 2247, January 1998. 1008 [RFC2251] Wahl, M., Howes, T., and Kille, S. 1009 "Lightweight Directory Access Protocol (v3)", 1010 RFC 2251, December 1997. 1012 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 1013 S. "Lightweight Directory Access Protocol 1014 (v3): Attribute Syntax Definitions", RFC 2252, 1015 December 1997. 1017 [RFC2253] Wahl, M., Kille, S., and Howes, T. 1018 "Lightweight Directory Access Protocol (v3): 1019 UTF-8 String Representation of DNs", RFC 2253, 1020 December 1997. 1022 [RFC2254] Howes, T. "The String Representation of LDAP 1023 Search Filters", RFC 2254, December 1997. 1025 [RFC2255] Howes, T., and Smith, M. "The LDAP URL 1026 Format", RFC 2255, December 1997. 1028 [RFC2256] Wahl, M. "A Summary of the X.500(96) User 1029 Schema for use with LDAPv3", RFC 2256, 1030 December 1997. 1032 [RFC2277] Alvestrand, H. "IETF Policy on Character Sets 1033 and Languages", BCP 18, RFC 2277, January 1034 1998. 1036 [RFC2308] Andrews, M. "Negative Caching of DNS Queries 1037 (DNS NCACHE)", RFC 2308, March 1998. 1039 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 1040 in LDAP", RFC 2596, May 1999. 1042 [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A 1043 DNS RR for specifying the location of services 1044 (DNS SRV)", RFC 2782, February 2000. 1046 [RFC2798] Smith, M. "Definition of the inetOrgPerson 1047 LDAP Object Class", RFC 2798, April 2000. 1049 [RFC3296] Zeilenga, K. "Named Subordinate References in 1050 Lightweight Directory Access Protocol (LDAP) 1051 Directories", RFC 3296, July 2002. 1053 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 1054 Directory Access Protocol (v3): Technical 1055 Specification", RFC 3377, September 2002. 1057 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 1058 "Internationalizing Domain Names in 1059 Applications (IDNA)", RFC 3490, March 2003. 1061 [CRISP-REQ] Newton, A. "Cross Registry Internet Service 1062 Protocol (CRISP) Requirements", draft-ietf- 1063 crisp-requirements-05, May 2003. 1065 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 1066 Service: Architecture and Implementation 1067 Guide", draft-ietf-crisp-firs-arch-00, May 1068 2003. 1070 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 1071 System Numbers in the Federated Internet 1072 Registry Service", draft-ietf-crisp-firs-asn- 1073 00, May 2003. 1075 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 1076 Persons in the Federated Internet Registry 1077 Service", draft-ietf-crisp-firs-contact-00, 1078 May 2003. 1080 [FIRS-CORE] Hall, E. "The Federated Internet Registry 1081 Service: Core Elements", draft-ietf-crisp- 1082 firs-core-00, May 2003. 1084 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 1085 the Federated Internet Registry Service", 1086 draft-ietf-crisp-firs-dns-00, May 2003. 1088 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 1089 Records in the Federated Internet Registry 1090 Service", draft-ietf-crisp-firs-dnsrr-00, May 1091 2003. 1093 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 1094 Blocks in the Federated Internet Registry 1095 Service", draft-ietf-crisp-firs-ipv4-00, May 1096 2003. 1098 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 1099 Blocks in the Federated Internet Registry 1100 Service", draft-ietf-crisp-firs-ipv6-00, May 1101 2003. 1103 [US-ASCII] Cerf, V. "ASCII format for Network 1104 Interchange", RFC 20, October 1969. 1106 11. Informational References 1107 [RFC812] Harrenstien, K., and White, V. 1108 "NICNAME/WHOIS", RFC 812, March 1982. 1110 12. Acknowledgments 1111 Funding for the RFC editor function is currently provided by the 1112 Internet Society. 1114 Portions of this document were funded by Verisign Labs. 1116 The first version of this specification was co-authored by Andrew 1117 Newton of Verisign Labs, and subsequent versions continue to be 1118 developed with his active participation. 1120 13. Changes from Previous Versions 1121 draft-ietf-crisp-fir-arch-00: 1123 * Restructured document set, separating the architectural 1124 discussion from the technical descriptions. 1126 * Consolidated the security discussions. 1128 draft-ietf-crisp-lw-core-00: 1130 * As a result of the formation of the CRISP working group, 1131 the original monolithic document has been broken into 1132 multiple documents, with draft-ietf-crisp-lw-core 1133 describing the core service, while related documents 1134 describe the per-resource schema and access mechanisms. 1136 * References to the ldaps: URL scheme have been removed, 1137 since there is no standards-track specification for the 1138 ldaps: scheme. 1140 * An acknowledgements section was added. 1142 draft-hall-FIRS-01: 1144 * The �Objectives� section has been removed. [ir-dir-req] is 1145 now being used as the guiding document for this service. 1147 * Several typographical errors have been fixed. 1149 * Some unnecessary text has been removed. 1151 * Figures changed to show complete sets of object classes, to 1152 improve inheritance visibility. 1154 * Clarified the handling of reverse-lookup domains (zones 1155 within the in-addr.arpa portion of the DNS hierarchy) in 1156 the inetDnsDomain object class reference text. 1158 * Referrals now use regular LDAP URLs (multiple responses 1159 with explicit hostnames and port numbers). Prior editions 1160 of this specification used LDAP SRV resource records for 1161 all referrals. 1163 * The delegation status codes used by the 1164 inetDnsDelegationStatus, inetIpv4DelegationStatus, 1165 inetIpv6DelegationStatus and inetAsnDelegationStatus 1166 attributes have been condensed to a more logical set. 1168 * Added an inetDnsAuthServers attribute for publishing the 1169 authoritative DNS servers associated with a domain. NOTE 1170 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 1171 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 1172 ATTRIBUTES. 1174 * Added an inetGeneralDisclaimer attribute for publishing 1175 generalized disclaimers. 1177 * Added the inetAssociatedResources auxiliary object class 1178 for defining associated resources, and moved some of the IP 1179 addressing and ASN attributes to the new object class. 1181 * Several attributes had their OIDs changed. NOTE THAT THIS 1182 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1183 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1185 14. Full Copyright Statement 1186 Copyright (C) The Internet Society (2003). All Rights Reserved. 1188 This document and translations of it may be copied and furnished 1189 to others, and derivative works that comment on or otherwise 1190 explain it or assist in its implementation may be prepared, 1191 copied, published and distributed, in whole or in part, without 1192 restriction of any kind, provided that the above copyright notice 1193 and this paragraph are included on all such copies and derivative 1194 works. However, this document itself may not be modified in any 1195 way, such as by removing the copyright notice or references to the 1196 Internet Society or other Internet organizations, except as needed 1197 for the purpose of developing Internet standards in which case the 1198 procedures for copyrights defined in the Internet Standards 1199 process must be followed, or as required to translate it into 1200 languages other than English. 1202 The limited permissions granted above are perpetual and will not 1203 be revoked by the Internet Society or its successors or assigns. 1205 This document and the information contained herein is provided on 1206 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1207 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1208 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1209 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.