idnits 2.17.1 draft-ietf-regext-epp-rdap-status-mapping-03.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 12, 2016) is 2752 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 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: Standards Track October 12, 2016 5 Expires: April 15, 2017 7 Extensible Provisioning Protocol (EPP) and Registration Data Access 8 Protocol (RDAP) Status Mapping 9 draft-ietf-regext-epp-rdap-status-mapping-03 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 April 15, 2017. 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. Acknowledgements . . . . . . . . . . . . . . . . . . 10 61 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10 62 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 10 63 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 10 64 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 65 B.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 10 66 B.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 11 67 B.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 11 68 B.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 This document maps the statuses defined in the Extensible 74 Provisioning Protocol (EPP) RFCs to the list of statuses registered 75 for use in the Registration Data Access Protocol (RDAP), in the RDAP 76 JSON Values Registry [rdap-json-values]. 78 The RDAP JSON Values Registry is described in section 10.2 of 79 [RFC7483] and is available in the RDAP JSON Values Registry 80 [rdap-json-values]. 82 The EPP statuses used as the source of the mapping include section 83 2.3 of the EPP Domain Name Mapping [RFC5731], section 2.3 of the EPP 84 Host Mapping [RFC5732], section 2.2 of the EPP Contact Mapping 85 [RFC5733], and section 3.1 of EPP Grace Period Mapping [RFC3915]. 87 Each EPP status MUST map to a single RDAP status to ensure that data 88 in the Domain Name Registries (DNRs) that use EPP can be accurately 89 presented in RDAP. 91 1.1. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. EPP to RDAP Status Mapping 99 Below is an alphabetically sorted list of EPP statuses from the EPP 100 RFCs ([RFC5731], [RFC5732], [RFC5733], and [RFC3915]) mapped to the 101 RDAP statuses registered in the RDAP JSON Values Registry 102 [rdap-json-values], with the format '=' , 103 where a blank indicates a gap in the mapping. 105 addPeriod = 106 autoRenewPeriod = 107 clientDeleteProhibited = 108 clientHold = 109 clientRenewProhibited = 110 clientTransferProhibited = 111 clientUpdateProhibited = 112 inactive = inactive 113 linked = associated 114 ok = active 115 pendingCreate = pending create 116 pendingDelete = pending delete 117 pendingRenew = pending renew 118 pendingRestore = 119 pendingTransfer = pending transfer 120 pendingUpdate = pending update 121 redemptionPeriod = 122 renewPeriod = 123 serverDeleteProhibited = 124 serverRenewProhibited = 125 serverTransferProhibited = 126 serverUpdateProhibited = 127 serverHold = 128 transferPeriod = 130 The RDAP JSON Values Registry [rdap-json-values] does have a set of 131 prohibited statuses including "renew prohibited", "update 132 prohibited", "transfer prohibited", and "delete prohibited", but 133 these statuses do not directly map to the EPP prohibited statuses. 134 EPP provides status codes that allow distinguishing the case that an 135 action is prohibited because of server policy from the case that an 136 action is prohibited because of a client request. The ability to 137 make this distinction needs to be preserved in RDAP. 139 Each of the EPP status values that don't map directly to an RDAP 140 status value is described below. Each EPP status value includes a 141 proposed new RDAP status value and a description of the value. The 142 RDAP status value is derived from the EPP status value by converting 143 the EPP camel case representation to lower case with a space 144 character inserted between word boundaries. 146 addPeriod = add period; This grace period is provided after the 147 initial registration of the object. If the object is deleted by 148 the client during this period, the server provides a credit to 149 the client for the cost of the registration. 150 autoRenewPeriod = auto renew period; This grace period is provided 151 after an object registration period expires and is extended 152 (renewed) automatically by the server. If the object is deleted 153 by the client during this period, the server provides a credit to 154 the client for the cost of the auto renewal. 155 clientDeleteProhibited = client delete prohibited; The client 156 requested that requests to delete the object MUST be rejected. 157 clientHold = client hold; The client requested that the DNS 158 delegation information MUST NOT be published for the object. 159 clientRenewProhibited = client renew prohibited; The client 160 requested that requests to renew the object MUST be rejected. 161 clientTransferProhibited = client transfer prohibited; The client 162 requested that requests to transfer the object MUST be rejected. 163 clientUpdateProhibited = client update prohibited; The client 164 requested that requests to update the object (other than to 165 remove this status) MUST be rejected. 166 pendingRestore = pending restore; An object is in the process of 167 being restored after being in the redemption period state. 168 redemptionPeriod = redemption period; A delete has been received, 169 but the object has not yet been purged because an opportunity 170 exists to restore the object and abort the deletion process. 171 renewPeriod = renew period; This grace period is provided after an 172 object registration period is explicitly extended (renewed) by 173 the client. If the object is deleted by the client during this 174 period, the server provides a credit to the client for the cost 175 of the renewal. 176 serverDeleteProhibited = server delete prohibited; The server set 177 the status so that requests to delete the object MUST be 178 rejected. 179 serverRenewProhibited = server renew prohibited; The server set the 180 status so that requests to renew the object MUST be rejected. 181 serverTransferProhibited = server transfer prohibited; The server 182 set the status so that requests to transfer the object MUST be 183 rejected. 184 serverUpdateProhibited = server update prohibited; The server set 185 the status so that requests to update the object (other than to 186 remove this status) MUST be rejected. 187 serverHold = server hold; The server set the status so that DNS 188 delegation information MUST NOT be published for the object. 189 transferPeriod = transfer period; This grace period is provided 190 after the successful transfer of object registration sponsorship 191 from one client to another client. If the object is deleted by 192 the client during this period, the server provides a credit to 193 the client for the cost of the transfer. 195 The resulting mapping after registering the new RDAP statuses is: 197 addPeriod = add period 198 autoRenewPeriod = auto renew period 199 clientDeleteProhibited = client delete prohibited 200 clientHold = client hold 201 clientRenewProhibited = client renew prohibited 202 clientTransferProhibited = client transfer prohibited 203 clientUpdateProhibited = client update prohibited 204 inactive = inactive 205 linked = associated 206 ok = active 207 pendingCreate = pending create 208 pendingDelete = pending delete 209 pendingRenew = pending renew 210 pendingRestore = pending restore 211 pendingTransfer = pending transfer 212 pendingUpdate = pending update 213 redemptionPeriod = redemption period 214 renewPeriod = renew period 215 serverDeleteProhibited = server delete prohibited 216 serverRenewProhibited = server renew prohibited 217 serverTransferProhibited = server transfer prohibited 218 serverUpdateProhibited = server update prohibited 219 serverHold = server hold 220 transferPeriod = transfer period 222 3. IANA Considerations 224 3.1. JSON Values Registry 226 The following values should be registered by the IANA in the RDAP 227 JSON Values Registry described in [RFC7483]: 229 Value: add period 231 Type: status 233 Description: This grace period is provided after the initial 234 registration of the object. If the object is deleted by the client 235 during this period, the server provides a credit to the client for 236 the cost of the registration. 238 Registrant Name: IESG 240 Registrant Contact Information: iesg@ietf.org 242 Value: auto renew period 243 Type: status 245 Description: This grace period is provided after an object 246 registration period expires and is extended (renewed) automatically 247 by the server. If the object is deleted by the client during this 248 period, the server provides a credit to the client for the cost of 249 the auto renewal. 251 Registrant Name: IESG 253 Registrant Contact Information: iesg@ietf.org 255 Value: client delete prohibited 257 Type: status 259 Description: The client requested that requests to delete the object 260 MUST be rejected. 262 Registrant Name: IESG 264 Registrant Contact Information: iesg@ietf.org 266 Value: client hold 268 Type: status 270 Description: The client requested that the DNS delegation information 271 MUST NOT be published for the object. 273 Registrant Name: IESG 275 Registrant Contact Information: iesg@ietf.org 277 Value: client renew prohibited 279 Type: status 281 Description: The client requested that requests to renew the object 282 MUST be rejected. 284 Registrant Name: IESG 286 Registrant Contact Information: iesg@ietf.org 288 Value: client transfer prohibited 290 Type: status 291 Description: The client requested that requests to transfer the 292 object MUST be rejected. 294 Registrant Name: IESG 296 Registrant Contact Information: iesg@ietf.org 298 Value: client update prohibited 300 Type: status 302 Description: The client requested that requests to update the object 303 (other than to remove this status) MUST be rejected. 305 Registrant Name: IESG 307 Registrant Contact Information: iesg@ietf.org 309 Value: pending restore 311 Type: status 313 Description: An object is in the process of being restored after 314 being in the redemption period state. 316 Registrant Name: IESG 318 Registrant Contact Information: iesg@ietf.org 320 Value: redemption period 322 Type: status 324 Description: A delete has been received, but the object has not yet 325 been purged because an opportunity exists to restore the object and 326 abort the deletion process. 328 Registrant Name: IESG 330 Registrant Contact Information: iesg@ietf.org 332 Value: renew period 334 Type: status 336 Description: This grace period is provided after an object 337 registration period is explicitly extended (renewed) by the client. 339 If the object is deleted by the client during this period, the server 340 provides a credit to the client for the cost of the renewal. 342 Registrant Name: IESG 344 Registrant Contact Information: iesg@ietf.org 346 Value: server delete prohibited 348 Type: status 350 Description: The server set the status so that requests to delete the 351 object MUST be rejected. 353 Registrant Name: IESG 355 Registrant Contact Information: iesg@ietf.org 357 Value: server renew prohibited 359 Type: status 361 Description: The server set the status so that requests to renew the 362 object MUST be rejected. 364 Registrant Name: IESG 366 Registrant Contact Information: iesg@ietf.org 368 Value: server transfer prohibited 370 Type: status 372 Description: The server set the status so that requests to transfer 373 the object MUST be rejected. 375 Registrant Name: IESG 377 Registrant Contact Information: iesg@ietf.org 379 Value: server update prohibited 381 Type: status 383 Description: The server set the status so that requests to update the 384 object (other than to remove this status) MUST be rejected. 386 Registrant Name: IESG 387 Registrant Contact Information: iesg@ietf.org 389 Value: server hold 391 Type: status 393 Description: The server set the status so that DNS delegation 394 information MUST NOT be published for the object. 396 Registrant Name: IESG 398 Registrant Contact Information: iesg@ietf.org 400 Value: transfer period 402 Type: status 404 Description: This grace period is provided after the successful 405 transfer of object registration sponsorship from one client to 406 another client. If the object is deleted by the client during this 407 period, the server provides a credit to the client for the cost of 408 the transfer. 410 Registrant Name: IESG 412 Registrant Contact Information: iesg@ietf.org 414 4. Security Considerations 416 The status values described in this document can be subject to 417 server-side information disclosure policies that restrict display of 418 the values to authorized clients. Implementers may wish to review 419 [RFC7481] for a description of the RDAP security services that can be 420 used to implement information disclosure policies. 422 5. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 428 the Extensible Provisioning Protocol (EPP)", RFC 3915, 429 September 2004. 431 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 432 Domain Name Mapping", STD 69, RFC 5731, August 2009. 434 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 435 Host Mapping", STD 69, RFC 5732, August 2009. 437 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 438 Contact Mapping", STD 69, RFC 5733, August 2009. 440 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 441 Registration Data Access Protocol (RDAP)", RFC 7481, DOI 442 10.17487/RFC7481, March 2015, 443 . 445 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 446 Registration Data Access Protocol (RDAP)", RFC 7483, March 447 2015. 449 [rdap-json-values] 450 "RDAP JSON Values Registry", 451 . 454 Appendix A. Acknowledgements 456 Suggestions that have been incorporated into this document were 457 provided by Andrew Newton, Scott Hollenbeck, Jim Galvin, Gustavo 458 Lozano, and Robert Sparks. 460 Appendix B. Change History 462 B.1. Change from 00 to 01 464 1. Changed the mapping of "linked" to "associated" and removed the 465 registration of "linked", based on feedback from Andrew Newton on 466 the weirds mailing list. 468 B.2. Change from 01 to 02 470 1. Ping update. 472 B.3. Change from 02 to 03 474 1. Ping update. 476 B.4. Change from 03 to REGEXT 00 478 1. Changed to regext working group draft by changing draft-gould- 479 epp-rdap-status-mapping to draft-ietf-regext-epp-rdap-status- 480 mapping. 482 B.5. Change from REGEXT 00 to REGEXT 01 484 1. Updated based on regext mailing feedback from Scott Hollenbeck 485 that included updating the registrant for the registration of the 486 new statuses to IESG and iesg@ietf.org, and revising the security 487 section. Changed to standards track based on suggestion by Jim 488 Galvin and support from Gustavo Lozano on the regext mailing 489 list. 491 B.6. Change from REGEXT 01 to REGEXT 02 493 1. Updated the text associated with distinguishing client and server 494 prohibited statuses in RDAP based on feedback by Robert Sparks on 495 the regext mailing list. 496 2. Removed the "For DNR that indicates" text from the description of 497 the statuses based on feedback by Robert Sparks on the regext 498 mailing list. 499 3. Made a few editorial changes to the status descriptions including 500 referring to "redemption period" instead of "redemptionPeriod" 501 and referring to "object" instead of "domain name". 502 4. Changed all references of "registrar" to "client" and "registry" 503 to "server" in the status descriptions to be consistent. 505 B.7. Change from REGEXT 02 to REGEXT 03 507 1. Updated descriptions of the add period, auto renew period, renew 508 period, and transfer period statuses to better reflect what the 509 status is in RFC 3915, based on feedback by Robert Sparks on the 510 regext mailing list. 512 Author's Address 514 James Gould 515 VeriSign, Inc. 516 12061 Bluemont Way 517 Reston, VA 20190 518 US 520 Email: jgould@verisign.com 521 URI: http://www.verisigninc.com