idnits 2.17.1 draft-ietf-crisp-firs-ipv4-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. ** The abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 7585 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2798' is mentioned on line 252, but not defined == Unused Reference: 'RFC2247' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'FIRS-IPV4' is defined on line 551, but no explicit reference was found in the text ** 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 2254 (Obsoleted by RFC 4510, RFC 4515) == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-02 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-02 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 3 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-ipv4-02.txt July 2003 4 Expires: February, 2004 5 Category: Experimental 7 Defining and Locating IPv4 Address Blocks 8 in the Federated Internet Registry Service 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 defines LDAP schema and searching rules for IPv4 39 address blocks, in support of the Federated Internet Registry 40 Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. 42 Table of Contents 44 1. Introduction...............................................2 45 2. Prerequisites and Terminology..............................2 46 3. Naming Syntax..............................................3 47 4. Object Classes and Attributes..............................4 48 5. Query Processing Rules.....................................7 49 5.1. Query Pre-Processing....................................7 50 5.2. Query Bootstrapping.....................................8 51 5.3. LDAP Matching...........................................9 52 5.4. Example Query..........................................10 53 6. Security Considerations...................................12 54 7. IANA Considerations.......................................12 55 8. Normative References......................................12 56 9. Changes from Previous Versions............................13 57 10. Author's Address..........................................14 58 11. Acknowledgments...........................................14 59 12. Full Copyright Statement..................................15 61 1. Introduction 63 This specification defines the naming syntax, object classes, 64 attributes, matching filters, and query processing rules for 65 storing and locating IPv4 address blocks in the FIRS service. 66 Refer to [FIRS-ARCH] for information on the FIRS architecture and 67 [FIRS-CORE] for the schema definitions and rules which govern the 68 FIRS service as a whole. 70 Note that reverse-lookup DNS domains for IPv4 address blocks are 71 managed as DNS domain entries in [FIRS-DNS]. These are entirely 72 different network resources, and should not be confused with IPv4 73 address block entries. 75 The definitions in this specification are intended to be used with 76 FIRS. Their usage outside of FIRS is not prohibited, but any such 77 usage is beyond this specification's scope of authority. 79 2. Prerequisites and Terminology 81 The complete set of specifications in the FIRS collection 82 cumulative define a structured and distributed information service 83 using LDAPv3 for the data-formatting and transport functions. This 84 specification should be read in the context of that set, which 85 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS], 86 [FIRS-DNSRR], [FIRS-CONTCT], [FIRS-ASN] and [FIRS-IPV6]. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 89 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 90 in this document are to be interpreted as described in RFC 2119. 92 3. Naming Syntax 94 The naming syntax for IPv4 address blocks in FIRS MUST follow the 95 form of "cn=,cn=inetResources,", 96 where is the IPv4 address block resource, 97 and where is a sequence of domainComponent relative 98 distinguished names which identifies the scope of authority for 99 the selected directory partition. 101 The inetIpv4NetworkSyntax rules use the traditional "dotted-quad" 102 notation, where each of four sub-components provide a decimal 103 value that represents one octet from a 32-bit IPv4 address, with 104 the sub-components being separated by a full-stop (period) 105 character, and with the four-part sequence being followed by a "/" 106 character and a decimal "prefix" value. 108 Entries which use the inetIpv4NetworkSyntax MUST use the starting 109 address from a range of inclusive addresses, and MUST use CIDR 110 prefix notation. In this manner, it is possible to create an 111 inetIpv4Network entry for a range of addresses of any size 112 (including a single host). 114 The leading zeroes from each octet MUST be removed before the 115 value is stored or used in a query. Octets which have a value of 116 zero MUST be represented by the single-digit value of "0". 118 If an input string does not match this syntax, a FIRS-aware 119 application MAY attempt to manipulate the input string to form a 120 valid value. For example, if a user enters a traditional IPv4 121 address without specifying a prefix value, the application MAY 122 append "/32" to the end of the input string to form a valid 123 assertion value. Similarly, if a user provides an octal or 124 hexadecimal value, the client MAY attempt to convert the input 125 string to the traditional dotted-quad IPv4 address notation. 127 An augmented BNF for this syntax is as follows: 129 inetIpv4NetworkSyntax = inetIpv4Octet "." inetIpv4Octet "." 130 inetIpv4Octet "." inetIpv4Octet "/" inetIpv4Prefix 131 inetIpv4Octet = decimal value between "0" and "255" 132 inclusive, with the non-affective leading zeroes removed 134 inetIpv4Prefix = decimal value between "1" and "32" 135 inclusive, with the non-affective leading zeroes removed 137 The schema definition for inetIpv4NetworkSyntax is as follows: 139 inetIpv4NetworkSyntax 140 ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetIpv4NetworkSyntax' DESC 141 'An IPv4 address and prefix.' ) 143 For example, an IPv4 address block with a range of addresses 144 between "10.0.0.0" and "10.0.255.255" inclusive would be written 145 as "cn=10.0.0.0/16", while a host address of "192.0.2.14" would be 146 written as "cn=192.0.2.14/32". 148 Note that the entry name of "cn=0.0.0.0/0" encompasses the entire 149 IPv4 address space. 151 Note that the use of "/" is illegal as data in URLs, and MUST be 152 escaped before it is stored in a URL as data. 154 4. Object Classes and Attributes 156 IPv4 address block entries in FIRS MUST use the inetIpv4Network 157 object class, in addition to the mandatory object classes defined 158 in [FIRS-CORE]. IPv4 address block entries MUST be treated as 159 containers capable of holding subordinate entries. If an entry 160 exists as a referral source, the entry MUST also be defined with 161 the referral object class, in addition to the above requirements. 163 The inetIpv4Network object class is a structural object class 164 which is subordinate to the inetResources object class. The 165 inetIpv4Network object class has no mandatory attributes, although 166 it does have several optional attributes. The inetIpv4Network 167 object class also inherits the attributes defined in the 168 inetResources object class, including the "cn" naming attribute. 170 The schema definition for the inetIpv4Network object class is as 171 follows: 173 inetIpv4Network 174 ( 1.3.6.1.4.1.7161.1.5.1 175 NAME 'inetIpv4Network' 176 DESC 'IPv4 network attributes.' 177 SUP inetResources 178 STRUCTURAL 179 MAY ( inetIpv4DelegationStatus $ inetIpv4DelegationDate $ 180 inetIpv4Registrar $ inetIpv4Registry $ inetIpv4Contacts $ 181 inetIpv4RoutingContacts ) ) 183 The attributes from the inetIpv4Network object class are described 184 below: 186 inetIpv4Contacts 187 ( 1.3.6.1.4.1.7161.1.5.2 188 NAME 'inetIpv4Contacts' 189 DESC 'Contacts for general administrative issues concerning 190 this IPv4 address block.' 191 EQUALITY caseIgnoreMatch 192 SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) 194 inetIpv4DelegationDate 195 ( 1.3.6.1.4.1.7161.1.5.3 196 NAME 'inetIpv4DelegationDate' 197 DESC 'Date this IPv4 address block was delegated.' 198 EQUALITY generalizedTimeMatch 199 ORDERING generalizedTimeOrderingMatch 200 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 201 SINGLE-VALUE ) 203 inetIpv4DelegationStatus 204 ( 1.3.6.1.4.1.7161.1.5.4 205 NAME 'inetIpv4DelegationStatus' 206 DESC 'Delegation status of this IPv4 address block.' 207 EQUALITY numericStringMatch 208 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} 209 SINGLE-VALUE ) 211 NOTE: In an effort to facilitate internationalization and 212 programmatic processing, the current status of a delegation 213 is identified by a 16-bit integer. The values and status 214 mapping is as follows: 216 0 Reserved delegation (permanently inactive) 217 1 Assigned and active (normal state) 218 2 Assigned but not yet active (new delegation) 219 3 Assigned but on hold (disputed) 220 4 Assignment revoked (database purge pending) 222 Additional values are reserved for future use, and are to 223 be administered by IANA. 225 Note that there is no status code for "unassigned"; 226 unassigned entries SHOULD NOT exist, and SHOULD NOT be 227 returned as answers. 229 inetIpv4Registrar 230 ( 1.3.6.1.4.1.7161.1.5.5 231 NAME 'inetIpv4Registrar' 232 DESC 'Registrar who delegated this IPv4 address block.' 233 EQUALITY caseExactMatch 234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 236 NOTE: The inetIpv4Registrar attribute uses a URL to 237 indicate the registrar who delegated the address block. The 238 attribute structure is identical to the labeledURI 239 attribute, as defined in [RFC2798], including the URL and 240 textual comments. The data can refer to any valid URL. 242 inetIpv4Registry 243 ( 1.3.6.1.4.1.7161.1.5.6 244 NAME 'inetIpv4Registry' 245 DESC 'Registry where this IPv4 address block is managed.' 246 EQUALITY caseExactMatch 247 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 249 NOTE: The inetIpv4Registry attribute uses a URL to indicate 250 the registry who is ultimately responsible for the address 251 block. The attribute structure is identical to the 252 labeledURI attribute, as defined in [RFC2798], including 253 the URL and textual comments. The data can refer to any 254 valid URL. 256 inetIpv4RoutingContacts 257 ( 1.3.6.1.4.1.7161.1.5.7 258 NAME 'inetIpv4RoutingContacts' 259 DESC 'Contacts for routing-related problems with this IPv4 260 address block.' 261 EQUALITY caseIgnoreMatch 262 SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) 264 An example of the inetIpv4Network object class is shown in Figure 265 1 below. The example includes attributes from the inetIpv4Network, 266 inetResources, and inetAssociatedResources object classes. 268 cn=192.0.2.0/24,cn=inetResources,dc=arin,dc=net 269 [top object class] 270 [inetResources object class] 271 [inetIpv4Network object class] 272 [inetAssociatedResources object class] 273 | 274 +-attribute: description 275 | value: "Example Hosting's IPv4 address block" 276 | 277 +-attribute: inetIpv4Contacts 278 | value: "hostmaster@example.com" 279 | 280 +-attribute: inetAssociatedAsNumbers 281 | value: "65535" 282 | 283 +-attribute: inetIpv4Registrar 284 value: "http://www.arin.net/ (ARIN)" 286 Figure 1: The entry for the 192.0.2.0/24 address block in the 287 dc=arin,dc=net partition. 289 5. Query Processing Rules 291 Queries for IPv4 address blocks have several special requirements, 292 as discussed in the following sections. 294 Refer to [FIRS-CORE] for general information about FIRS queries. 296 5.1. Query Pre-Processing 298 Clients MUST ensure that the query input is normalized according 299 to the rules specified in section 3 before the input is used as 300 the assertion value in the resulting LDAP query. 302 The authoritative partition for an IPv4 address block is 303 determined by mapping the normalized input to an associated 304 reverse-lookup DNS domain name, and then mapping the resulting DNS 305 domain name to a sequence of domainComponent labels. 307 The least-significant octet MUST include the subnet prefix in this 308 mapping process, except in those cases where the address falls on 309 an eight-bit boundary. In those cases where the address block 310 specifies a 32-bit host address, the subnet prefix MUST be 311 stripped from the input during the mapping process. In those cases 312 where the address block specifies a legacy "address class", the 313 least-significant octet and subnet prefix MUST both be stripped 314 from the input during the mapping process. These steps are 315 necessary in order to ensure that the reverse-pointer delegations 316 in the public DNS are correctly matched to the authoritative 317 partitions (note that these rules only apply to the mapping 318 process by which an authoritative partition is constructed, and do 319 not apply to the process by which the entry-specific relative 320 distinguished name is constructed). 322 For example, a host-specific IPv4 address block of "192.0.2.14/32" 323 would be mapped to the reverse-lookup DNS domain name of 324 "14.2.0.192.in-addr.arpa." which would in turn be mapped to 325 "dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Meanwhile, the "Class 326 C" block of "192.0.2.0/24" would be mapped to the reverse-lookup 327 DNS domain name of "2.0.192.in-addr.arpa." which would in turn be 328 mapped to "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Finally, a 329 classless IPv4 address block of "192.0.2.0/20" would be mapped to 330 the reverse-lookup domain name of "0/20.14.2.0.192.in-addr.arpa" 331 which would in turn be mapped to the fully-qualified distinguished 332 name of "dc=0/20,dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". 334 5.2. Query Bootstrapping 336 FIRS clients MUST use the targeted bootstrap model by default for 337 IPv4 address block queries, using the "in-addr.arpa" zone as the 338 seed domain for the initial query. 340 FIRS clients MAY use the top-down or bottom-up bootstrap models 341 for queries if necessary or desirable. However, it is not likely 342 that entries will be found for all IPv4 address block resources 343 using these models. As such, the targeted bootstrap model will be 344 the most useful in most cases, and MUST be used by default. 346 5.3. LDAP Matching 348 If the server advertises the inetIpv4Network object class in the 349 firsVersion server control, FIRS clients MUST use the 350 inetIpv4NetworkMatch extensible matching filter in LDAP searches 351 for IPv4 network entries. 353 The inetIpv4NetworkMatch filter provides an identifier and search 354 string format which collectively inform a queried server that a 355 specific IPv4 address should be searched for, and that any 356 matching inetIpv4network object class entries should be returned. 358 The inetIpv4NetworkMatch extensibleMatch filter is defined as 359 follows: 361 inetIpv4NetworkMatch 362 ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetIpv4NetworkMatch' SYNTAX 363 inetIpv4NetworkSyntax ) 365 The assertion value MUST be a normalized IPv4 address, using the 366 inetIpv4NetworkSyntax defined in section 3. 368 A FIRS server MUST compare the assertion value against the RDN of 369 all entries in the inetResources container of the partition 370 specified in the search base which have an object class of 371 inetIpv4Network. Any entry with an object class of inetIpv4Network 372 and with a relative distinguished name which clearly encompasses 373 the IPv4 address provided in the assertion value MUST be returned. 374 Entries which do not clearly encompass the queried address MUST 375 NOT be returned. Entries which do not have an object class of 376 inetIpv4Network MUST NOT be returned. 378 In order to ensure that all of the relevant entries are found 379 (including any referrals), the search filters for these resources 380 MUST specify the inetIpv4Network object class along with the 381 search criteria. For example, "(&(objectclass=inetIpv4Network) 382 (1.3.6.1.4.1.7161.1.5.8:=192.0.2.0/24))" with a search base of 383 "cn=inetResources,dc=arin,dc=net" would find all of the 384 inetIpv4Network object class entries which were superior to the 385 "192.0.2.0/24" address block in the "dc=arin,dc=net" partition. 387 Note that the entry name of "cn=0.0.0.0/0" encompasses the entire 388 IPv4 address space. When used in conjunction with referrals, this 389 entry MAY be used to redirect all inetIpv4NetworkMatch queries to 390 another partition for subsequent processing. 392 The matching filters defined in this specification MUST be 393 supported by FIRS clients and servers. FIRS servers MAY support 394 additional sub-string filters, soundex filters, or any other 395 filters they wish (these may be required to support generic LDAP 396 clients), although FIRS clients MUST NOT expect any additional 397 filters to be available. 399 If the server does not advertise support for the inetIpv4Network 400 object class in the firsVersion server control, the client MAY 401 choose to emulate this matching process through the use of 402 locally-constructed filters. Since the inetIpv4NetworkMatch filter 403 simply locates all of the entries in the delegation path to the 404 named network, it is possible that a client could emulate this 405 query by generating distinct queries for any entries associated 406 with the parent networks. 408 For example, if the user asked for information about the 409 "192.0.2.14/32" network resource but the server does not advertise 410 support for the inetIpv4Network object class, the client could 411 theoretically issue secondary queries for inetIpv4Network entries 412 with cn attributes that begin with "192.0.2" or "192.0". 414 Unfortunately, this kind of matching is not guaranteed to work in 415 most situations, and clients also need to be careful not to issue 416 overly-broad queries that match all answers. As such, if the 417 server advertises support for the inetIpv4Network object class in 418 the firsVersion control, then the client MUST use the 419 inetIpv4NetworkMatch filter defined above. 421 5.4. Example Query 423 The following example assumes that the user has specified 424 "192.0.2.14/32" as the query value: 426 a. Normalize the input, which is "192.0.2.14/32" in this case. 428 b. Determine the canonical authoritative partition. 430 1. Map the input sequence to the reverse-lookup domain 431 name, which is "14.2.0.192.in-addr.arpa" in this case. 433 2. Determine the initial domain name which is appropriate 434 for the bootstrap model in use. In the default case of 435 a targeted query, use "in-addr.arpa". In the case of a 436 bottom-up query, use the label sequence determined in 437 step 5.4.b.1. In the case of a top-down query, set the 438 domain name to "arpa". 440 3. Map the domain name to an authoritative partition, 441 which would be "dc=in-addr,dc=arpa" if the default 442 bootstrap model were in use. 444 c. Determine the search base for the query, which will be 445 "cn=inetResources,dc=arpa" if the defaults are used. 447 d. Initiate a DNS lookup for the SRV resource records 448 associated with "_ldap._tcp.in-addr.arpa." For the purpose 449 of this example, assume that this lookup succeeds, with the 450 DNS response message indicating that "firs.iana.org" is the 451 preferred LDAP server. 453 e. Submit an LDAPv3 query to the specified server, using 454 "(&(objectClass=inetIpv4Network) 455 (1.3.6.1.4.1.7161.1.5.8:=192.0.2.14/32))" as the matching 456 filter, "cn=inetResources,dc=in-addr,dc=arpa" as the search 457 base, and the global query defaults defined in [FIRS-CORE]. 459 f. Assume that the queried server returns a continuation 460 reference referral which points to 461 "ldap:///cn=inetResources,dc=arin,dc=net". The 462 distinguished name element of 463 "cn=inetResources,dc=arin,dc=net" will be used as the new 464 search base, while "dc=arin,dc=net" will be used as the new 465 authoritative partition. 467 g. Initiate a DNS lookup for the SRV resource records 468 associated with "_ldap._tcp. arin.net." For the purpose of 469 this example, assume that this lookup succeeds, with the 470 DNS response message indicating that "firs.arin.net" is the 471 preferred LDAP server. 473 h. Submit an LDAPv3 query to the specified server, using 474 "(&(objectClass=inetIpv4Network) 475 (1.3.6.1.4.1.7161.1.5.8:=192.0.2.14/32)" as the matching 476 filter, "cn=inetResources,dc=arin,dc=net" as the search 477 base, and the global query defaults defined in [FIRS-CORE]. 479 i. Assume that no other referrals are received. Display the 480 answer data which has been received and exit the query. 482 6. Security Considerations 484 Security considerations are discussed in [FIRS-ARCH]. 486 7. IANA Considerations 488 This specification uses the "dc=in-addr,dc=arpa" directory 489 partition by default. It is expected that authoritative LDAP 490 partitions will be mapped to that zone, and that FIRS-capable LDAP 491 servers will be established to service this partition, with this 492 partition containing IPv4-specific entries which will provide 493 referrals to the appropriate RIR partitions. It is further 494 expected that IANA will oversee the creation and management of the 495 in-addr.arpa domain's LDAP SRV resource records, the 496 "dc=in-addr,dc=arpa" LDAP partition, and the necessary LDAP 497 servers. 499 The inetIpv4DelegationStatus attribute uses numeric code values. 500 It is expected that IANA will manage the assignment of these 501 values. 503 Additional IANA considerations are discussed in [FIRS-ARCH]. 505 8. Normative References 507 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 508 and Sataluri, S. "Using Domains in LDAP/X.500 509 DNs", RFC 2247, January 1998. 511 [RFC2251] Wahl, M., Howes, T., and Kille, S. 512 "Lightweight Directory Access Protocol (v3)", 513 RFC 2251, December 1997. 515 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 516 S. "Lightweight Directory Access Protocol 517 (v3): Attribute Syntax Definitions", RFC 2252, 518 December 1997. 520 [RFC2254] Howes, T. "The String Representation of LDAP 521 Search Filters", RFC 2254, December 1997. 523 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 524 Service: Architecture and Implementation 525 Guide", draft-ietf-crisp-firs-arch-02, July 526 2003. 528 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 529 System Numbers in the Federated Internet 530 Registry Service", draft-ietf-crisp-firs-asn- 531 02, July 2003. 533 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 534 Persons in the Federated Internet Registry 535 Service", draft-ietf-crisp-firs-contact-02, 536 July 2003. 538 [FIRS-CORE] Hall, E. "The Federated Internet Registry 539 Service: Core Elements", draft-ietf-crisp- 540 firs-core-02, July 2003. 542 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 543 the Federated Internet Registry Service", 544 draft-ietf-crisp-firs-dns-02, July 2003. 546 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 547 Records in the Federated Internet Registry 548 Service", draft-ietf-crisp-firs-dnsrr-02, July 549 2003. 551 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 552 Blocks in the Federated Internet Registry 553 Service", draft-ietf-crisp-firs-ipv4-02, July 554 2003. 556 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 557 Blocks in the Federated Internet Registry 558 Service", draft-ietf-crisp-firs-ipv6-02, July 559 2003. 561 9. Changes from Previous Versions 563 draft-ietf-crisp-firs-ipv4-02: 565 * Several clarifications and corrections have been made. 567 * Changed the default bootstrap model to use targeted 568 queries, with "in-addr.arpa" as the default zone and 569 "dc=in-addr,dc=arpa" as the default partition. 571 draft-ietf-crisp-firs-ipv4-01: 573 * Several clarifications and corrections have been made. 575 draft-ietf-crisp-firs-ipv4-00: 577 * Restructured the document set. 579 * "Attribute references" have been eliminated from the 580 specification. All referential attributes now provide 581 actual data instead of URL pointers to data. Clients that 582 wish to retrieve these values will need to start new 583 queries using the data values instead of URLs. 585 * The attribute-specific operational attributes have been 586 eliminated as unnecessary. 588 * The inetIpv4Registrar and inetIpv4Registry attributes were 589 added. 591 * Several attributes had their OIDs changed. NOTE THAT THIS 592 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 593 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 595 * Several typographical errors have been fixed. 597 * Some unnecessary text has been removed. 599 10. Author's Address 601 Eric A. Hall 602 ehall@ehsco.com 604 11. Acknowledgments 606 Funding for the RFC editor function is currently provided by the 607 Internet Society. 609 Portions of this document were funded by VeriSign Labs. 611 The first version of this specification was co-authored by Andrew 612 Newton of VeriSign Labs, and subsequent versions continue to be 613 developed with his active participation. Edward Lewis also 614 contributed significant feedback to this specification in the 615 later stages of its developments. 617 12. Full Copyright Statement 619 Copyright (C) The Internet Society (2003). All Rights Reserved. 621 This document and translations of it may be copied and furnished 622 to others, and derivative works that comment on or otherwise 623 explain it or assist in its implementation may be prepared, 624 copied, published and distributed, in whole or in part, without 625 restriction of any kind, provided that the above copyright notice 626 and this paragraph are included on all such copies and derivative 627 works. However, this document itself may not be modified in any 628 way, such as by removing the copyright notice or references to the 629 Internet Society or other Internet organizations, except as needed 630 for the purpose of developing Internet standards in which case the 631 procedures for copyrights defined in the Internet Standards 632 process must be followed, or as required to translate it into 633 languages other than English. 635 The limited permissions granted above are perpetual and will not 636 be revoked by the Internet Society or its successors or assigns. 638 This document and the information contained herein is provided on 639 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 641 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.