idnits 2.17.1 draft-ietf-regext-epp-rdap-status-mapping-00.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 (June 10, 2016) is 2876 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Informational June 10, 2016 5 Expires: December 12, 2016 7 Extensible Provisioning Protocol (EPP) and Registration Data Access 8 Protocol (RDAP) Status Mapping 9 draft-ietf-regext-epp-rdap-status-mapping-00 11 Abstract 13 This document describes the mapping of the Extensible Provisioning 14 Protocol (EPP) statuses with the statuses registered for use in the 15 Registration Data Access Protocol (RDAP). This document identifies 16 gaps in the mapping, and registers RDAP statuses to fill the gaps to 17 ensure that all of the EPP RFC statuses are supported in RDAP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 12, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 55 2. EPP to RDAP Status Mapping . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. JSON Values Registry . . . . . . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 9 60 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 61 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 10 62 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 10 63 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 64 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 This document maps the statuses defined in the Extensible 70 Provisioning Protocol (EPP) RFCs to the list of statuses registered 71 for use in the Registration Data Access Protocol (RDAP), in the RDAP 72 JSON Values Registry [rdap-json-values]. 74 The RDAP JSON Values Registry is described in section 10.2 of 75 [RFC7483] and is available in the RDAP JSON Values Registry 76 [rdap-json-values]. 78 The EPP statuses used as the source of the mapping include section 79 2.3 of the EPP Domain Name Mapping [RFC5731], section 2.3 of the EPP 80 Host Mapping [RFC5732], section 2.2 of the EPP Contact Mapping 81 [RFC5733], and section 3.1 of EPP Grace Period Mapping [RFC3915]. 83 Each EPP status MUST map to a single RDAP status to ensure that data 84 in the Domain Name Registries (DNRs) that use EPP can be accurately 85 presented in RDAP. 87 1.1. Conventions Used in This Document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. EPP to RDAP Status Mapping 95 Below is an alphabetically sorted list of EPP statuses from the EPP 96 RFCs ([RFC5731], [RFC5732], [RFC5733], and [RFC3915]) mapped to the 97 RDAP statuses registered in the RDAP JSON Values Registry 98 [rdap-json-values], with the format '=' , 99 where a blank indicates a gap in the mapping. 101 addPeriod = 102 autoRenewPeriod = 103 clientDeleteProhibited = 104 clientHold = 105 clientRenewProhibited = 106 clientTransferProhibited = 107 clientUpdateProhibited = 108 inactive = inactive 109 linked = associated 110 ok = active 111 pendingCreate = pending create 112 pendingDelete = pending delete 113 pendingRenew = pending renew 114 pendingRestore = 115 pendingTransfer = pending transfer 116 pendingUpdate = pending update 117 redemptionPeriod = 118 renewPeriod = 119 serverDeleteProhibited = 120 serverRenewProhibited = 121 serverTransferProhibited = 122 serverUpdateProhibited = 123 serverHold = 124 transferPeriod = 126 The RDAP JSON Values Registry [rdap-json-values] does have a set of 127 prohibited statuses including "renew prohibited", "update 128 prohibited", "transfer prohibited", and "delete prohibited", but 129 these statuses do not directly map to the EPP prohibited statuses. 130 The EPP prohibited statuses reflect both what is prohibited ("renew", 131 "update", "transfer", "delete") and who set ("client" or "server") 132 and can clear the status. In the DNR, the client and server 133 prohibited statuses are separate and RDAP MUST support the same 134 separation. 136 Each of the EPP status values that don't map directly to an RDAP 137 status value is described below. Each EPP status value includes a 138 proposed new RDAP status value and a description of the value. The 139 RDAP status value is derived from the EPP status value by converting 140 the EPP camel case representation to lower case with a space 141 character inserted between word boundaries. 143 addPeriod = add period; For DNR that indicates if the object is 144 deleted by the registrar during this period, the registry 145 provides a credit to the registrar for the cost of the 146 registration. 147 autoRenewPeriod = auto renew period; For DNR that indicates if the 148 object is deleted by the registrar during this period, the 149 registry provides a credit to the registrar for the cost of the 150 auto renewal. 151 clientDeleteProhibited = client delete prohibited; For DNR that 152 indicates the client requested that requests to delete the object 153 MUST be rejected. 154 clientHold = client hold; For DNR that indicates the client 155 requested that the DNS delegation information MUST NOT be 156 published for the object. 157 clientRenewProhibited = client renew prohibited; For DNR that 158 indicates the client requested that requests to renew the object 159 MUST be rejected. 160 clientTransferProhibited = client transfer prohibited; For DNR that 161 indicates the client requested that requests to transfer the 162 object MUST be rejected. 163 clientUpdateProhibited = client update prohibited; For DNR that 164 indicates the client requested that requests to update the object 165 (other than to remove this status) MUST be rejected. 166 pendingRestore = pending restore; For DNR that indicates a object is 167 in the process of being restored after being in the 168 redemptionPeriod state. 169 redemptionPeriod = redemption period; For DNR that indicates a 170 delete has been received, but the object has not yet been purged 171 because an opportunity exists to restore the object and abort the 172 deletion process. 173 renewPeriod = renew period; For DNR that indicates if the object is 174 deleted by the registrar during this period, the registry 175 provides a credit to the registrar for the cost of the renewal. 176 serverDeleteProhibited = server delete prohibited; For DNR that 177 indicates the server set the status so that requests to delete 178 the object MUST be rejected. 179 serverRenewProhibited = server renew prohibited; For DNR that 180 indicates the server set the status so that requests to renew the 181 object MUST be rejected. 182 serverTransferProhibited = server transfer prohibited; For DNR that 183 indicates the server set the status so that requests to transfer 184 the object MUST be rejected. 185 serverUpdateProhibited = server update prohibited; For DNR that 186 indicates the server set the status so that requests to update 187 the object (other than to remove this status) MUST be rejected. 189 serverHold = server hold; For DNR that indicates the server set the 190 status so that DNS delegation information MUST NOT be published 191 for the object. 192 transferPeriod = transfer period; For DNR that indicates if the 193 domain name is deleted by the registrar during this period, the 194 registry provides a credit to the registrar for the cost of the 195 transfer. 197 The resulting mapping after registering the new RDAP statuses is: 199 addPeriod = add period 200 autoRenewPeriod = auto renew period 201 clientDeleteProhibited = client delete prohibited 202 clientHold = client hold 203 clientRenewProhibited = client renew prohibited 204 clientTransferProhibited = client transfer prohibited 205 clientUpdateProhibited = client update prohibited 206 inactive = inactive 207 linked = associated 208 ok = active 209 pendingCreate = pending create 210 pendingDelete = pending delete 211 pendingRenew = pending renew 212 pendingRestore = pending restore 213 pendingTransfer = pending transfer 214 pendingUpdate = pending update 215 redemptionPeriod = redemption period 216 renewPeriod = renew period 217 serverDeleteProhibited = server delete prohibited 218 serverRenewProhibited = server renew prohibited 219 serverTransferProhibited = server transfer prohibited 220 serverUpdateProhibited = server update prohibited 221 serverHold = server hold 222 transferPeriod = transfer period 224 3. IANA Considerations 226 3.1. JSON Values Registry 228 The following values should be registered by the IANA in the RDAP 229 JSON Values Registry described in [RFC7483]: 231 Value: add period 233 Type: status 234 Description: For DNR that indicates if the object is deleted by the 235 registrar during this period, the registry provides a credit to the 236 registrar for the cost of the registration. 238 Registrant Name: VeriSign Inc. 240 Registrant Contact Information: epp-registry@verisign.com 242 Value: auto renew period 244 Type: status 246 Description: For DNR that indicates if the object is deleted by the 247 registrar during this period, the registry provides a credit to the 248 registrar for the cost of the auto renewal. 250 Registrant Name: VeriSign Inc. 252 Registrant Contact Information: epp-registry@verisign.com 254 Value: client delete prohibited 256 Type: status 258 Description: For DNR that indicates the client requested that 259 requests to delete the object MUST be rejected. 261 Registrant Name: VeriSign Inc. 263 Registrant Contact Information: epp-registry@verisign.com 265 Value: client hold 267 Type: status 269 Description: For DNR that indicates the client requested that the DNS 270 delegation information MUST NOT be published for the object. 272 Registrant Name: VeriSign Inc. 274 Registrant Contact Information: epp-registry@verisign.com 276 Value: client renew prohibited 278 Type: status 280 Description: For DNR that indicates the client requested that 281 requests to renew the object MUST be rejected. 283 Registrant Name: VeriSign Inc. 285 Registrant Contact Information: epp-registry@verisign.com 287 Value: client transfer prohibited 289 Type: status 291 Description: For DNR that indicates the client requested that 292 requests to transfer the object MUST be rejected. 294 Registrant Name: VeriSign Inc. 296 Registrant Contact Information: epp-registry@verisign.com 298 Value: client update prohibited 300 Type: status 302 Description: For DNR that indicates the client requested that 303 requests to update the object (other than to remove this status) MUST 304 be rejected. 306 Registrant Name: VeriSign Inc. 308 Registrant Contact Information: epp-registry@verisign.com 310 Value: pending restore 312 Type: status 314 Description: For DNR that indicates a object is in the process of 315 being restored after being in the redemptionPeriod state. 317 Registrant Name: VeriSign Inc. 319 Registrant Contact Information: epp-registry@verisign.com 321 Value: redemption period 323 Type: status 325 Description: For DNR that indicates a delete has been received, but 326 the object has not yet been purged because an opportunity exists to 327 restore the object and abort the deletion process. 329 Registrant Name: VeriSign Inc. 331 Registrant Contact Information: epp-registry@verisign.com 333 Value: renew period 335 Type: status 337 Description: For DNR that indicates if the object is deleted by the 338 registrar during this period, the registry provides a credit to the 339 registrar for the cost of the renewal. 341 Registrant Name: VeriSign Inc. 343 Registrant Contact Information: epp-registry@verisign.com 345 Value: server delete prohibited 347 Type: status 349 Description: For DNR that indicates the server set the status so that 350 requests to delete the object MUST be rejected. 352 Registrant Name: VeriSign Inc. 354 Registrant Contact Information: epp-registry@verisign.com 356 Value: server renew prohibited 358 Type: status 360 Description: For DNR that indicates the server set the status so that 361 requests to renew the object MUST be rejected. 363 Registrant Name: VeriSign Inc. 365 Registrant Contact Information: epp-registry@verisign.com 367 Value: server transfer prohibited 369 Type: status 371 Description: For DNR that indicates the server set the status so that 372 requests to transfer the object MUST be rejected. 374 Registrant Name: VeriSign Inc. 376 Registrant Contact Information: epp-registry@verisign.com 378 Value: server update prohibited 379 Type: status 381 Description: For DNR that indicates the server set the status so that 382 requests to update the object (other than to remove this status) MUST 383 be rejected. 385 Registrant Name: VeriSign Inc. 387 Registrant Contact Information: epp-registry@verisign.com 389 Value: server hold 391 Type: status 393 Description: For DNR that indicates the server set the status so that 394 DNS delegation information MUST NOT be published for the object. 396 Registrant Name: VeriSign Inc. 398 Registrant Contact Information: epp-registry@verisign.com 400 Value: transfer period 402 Type: status 404 Description: For DNR that indicates if the domain name is deleted by 405 the registrar during this period, the registry provides a credit to 406 the registrar for the cost of the transfer. 408 Registrant Name: VeriSign Inc. 410 Registrant Contact Information: epp-registry@verisign.com 412 4. Security Considerations 414 The mapping described in this document do not provide any security 415 services beyond those described by RDAP [RFC7483]. 417 5. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 423 the Extensible Provisioning Protocol (EPP)", RFC 3915, 424 September 2004. 426 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 427 Domain Name Mapping", STD 69, RFC 5731, August 2009. 429 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 430 Host Mapping", STD 69, RFC 5732, August 2009. 432 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 433 Contact Mapping", STD 69, RFC 5733, August 2009. 435 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 436 Registration Data Access Protocol (RDAP)", RFC 7483, March 437 2015. 439 [rdap-json-values] 440 "RDAP JSON Values Registry", 441 . 444 Appendix A. Change History 446 A.1. Change from 00 to 01 448 1. Changed the mapping of "linked" to "associated" and removed the 449 registration of "linked", based on feedback from Andrew Newton on 450 the weirds mailing list. 452 A.2. Change from 01 to 02 454 1. Ping update. 456 A.3. Change from 02 to 03 458 1. Ping update. 460 A.4. Change from 03 to REGEXT 00 462 1. Changed to regext working group draft by changing draft-gould- 463 epp-rdap-status-mapping to draft-ietf-regext-epp-rdap-status- 464 mapping. 466 Author's Address 467 James Gould 468 VeriSign, Inc. 469 12061 Bluemont Way 470 Reston, VA 20190 471 US 473 Email: jgould@verisign.com 474 URI: http://www.verisigninc.com