idnits 2.17.1 draft-hollenbeck-regext-rdap-object-tag-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 313: '... SHOULD be consistent. If they are ...' -- The draft header indicates that this document updates RFC7484, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2016) is 2703 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 446 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7482 (Obsoleted by RFC 9082) -- Obsolete informational reference (is this intentional?): RFC 7483 (Obsoleted by RFC 9083) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions S. Hollenbeck 3 Internet-Draft Verisign Labs 4 Updates: 7484 (if approved) A. Newton 5 Intended status: Best Current Practice ARIN 6 Expires: May 25, 2017 November 21, 2016 8 Registration Data Access Protocol (RDAP) Object Tagging 9 draft-hollenbeck-regext-rdap-object-tag-01 11 Abstract 13 The Registration Data Access Protocol (RDAP) includes a method that 14 can be used to identify the authoritative server for processing 15 domain name, IP address, and autonomous system number queries. The 16 method does not describe how to identify the authoritative server for 17 processing other RDAP query types, such as entity queries. This 18 limitation exists because the identifiers associated with these query 19 types are typically unstructured. This document describes an 20 operational practice that can be used to add structure to RDAP 21 identifiers that makes it possible to identify the authoritative 22 server for additional RDAP queries. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 25, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3 60 3. Bootstrap Service Registry for RDAP Service Providers . . . . 7 61 3.1. Registration Procedure . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. Bootstrap Service Registry for RDAP Service Providers . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . 10 69 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The Registration Data Access Protocol (RDAP) includes a method 76 ([RFC7484]) that can be used to identify the authoritative server for 77 processing domain name, IP address, and autonomous system number 78 (ASN) queries. This method works because each of these data elements 79 is structured in a way that facilitates automated parsing of the 80 element and association of the data element with a particular RDAP 81 service provider. For example, domain names include labels (such as 82 "com", "net", and "org") that are associated with specific service 83 providers. 85 As noted in Section 9 of RFC 7484 [RFC7484], the method does not 86 describe how to identify the authoritative server for processing 87 entity queries, name server queries, help queries, or queries using 88 certain search patterns. This limitation exists because the 89 identifiers bound to these queries are typically not structured in a 90 way that makes it easy to associate an identifier with a specific 91 service provider. This document describes an operational practice 92 that can be used to add structure to RDAP identifiers that makes it 93 possible to identify the authoritative server for additional RDAP 94 queries. 96 2. Object Naming Practice 98 Tagging object identifiers with a service provider tag makes it 99 possible to identify the authoritative server for processing an RDAP 100 query using the method described in RFC 7484 [RFC7484]. A service 101 provider tag is constructed by concatenating the Unicode COMMERCIAL 102 AT character '@' (U+0040) to an IANA-registered value that represents 103 the service provider. For example, a tag for a service provider 104 identified by the string value "ARIN" is represented as "@ARIN". 106 Service provider tags are concatenated to the end of RDAP query 107 object identifiers to unambiguously identify the authoritative server 108 for processing an RDAP query. Building on the example from 109 Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be 110 constructed that allows an RDAP client to bootstrap an entity query. 111 The following identifier is used to find information for the entity 112 associated with handle "XXXX" at service provider "ARIN": 114 XXXX@ARIN 116 Clients that wish to bootstrap an entity query can parse this 117 identifier into distinct handle and service provider identifier 118 elements. Handles can themselves contain COMMERCIAL AT characters; 119 the service provider identifier is found following the last (reading 120 from left to right) COMMERCIAL AT character in the tagged identifier. 121 The service provider identifier is used to retrieve a base RDAP URL 122 from an IANA registry. The base URL and entity handle are then used 123 to form a complete RDAP query path segment. For example, if the base 124 RDAP URL "https://example.com/rdap/" is associated with service 125 provider "YYYY" in an IANA registry, an RDAP client will parse a 126 tagged entity identifier "XXXX@YYYY" into distinct handle ("XXXX") 127 and service provider ("YYYY") identifiers. The service provider 128 identifier "YYYY" is used to query an IANA registry to retrieve the 129 base RDAP URL "https://example.com/rdap/". The base RDAP URL is 130 concatenated to the entity handle to create a complete RDAP query 131 path segment of "https://example.com/rdap/entity/XXXX@YYYY". 133 Implementation of this practice requires tagging of unstructured 134 potential query identifiers in RDAP responses. Consider these elided 135 examples from Section 5.3 of RFC 7483 [RFC7483] in which the handle 136 identifiers have been tagged with a service provider tag: 138 { 139 "objectClassName" : "domain", 140 "handle" : "XXXX@RIR", 141 "ldhName" : "0.2.192.in-addr.arpa", 142 "nameservers" : 143 [ 144 ... 145 ], 146 "secureDNS": 147 { 148 ... 149 }, 150 "remarks" : 151 [ 152 ... 153 ], 154 "links" : 155 [ 156 ... 157 ], 158 "events" : 159 [ 160 ... 161 ], 162 "entities" : 163 [ 164 { 165 "objectClassName" : "entity", 166 "handle" : "XXXX@RIR", 167 "vcardArray": 168 [ 169 ... 170 ], 171 "roles" : [ "registrant" ], 172 "remarks" : 173 [ 174 ... 175 ], 176 "links" : 177 [ 178 ... 179 ], 180 "events" : 181 [ 182 ... 183 ] 184 } 185 ], 186 "network" : 187 { 188 "objectClassName" : "ip network", 189 "handle" : "XXXX@RIR", 190 "startAddress" : "192.0.2.0", 191 "endAddress" : "192.0.2.255", 192 "ipVersion" : "v4", 193 "name": "NET-RTR-1", 194 "type" : "DIRECT ALLOCATION", 195 "country" : "AU", 196 "parentHandle" : "YYYY@RIR", 197 "status" : [ "active" ] 198 } 199 } 201 Figure 1 203 { 204 "objectClassName" : "domain", 205 "handle" : "XXXX@DNR", 206 "ldhName" : "xn--fo-5ja.example", 207 "unicodeName" : "foo.example", 208 "variants" : 209 [ 210 ... 211 ], 212 "status" : [ "locked", "transfer prohibited" ], 213 "publicIds": 214 [ 215 ... 216 ], 217 "nameservers" : 218 [ 219 { 220 "objectClassName" : "nameserver", 221 "handle" : "XXXX@DNR", 222 "ldhName" : "ns1.example.com", 223 "status" : [ "active" ], 224 "ipAddresses" : 225 { 226 ... 227 }, 228 "remarks" : 229 [ 230 ... 231 ], 232 "links" : 233 [ 234 ... 235 ], 236 "events" : 237 [ 238 ... 239 ] 241 }, 242 { 243 "objectClassName" : "nameserver", 244 "handle" : "XXXX@DNR", 245 "ldhName" : "ns2.example.com", 246 "status" : [ "active" ], 247 "ipAddresses" : 248 { 249 ... 250 }, 251 "remarks" : 252 [ 253 ... 254 ], 255 "links" : 256 [ 257 ... 258 ], 259 "events" : 260 [ 261 ... 262 ] 263 } 264 ], 265 "secureDNS": 266 { 267 ... 268 }, 269 "remarks" : 270 [ 271 ... 272 ], 273 "links" : 274 [ 275 ... 276 ], 277 "port43" : "whois.example.net", 278 "events" : 279 [ 280 ... 281 ], 282 "entities" : 283 [ 284 { 285 "objectClassName" : "entity", 286 "handle" : "XXXX@8", 287 "vcardArray": 288 [ 289 ... 290 ], 291 "status" : [ "validated", "locked" ], 292 "roles" : [ "registrant" ], 293 "remarks" : 294 [ 295 ... 296 ], 297 "links" : 298 [ 299 ... 300 ], 301 "events" : 302 [ 303 ... 304 ] 305 } 306 ] 307 } 309 Figure 2 311 As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can 312 contain "self" links. Service provider tags and self references 313 SHOULD be consistent. If they are inconsistent, the service provider 314 tag is processed with higher priority when using these values to 315 identify a service provider. 317 3. Bootstrap Service Registry for RDAP Service Providers 319 The bootstrap service registry for the RDAP service provider space is 320 represented using the structure specified in Section 3 of RFC 7484 321 [RFC7484]. The JSON output of this registry contains alphanumeric 322 identifiers that identify RDAP service providers, grouped by base 323 RDAP URLs, as shown in this example. 325 { 326 "version": "1.0", 327 "publication": "YYYY-MM-DDTHH:MM:SSZ", 328 "description": "RDAP bootstrap file for service provider allocations", 329 "services": [ 330 [ 331 ["YYYY"], 332 [ 333 "https://example.com/rdap/" 334 ] 335 ], 336 [ 337 ["ZZ54"], 338 [ 339 "http://rdap.example.org/" 340 ] 341 ], 342 [ 343 ["1754"], 344 [ 345 "https://example.net/rdap/", 346 "http://example.net/rdap/" 347 ] 348 ] 349 ] 350 } 352 Figure 3 354 Alphanumeric service provider identifiers conform to the syntax 355 specified in the IANA registry of Extensible Provisioning Protocol 356 (EPP) Repository Identifiers [1], with one exception: identifiers 357 always start with a letter to avoid confusion with network handles of 358 the form "NET-192-0-0-0-1" that always end with a HYPHEN-MINUS 359 character followed by a number. 361 3.1. Registration Procedure 363 The service provider registry is populated using the "First Come 364 First Served" policy defined in RFC 5226 [RFC5226]. Provider 365 identifier values can be derived and assigned by IANA on request. 366 Registration requests include the requested service provider 367 identifier (or an indication that IANA should assign an identifier) 368 and the base RDAP URL to be associated with the service provider 369 identifier. 371 4. IANA Considerations 373 IANA is requested to create the RDAP Bootstrap Services Registry 374 listed below and make it available as JSON objects. The contents of 375 this registry is described in Section 3, with the formal syntax 376 specified in Section 10 of RFC 7484 [RFC7484]. 378 4.1. Bootstrap Service Registry for RDAP Service Providers 380 Entries in this registry contain at least the following: 382 o An alphanumeric value that identifies the RDAP service provider 383 being registered. 384 o One or more URLs that provide the RDAP service regarding this 385 registration. 387 5. Security Considerations 389 This practice helps to ensure that end users will get RDAP data from 390 an authoritative source using a bootstrap method to find 391 authoritative RDAP servers, reducing the risk of sending queries to 392 non-authoritative sources. The method has the same security 393 properties as the RDAP protocols themselves. The transport used to 394 access the IANA registries can be more secure by using TLS [RFC5246], 395 which IANA supports. Additional considerations associated with RDAP 396 are described in RFC 7481 [RFC7481]. 398 6. Acknowledgements 400 The author would like to acknowledge the following individuals for 401 their contributions to the development of this document: Tom 402 Harrison, and Marcos Sanz. In addition, the authors would like to 403 recognize the Regional Internet Registry (RIR) operators (AFRINIC, 404 APNIC, ARIN, LACNIC, and RIPE) that have been implementing and using 405 the practice of tagging handle identifiers for several years. Their 406 experience provided significant inspiration for the development of 407 this document. 409 7. References 411 7.1. Normative References 413 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 414 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 415 DOI 10.17487/RFC5226, May 2008, 416 . 418 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 419 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 420 2015, . 422 7.2. Informative References 424 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 425 (TLS) Protocol Version 1.2", RFC 5246, 426 DOI 10.17487/RFC5246, August 2008, 427 . 429 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 430 Registration Data Access Protocol (RDAP)", RFC 7481, 431 DOI 10.17487/RFC7481, March 2015, 432 . 434 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 435 Protocol (RDAP) Query Format", RFC 7482, 436 DOI 10.17487/RFC7482, March 2015, 437 . 439 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 440 Registration Data Access Protocol (RDAP)", RFC 7483, 441 DOI 10.17487/RFC7483, March 2015, 442 . 444 7.3. URIs 446 [1] http://www.iana.org/assignments/epp-repository-ids/epp- 447 repository-ids.xhtml#epp-repository-ids-1 449 Appendix A. Change Log 451 00: Initial version. 452 01: Changed separator character from HYPHEN MINUS to COMMERCIAL AT. 453 Added a recommendation to maintain consistency between service 454 provider tags and "self" links (suggestion received from Tom 455 Harrison). Fixed a spelling error, and corrected the network 456 example in Section 2 (editorial erratum reported for RFC 7483 by 457 Marcos Sanz). Added acknowledgements. 459 Authors' Addresses 460 Scott Hollenbeck 461 Verisign Labs 462 12061 Bluemont Way 463 Reston, VA 20190 464 USA 466 Email: shollenbeck@verisign.com 467 URI: http://www.verisignlabs.com/ 469 Andrew Lee Newton 470 American Registry for Internet Numbers 471 PO Box 232290 472 Centreville, VA 20120 473 US 475 Email: andy@arin.net 476 URI: http://www.arin.net