idnits 2.17.1 draft-ietf-regext-epp-rdap-status-mapping-04.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 28, 2016) is 2730 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 28, 2016 5 Expires: May 1, 2017 7 Extensible Provisioning Protocol (EPP) and Registration Data Access 8 Protocol (RDAP) Status Mapping 9 draft-ietf-regext-epp-rdap-status-mapping-04 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 May 1, 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 . . . . . . . . . . . . 3 55 2. EPP to RDAP Status Mapping . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. JSON Values Registry . . . . . . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 10 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 61 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 11 62 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 11 63 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 11 64 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 11 65 B.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 11 66 B.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 12 67 B.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 12 68 B.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 12 69 B.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 This document maps the statuses defined in the Extensible 75 Provisioning Protocol (EPP) RFCs to the list of statuses registered 76 for use in the Registration Data Access Protocol (RDAP), in the RDAP 77 JSON Values Registry [rdap-json-values]. 79 The RDAP JSON Values Registry is described in section 10.2 of 80 [RFC7483] and is available in the RDAP JSON Values Registry 81 [rdap-json-values]. 83 The EPP statuses used as the source of the mapping include section 84 2.3 of the Extensible Provisioning Protocol (EPP) Domain Name Mapping 85 [RFC5731], section 2.3 of the Extensible Provisioning Protocol (EPP) 86 Host Mapping [RFC5732], section 2.2 of the Extensible Provisioning 87 Protocol (EPP) Contact Mapping [RFC5733], and section 3.1 of Domain 88 Registry Grace Period Mapping for the Extensible Provisioning 89 Protocol (EPP) [RFC3915]. 91 Each EPP status MUST map to a single RDAP status to ensure that data 92 in the Domain Name Registries (DNRs) that use EPP can be accurately 93 presented in RDAP. 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. EPP to RDAP Status Mapping 103 Below is an alphabetically sorted list of EPP statuses from the EPP 104 RFCs ([RFC5731], [RFC5732], [RFC5733], and [RFC3915]) mapped to the 105 RDAP statuses registered in the RDAP JSON Values Registry 106 [rdap-json-values], with the format '=' , 107 where a blank indicates a gap in the mapping. 109 addPeriod = 110 autoRenewPeriod = 111 clientDeleteProhibited = 112 clientHold = 113 clientRenewProhibited = 114 clientTransferProhibited = 115 clientUpdateProhibited = 116 inactive = inactive 117 linked = associated 118 ok = active 119 pendingCreate = pending create 120 pendingDelete = pending delete 121 pendingRenew = pending renew 122 pendingRestore = 123 pendingTransfer = pending transfer 124 pendingUpdate = pending update 125 redemptionPeriod = 126 renewPeriod = 127 serverDeleteProhibited = 128 serverRenewProhibited = 129 serverTransferProhibited = 130 serverUpdateProhibited = 131 serverHold = 132 transferPeriod = 134 The RDAP JSON Values Registry [rdap-json-values] does have a set of 135 prohibited statuses including "renew prohibited", "update 136 prohibited", "transfer prohibited", and "delete prohibited", but 137 these statuses do not directly map to the EPP prohibited statuses. 138 EPP provides status codes that allow distinguishing the case that an 139 action is prohibited because of server policy from the case that an 140 action is prohibited because of a client request. The ability to 141 make this distinction needs to be preserved in RDAP. 143 Each of the EPP status values that don't map directly to an RDAP 144 status value is described below. Each EPP status value includes a 145 proposed new RDAP status value and a description of the value. The 146 RDAP status value is derived from the EPP status value by converting 147 the EPP camel case representation to lower case with a space 148 character inserted between word boundaries. 150 addPeriod = add period; This grace period is provided after the 151 initial registration of the object. If the object is deleted by 152 the client during this period, the server provides a credit to 153 the client for the cost of the registration. 154 autoRenewPeriod = auto renew period; This grace period is provided 155 after an object registration period expires and is extended 156 (renewed) automatically by the server. If the object is deleted 157 by the client during this period, the server provides a credit to 158 the client for the cost of the auto renewal. 159 clientDeleteProhibited = client delete prohibited; The client 160 requested that requests to delete the object MUST be rejected. 161 clientHold = client hold; The client requested that the DNS 162 delegation information MUST NOT be published for the object. 163 clientRenewProhibited = client renew prohibited; The client 164 requested that requests to renew the object MUST be rejected. 165 clientTransferProhibited = client transfer prohibited; The client 166 requested that requests to transfer the object MUST be rejected. 167 clientUpdateProhibited = client update prohibited; The client 168 requested that requests to update the object (other than to 169 remove this status) MUST be rejected. 170 pendingRestore = pending restore; An object is in the process of 171 being restored after being in the redemption period state. 172 redemptionPeriod = redemption period; A delete has been received, 173 but the object has not yet been purged because an opportunity 174 exists to restore the object and abort the deletion process. 175 renewPeriod = renew period; This grace period is provided after an 176 object registration period is explicitly extended (renewed) by 177 the client. If the object is deleted by the client during this 178 period, the server provides a credit to the client for the cost 179 of the renewal. 180 serverDeleteProhibited = server delete prohibited; The server set 181 the status so that requests to delete the object MUST be 182 rejected. 183 serverRenewProhibited = server renew prohibited; The server set the 184 status so that requests to renew the object MUST be rejected. 185 serverTransferProhibited = server transfer prohibited; The server 186 set the status so that requests to transfer the object MUST be 187 rejected. 188 serverUpdateProhibited = server update prohibited; The server set 189 the status so that requests to update the object (other than to 190 remove this status) MUST be rejected. 192 serverHold = server hold; The server set the status so that DNS 193 delegation information MUST NOT be published for the object. 194 transferPeriod = transfer period; This grace period is provided 195 after the successful transfer of object registration sponsorship 196 from one client to another client. If the object is deleted by 197 the client during this period, the server provides a credit to 198 the client for the cost of the transfer. 200 The resulting mapping after registering the new RDAP statuses is: 202 addPeriod = add period 203 autoRenewPeriod = auto renew period 204 clientDeleteProhibited = client delete prohibited 205 clientHold = client hold 206 clientRenewProhibited = client renew prohibited 207 clientTransferProhibited = client transfer prohibited 208 clientUpdateProhibited = client update prohibited 209 inactive = inactive 210 linked = associated 211 ok = active 212 pendingCreate = pending create 213 pendingDelete = pending delete 214 pendingRenew = pending renew 215 pendingRestore = pending restore 216 pendingTransfer = pending transfer 217 pendingUpdate = pending update 218 redemptionPeriod = redemption period 219 renewPeriod = renew period 220 serverDeleteProhibited = server delete prohibited 221 serverRenewProhibited = server renew prohibited 222 serverTransferProhibited = server transfer prohibited 223 serverUpdateProhibited = server update prohibited 224 serverHold = server hold 225 transferPeriod = transfer period 227 3. IANA Considerations 229 3.1. JSON Values Registry 231 The following values should be registered by the IANA in the RDAP 232 JSON Values Registry described in [RFC7483]: 234 Value: add period 236 Type: status 238 Description: This grace period is provided after the initial 239 registration of the object. If the object is deleted by the client 240 during this period, the server provides a credit to the client for 241 the cost of the registration. This maps to the Domain Registry Grace 242 Period Mapping for the Extensible Provisioning Protocol (EPP) 243 [RFC3915] 'addPeriod' status. 245 Registrant Name: IESG 247 Registrant Contact Information: iesg@ietf.org 249 Value: auto renew period 251 Type: status 253 Description: This grace period is provided after an object 254 registration period expires and is extended (renewed) automatically 255 by the server. If the object is deleted by the client during this 256 period, the server provides a credit to the client for the cost of 257 the auto renewal. This maps to the Domain Registry Grace Period 258 Mapping for the Extensible Provisioning Protocol (EPP) [RFC3915] 259 'autoRenewPeriod' status. 261 Registrant Name: IESG 263 Registrant Contact Information: iesg@ietf.org 265 Value: client delete prohibited 267 Type: status 269 Description: The client requested that requests to delete the object 270 MUST be rejected. This maps to the Extensible Provisioning Protocol 271 (EPP) Domain Name Mapping [RFC5731], Extensible Provisioning Protocol 272 (EPP) Host Mapping [RFC5732], and Extensible Provisioning Protocol 273 (EPP) Contact Mapping [RFC5733] 'clientDeleteProhibited' status. 275 Registrant Name: IESG 277 Registrant Contact Information: iesg@ietf.org 279 Value: client hold 281 Type: status 283 Description: The client requested that the DNS delegation information 284 MUST NOT be published for the object. This maps to the Extensible 285 Provisioning Protocol (EPP) Domain Name Mapping [RFC5731] 286 'clientHold' status. 288 Registrant Name: IESG 290 Registrant Contact Information: iesg@ietf.org 292 Value: client renew prohibited 294 Type: status 296 Description: The client requested that requests to renew the object 297 MUST be rejected. This maps to the Extensible Provisioning Protocol 298 (EPP) Domain Name Mapping [RFC5731] 'clientRenewProhibited' status. 300 Registrant Name: IESG 302 Registrant Contact Information: iesg@ietf.org 304 Value: client transfer prohibited 306 Type: status 308 Description: The client requested that requests to transfer the 309 object MUST be rejected. This maps to the Extensible Provisioning 310 Protocol (EPP) Domain Name Mapping [RFC5731] and Extensible 311 Provisioning Protocol (EPP) Contact Mapping [RFC5733] 312 'clientTransferProhibited' status. 314 Registrant Name: IESG 316 Registrant Contact Information: iesg@ietf.org 318 Value: client update prohibited 320 Type: status 322 Description: The client requested that requests to update the object 323 (other than to remove this status) MUST be rejected. This maps to 324 the Extensible Provisioning Protocol (EPP) Domain Name Mapping 325 [RFC5731], Extensible Provisioning Protocol (EPP) Host Mapping 326 [RFC5732], and Extensible Provisioning Protocol (EPP) Contact Mapping 327 [RFC5733] 'clientUpdateProhibited' status. 329 Registrant Name: IESG 331 Registrant Contact Information: iesg@ietf.org 333 Value: pending restore 335 Type: status 336 Description: An object is in the process of being restored after 337 being in the redemption period state. This maps to the Domain 338 Registry Grace Period Mapping for the Extensible Provisioning 339 Protocol (EPP) [RFC3915] 'pendingRestore' status. 341 Registrant Name: IESG 343 Registrant Contact Information: iesg@ietf.org 345 Value: redemption period 347 Type: status 349 Description: A delete has been received, but the object has not yet 350 been purged because an opportunity exists to restore the object and 351 abort the deletion process. This maps to the Domain Registry Grace 352 Period Mapping for the Extensible Provisioning Protocol (EPP) 353 [RFC3915] 'redemptionPeriod' status. 355 Registrant Name: IESG 357 Registrant Contact Information: iesg@ietf.org 359 Value: renew period 361 Type: status 363 Description: This grace period is provided after an object 364 registration period is explicitly extended (renewed) by the client. 365 If the object is deleted by the client during this period, the server 366 provides a credit to the client for the cost of the renewal. This 367 maps to the Domain Registry Grace Period Mapping for the Extensible 368 Provisioning Protocol (EPP) [RFC3915] 'renewPeriod' status. 370 Registrant Name: IESG 372 Registrant Contact Information: iesg@ietf.org 374 Value: server delete prohibited 376 Type: status 378 Description: The server set the status so that requests to delete the 379 object MUST be rejected. This maps to the Extensible Provisioning 380 Protocol (EPP) Domain Name Mapping [RFC5731], Extensible Provisioning 381 Protocol (EPP) Host Mapping [RFC5732], and Extensible Provisioning 382 Protocol (EPP) Contact Mapping [RFC5733] 'serverDeleteProhibited' 383 status. 385 Registrant Name: IESG 387 Registrant Contact Information: iesg@ietf.org 389 Value: server renew prohibited 391 Type: status 393 Description: The server set the status so that requests to renew the 394 object MUST be rejected. This maps to the Extensible Provisioning 395 Protocol (EPP) Domain Name Mapping [RFC5731] 'serverRenewProhibited' 396 status. 398 Registrant Name: IESG 400 Registrant Contact Information: iesg@ietf.org 402 Value: server transfer prohibited 404 Type: status 406 Description: The server set the status so that requests to transfer 407 the object MUST be rejected. This maps to the Extensible 408 Provisioning Protocol (EPP) Domain Name Mapping [RFC5731] and 409 Extensible Provisioning Protocol (EPP) Contact Mapping [RFC5733] 410 'serverTransferProhibited' status. 412 Registrant Name: IESG 414 Registrant Contact Information: iesg@ietf.org 416 Value: server update prohibited 418 Type: status 420 Description: The server set the status so that requests to update the 421 object (other than to remove this status) MUST be rejected. This 422 maps to the Extensible Provisioning Protocol (EPP) Domain Name 423 Mapping [RFC5731], Extensible Provisioning Protocol (EPP) Host 424 Mapping [RFC5732], and Extensible Provisioning Protocol (EPP) Contact 425 Mapping [RFC5733] 'serverUpdateProhibited' status. 427 Registrant Name: IESG 429 Registrant Contact Information: iesg@ietf.org 431 Value: server hold 432 Type: status 434 Description: The server set the status so that DNS delegation 435 information MUST NOT be published for the object. This maps to the 436 Extensible Provisioning Protocol (EPP) Domain Name Mapping [RFC5731] 437 'serverHold' status. 439 Registrant Name: IESG 441 Registrant Contact Information: iesg@ietf.org 443 Value: transfer period 445 Type: status 447 Description: This grace period is provided after the successful 448 transfer of object registration sponsorship from one client to 449 another client. If the object is deleted by the client during this 450 period, the server provides a credit to the client for the cost of 451 the transfer. This maps to the Domain Registry Grace Period Mapping 452 for the Extensible Provisioning Protocol (EPP) [RFC3915] 453 'transferPeriod' status. 455 Registrant Name: IESG 457 Registrant Contact Information: iesg@ietf.org 459 4. Security Considerations 461 The status values described in this document can be subject to 462 server-side information disclosure policies that restrict display of 463 the values to authorized clients. Implementers may wish to review 464 [RFC7481] for a description of the RDAP security services that can be 465 used to implement information disclosure policies. 467 5. Normative References 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 473 the Extensible Provisioning Protocol (EPP)", RFC 3915, 474 September 2004. 476 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 477 Domain Name Mapping", STD 69, RFC 5731, August 2009. 479 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 480 Host Mapping", STD 69, RFC 5732, August 2009. 482 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 483 Contact Mapping", STD 69, RFC 5733, August 2009. 485 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 486 Registration Data Access Protocol (RDAP)", RFC 7481, DOI 487 10.17487/RFC7481, March 2015, 488 . 490 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 491 Registration Data Access Protocol (RDAP)", RFC 7483, March 492 2015. 494 [rdap-json-values] 495 "RDAP JSON Values Registry", 496 . 499 Appendix A. Acknowledgements 501 Suggestions that have been incorporated into this document were 502 provided by Andrew Newton, Scott Hollenbeck, Jim Galvin, Gustavo 503 Lozano, and Robert Sparks. 505 Appendix B. Change History 507 B.1. Change from 00 to 01 509 1. Changed the mapping of "linked" to "associated" and removed the 510 registration of "linked", based on feedback from Andrew Newton on 511 the weirds mailing list. 513 B.2. Change from 01 to 02 515 1. Ping update. 517 B.3. Change from 02 to 03 519 1. Ping update. 521 B.4. Change from 03 to REGEXT 00 523 1. Changed to regext working group draft by changing draft-gould- 524 epp-rdap-status-mapping to draft-ietf-regext-epp-rdap-status- 525 mapping. 527 B.5. Change from REGEXT 00 to REGEXT 01 529 1. Updated based on regext mailing feedback from Scott Hollenbeck 530 that included updating the registrant for the registration of the 531 new statuses to IESG and iesg@ietf.org, and revising the security 532 section. Changed to standards track based on suggestion by Jim 533 Galvin and support from Gustavo Lozano on the regext mailing 534 list. 536 B.6. Change from REGEXT 01 to REGEXT 02 538 1. Updated the text associated with distinguishing client and server 539 prohibited statuses in RDAP based on feedback by Robert Sparks on 540 the regext mailing list. 541 2. Removed the "For DNR that indicates" text from the description of 542 the statuses based on feedback by Robert Sparks on the regext 543 mailing list. 544 3. Made a few editorial changes to the status descriptions including 545 referring to "redemption period" instead of "redemptionPeriod" 546 and referring to "object" instead of "domain name". 547 4. Changed all references of "registrar" to "client" and "registry" 548 to "server" in the status descriptions to be consistent. 550 B.7. Change from REGEXT 02 to REGEXT 03 552 1. Updated descriptions of the add period, auto renew period, renew 553 period, and transfer period statuses to better reflect what the 554 status is in RFC 3915, based on feedback by Robert Sparks on the 555 regext mailing list. 557 B.8. Change from REGEXT 03 to REGEXT 04 559 1. Updated the descriptions of the JSON Values Registry entries to 560 include a reference back to the appropriate EPP RFC status, based 561 on feedback by Sabrina Tanamal from IANA. 563 Author's Address 565 James Gould 566 VeriSign, Inc. 567 12061 Bluemont Way 568 Reston, VA 20190 569 US 571 Email: jgould@verisign.com 572 URI: http://www.verisigninc.com