idnits 2.17.1 draft-ietf-weirds-bootstrap-08.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 (October 13, 2014) is 3482 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) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-10 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-15 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-13 -- 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 October 13, 2014 5 Expires: April 16, 2015 7 Finding the Authoritative Registration Data (RDAP) Service 8 draft-ietf-weirds-bootstrap-08.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 April 16, 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 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 . . . 13 69 12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 13 70 12.3. Autonomous System Number Space RDAP Bootstrap Service 71 Registry . . . . . . . . . . . . . . . . . . . . . . . . 14 72 12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 14 73 12.5. Additional Consideration . . . . . . . . . . . . . . . . 14 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 14.2. Non-Normative References . . . . . . . . . . . . . . . . 15 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Querying and retrieving registration data from registries are defined 83 in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap 84 -query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. 85 These documents do not specify where to send the queries. This 86 document specifies a method to find which server is authoritative to 87 answer queries for the requested scope. 89 TLDs, AS numbers, and network blocks are delegated by IANA to 90 registrars that then issue further delegations and maintain 91 information about them. Thus, obviously the bootstrap information 92 needed by RDAP clients is best generated from data and processes 93 already maintained by IANA, whose registries already exist at 94 [ipv4reg], [ipv6reg], [asreg], and [domainreg]. 96 The required new functionality in support of RDAP could be 97 accomplished by augmenting these registries to contain new fields, or 98 creating second parallel registries containing the extra fields whose 99 entries mirror the existing ones. Either approach will satisfy the 100 needs of this document. This document requests IANA to make these 101 registries available for the specific purpose of RDAP use, herein 102 named RDAP Bootstrap Service Registries. An RDAP client fetches the 103 RDAP Bootstrap Service Registries, extracts the data and then does a 104 match with the query data to find the authoritative registration data 105 server and appropriate query base URL. 107 2. Conventions Used In This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Structure of RDAP Bootstrap Service Registries 115 The RDAP Bootstrap Service Registries, as specified in Section 12, 116 will be made available as JSON [RFC7159] objects, to be retrieved via 117 HTTP from a location as specified by IANA. The JSON object for each 118 registry will start with a series of members that contain metadata 119 about the registry such as a version identifier, a timestamp of the 120 publication date of the registry and a description. Following that 121 is a "services" member which contains the registry items themselves, 122 as an array. Each item of the array contains a second-level array, 123 with two elements, each of them being a third-level array. 125 There is no assumption of sorting except that the two arrays found in 126 each second-level array MUST appear in the correct order: The entries 127 array are followed by the service URL array. An example structure of 128 the JSON output of a RDAP Bootstrap Service Registry is illustrated: 130 { 131 "version": "1.0", 132 "publication": "YYYY-MM-DDTHH:MM:SSZ", 133 "description": "Some text", 134 "services": [ 135 [ 136 ["entry1", "entry2", "entry3"], 137 [ 138 "https://registry.example.com/myrdap/", 139 "http://registry.example.com/myrdap/" 140 ] 141 ], 142 [ 143 ["entry4"], 144 [ 145 "http://example.org/" 146 ] 147 ] 148 ] 149 } 151 The formal syntax is described in Section 10. 153 The "version" corresponds to the format version of the registry. 154 This specification defines "1.0". 156 The syntax of "publication" value conforms to the Internet date/time 157 format [RFC3339]. 159 The optional "description" string can contain a comment regarding the 160 content of the bootstrap object. 162 Per [RFC7258], in each array of base RDAP URLs, the secure versions 163 of the transport protocol SHOULD be preferred and tried first. For 164 example, if the base RDAP URLs array contain both https and http 165 URLs, the bootstrap client SHOULD try the https version first. 167 Base RDAP URLs MUST have a trailing "/" character because they are 168 concatenated to the various segments defined in 169 [I-D.ietf-weirds-rdap-query]. 171 JSON names MUST follow the format recommendations of 172 [I-D.ietf-weirds-using-http]. Any unknown or unspecified JSON object 173 properties or values should be ignored by implementers. 175 Internationalized Domain Names labels used as entries or base RDAP 176 URLs in the registries defined in this document MUST be only 177 represented using their A-Label form as defined in [RFC5890]. 179 All Domain Names labels used as entries or base RDAP URLs in the 180 registries defined in this document MUST be only represented in 181 lowercase. 183 4. Domain Name RDAP Bootstrap Service Registry 185 The JSON output of this registry contains domain labels entries 186 attached to the root, grouped by base RDAP URLs, as shown in this 187 example. 189 { 190 "version": "1.0", 191 "publication": "YYYY-MM-DDTHH:MM:SSZ", 192 "description": "Some text", 193 "services": [ 194 [ 195 ["net", "com"], 196 [ 197 "https://registry.example.com/myrdap/" 198 ] 199 ], 200 [ 201 ["org", "mytld"], 202 [ 203 "http://example.org/" 204 ] 205 ], 206 [ 207 ["xn--zckzah"], 208 [ 209 "https://example.net/rdapxn--zckzah/", 210 "http://example.net/rdapxn--zckzah/" 211 ] 212 ] 213 ] 214 } 216 The domain names authoritative registration data service is found by 217 doing the label-wise longest match of the target domain name with the 218 domain values in the arrays in the IANA Domain Name RDAP Bootstrap 219 Service Registry. The values contained in the second element of the 220 array are the valid base RDAP URLs as described in 221 [I-D.ietf-weirds-rdap-query]. 223 For example, a domain RDAP query for a.b.example.com matches the com 224 entry in one of the arrays of the registry. The base RDAP URL for 225 this query is then taken from the second element of the array, which 226 is an array of base RDAP URLs valid for this entry. The client 227 chooses one of the base URLs from this array; in this example it 228 chooses the only one available, "https://registry.example.com/ 229 myrdap/". The segment specified in [I-D.ietf-weirds-rdap-query] is 230 then appended to the base URL to complete the query. The complete 231 query is then "https://registry.example.com/myrdap/domain/ 232 a.b.example.com". 234 If a domain RDAP query for a.b.example.com matches both com and 235 example.com entries in the registry, then the longest match applies 236 and the example.com entry is used by the client. 238 5. Internet Numbers RDAP Bootstrap Service Registries 240 This section discusses IPv4 and IPv6 address space and autonomous 241 system numbers. 243 For IP address space, the authoritative registration data service is 244 found by doing a longest match of the target address with the values 245 of the arrays in the corresponding Address Space RDAP Bootstrap 246 Service registry. The longest match is done the same way as for 247 routing: the addresses are converted in binary form and then the 248 binary strings are compared to find the longest match up to the 249 specified prefix length. The values contained in the second element 250 of the array are the base RDAP URLs as described in 251 [I-D.ietf-weirds-rdap-query]. The longest match method enables 252 covering prefixes of a larger address space pointing to one base RDAP 253 URL while more specific prefixes within the covering prefix being 254 served by another base RDAP URL. 256 5.1. IPv4 Address Space RDAP Bootstrap Service Registry 258 The JSON output of this registry contains IPv4 prefix entries, 259 specified in CIDR format and grouped by RDAP URLs, as shown in this 260 example. 262 { 263 "version": "1.0", 264 "publication": "2024-01-07T10:11:12Z", 265 "description": "RDAP Bootstrap file for example registries.", 266 "services": [ 267 [ 268 ["1.0.0.0/8", "192.0.0.0/8"], 269 [ 270 "https://rir1.example.com/myrdap/" 271 ] 272 ], 273 [ 274 ["28.2.0.0/16", "192.0.2.0/24"], 275 [ 276 "http://example.org/" 277 ] 278 ], 279 [ 280 ["28.3.0.0/16"], 281 [ 282 "https://example.net/rdaprir2/", 283 "http://example.net/rdaprir2/" 284 ] 285 ] 286 ] 287 } 289 For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8" 290 entry and the "192.0.2.0/24" entry in the example registry above. 291 The latter is chosen by the client given the longest match. The base 292 RDAP URL for this query is then taken from the second element of the 293 array, which is an array of base RDAP URLs valid for this entry. The 294 client chooses one of the base URLs from this array; in this example 295 it chooses the only one available, "http://example.org/". The 296 {resource} specified in [I-D.ietf-weirds-rdap-query] is then appended 297 to the base URL to complete the query. The complete query is then 298 "https://example.org/ip/192.0.2.1/25". 300 5.2. IPv6 Address Space RDAP Bootstrap Service Registry 302 The JSON output of this registry contains IPv6 prefix entries, using 303 [RFC4291] text representation of address prefixes format, grouped by 304 base RDAP URLs, as shown in this example. 306 { 307 "version": "1.0", 308 "publication": "2024-01-07T10:11:12Z", 309 "description": "RDAP Bootstrap file for example registries.", 310 "services": [ 311 [ 312 ["2001:0200::/23", "2001:db8::/32"], 313 [ 314 "https://rir2.example.com/myrdap/" 315 ] 316 ], 317 [ 318 ["2600::/16", "2100:ffff::/32"], 319 [ 320 "http://example.org/" 321 ] 322 ], 323 [ 324 ["2001:0200:1000::/28"], 325 [ 326 "https://example.net/rdaprir2/", 327 "http://example.net/rdaprir2/" 328 ] 329 ] 330 ] 331 } 333 For example, a query for "2001:0200:1000::/48" matches the 334 "2001:0200::/23" entry and the "2001:0200:1000::/28" entry in the 335 example registry above. The latter is chosen by the client given the 336 longest match. The base RDAP URL for this query is then taken from 337 the second element of the array, which is an array of base RDAP URLs 338 valid for this entry. The client chooses one of the base URLs from 339 this array; in this example it chooses "https://example.net/ 340 rdaprir2/" because it's the secure version of the protocol. The 341 segment specified in [I-D.ietf-weirds-rdap-query] is then appended to 342 the base URL to complete the query. The complete query is therefore 343 "https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the server 344 does not answer, the client can then use another URL prefix from the 345 array. 347 5.3. Autonomous Systems RDAP Bootstrap Service Registry 349 The JSON output of this contains Autonomous Systems Number Ranges 350 entries, grouped by base RDAP URLs, as shown in this example. The 351 first element of each second-level array is an array containing the 352 list of AS number ranges served by the base RDAP URLs found in the 353 second element. The array always contains two AS numbers which 354 represents the range of AS Numbers between the two elements of the 355 array. When the two AS numbers are identical, then it only refers to 356 that single AS number. 358 { 359 "version": "1.0", 360 "publication": "2024-01-07T10:11:12Z", 361 "description": "RDAP Bootstrap file for example registries.", 362 "services": [ 363 [ 364 ["2045-2045"], 365 [ 366 "https://rir3.example.com/myrdap/" 367 ] 368 ], 369 [ 370 ["10000-12000", "300000-400000"], 371 [ 372 "http://example.org/" 373 ] 374 ], 375 [ 376 ["64512-65534"], 377 [ 378 "http://example.net/rdaprir2/", 379 "https://example.net/rdaprir2/" 380 ] 381 ] 382 ] 383 } 385 For example, a query for AS 65411 matches the 64512-65534 entry in 386 the example registry above. The base RDAP URL for this query is then 387 taken from the second element of the array, which is an array of base 388 RDAP URLs valid for this entry. The client chooses one of the base 389 URLs from this array; in this example it chooses 390 "https://example.net/rdaprir2/". The segment specified in 391 [I-D.ietf-weirds-rdap-query] is then appended to the base URL to 392 complete the query. The complete query is therefore 393 "https://example.net/rdaprir2/autnum/65411". If the server does not 394 answer, the client can then use another URL prefix from the array. 396 6. Entity 398 Since there is no global namespace for entities, this document does 399 not describe how to find the authoritative RDAP server for entities. 400 It is possible however that, if the entity identifier was received 401 from a previous query, the same RDAP server could be queried for that 402 entity or the entity identifier itself is a fully referenced URL that 403 can be queried. 405 7. Non-existent Entries or RDAP URL Values 407 The registries may not contain the requested value or the base RDAP 408 URL value may be empty. In these cases, there is no known RDAP 409 server for that requested value and the client SHOULD provide an 410 appropriate error message to the user. 412 8. Deployment and Implementation Considerations 414 This method relies on the fact that RDAP clients are fetching the 415 IANA registries to then find the servers locally. Clients SHOULD NOT 416 fetch the registry on every RDAP request. Clients SHOULD cache the 417 registry, but use underlying protocol signalling, such as the HTTP 418 Expires header field [RFC7234], to identify when it is time to 419 refresh the cached registry. 421 If the query data does not match any entry in the client cached 422 registry, then the client may implement various methods, such as the 423 following: 425 o In the case of a domain object, the client may first query the DNS 426 to see if the respective entry has been delegated or if it is a 427 mistyped information by the user. The DNS query could be to fetch 428 the NS records for the TLD domain. If the DNS answer is negative, 429 then there is no need to fetch the new version of the registry. 430 However, if the DNS answer is positive, this may mean that the 431 currently cached registry is no longer current. The client could 432 then fetch the registry, parse and then do the normal matching as 433 specified above. This method may not work for all types of RDAP 434 objects. 436 o If the client knows the existence of an RDAP aggregator or 437 redirector and its associated base URL, and trusts that service, 438 then it could send the query to the redirector, which would 439 redirect the client if it knows the authoritative server that 440 client has not found. 442 Some authorities of registration data may work together on sharing 443 their information for a common service, including mutual redirection 444 [I-D.ietf-weirds-redirects]. 446 When a new object is allocated, such as a new AS range, a new TLD or 447 a new IP address range, there is no guarantee that this new object 448 will have an entry in the corresponding bootstrap RDAP registry, 449 since the setup of the RDAP server for this new entry may become live 450 and registered later. Therefore, the clients should expect that even 451 if an object, such as TLD, IP address range or AS range is allocated, 452 the existence of the entry in the corresponding bootstrap registry is 453 not guaranteed. 455 9. Limitations 457 This method does not provide a direct way to find authoritative RDAP 458 servers for any other objects than the ones described in this 459 document. In particular, the following objects are not bootstrapped 460 with the method described in this document: 462 o entities 464 o queries using search patterns that do not contain a terminating 465 string that matches some entries in the registries 467 o nameservers 469 o help 471 10. Formal Definition 473 This section is the formal definition of the registries. The 474 structure of JSON objects and arrays using a set of primitive 475 elements is defined in [RFC7159]. Those elements are used to 476 describe the JSON structure of the registries. 478 10.1. Imported JSON Terms 480 o OBJECT: a JSON object, defined in Section 2.2 of [RFC7159] 482 o MEMBER: a member of a JSON object, defined in Section 2.2 of 483 [RFC7159] 485 o MEMBER-NAME: the name of a MEMBER, defined as a "string" in 486 Section 2.2 of [RFC7159] 488 o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in 489 Section 2.2 of [RFC7159] 491 o ARRAY: an array, defined in Section 2.3 of [RFC7159] 493 o ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of 494 [RFC7159] 496 o STRING: a "string" as defined in Section 2.5 of [RFC7159] 498 10.2. Registry Syntax 500 Using the above terms for the JSON structures, the syntax of a 501 registry is defined as follows: 503 o rdap-bootstrap-registry: an OBJECT containing a MEMBER version and 504 a MEMBER publication and a MEMBER description and a MEMBER 505 services-list 507 o version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a 508 STRING 510 o publication: a MEMBER with MEMBER-NAME "publication" and MEMBER- 511 VALUE a STRING 513 o description: a MEMBER with MEMBER-NAME "description" and MEMBER- 514 VALUE a STRING 516 o services-list: a MEMBER with MEMBER-NAME "services" and MEMBER- 517 VALUE a services-array 519 o services-array: an ARRAY, where each ARRAY-VALUE is a service 521 o service: an ARRAY of 2 elements, where the first ARRAY-VALUE is a 522 an entry-list and the second ARRAY-VALUE is a service-uri-list 524 o entry-list: an ARRAY, where each ARRAY-VALUE is a entry 526 o entry: a STRING 528 o service-uri-list: an ARRAY, where each ARRAY-VALUE is a service- 529 uri 531 o service-uri: a STRING 533 11. Security Considerations 535 By providing a bootstrap method to find RDAP servers, this document 536 helps to ensure that the end-users will get the RDAP data from an 537 authoritative source, instead of from rogue sources. The method has 538 the same security properties as the RDAP protocols themselves. The 539 transport used to access the registries could be more secure by using 540 TLS [RFC5246] if IANA supports it. 542 12. IANA Considerations 544 IANA is requested to make the RDAP Bootstrap Services Registries 545 described below available as JSON objects, the syntax of which are 546 described by section 10. The process for adding or updating entries 547 into these registries does not correspond to the registration 548 policies described in [RFC5226]; as stated earlier, these registries 549 are generated from the data, processes, and policies maintained by 550 IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg], 551 and [domainreg]). IANA is expected to generate the RDAP Bootstrap 552 Services Registries data from these above mentioned registries, 553 according to their own registration policies. This document does not 554 extend or otherwise change those policies. 556 Each of the RDAP Bootstrap Services Registries needs to be made 557 available for general public on-demand download in the JSON format at 558 a location determined by IANA. 560 IANA is also advised that the download demand for the RDAP Bootstrap 561 Services Registries may be unusually high compared to other 562 registries that exist already. The technical infrastructure by which 563 registries are published may need to be reviewed. 565 Multiple entries pointing to the same set of URLs are grouped 566 together in an array. Since multiple entries of non contiguous space 567 may be grouped together, the registry may not be sortable by entries, 568 therefore it is not required or expected that the entries be sorted 569 in a registry. 571 12.1. IPv4 Address Space RDAP Bootstrap Service Registry 573 Entries in this registry contain at least the following: 575 o a CIDR specification of the network block being registered 577 o one or more URLs that provide the RDAP service regarding this 578 registration. 580 12.2. IPv6 Address Space RDAP Bootstrap Service Registry 582 Entries in this registry contain at least the following: 584 o an IPv6 prefix [RFC4291] specification of the network block being 585 registered 587 o one or more URLs that provide the RDAP service regarding this 588 registration. 590 12.3. Autonomous System Number Space RDAP Bootstrap Service Registry 592 Entries in this registry contain at least the following: 594 o a range of Autonomous System numbers being registered 596 o one or more URLs that provide the RDAP service regarding this 597 registration. 599 12.4. Domain Name Space RDAP Bootstrap Service Registry 601 Entries in this registry contain at least the following: 603 o a domain name attached to the root being registered 605 o one or more URLs that provide the RDAP service regarding this 606 registration. 608 12.5. Additional Consideration 610 The HTTP Content-Type returned to clients accessing the JSON output 611 of the registries MUST be "application/json" as defined in [RFC7159]. 613 13. Acknowledgements 615 The WEIRDS working group had multiple discussions on this topic, 616 including a session during IETF 84, where various methods such as in- 617 DNS and others were debated. The idea of using IANA registries was 618 discovered by the editor during discussions with his colleagues as 619 well as by a comment from Andy Newton. All the people involved in 620 these discussions are herein acknowledged. Linlin Zhou, Jean- 621 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 622 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom 623 Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete 624 Resnick have provided input and suggestions to this document. 625 Guillaume Leclanche was a co-editor of this document for some 626 revisions; his support is therein acknowledged and greatly 627 appreciated. The section on formal definition was inspired by 628 section 6.2 of [RFC7071]. 630 14. References 632 14.1. Normative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 638 Internet: Timestamps", RFC 3339, July 2002. 640 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 641 Architecture", RFC 4291, February 2006. 643 [RFC5890] Klensin, J., "Internationalized Domain Names for 644 Applications (IDNA): Definitions and Document Framework", 645 RFC 5890, August 2010. 647 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 648 Interchange Format", RFC 7159, March 2014. 650 14.2. Non-Normative References 652 [I-D.ietf-weirds-json-response] 653 Newton, A. and S. Hollenbeck, "JSON Responses for the 654 Registration Data Access Protocol (RDAP)", draft-ietf- 655 weirds-json-response-10 (work in progress), October 2014. 657 [I-D.ietf-weirds-rdap-query] 658 Newton, A. and S. Hollenbeck, "Registration Data Access 659 Protocol Query Format", draft-ietf-weirds-rdap-query-15 660 (work in progress), October 2014. 662 [I-D.ietf-weirds-redirects] 663 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 664 for Registration Data Access Protocol", draft-ietf-weirds- 665 redirects-04 (work in progress), July 2014. 667 [I-D.ietf-weirds-using-http] 668 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 669 Registration Data Access Protocol (RDAP)", draft-ietf- 670 weirds-using-http-13 (work in progress), October 2014. 672 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 673 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 674 May 2008. 676 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 677 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 679 [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for 680 Reputation Interchange", RFC 7071, November 2013. 682 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 683 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 684 2014. 686 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 687 Attack", BCP 188, RFC 7258, May 2014. 689 [asreg] Internet Assigned Numbers Authority(IANA), , "Autonomous 690 System (AS) Numbers", . 693 [domainreg] 694 Internet Assigned Numbers Authority(IANA), , "Root Zone 695 Database", . 697 [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address 698 Space", . 701 [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global 702 Unicast Address Assignments", 703 . 706 Author's Address 708 Marc Blanchet 709 Viagenie 710 246 Aberdeen 711 Quebec, QC G1R 2E1 712 Canada 714 Email: Marc.Blanchet@viagenie.ca 715 URI: http://viagenie.ca