idnits 2.17.1 draft-ietf-weirds-bootstrap-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2014) is 3417 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: 'RFC5226' is defined on line 742, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-13 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-16 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track December 18, 2014 5 Expires: June 21, 2015 7 Finding the Authoritative Registration Data (RDAP) Service 8 draft-ietf-weirds-bootstrap-11.txt 10 Abstract 12 This document specifies a method to find which Registration Data 13 Access Protocol (RDAP) server is authoritative to answer queries for 14 a requested scope, such as domain names, IP addresses or Autonomous 15 System numbers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 21, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 53 3. Structure of the RDAP Bootstrap Service Registries . . . . . 3 54 4. Domain Name RDAP Bootstrap Service Registry . . . . . . . . . 5 55 5. Internet Numbers RDAP Bootstrap Service Registries . . . . . 6 56 5.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 6 57 5.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 7 58 5.3. Autonomous Systems RDAP Bootstrap Service Registry . . . 8 59 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 61 8. Deployment and Implementation Considerations . . . . . . . . 10 62 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11 64 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11 65 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 12.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 14 69 12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 14 70 12.3. Autonomous System Number Space RDAP Bootstrap Service 71 Registry . . . . . . . . . . . . . . . . . . . . . . . . 15 72 12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 15 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 14.2. Non-Normative References . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Querying and retrieving registration data from registries are defined 82 in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap 83 -query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. 84 These documents do not specify where to send the queries. This 85 document specifies a method to find which server is authoritative to 86 answer queries for the requested scope. 88 Top-level domains(TLD), Autonomous System numbers (AS), and network 89 blocks are delegated by IANA to Internet registries such as TLD 90 registries and Regional Internet Registries (RIR) that then issue 91 further delegations and maintain information about them. Thus, the 92 bootstrap information needed by RDAP clients is best generated from 93 data and processes already maintained by IANA, which registries 94 already exist at [ipv4reg], [ipv6reg], [asreg], and [domainreg]. 96 This document requests IANA to create new registries based on a JSON 97 format specified in this document, herein named RDAP Bootstrap 98 Service Registries. These new registries are based on the existing 99 entries of the above mentioned registries. An RDAP client fetches 100 the RDAP Bootstrap Service Registries, extracts the data and then 101 performs a match with the query data to find the authoritative 102 registration data server and appropriate query base URL. 104 2. Conventions Used In This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Structure of the RDAP Bootstrap Service Registries 112 The RDAP Bootstrap Service Registries, as specified in Section 12 113 below, will be made available as JSON [RFC7159] objects, to be 114 retrieved via HTTP from a location specified by IANA. The JSON 115 object for each registry contains a series of members containing 116 metadata about the registry such as a version identifier, a timestamp 117 of the publication date of the registry and a description. 118 Additionally, a "services" member contains the registry items 119 themselves, as an array. Each item of the array contains a second- 120 level array, with two elements, each of them being a third-level 121 array. 123 Each element of the Services array is a second-level array with two 124 elements: in order, an Entry Array and a Service URL Array. 126 The Entry Array contains all entries that have the same set of base 127 RDAP URLs. The Service URL Array contains the list of base RDAP URLs 128 usable for the entries found in the Entry Array. Elements within 129 these two arrays are not sorted in any way. 131 An example structure of the JSON output of a RDAP Bootstrap Service 132 Registry is illustrated: 134 { 135 "version": "1.0", 136 "publication": "YYYY-MM-DDTHH:MM:SSZ", 137 "description": "Some text", 138 "services": [ 139 [ 140 ["entry1", "entry2", "entry3"], 141 [ 142 "https://registry.example.com/myrdap/", 143 "http://registry.example.com/myrdap/" 144 ] 145 ], 146 [ 147 ["entry4"], 148 [ 149 "http://example.org/" 150 ] 151 ] 152 ] 153 } 155 The formal syntax is described in Section 10. 157 The "version" corresponds to the format version of the registry. 158 This specification defines version "1.0". 160 The syntax of "publication" value conforms to the Internet date/time 161 format [RFC3339]. The value is the latest update date of the 162 registry by IANA. 164 The optional "description" string can contain a comment regarding the 165 content of the bootstrap object. 167 Per [RFC7258], in each array of base RDAP URLs, the secure versions 168 of the transport protocol SHOULD be preferred and tried first. For 169 example, if the base RDAP URLs array contain both https and http 170 URLs, the bootstrap client SHOULD try the https version first. 172 Base RDAP URLs MUST have a trailing "/" character because they are 173 concatenated to the various segments defined in 174 [I-D.ietf-weirds-rdap-query]. 176 JSON names MUST follow the format recommendations of 177 [I-D.ietf-weirds-using-http]. Any unrecognized JSON object 178 properties or values MUST be ignored by implementations. 180 Internationalized Domain Names labels used as entries or base RDAP 181 URLs in the registries defined in this document MUST be only 182 represented using their A-Label form as defined in [RFC5890]. 184 All Domain Names labels used as entries or base RDAP URLs in the 185 registries defined in this document MUST be only represented in 186 lowercase. 188 4. Domain Name RDAP Bootstrap Service Registry 190 The JSON output of this registry contains domain labels entries 191 attached to the root, grouped by base RDAP URLs, as shown in this 192 example. 194 { 195 "version": "1.0", 196 "publication": "YYYY-MM-DDTHH:MM:SSZ", 197 "description": "Some text", 198 "services": [ 199 [ 200 ["net", "com"], 201 [ 202 "https://registry.example.com/myrdap/" 203 ] 204 ], 205 [ 206 ["org", "mytld"], 207 [ 208 "http://example.org/" 209 ] 210 ], 211 [ 212 ["xn--zckzah"], 213 [ 214 "https://example.net/rdapxn--zckzah/", 215 "http://example.net/rdapxn--zckzah/" 216 ] 217 ] 218 ] 219 } 221 The domain names authoritative registration data service is found by 222 doing the label-wise longest match of the target domain name with the 223 domain values in the Entry Arrays in the IANA Domain Name RDAP 224 Bootstrap Service Registry. The match is done per label, from right 225 to left. If the longest match results in multiple entries, then 226 those entries are considered equivalent. The values contained in the 227 Service URL Array of the matching second-level array are the valid 228 base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. 230 For example, a domain RDAP query for a.b.example.com matches the com 231 entry in one of the arrays of the registry. The base RDAP URL for 232 this query is then taken from the second element of the array, which 233 is an array of base RDAP URLs valid for this entry. The client 234 chooses one of the base URLs from this array; in this example it 235 chooses the only one available, "https://registry.example.com/ 236 myrdap/". The segment specified in [I-D.ietf-weirds-rdap-query] is 237 then appended to the base URL to complete the query. The complete 238 query is then "https://registry.example.com/myrdap/domain/ 239 a.b.example.com". 241 If a domain RDAP query for a.b.example.com matches both com and 242 example.com entries in the registry, then the longest match applies 243 and the example.com entry is used by the client. 245 If the registry contains entries such as com and goodexample.com, 246 then a domain RDAP query for example.com only match com entry, 247 because matching is done on a per label basis. 249 The entry for the root of the domain name space is specified as "". 251 5. Internet Numbers RDAP Bootstrap Service Registries 253 This section discusses IPv4 and IPv6 address space and autonomous 254 system numbers. 256 For IP address space, the authoritative registration data service is 257 found by doing a longest match of the target address with the values 258 of the arrays in the corresponding Address Space RDAP Bootstrap 259 Service registry. The longest match is done the same way as for 260 routing: the addresses are converted in binary form and then the 261 binary strings are compared to find the longest match up to the 262 specified prefix length. The values contained in the second element 263 of the array are the base RDAP URLs as described in 264 [I-D.ietf-weirds-rdap-query]. The longest match method enables 265 covering prefixes of a larger address space pointing to one base RDAP 266 URL while more specific prefixes within the covering prefix are being 267 served by another base RDAP URL. 269 5.1. IPv4 Address Space RDAP Bootstrap Service Registry 271 The JSON output of this registry contains IPv4 prefix entries, 272 specified in CIDR format [RFC4632] and grouped by RDAP URLs, as shown 273 in this example. 275 { 276 "version": "1.0", 277 "publication": "2024-01-07T10:11:12Z", 278 "description": "RDAP Bootstrap file for example registries.", 279 "services": [ 280 [ 281 ["1.0.0.0/8", "192.0.0.0/8"], 282 [ 283 "https://rir1.example.com/myrdap/" 284 ] 285 ], 286 [ 287 ["28.2.0.0/16", "192.0.2.0/24"], 288 [ 289 "http://example.org/" 290 ] 291 ], 292 [ 293 ["28.3.0.0/16"], 294 [ 295 "https://example.net/rdaprir2/", 296 "http://example.net/rdaprir2/" 297 ] 298 ] 299 ] 300 } 302 For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8" 303 entry and the "192.0.2.0/24" entry in the example registry above. 304 The latter is chosen by the client given the longest match. The base 305 RDAP URL for this query is then taken from the second element of the 306 array, which is an array of base RDAP URLs valid for this entry. The 307 client chooses one of the base URLs from this array; in this example 308 it chooses the only one available, "http://example.org/". The 309 {resource} specified in [I-D.ietf-weirds-rdap-query] is then appended 310 to the base URL to complete the query. The complete query is then 311 "https://example.org/ip/192.0.2.1/25". 313 5.2. IPv6 Address Space RDAP Bootstrap Service Registry 315 The JSON output of this registry contains IPv6 prefix entries, using 316 [RFC4291] text representation of address prefixes format, grouped by 317 base RDAP URLs, as shown in this example. 319 { 320 "version": "1.0", 321 "publication": "2024-01-07T10:11:12Z", 322 "description": "RDAP Bootstrap file for example registries.", 323 "services": [ 324 [ 325 ["2001:0200::/23", "2001:db8::/32"], 326 [ 327 "https://rir2.example.com/myrdap/" 328 ] 329 ], 330 [ 331 ["2600::/16", "2100:ffff::/32"], 332 [ 333 "http://example.org/" 334 ] 335 ], 336 [ 337 ["2001:0200:1000::/36"], 338 [ 339 "https://example.net/rdaprir2/", 340 "http://example.net/rdaprir2/" 341 ] 342 ] 343 ] 344 } 346 For example, a query for "2001:0200:1000::/48" matches the 347 "2001:0200::/23" entry and the "2001:0200:1000::/36" entry in the 348 example registry above. The latter is chosen by the client given the 349 longest match. The base RDAP URL for this query is then taken from 350 the second element of the array, which is an array of base RDAP URLs 351 valid for this entry. The client chooses one of the base URLs from 352 this array; in this example it chooses "https://example.net/ 353 rdaprir2/" because it's the secure version of the protocol. The 354 segment specified in [I-D.ietf-weirds-rdap-query] is then appended to 355 the base URL to complete the query. The complete query is therefore 356 "https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the target 357 RDAP server does not answer, the client can then use another URL 358 prefix from the array. 360 5.3. Autonomous Systems RDAP Bootstrap Service Registry 362 The JSON output of this contains Autonomous Systems Number Ranges 363 entries, grouped by base RDAP URLs, as shown in this example. The 364 Entry Array is an array containing the list of AS number ranges 365 served by the base RDAP URLs found in the second element. The array 366 always contains two AS numbers represented in decimal format which 367 represents the range of AS Numbers between the two elements of the 368 array. A single AS number is represented as a range of two identical 369 AS numbers. 371 { 372 "version": "1.0", 373 "publication": "2024-01-07T10:11:12Z", 374 "description": "RDAP Bootstrap file for example registries.", 375 "services": [ 376 [ 377 ["2045-2045"], 378 [ 379 "https://rir3.example.com/myrdap/" 380 ] 381 ], 382 [ 383 ["10000-12000", "300000-400000"], 384 [ 385 "http://example.org/" 386 ] 387 ], 388 [ 389 ["64512-65534"], 390 [ 391 "http://example.net/rdaprir2/", 392 "https://example.net/rdaprir2/" 393 ] 394 ] 395 ] 396 } 398 For example, a query for AS 65411 matches the 64512-65534 entry in 399 the example registry above. The base RDAP URL for this query is then 400 taken from the second element of the array, which is an array of base 401 RDAP URLs valid for this entry. The client chooses one of the base 402 URLs from this array; in this example it chooses 403 "https://example.net/rdaprir2/". The segment specified in 404 [I-D.ietf-weirds-rdap-query] is then appended to the base URL to 405 complete the query. The complete query is therefore 406 "https://example.net/rdaprir2/autnum/65411". If the server does not 407 answer, the client can then use another URL prefix from the array. 409 6. Entity 411 Entities (such as contacts, registrants or registrars) can be queried 412 by handle as described in [I-D.ietf-weirds-rdap-query]. Since there 413 is no global namespace for entities, this document does not describe 414 how to find the authoritative RDAP server for entities. It is 415 possible however that, if the entity identifier was received from a 416 previous query, the same RDAP server could be queried for that entity 417 or the entity identifier itself is a fully referenced URL that can be 418 queried. 420 7. Non-existent Entries or RDAP URL Values 422 The registries may not contain the requested value. In these cases, 423 there is no known RDAP server for that requested value and the client 424 SHOULD provide an appropriate error message to the user. 426 8. Deployment and Implementation Considerations 428 This method relies on the fact that RDAP clients are fetching the 429 IANA registries to then find the servers locally. Clients SHOULD NOT 430 fetch the registry on every RDAP request. Clients SHOULD cache the 431 registry, but use underlying protocol signalling, such as the HTTP 432 Expires header field [RFC7234], to identify when it is time to 433 refresh the cached registry. 435 If the query data does not match any entry in the client cached 436 registry, then the client may implement various methods, such as the 437 following: 439 o In the case of a domain object, the client may first query the DNS 440 to see if the respective entry has been delegated or if it is 441 mistyped information by the user. The DNS query could be to fetch 442 the NS records for the TLD domain. If the DNS answer is negative, 443 then there is no need to fetch the new version of the registry. 444 However, if the DNS answer is positive, this may mean that the 445 currently cached registry is no longer current. The client could 446 then fetch the registry, parse and then do the normal matching as 447 specified above. This method may not work for all types of RDAP 448 objects. 450 o If the client knows the existence of an RDAP aggregator or 451 redirector and its associated base URL, and trusts that service, 452 then it could send the query to the redirector, which would 453 redirect the client if it knows the authoritative server that 454 client has not found. 456 Some authorities of registration data may work together on sharing 457 their information for a common service, including mutual redirection 458 [I-D.ietf-weirds-redirects]. 460 When a new object is allocated, such as a new AS range, a new TLD or 461 a new IP address range, there is no guarantee that this new object 462 will have an entry in the corresponding bootstrap RDAP registry, 463 since the setup of the RDAP server for this new entry may become live 464 and registered later. Therefore, the clients should expect that even 465 if an object, such as TLD, IP address range or AS range is allocated, 466 the existence of the entry in the corresponding bootstrap registry is 467 not guaranteed. 469 9. Limitations 471 This method does not provide a direct way to find authoritative RDAP 472 servers for any other objects than the ones described in this 473 document. In particular, the following objects are not bootstrapped 474 with the method described in this document: 476 o entities 478 o queries using search patterns that do not contain a terminating 479 string that matches some entries in the registries 481 o nameservers 483 o help 485 10. Formal Definition 487 This section is the formal definition of the registries. The 488 structure of JSON objects and arrays using a set of primitive 489 elements is defined in [RFC7159]. Those elements are used to 490 describe the JSON structure of the registries. 492 10.1. Imported JSON Terms 494 o OBJECT: a JSON object, defined in Section 2.2 of [RFC7159] 496 o MEMBER: a member of a JSON object, defined in Section 2.2 of 497 [RFC7159] 499 o MEMBER-NAME: the name of a MEMBER, defined as a "string" in 500 Section 2.2 of [RFC7159] 502 o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in 503 Section 2.2 of [RFC7159] 505 o ARRAY: an array, defined in Section 2.3 of [RFC7159] 507 o ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of 508 [RFC7159] 510 o STRING: a "string" as defined in Section 2.5 of [RFC7159] 512 10.2. Registry Syntax 514 Using the above terms for the JSON structures, the syntax of a 515 registry is defined as follows: 517 o rdap-bootstrap-registry: an OBJECT containing a MEMBER version and 518 a MEMBER publication and a optional MEMBER description and a 519 MEMBER services-list 521 o version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a 522 STRING 524 o publication: a MEMBER with MEMBER-NAME "publication" and MEMBER- 525 VALUE a STRING 527 o description: a MEMBER with MEMBER-NAME "description" and MEMBER- 528 VALUE a STRING 530 o services-list: a MEMBER with MEMBER-NAME "services" and MEMBER- 531 VALUE a services-array 533 o services-array: an ARRAY, where each ARRAY-VALUE is a service 535 o service: an ARRAY of 2 elements, where the first ARRAY-VALUE is a 536 an entry-list and the second ARRAY-VALUE is a service-uri-list 538 o entry-list: an ARRAY, where each ARRAY-VALUE is an entry 540 o entry: a STRING 542 o service-uri-list: an ARRAY, where each ARRAY-VALUE is a service- 543 uri 545 o service-uri: a STRING 547 11. Security Considerations 549 By providing a bootstrap method to find RDAP servers, this document 550 helps to ensure that the end-users will get the RDAP data from an 551 authoritative source, instead of from rogue sources. The method has 552 the same security properties as the RDAP protocols themselves. The 553 transport used to access the registries could be more secure by using 554 TLS [RFC5246] if IANA supports it. 556 Additional considerations on using RDAP are described in 557 [I-D.ietf-weirds-rdap-sec] 559 12. IANA Considerations 561 IANA is requested to make the RDAP Bootstrap Services Registries, 562 created below, available as JSON objects. The contents of these 563 registries are described in Section 3, Section 4 and Section 5, with 564 the formal syntax specified in Section 10. 566 The process for adding or updating entries in these registries 567 differs from the normal IANA registry processes: these registries are 568 generated from the data, processes, and policies maintained by IANA 569 in their allocation registries (([ipv4reg], [ipv6reg], [asreg], and 570 [domainreg])), with the addition of new RDAP server information. 572 IANA is expected to create and update RDAP Bootstrap Services 573 Registries entries from the allocation registries as those registries 574 are updated. 576 This document does not change any policies related to the allocation 577 registries, but IANA will need to provide a mechanism for collecting 578 the RDAP server information. The RDAP Bootstrap Services Registries 579 will start empty and will be gradually populated as registrants of 580 domains and address spaces provide RDAP server information to IANA. 582 IANA is asked to create a new top-level category on the Protocol 583 Registries page, http://www.iana.org/protocols . The group will be 584 called "Registration Data Access Protocol (RDAP) Registries". Each 585 of the RDAP Bootstrap Services Registries needs to be made available 586 for general public on-demand download in the JSON format, and that 587 registry's URI will be listed directly on the Protocol Registries 588 page, in addition to being linked from the registry's name. Those 589 entries in the new category might look like this: 591 ------------------------------ 592 Registration Data Access Protocol (RDAP) 594 Bootstrap Service Registry RFC xxxx 595 for IPv4 Address Space http://iana URI for IPv4 bootstrap 597 Bootstrap Service Registry RFC xxxx 598 for IPv6 Address Space http://iana URI for IPv6 bootstrap 600 Bootstrap Service Registry RFC xxxx 601 for AS Number Space http://iana URI for ASN bootstrap 603 Bootstrap Service Registry RFC xxxx 604 for Domain Name Space http://iana URI for DN bootstrap 605 ------------------------------ 607 Other normal registries will be added to this group by other 608 documents, but it is important that the URIs for these registries be 609 clearly listed on the main page, to make those URIs obvious to 610 implementors -- these are registries that will be accessed by 611 software, as well as reference information for humans. 613 Because these registries will be accessed by software, the download 614 demand for the RDAP Bootstrap Services Registries may be unusually 615 high compared to normal IANA registries. The technical 616 infrastructure by which registries are published will need to be 617 reviewed, and might need to be augmented. 619 As discussed in Section Section 8, software that accesses these 620 registries will depend on the HTTP Expires header field to limit 621 their query rate. It is, therefore, important for that header field 622 to be properly set to provide timely information as the registries 623 change, while maintaining a reasonable load on the IANA servers. 625 The HTTP Content-Type returned to clients accessing these JSON- 626 formatted registries MUST be "application/json", as defined in 627 [RFC7159]. 629 Because of how information in the RDAP Bootstrap Services Registries 630 is grouped and formatted, the registry entries may not be sortable. 631 It is therefore not required or expected that the entries be sorted 632 in any way. 634 12.1. IPv4 Address Space RDAP Bootstrap Service Registry 636 Entries in this registry contain at least the following: 638 o a CIDR [RFC4632] specification of the network block being 639 registered 641 o one or more URLs that provide the RDAP service regarding this 642 registration. 644 12.2. IPv6 Address Space RDAP Bootstrap Service Registry 646 Entries in this registry contain at least the following: 648 o an IPv6 prefix [RFC4291] specification of the network block being 649 registered 651 o one or more URLs that provide the RDAP service regarding this 652 registration. 654 12.3. Autonomous System Number Space RDAP Bootstrap Service Registry 656 Entries in this registry contain at least the following: 658 o a range of Autonomous System numbers being registered 660 o one or more URLs that provide the RDAP service regarding this 661 registration. 663 12.4. Domain Name Space RDAP Bootstrap Service Registry 665 Entries in this registry contain at least the following: 667 o a domain name attached to the root being registered 669 o one or more URLs that provide the RDAP service regarding this 670 registration. 672 13. Acknowledgements 674 The WEIRDS working group had multiple discussions on this topic, 675 including a session during IETF 84, where various methods such as in- 676 DNS and others were debated. The idea of using IANA registries was 677 discovered by the editor during discussions with his colleagues as 678 well as by a comment from Andy Newton. All the people involved in 679 these discussions are herein acknowledged. Linlin Zhou, Jean- 680 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 681 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom 682 Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete 683 Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari 684 Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, Jean- 685 Francois Tremblay have provided input and suggestions to this 686 document. Guillaume Leclanche was a co-editor of this document for 687 some revisions; his support is therein acknowledged and greatly 688 appreciated. The section on formal definition was inspired by 689 section 6.2 of [RFC7071]. 691 14. References 693 14.1. Normative References 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 699 Internet: Timestamps", RFC 3339, July 2002. 701 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 702 Architecture", RFC 4291, February 2006. 704 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 705 (CIDR): The Internet Address Assignment and Aggregation 706 Plan", BCP 122, RFC 4632, August 2006. 708 [RFC5890] Klensin, J., "Internationalized Domain Names for 709 Applications (IDNA): Definitions and Document Framework", 710 RFC 5890, August 2010. 712 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 713 Interchange Format", RFC 7159, March 2014. 715 14.2. Non-Normative References 717 [I-D.ietf-weirds-json-response] 718 Newton, A. and S. Hollenbeck, "JSON Responses for the 719 Registration Data Access Protocol (RDAP)", draft-ietf- 720 weirds-json-response-13 (work in progress), December 2014. 722 [I-D.ietf-weirds-rdap-query] 723 Newton, A. and S. Hollenbeck, "Registration Data Access 724 Protocol Query Format", draft-ietf-weirds-rdap-query-16 725 (work in progress), October 2014. 727 [I-D.ietf-weirds-rdap-sec] 728 Hollenbeck, S. and N. Kong, "Security Services for the 729 Registration Data Access Protocol", draft-ietf-weirds- 730 rdap-sec-12 (work in progress), December 2014. 732 [I-D.ietf-weirds-redirects] 733 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 734 for Registration Data Access Protocol", draft-ietf-weirds- 735 redirects-04 (work in progress), July 2014. 737 [I-D.ietf-weirds-using-http] 738 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 739 Registration Data Access Protocol (RDAP)", draft-ietf- 740 weirds-using-http-15 (work in progress), November 2014. 742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 744 May 2008. 746 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 747 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 749 [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for 750 Reputation Interchange", RFC 7071, November 2013. 752 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 753 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 754 2014. 756 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 757 Attack", BCP 188, RFC 7258, May 2014. 759 [asreg] Internet Assigned Numbers Authority(IANA), , "Autonomous 760 System (AS) Numbers", . 763 [domainreg] 764 Internet Assigned Numbers Authority(IANA), , "Root Zone 765 Database", . 767 [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address 768 Space", . 771 [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global 772 Unicast Address Assignments", 773 . 776 Author's Address 778 Marc Blanchet 779 Viagenie 780 246 Aberdeen 781 Quebec, QC G1R 2E1 782 Canada 784 Email: Marc.Blanchet@viagenie.ca 785 URI: http://viagenie.ca