idnits 2.17.1 draft-ietf-crisp-firs-ipv4-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (May 2003) is 7653 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2798' is mentioned on line 266, but not defined == Unused Reference: 'RFC2247' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 508, 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-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-01 == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-01 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-01.txt May 2003 4 Expires: December, 2003 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.............................5 48 5. Query Processing Rules....................................7 49 5.1. Query Pre-Processing...................................8 50 5.2. Query Bootstrapping....................................8 51 5.3. LDAP Matching..........................................9 52 5.4. Example Query.........................................10 53 6. Security Considerations..................................11 54 7. IANA Considerations......................................11 55 8. Author's Addresses.......................................12 56 9. Normative References.....................................12 57 10. Acknowledgments..........................................13 58 11. Changes from Previous Versions...........................13 59 12. Full Copyright Statement.................................14 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 the complete set of 85 specifications, which currently include the following: 87 draft-ietf-crisp-firs-arch-01, "The Federated Internet 88 Registry Service: Architecture and Implementation" 89 [FIRS-ARCH] 91 draft-ietf-crisp-firs-core-01, "The Federated Internet 92 Registry Service: Core Elements" [FIRS-CORE] 94 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 95 Domains in the Federated Internet Registry Service" 96 [FIRS-DNS] 98 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 99 Resource Records in the Federated Internet Registry 100 Service" [FIRS-DNSRR] 102 draft-ietf-crisp-firs-contact-01, "Defining and Locating 103 Contact Persons in the Federated Internet Registry Service" 104 [FIRS-CONTCT] 106 draft-ietf-crisp-firs-asn-01, "Defining and Locating 107 Autonomous System Numbers in the Federated Internet 108 Registry Service" [FIRS-ASN] 110 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 111 Address Blocks in the Federated Internet Registry Service" 112 (this document) [FIRS-IPV4] 114 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 115 Address Blocks in the Federated Internet Registry Service" 116 [FIRS-IPV6] 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 119 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 120 in this document are to be interpreted as described in RFC 2119. 122 3. Naming Syntax 124 The naming syntax for IPv4 address blocks in FIRS MUST follow the 125 form of "cn=,cn=inetResources,", 126 where is the IPv4 address block resource, 127 and where is a sequence of domainComponent relative 128 distinguished names which identifies the scope of authority for 129 the selected directory partition. 131 The inetIpv4NetworkSyntax rules use the traditional "dotted-quad" 132 notation, where each of four sub-components provide a decimal 133 value that represents one octet from a 32-bit IPv4 address, with 134 the sub-components being separated by a full-stop (period) 135 character, and with the four-part sequence being followed by a "/" 136 character and a three-digit decimal "prefix" value. 138 Entries which use the inetIpv4NetworkSyntax MUST use the starting 139 address from a range of inclusive addresses, and MUST use CIDR 140 prefix notation. In this manner, it is possible to create an 141 inetIpv4Network entry for a range of addresses of any size 142 (including a single host). 144 The leading zeroes from each octet MUST be removed before the 145 value is stored or used in a query. Octets which have a value of 146 zero MUST be represented by the single-digit numeric value of "0". 148 If an input string does not match this syntax, a FIRS-aware 149 application MAY attempt to manipulate the input string to form a 150 valid value. For example, if a user enters a traditional IPv4 151 address without specifying a prefix value, the application MAY 152 append "/32" to the end of the input string to form a valid 153 assertion value. Similarly, if a user provides an octal or 154 hexadecimal value, the client MAY attempt to convert the input 155 string to the traditional dotted-quad IPv4 address notation. 157 An augmented BNF for this syntax is as follows: 159 inetIpv4NetworkSyntax = inetIpv4Octet "." inetIpv4Octet "." 160 inetIpv4Octet "." inetIpv4Octet "/" inetIpv4Prefix 162 inetIpv4Octet = decimal value between "0" and "255" 163 inclusive, with the non-affective leading zeroes removed 165 inetIpv4Prefix = decimal value between "1" and "32" 166 inclusive, with the non-affective leading zeroes removed 168 The schema definition for inetIpv4NetworkSyntax is as follows: 170 inetIpv4NetworkSyntax 171 ( 1.3.6.1.4.1.7161.1.2.1 NAME 'inetIpv4NetworkSyntax' DESC 172 'An IPv4 address and prefix.' ) 174 For example, an IPv4 address block with a range of addresses 175 between "10.0.0.0" and "10.0.255.255" inclusive would be written 176 as "cn=10.0.0.0/16", while a host address of "192.0.2.14" would be 177 written as "cn=192.0.2.14/32". 179 Note that the entry name of "cn=0.0.0.0/0" encompasses the entire 180 IPv4 address space. 182 Note that the use of "/" is illegal as data in URLs, and MUST be 183 escaped before it is stored in a URL as data. 185 4. Object Classes and Attributes 187 IPv4 address block entries in FIRS MUST use the inetIpv4Network 188 object class, in addition to the mandatory object classes defined 189 in [FIRS-CORE]. IPv4 address block entries MUST be treated as 190 containers capable of holding subordinate entries. If an entry 191 exists as a referral source, the entry MUST also be defined with 192 the referral object class, in addition to the above requirements. 194 The inetIpv4Network object class is a structural object class 195 which is subordinate to the inetResources object class. The 196 inetIpv4Network object class has no mandatory attributes, although 197 it does have several optional attributes. The inetIpv4Network 198 object class also inherits the attributes defined in the 199 inetResources object class, including the "cn" naming attribute. 201 The schema definition for the inetIpv4Network object class is as 202 follows: 204 inetIpv4Network 205 ( 1.3.6.1.4.1.7161.1.2.0 NAME 'inetIpv4Network' DESC 'IPv4 206 network attributes.' SUP inetResources STRUCTURAL MAY ( 207 inetIpv4DelegationStatus $ inetIpv4DelegationDate $ 208 inetIpv4Registrar $ inetIpv4Registry $ inetIpv4Contacts $ 209 inetIpv4RoutingContacts $ ) ) 211 The attributes from the inetIpv4Network object class are described 212 below: 214 inetIpv4Contacts 215 ( 1.3.6.1.4.1.7161.1.2.2 NAME 'inetIpv4Contacts' DESC 216 'Contacts for general administrative issues concerning this 217 IPv4 address block.' EQUALITY caseIgnoreMatch SYNTAX 218 inetContactSyntax ) 219 inetIpv4DelegationDate 220 ( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4DelegationDate' DESC 221 'Date this IPv4 address block was delegated.' EQUALITY 222 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 223 SYNTAX generalizedTime SINGLE-VALUE ) 225 inetIpv4DelegationStatus 226 ( 1.3.6.1.4.1.7161.1.2.4 NAME 'inetIpv4DelegationStatus' DESC 227 'Delegation status of this IPv4 address block.' EQUALITY 228 numericStringMatch SYNTAX numericString{2} SINGLE-VALUE ) 230 NOTE: In an effort to facilitate internationalization and 231 programmatic processing, the current status of a delegation 232 is identified by a 16-bit integer. The values and status 233 mapping is as follows: 235 0 Reserved delegation (permanently inactive) 236 1 Assigned and active (normal state) 237 2 Assigned but not yet active (new delegation) 238 3 Assigned but on hold (disputed) 239 4 Assignment revoked (database purge pending) 241 Additional values are reserved for future use, and are to 242 be administered by IANA. 244 Note that there is no status code for "unassigned"; 245 unassigned entries SHOULD NOT exist, and SHOULD NOT be 246 returned as answers. 248 inetIpv4Registrar 249 ( 1.3.6.1.4.1.7161.1.2.5 NAME 'inetIpv4Registrar' DESC 250 'Registrar who delegated this IPv4 address block.' EQUALITY 251 caseIgnoreMatch SYNTAX directoryString ) 253 NOTE: The inetIpv4Registrar attribute uses a URL to 254 indicate the registrar who delegated the address block. The 255 attribute structure is identical to the labeledURI 256 attribute, as defined in [RFC2798], including the URL and 257 textual comments. The data can refer to any valid URL. 259 inetIpv4Registry 260 ( 1.3.6.1.4.1.7161.1.2.6 NAME 'inetIpv4Registry' DESC 261 'Registry where this IPv4 address block is managed.' 262 EQUALITY caseIgnoreMatch SYNTAX directoryString ) 263 NOTE: The inetIpv4Registry attribute uses a URL to indicate 264 the registry who is ultimately responsible for the address 265 block. The attribute structure is identical to the 266 labeledURI attribute, as defined in [RFC2798], including 267 the URL and textual comments. The data can refer to any 268 valid URL. 270 inetIpv4RoutingContacts 271 ( 1.3.6.1.4.1.7161.1.2.7 NAME 'inetIpv4RoutingContacts' DESC 272 'Contacts for routing-related problems with this IPv4 273 address block.' EQUALITY caseExactMatch SYNTAX 274 inetContactSyntax ) 276 An example of the inetIpv4Network object class is shown in Figure 277 1 below. The example includes attributes from the inetIpv4Network, 278 inetResources, and inetAssociatedResources object classes. 280 cn=192.0.2.0/24,cn=inetResources,dc=arin,dc=net 281 [top object class] 282 [inetResources object class] 283 [inetIpv4Network object class] 284 [inetAssociatedResources object class] 285 | 286 +-attribute: description 287 | value: "Example Hosting's IPv4 address block" 288 | 289 +-attribute: inetIpv4Contacts 290 | value: "hostmaster@example.com" 291 | 292 +-attribute: inetAssociatedAsNumbers 293 | value: "65535" 294 | 295 +-attribute: inetIpv4Registrar 296 value: "http://www.arin.net/ (ARIN)" 298 Figure 1: The entry for the 192.0.2.0/24 address block in the 299 dc=arin,dc=net partition. 301 5. Query Processing Rules 303 Queries for IPv4 address blocks have several special requirements, 304 as discussed in the following sections. 306 Refer to [FIRS-CORE] for general information about FIRS queries. 308 5.1. Query Pre-Processing 310 Clients MUST ensure that the query input is normalized according 311 to the rules specified in section 3 before the input is used as 312 the assertion value to the resulting LDAP query. 314 The authoritative partition for an IPv4 address block is 315 determined by mapping the normalized input to an associated 316 reverse-lookup DNS domain name, and then mapping the resulting DNS 317 domain name to a sequence of domainComponent labels. 319 The least-significant octet MUST include the subnet prefix in this 320 mapping process, except in those cases where the address falls on 321 an eight-bit boundary. In those cases where the address block 322 specifies a 32-bit host address, the subnet prefix MUST be 323 stripped from the input during the mapping process. In those cases 324 where the address block specifies a legacy "address class", the 325 least-significant octet and subnet prefix MUST both be stripped 326 from the input during the mapping process. These steps are 327 necessary in order to ensure that the reverse-pointer delegations 328 in the public DNS are correctly matched to the authoritative 329 partitions (note that these rules only apply to the mapping 330 process by which an authoritative partition is constructed, and 331 does not apply to the process by which the entry-specific relative 332 distinguished name is constructed). 334 For example, a host-specific IPv4 address block of "192.0.2.14/32" 335 would be mapped to the reverse-lookup DNS domain name of 336 "14.2.0.192.in-addr.arpa." which would in turn be mapped to 337 "dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Meanwhile, the "Class 338 C" block of "192.0.2.0/24" would be mapped to the reverse-lookup 339 DNS domain name of "2.0.192.in-addr.arpa." which would in turn be 340 mapped to "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Finally, a 341 classless IPv4 address block of "192.0.2.0/20" would be mapped to 342 the reverse-lookup DNS domain name of "0/14.2.0.192.in-addr.arpa" 343 which would in turn be mapped to the fully-qualified distinguished 344 name of "dc=0/14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". 346 5.2. Query Bootstrapping 348 FIRS clients MUST use the top-down bootstrap model by default for 349 IPv4 address block queries. As such, the search base for default 350 queries would be set to "dc=arpa" rather than being set to the 351 fully-qualified distinguished name of the authoritative partition. 353 FIRS clients MAY use the targeted or bottom-up bootstrap models 354 for queries if necessary or desirable. However, it is not likely 355 that entries will be found for all IPv4 address block resources 356 using these models. As such, the top-down bootstrap model will be 357 the most useful in most cases, and MUST be used by default. 359 5.3. LDAP Matching 361 FIRS clients MUST use the inetIpv4NetworkMatch extensible matching 362 filter in LDAP searches for IPv4 address block entries. 364 The inetIpv4NetworkMatch filter provides an identifier and search 365 string format which collectively inform a queried server that a 366 specific IPv4 address should be searched for, and that any 367 matching inetIpv4network object class entries should be returned. 369 The inetIpv4NetworkMatch extensibleMatch filter is defined as 370 follows: 372 inetIpv4NetworkMatch 373 ( 1.3.6.1.4.1.7161.1.2.8 NAME 'inetIpv4NetworkMatch' SYNTAX 374 inetIpv4NetworkSyntax ) 376 The assertion value MUST be a normalized IPv4 address, using the 377 inetIpv4NetworkSyntax defined in section 3. 379 A FIRS server MUST compare the assertion value against the RDN of 380 all entries in the inetResources container of the partition 381 specified in the search base which have an object class of 382 inetIpv4Network. Any entry with an object class of inetIpv4Network 383 and with a relative distinguished name which clearly encompasses 384 the IPv4 address provided in the assertion value MUST be returned. 385 Entries which do not clearly encompass the queried address MUST 386 NOT be returned. Entries which do not have an object class of 387 inetIpv4Network MUST NOT be returned. 389 In order to ensure that all of the relevant entries are found 390 (including any referrals), the search filters for these resources 391 MUST specify the inetIpv4Network object class along with the 392 search criteria. For example, "(&(objectclass=inetIpv4Network) 393 (1.3.6.1.4.1.7161.1.2.8:=192.0.2.0/24))" with a search base of 394 "cn=inetResources,dc=arin,dc=net" would find all of the 395 inetIpv4Network object class entries which were superior to the 396 "192.0.2.0/24" address block in the "dc=arin,dc=net" partition. 398 Note that the entry name of "cn=0.0.0.0/0" encompasses the entire 399 IPv4 address space. When used in conjunction with referrals, this 400 entry MAY be used to redirect all inetIpv4NetworkMatch queries to 401 another partition for subsequent processing. 403 The matching filters defined in this specification MUST be 404 supported by FIRS clients and servers. FIRS servers MAY support 405 additional sub-string filters, soundex filters, or any other 406 filters they wish (these may be required to support generic LDAP 407 clients), although FIRS clients MUST NOT expect any additional 408 filters to be available. 410 5.4. Example Query 412 The following example assumes that the user has specified 413 "192.0.2.14/32" as the query value: 415 a. Normalize the input, which is "192.0.2.14/32" in this case. 417 b. Determine the authoritative partition. 419 1. Map the input sequence to the reverse-lookup domain 420 name, which is "14.2.0.192.in-addr.arpa" in this case. 422 2. Map the domain name to an authoritative partition, 423 which is "dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" 424 in this case. By default, queries for IPv4 address 425 blocks use the top-down model, meaning that the right- 426 most relative distinguished name of "dc=arpa" will be 427 used as the authoritative partition. 429 c. Determine the search base for the query, which will be 430 "cn=inetResources,dc=arpa" if the defaults are used. 432 d. Initiate a DNS lookup for the SRV resource records 433 associated with "_ldap._tcp.arpa." For the purpose of this 434 example, assume that this lookup succeeds, with the DNS 435 response message indicating that "firs.iana.org" is the 436 preferred LDAP server. 438 e. Submit an LDAPv3 query to the specified server, using 439 "(&(objectClass=inetIpv4Network) 440 (1.3.6.1.4.1.7161.1.2.8:=192.0.2.14/32))" as the matching 441 filter, "cn=inetResources,dc=arpa" as the search base, and 442 the global query defaults defined in [FIRS-CORE]. 444 f. Assume that the queried server returns a continuation 445 reference referral which points to 446 "ldap:///cn=inetResources,dc=arin,dc=net". The 447 distinguished name element of 448 "cn=inetResources,dc=arin,dc=net" will be used as the new 449 search base, while "dc=arin,dc=net" will be used as the new 450 authoritative partition. 452 g. Initiate a DNS lookup for the SRV resource records 453 associated with "_ldap._tcp. arin.net." For the purpose of 454 this example, assume that this lookup succeeds, with the 455 DNS response message indicating that "firs.arin.net" is the 456 preferred LDAP server. 458 h. Submit an LDAPv3 query to the specified server, using 459 "(&(objectClass=inetIpv4Network) 460 (1.3.6.1.4.1.7161.1.2.8:=192.0.2.14/32)" as the matching 461 filter, "cn=inetResources,dc=arin,dc=net" as the search 462 base, and the global query defaults defined in [FIRS-CORE]. 464 i. Assume that no other referrals are received. Display the 465 answer data which has been received and exit the query. 467 6. Security Considerations 469 Security considerations are discussed in [FIRS-ARCH]. 471 7. IANA Considerations 473 This specification uses the "dc=arpa" directory partition by 474 default, with the expectation that FIRS-capable LDAP servers will 475 be established, with this partition containing IPv4-specific 476 entries which will provide referrals to the appropriate 477 registrar's partitions. It is further expected that IANA will 478 oversee the creation and management of the ARPA domain's LDAP SRV 479 resource records, the "dc=arpa" LDAP partition, and the necessary 480 LDAP servers. 482 The inetIpv4DelegationStatus attribute uses numeric code values. 483 It is expected that IANA will manage the assignment of these 484 values. 486 Additional IANA considerations are discussed in [FIRS-ARCH]. 488 8. Author's Addresses 490 Eric A. Hall 491 ehall@ehsco.com 493 9. Normative References 495 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 496 and Sataluri, S. "Using Domains in LDAP/X.500 497 DNs", RFC 2247, January 1998. 499 [RFC2251] Wahl, M., Howes, T., and Kille, S. 500 "Lightweight Directory Access Protocol (v3)", 501 RFC 2251, December 1997. 503 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 504 S. "Lightweight Directory Access Protocol 505 (v3): Attribute Syntax Definitions", RFC 2252, 506 December 1997. 508 [RFC2254] Howes, T. "The String Representation of LDAP 509 Search Filters", RFC 2254, December 1997. 511 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 512 Service: Architecture and Implementation 513 Guide", draft-ietf-crisp-firs-arch-01, May 514 2003. 516 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 517 System Numbers in the Federated Internet 518 Registry Service", draft-ietf-crisp-firs-asn- 519 01, May 2003. 521 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 522 Persons in the Federated Internet Registry 523 Service", draft-ietf-crisp-firs-contact-01, 524 May 2003. 526 [FIRS-CORE] Hall, E. "The Federated Internet Registry 527 Service: Core Elements", draft-ietf-crisp- 528 firs-core-01, May 2003. 530 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 531 the Federated Internet Registry Service", 532 draft-ietf-crisp-firs-dns-01, May 2003. 534 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 535 Records in the Federated Internet Registry 536 Service", draft-ietf-crisp-firs-dnsrr-01, May 537 2003. 539 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 540 Blocks in the Federated Internet Registry 541 Service", draft-ietf-crisp-firs-ipv4-01, May 542 2003. 544 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 545 Blocks in the Federated Internet Registry 546 Service", draft-ietf-crisp-firs-ipv6-01, May 547 2003. 549 10. Acknowledgments 551 Funding for the RFC editor function is currently provided by the 552 Internet Society. 554 Portions of this document were funded by Verisign Labs. 556 The first version of this specification was co-authored by Andrew 557 Newton of Verisign Labs, and subsequent versions continue to be 558 developed with his active participation. 560 11. Changes from Previous Versions 562 draft-ietf-crisp-firs-ipv4-01: 564 * Several clarifications and corrections have been made. 566 draft-ietf-crisp-firs-ipv4-00: 568 * Restructured the document set. 570 * "Attribute references" have been eliminated from the 571 specification. All referential attributes now provide 572 actual data instead of URL pointers to data. Clients that 573 wish to retrieve these values will need to start new 574 queries using the data values instead of URLs. 576 * The attribute-specific operational attributes have been 577 eliminated as unnecessary. 579 * The inetIpv4Registrar and inetIpv4Registry attributes were 580 added. 582 * Several attributes had their OIDs changed. NOTE THAT THIS 583 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 584 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 586 * Several typographical errors have been fixed. 588 * Some unnecessary text has been removed. 590 12. Full Copyright Statement 592 Copyright (C) The Internet Society (2003). All Rights Reserved. 594 This document and translations of it may be copied and furnished 595 to others, and derivative works that comment on or otherwise 596 explain it or assist in its implementation may be prepared, 597 copied, published and distributed, in whole or in part, without 598 restriction of any kind, provided that the above copyright notice 599 and this paragraph are included on all such copies and derivative 600 works. However, this document itself may not be modified in any 601 way, such as by removing the copyright notice or references to the 602 Internet Society or other Internet organizations, except as needed 603 for the purpose of developing Internet standards in which case the 604 procedures for copyrights defined in the Internet Standards 605 process must be followed, or as required to translate it into 606 languages other than English. 608 The limited permissions granted above are perpetual and will not 609 be revoked by the Internet Society or its successors or assigns. 611 This document and the information contained herein is provided on 612 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 613 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 614 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 615 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.