idnits 2.17.1 draft-ietf-regext-change-poll-02.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 == Line 242 has weird spacing: '... udrp a Uni...' -- The document date (June 23, 2017) is 2492 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 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 S. Wodjenski 5 Expires: December 25, 2017 Neustar 6 June 23, 2017 8 Change Poll Extension for the Extensible Provisioning Protocol (EPP) 9 draft-ietf-regext-change-poll-02 11 Abstract 13 This document describes an Extensible Provisioning Protocol (EPP) 14 extension for notifying clients of operations on client sponsored 15 objects that were not initiated by the client through EPP. These 16 operations MAY include contractual or policy requirements including 17 but not limited to regular batch processes, customer support actions, 18 Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid 19 Suspension (URS) actions, court directed actions, and bulk updates 20 based on customer requests. Since the client is not directly 21 involved or knowledgable of these operations, the extension is used 22 along with an EPP object mapping to provide the resulting state of 23 the post-operation object, and optionally a pre-operation object, 24 with the operation meta-data of what, when, who, and why. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 25, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 68 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 69 3.1.3. EPP Command . . . . . . . . . . . . . . . 15 70 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 71 3.2.1. EPP Command . . . . . . . . . . . . . . . . 15 72 3.2.2. EPP Command . . . . . . . . . . . . . . . . 15 73 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 15 74 3.2.4. EPP Command . . . . . . . . . . . . . . . 15 75 3.2.5. EPP Command . . . . . . . . . . . . . . . . 15 76 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 77 4.1. Change Poll Extension Schema . . . . . . . . . . . . . . 16 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18 80 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19 81 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 82 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20 83 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 20 84 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 20 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 88 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 89 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22 90 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 22 91 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 22 92 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 22 93 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 22 94 A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 22 95 A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 23 96 A.8. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 23 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 This document describes an extension mapping for version 1.0 of the 102 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 103 extension to EPP object mappings like the EPP domain name mapping 104 [RFC5731], is used to notify clients of operations they are not 105 directly involved in, on objects that the client sponsors. It is up 106 to server policy to determine what transform operations and clients 107 to notify. Using this extension clients can more easily keep their 108 systems in-sync with the objects stored in the server. When a change 109 occurs that a client needs to be notified of, a poll message can be 110 inserted by the server for consumption by the client using the EPP 111 command and response defined in [RFC5730]. The extension 112 supports including a "before" operation poll message and an "after" 113 operation poll message. 115 1.1. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 XML is case sensitive. Unless stated otherwise, XML specifications 122 and examples provided in this document MUST be interpreted in the 123 character case presented in order to develop a conforming 124 implementation. 126 In examples, "C:" represents lines sent by a protocol client and "S:" 127 represents lines returned by a protocol server. Indentation and 128 white space in examples are provided only to illustrate element 129 relationships and are not a REQUIRED feature of this protocol. 131 "changePoll-1.0" is used as an abbreviation for 132 "urn:ietf:params:xml:ns:changePoll-1.0". The XML namespace prefix 133 "changePoll" is used, but implementations MUST NOT depend on it and 134 instead employ a proper namespace-aware XML parser and serializer to 135 interpret and output the XML documents. 137 2. Object Attributes 139 This extension adds additional elements to EPP object mappings like 140 the EPP domain name mapping [RFC5731]. Only those new elements are 141 described here. 143 2.1. Operation 145 An operation consists of any transform operation that impacts objects 146 that the client sponsers and SHOULD be notified of. The 147 element defines the operation. The OPTIONAL 148 "op" attribute is used to define a sub-operation or the name of a 149 "custom" operation. The enumerated list of 150 values include: 152 "create" Create operation as defined in [RFC5730]. 153 "delete" Delete operation as defined in [RFC5730]. If the delete 154 operation results in an immediate purge of the object, then the 155 "op" attribute MUST be set to "purge". 156 "renew" Renew operation as defined in [RFC5730]. 157 "transfer" Transfer operation as defined in [RFC5730] with the 158 OPTIONAL "op" attribute defining the transfer type with the 159 possible values of "request", "approve", "cancel", and "reject". 160 "update" Update operation as defined in [RFC5730]. 161 "restore" Restore operation as defined in [RFC3915] with the 162 OPTIONAL "op" attribute defining the restore type with the 163 possible values of "request" and "report". 164 "autoRenew" Auto renew operation executed by the server. 165 "autoDelete" Auto delete operation executed by the server. If the 166 "autoDelete" operation results in an immediate purge of the 167 object, then the "op" attribute MUST be set to "purge". 168 "autoPurge" Auto purge operation executed by the server when 169 removing the object after it had the "pendingDelete" status. 170 "custom" Custom operation that uses the "op" attribute to define the 171 custom operation name. 173 2.2. Who 175 Who defines who executed the operation for audit purposes, and is 176 represented using the element. The scheme used for 177 the possible set of Who values is up to server policy. The server 178 MAY identify Who based on: 180 "Identifier" Unique user identifier of the user that executed the 181 operation. An example is "ClientX". 182 "Name" Name of the user that executed the operation. An example is 183 "John Doe". 184 "Role" Role of the user that executed operation. An example is 185 "CSR" for a Customer Support Representative or "Batch" for a 186 server batch. 188 3. EPP Command Mapping 190 A detailed description of the EPP syntax and semantics can be found 191 in the EPP core protocol specification [RFC5730]. 193 3.1. EPP Query Commands 195 EPP provides three commands to retrieve object information: 196 to determine if an object is known to the server, to retrieve 197 detailed information associated with an object, and to 198 retrieve object transfer status information. 200 3.1.1. EPP Command 202 This extension does not add any elements to the EPP command 203 or response described in the [RFC5730]. 205 3.1.2. EPP Command 207 This extension does not add any elements to the EPP command 208 described in the [RFC5730]. 210 This extension adds transaction detail of the operations to the EPP 211 poll response, as described in [RFC5730], of an EPP Object 212 Mapping like [RFC5731]. Any transform operation to an object defined 213 in an EPP Object Mapping, by a client other than the sponsoring 214 client, MAY result in extending the response of the object for 215 inserting an EPP poll message with the operation detail. The 216 sponsoring client will then receive the state of the object with 217 operation detail like what, who, when, and why the object was 218 changed. The element contains the operation 219 detail along with an indication of whether the object reflects the 220 state before or after the operation, using the OPTIONAL "state" 221 attribute, with the possible values of "before" or "after", and with 222 a default value of "after". The "state" attribute describes the 223 state of the response data or block returned in the poll 224 response. The server MAY support providing the "before" state and 225 "after" state to the operation, by using one poll message for the 226 "before" state and one poll message for the "after" state. When 227 using the "before" state poll message, it MUST be inserted prior to 228 the "after" state poll message. The element 229 includes the operation detail with the following child elements: 231 Transform operation executed on the object as 232 defined in Section 2.1. 233 Date and time when the operation was executed. 234 Server transaction identifier of the operation. 236 Who executed the operation as defined in 237 Section 2.2. 238 OPTIONAL case identifer associated with the 239 operation. The required "type" attribute defines the type of 240 case with an enumerated list of case types including: 242 udrp a Uniform Domain-Name Dispute-Resolution Policy (UDRP) 243 case. 244 urs a Uniform Rapid Suspension (URS) case. 245 custom A custom case that is defined using the "name" attribute. 246 OPTIONAL reason for executing the operation. If 247 present, this element contains the server-specific text to help 248 explain the reason the operation was executed. This text MUST be 249 represented in the response language previously negotiated with 250 the client; an OPTIONAL "lang" attribute MAY be present to 251 identify the language if the negotiated value is something other 252 than the default value of "en" (English). 254 Example poll response with the 255 extension for a URS lock transaction on the domain.example domain 256 name, with the "before" state. The "before" state is reflected in 257 the block: 259 S: 260 S: 261 S: 262 S: 263 S: 264 S: Command completed successfully; ack to dequeue 265 S: 266 S: 267 S: 2013-10-22T14:25:57.0Z 268 S: Registry initiated update of domain. 269 S: 270 S: 271 S: 273 S: domain.example 274 S: EXAMPLE1-REP 275 S: 276 S: jd1234 277 S: sh8013 278 S: sh8013 279 S: ClientX 280 S: ClientY 281 S: 2012-04-03T22:00:00.0Z 282 S: 2014-04-03T22:00:00.0Z 283 S: 284 S: 285 S: 286 S: 289 S: update 290 S: 2013-10-22T14:25:57.0Z 291 S: 12345-XYZ 292 S: URS Admin 293 S: urs123 294 S: URS Lock 295 S: 296 S: 297 S: 298 S: ABC-12345 299 S: 54321-XYZ 300 S: 301 S: 302 S: 304 Example poll response with the 305 extension for a URS lock transaction on the domain.example domain 306 name, with the "after" state. The "after" state is reflected in the 307 block: 309 S: 310 S: 311 S: 312 S: 313 S: 314 S: Command completed successfully; ack to dequeue 315 S: 316 S: 317 S: 2013-10-22T14:25:57.0Z 318 S: Registry initiated update of domain. 319 S: 320 S: 321 S: 323 S: domain.example 324 S: EXAMPLE1-REP 325 S: 326 S: 327 S: 328 S: jd1234 329 S: sh8013 330 S: sh8013 331 S: ClientX 332 S: ClientY 333 S: 2012-04-03T22:00:00.0Z 334 S: ClientZ 335 S: 2013-10-22T14:25:57.0Z 336 S: 2014-04-03T22:00:00.0Z 337 S: 338 S: 339 S: 340 S: 343 S: update 344 S: 2013-10-22T14:25:57.0Z 345 S: 12345-XYZ 346 S: URS Admin 347 S: urs123 348 S: URS Lock 349 S: 350 S: 351 S: 352 S: ABC-12345 353 S: 54321-XYZ 354 S: 355 S: 356 S: 357 Example poll response with the 358 extension for a custom "sync" operation on the domain.example domain 359 name, with the default "after" state. The "after" state is reflected 360 in the block: 362 S: 363 S: 364 S: 365 S: 366 S: Command completed successfully; ack to dequeue 367 S: 368 S: 369 S: 2013-10-22T14:25:57.0Z 370 S: Registry initiated Sync of Domain Expiration Date 371 S: 372 S: 373 S: 375 S: domain.example 376 S: EXAMPLE1-REP 377 S: 378 S: jd1234 379 S: sh8013 380 S: sh8013 381 S: ClientX 382 S: ClientY 383 S: 2012-04-03T22:00:00.0Z 384 S: ClientZ 385 S: 2013-10-22T14:25:57.0Z 386 S: 2014-04-03T22:00:00.0Z 387 S: 388 S: 389 S: 390 S: 392 S: custom 393 S: 394 S: 2013-10-22T14:25:57.0Z 395 S: 12345-XYZ 396 S: CSR 397 S: Customer sync request 398 S: 399 S: 400 S: 401 S: 402 S: ABC-12345 403 S: 54321-XYZ 404 S: 405 S: 406 S: 407 Example poll response with the 408 extension for a "delete" operation on the domain.example domain name 409 that is immediately purged, with the default "after" state. The 410 "after" state is reflected in the block: 412 S: 413 S: 414 S: 415 S: 416 S: Command completed successfully; ack to dequeue 417 S: 418 S: 419 S: 2013-10-22T14:25:57.0Z 420 S: Registry initiated delete of 421 S: domain resulting in immediate purge. 422 S: 423 S: 424 S: 426 S: domain.example 427 S: EXAMPLE1-REP 428 S: ClientX 429 S: 430 S: 431 S: 432 S: 434 S: 435 S: delete 436 S: 2013-10-22T14:25:57.0Z 437 S: 12345-XYZ 438 S: ClientZ 439 S: Court order 440 S: 441 S: 442 S: 443 S: ABC-12345 444 S: 54321-XYZ 445 S: 446 S: 447 S: 448 Example poll response with the 449 extension for an "autoPurge" operation on the domain.example domain 450 name that previously had the "pendingDelete" status, with the default 451 "after" state. The "after" state is reflected in the 452 block: 454 S: 455 S: 456 S: 457 S: 458 S: Command completed successfully; ack to dequeue 459 S: 460 S: 461 S: 2013-10-22T14:25:57.0Z 462 S: Registry purged domain with pendingDelete status. 463 S: 464 S: 465 S: 467 S: domain.example 468 S: EXAMPLE1-REP 469 S: ClientX 470 S: 471 S: 472 S: 473 S: 475 S: 476 S: autoPurge 477 S: 2013-10-22T14:25:57.0Z 478 S: 12345-XYZ 479 S: Batch 480 S: 481 S: Past pendingDelete 5 day period 482 S: 483 S: 484 S: 485 S: 486 S: ABC-12345 487 S: 54321-XYZ 488 S: 489 S: 490 S: 491 Example poll response with the 492 extension for an "update" operation on the ns1.domain.example host, 493 with the default "after" state. The "after" state is reflected in 494 the block: 496 S: 497 S: 498 S: 499 S: 500 S: Command completed successfully; ack to dequeue 501 S: 502 S: 503 S: 2013-10-22T14:25:57.0Z 504 S: Registry initiated update of host. 505 S: 506 S: 507 S: 509 S: ns1.domain.example 510 S: NS1_EXAMPLE1-REP 511 S: 512 S: 513 S: 514 S: 192.0.2.2 515 S: 1080:0:0:0:8:800:200C:417A 516 S: ClientX 517 S: ClientY 518 S: 2012-04-03T22:00:00.0Z 519 S: ClientY 520 S: 2013-10-22T14:25:57.0Z 521 S: 522 S: 523 S: 524 S: 526 S: update 527 S: 2013-10-22T14:25:57.0Z 528 S: 12345-XYZ 529 S: ClientZ 530 S: Host Lock 531 S: 532 S: 533 S: 534 S: ABC-12345 535 S: 54321-XYZ 536 S: 537 S: 538 S: 540 3.1.3. EPP Command 542 This extension does not add any elements to the EPP query 543 command or response described in the [RFC5730]. 545 3.2. EPP Transform Commands 547 EPP provides five commands to transform objects: to create 548 an instance of an object, to delete an instance of an 549 object, to extend the validity period of an object, 550 to manage object sponsorship changes, and to 551 change information associated with an object. 553 3.2.1. EPP Command 555 This extension does not add any elements to the EPP command 556 or response described in the [RFC5730]. 558 3.2.2. EPP Command 560 This extension does not add any elements to the EPP command 561 or response described in the [RFC5730]. 563 3.2.3. EPP Command 565 This extension does not add any elements to the EPP command 566 or response described in the [RFC5730]. 568 3.2.4. EPP Command 570 This extension does not add any elements to the EPP 571 command or response described in the [RFC5730]. 573 3.2.5. EPP Command 575 This extension does not add any elements to the EPP command 576 or response described in the [RFC5730]. 578 4. Formal Syntax 580 One schema is presented here that is the EPP Change Poll Extension 581 schema. 583 The formal syntax presented here is a complete schema representation 584 of the object mapping suitable for automated validation of EPP XML 585 instances. The BEGIN and END tags are not part of the schema; they 586 are used to note the beginning and ending of the schema for URI 587 registration purposes. 589 4.1. Change Poll Extension Schema 591 BEGIN 592 593 600 603 604 606 607 608 Extensible Provisioning Protocol v1.0 609 Change Poll Mapping Schema. 610 611 613 616 618 621 622 623 624 625 626 627 629 631 632 634 635 638 639 640 641 642 643 644 645 646 647 648 649 650 651 653 656 657 658 659 660 661 663 666 667 668 669 670 671 672 674 677 678 679 680 682 684 685 686 688 691 692 693 694 695 696 697 699 702 703 704 705 706 707 709 712 713 END 715 5. IANA Considerations 717 5.1. XML Namespace 719 This document uses URNs to describe XML namespaces and XML schemas 720 conforming to a registry mechanism described in [RFC3688]. The 721 following URI assignment is requested of IANA: 723 URI: urn:ietf:params:xml:ns:changePoll-1.0 725 Registrant Contact: See the "Author's Address" section of this 726 document. 728 XML: See the "Formal Syntax" section of this document. 730 5.2. EPP Extension Registry 732 The EPP extension described in this document should be registered by 733 the IANA in the EPP Extension Registry described in [RFC7451]. The 734 details of the registration are as follows: 736 Name of Extension: "Change Poll Extension for the Extensible 737 Provisioning Protocol (EPP)" 739 Document status: Standards Track 741 Reference: (insert reference to RFC version of this document) 743 Registrant Name and Email Address: IESG, 745 TLDs: Any 747 IPR Disclosure: None 749 Status: Active 751 Notes: None 753 6. Implementation Status 755 Note to RFC Editor: Please remove this section and the reference to 756 RFC 6982 [RFC6982] before publication. 758 This section records the status of known implementations of the 759 protocol defined by this specification at the time of posting of this 760 Internet-Draft, and is based on a proposal described in RFC 6982 761 [RFC6982]. The description of implementations in this section is 762 intended to assist the IETF in its decision processes in progressing 763 drafts to RFCs. Please note that the listing of any individual 764 implementation here does not imply endorsement by the IETF. 765 Furthermore, no effort has been spent to verify the information 766 presented here that was supplied by IETF contributors. This is not 767 intended as, and must not be construed to be, a catalog of available 768 implementations or their features. Readers are advised to note that 769 other implementations may exist. 771 According to RFC 6982 [RFC6982], "this will allow reviewers and 772 working groups to assign due consideration to documents that have the 773 benefit of running code, which may serve as evidence of valuable 774 experimentation and feedback that have made the implemented protocols 775 more mature. It is up to the individual working groups to use this 776 information as they see fit". 778 6.1. Verisign EPP SDK 780 Organization: Verisign Inc. 782 Name: Verisign EPP SDK 784 Description: The Verisign EPP SDK includes both a full client 785 implementation and a full server stub implementation of draft-ietf- 786 regext-change-poll. 788 Level of maturity: Production 790 Coverage: All aspects of the protocol are implemented. 792 Licensing: GNU Lesser General Public License 794 Contact: jgould@verisign.com 796 URL: https://www.verisign.com/en_US/channel-resources/domain- 797 registry-products/epp-sdks 799 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 801 Organization: Verisign Inc. 803 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 804 System (SRS) 806 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 807 Registry System (SRS) implements the server-side of draft-ietf- 808 regext-change-poll for a variety of Top Level Domains (TLD's). 810 Level of maturity: Production 812 Coverage: The "after" state poll message for an "update" transform 813 operation of a domain name due to server policy. 815 Licensing: Proprietary 817 Contact: jgould@verisign.com 819 6.3. Verisign .COM / .NET SRS 821 Organization: Verisign Inc. 823 Name: Verisign .COM / .NET Shared Registry System (SRS) 824 Description: The Verisign Shared Registry System (SRS) for .COM and 825 .NET implements the server-side of draft-ietf-regext-change-poll. 827 Level of maturity: Production 829 Coverage: The "after" state poll message for an "update" transform 830 operation of a domain name due to server policy. 832 Licensing: Proprietary 834 Contact: jgould@verisign.com 836 7. Security Considerations 838 The mapping extensions described in this document do not provide any 839 security services beyond those described by EPP [RFC5730] and 840 protocol layers used by EPP. The security considerations described 841 in these other specifications apply to this specification as well. 843 8. Acknowledgements 845 The authors wish to acknowledge the original concept for this draft 846 and the efforts in the initial versions of this draft by Trung Tran. 848 Special suggestions that have been incorporated into this document 849 were provided by Michael Holloway. 851 9. Normative References 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, 855 DOI 10.17487/RFC2119, March 1997, 856 . 858 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 859 DOI 10.17487/RFC3688, January 2004, 860 . 862 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 863 the Extensible Provisioning Protocol (EPP)", RFC 3915, 864 DOI 10.17487/RFC3915, September 2004, 865 . 867 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 868 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 869 . 871 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 872 Domain Name Mapping", STD 69, RFC 5731, 873 DOI 10.17487/RFC5731, August 2009, 874 . 876 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 877 Code: The Implementation Status Section", RFC 6982, 878 DOI 10.17487/RFC6982, July 2013, 879 . 881 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 882 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 883 February 2015, . 885 Appendix A. Change History 887 A.1. Change from 00 to 01 889 1. Added an optional caseId element that defines the case identifier 890 from UDRP, URS, or custom case, based on feedback from Michael 891 Holloway. 893 A.2. Change from 01 to 02 895 1. Amended XML Namespace section of IANA Considerations, added EPP 896 Extension Registry section. 897 2. Moved Change History to the back section as an Appendix. 899 A.3. Change from 02 to 03 901 1. Fixed "before" state example to use the "before" state value 902 based on feedback from Patrick Mevzek. 904 A.4. Change from 03 to 04 906 1. Updated the authors for the draft. 908 A.5. Change from 04 to 05 910 1. Ping update. 912 A.6. Change from 05 to REGEXT 00 914 1. Changed to regext working group draft by changing draft-gould- 915 change-poll to draft-ietf-regext-change-poll. 917 A.7. Change from REGEXT 00 to REGEXT 01 919 1. Ping update. 921 A.8. Change from REGEXT 01 to REGEXT 02 923 1. Added the Implementation Status section. 925 Authors' Addresses 927 James Gould 928 VeriSign, Inc. 929 12061 Bluemont Way 930 Reston, VA 20190 931 US 933 Email: jgould@verisign.com 934 URI: http://www.verisigninc.com 936 Sharon Wodjenski 937 Neustar 938 21575 Ridgetop Circle 939 Sterling, VA 20166 940 US 942 Email: Sharon.Wodjenski@neustar.biz 943 URI: http://www.neustar.biz