idnits 2.17.1 draft-ietf-regext-change-poll-05.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 257 has weird spacing: '... udrp a Uni...' -- The document date (January 2, 2018) is 2305 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 K. Feher 5 Expires: July 6, 2018 Neustar 6 January 2, 2018 8 Change Poll Extension for the Extensible Provisioning Protocol (EPP) 9 draft-ietf-regext-change-poll-05 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 July 6, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 5 66 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 69 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 70 3.1.3. EPP Command . . . . . . . . . . . . . . . 15 71 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 72 3.2.1. EPP Command . . . . . . . . . . . . . . . . 15 73 3.2.2. EPP Command . . . . . . . . . . . . . . . . 15 74 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 15 75 3.2.4. EPP Command . . . . . . . . . . . . . . . 15 76 3.2.5. EPP Command . . . . . . . . . . . . . . . . 15 77 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 78 4.1. Change Poll Extension Schema . . . . . . . . . . . . . . 16 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18 81 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19 82 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 83 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20 84 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 20 85 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 20 86 6.4. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 21 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 9. Normative References . . . . . . . . . . . . . . . . . . . . 22 90 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 91 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22 92 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 23 93 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 23 94 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 23 95 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 23 96 A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 23 97 A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 23 98 A.8. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 23 99 A.9. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 23 100 A.10. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 23 101 A.11. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 This document describes an extension mapping for version 1.0 of the 107 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 108 extension to EPP object mappings like the EPP domain name mapping 109 [RFC5731], is used to notify clients of operations they are not 110 directly involved in, on objects that the client sponsors. It is up 111 to server policy to determine what transform operations and clients 112 to notify. Using this extension, clients can more easily keep their 113 systems in-sync with the objects stored in the server. When a change 114 occurs that a client needs to be notified of, a poll message can be 115 inserted by the server for consumption by the client using the EPP 116 command and response defined in [RFC5730]. The extension 117 supports including a "before" operation poll message and an "after" 118 operation poll message. 120 1.1. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 XML is case sensitive. Unless stated otherwise, XML specifications 127 and examples provided in this document MUST be interpreted in the 128 character case presented in order to develop a conforming 129 implementation. 131 In examples, "C:" represents lines sent by a protocol client and "S:" 132 represents lines returned by a protocol server. Indentation and 133 white space in examples are provided only to illustrate element 134 relationships and are not a REQUIRED feature of this protocol. 136 "changePoll-1.0" is used as an abbreviation for 137 "urn:ietf:params:xml:ns:changePoll-1.0". The XML namespace prefix 138 "changePoll" is used, but implementations MUST NOT depend on it and 139 instead employ a proper namespace-aware XML parser and serializer to 140 interpret and output the XML documents. 142 2. Object Attributes 144 This extension adds additional elements to EPP object mappings like 145 the EPP domain name mapping [RFC5731]. Only those new elements are 146 described here. 148 2.1. Operation 150 An operation consists of any transform operation that impacts objects 151 that the client sponsers and SHOULD be notified of. The 152 element defines the operation. The OPTIONAL 153 "op" attribute is used to define a sub-operation or the name of a 154 "custom" operation. The enumerated list of 155 values include: 157 "create" Create operation as defined in [RFC5730]. 158 "delete" Delete operation as defined in [RFC5730]. If the delete 159 operation results in an immediate purge of the object, then the 160 "op" attribute MUST be set to "purge". 161 "renew" Renew operation as defined in [RFC5730]. 162 "transfer" Transfer operation as defined in [RFC5730] that MUST set 163 the "op" attribute with one of the possible transfer type values 164 that include "request", "approve", "cancel", or "reject". 165 "update" Update operation as defined in [RFC5730]. 166 "restore" Restore operation as defined in [RFC3915] that MUST set 167 the "op" attribute with one of the possible restore type values 168 that include "request" or "report". 169 "autoRenew" Auto renew operation executed by the server. 170 "autoDelete" Auto delete operation executed by the server. If the 171 "autoDelete" operation results in an immediate purge of the 172 object, then the "op" attribute MUST be set to "purge". 173 "autoPurge" Auto purge operation executed by the server when 174 removing the object after it had the "pendingDelete" status. 175 "custom" Custom operation that MUST set the "op" attribute with the 176 custom operation name. 178 2.2. Who 180 The element defines who executed the operation for 181 audit purposes. The scheme used for the possible set of 182 element values is up to server policy. The server 183 MAY identify the element value based on: 185 "Identifier" Unique user identifier of the user that executed the 186 operation. An example is "ClientX". 187 "Name" Name of the user that executed the operation. An example is 188 "John Doe". 190 "Role" Role of the user that executed operation. An example is 191 "CSR" for a Customer Support Representative or "Batch" for a 192 server batch. 194 2.3. Dates and Times 196 Date and time attribute values MUST be represented in Universal 197 Coordinated Time (UTC) using the Gregorian calendar. The extended 198 date-time form using upper case "T" and "Z" characters defined in 199 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 200 values, as XML Schema does not support truncated date-time forms or 201 lower case "T" and "Z" characters. 203 3. EPP Command Mapping 205 A detailed description of the EPP syntax and semantics can be found 206 in the EPP core protocol specification [RFC5730]. 208 3.1. EPP Query Commands 210 EPP provides three commands to retrieve object information: 211 to determine if an object is known to the server, to retrieve 212 detailed information associated with an object, and to 213 retrieve object transfer status information. 215 3.1.1. EPP Command 217 This extension does not add any elements to the EPP command 218 or response described in the [RFC5730]. 220 3.1.2. EPP Command 222 This extension does not add any elements to the EPP command 223 described in the [RFC5730]. 225 This extension adds operation detail of EPP object mapping operations 226 Section 2.1 to an EPP poll response, as described in [RFC5730], that 227 is an extension of the EPP object mapping info response. Any 228 transform operation to an object defined in an EPP object mapping, by 229 a client other than the sponsoring client, MAY result in extending 230 the response of the object for inserting an EPP poll message 231 with the operation detail. The sponsoring client will then receive 232 the state of the object with operation detail like what, who, when, 233 and why the object was changed. The element 234 contains the operation detail along with an indication of whether the 235 object reflects the state before or after the operation, using the 236 OPTIONAL "state" attribute, with the possible values of "before" or 237 "after", and with a default value of "after". The "state" attribute 238 describes the state of the response data or block returned 239 in the poll response. The server MAY support providing the "before" 240 state and "after" state to the operation, by using one poll message 241 for the "before" state and one poll message for the "after" state. 242 When using the "before" state poll message, it MUST be inserted prior 243 to the "after" state poll message. The 244 element includes the operation detail with the following child 245 elements: 247 Transform operation executed on the object as 248 defined in Section 2.1. 249 Date and time when the operation was executed. 250 Server transaction identifier of the operation. 251 Who executed the operation as defined in 252 Section 2.2. 253 OPTIONAL case identifer associated with the 254 operation. The required "type" attribute defines the type of 255 case with an enumerated list of case types including: 257 udrp a Uniform Domain-Name Dispute-Resolution Policy (UDRP) 258 case. 259 urs a Uniform Rapid Suspension (URS) case. 260 custom A custom case that is defined using the "name" attribute. 261 OPTIONAL reason for executing the operation. If 262 present, this element contains the server-specific text to help 263 explain the reason the operation was executed. This text MUST be 264 represented in the response language previously negotiated with 265 the client; an OPTIONAL "lang" attribute MAY be present to 266 identify the language if the negotiated value is something other 267 than the default value of "en" (English). 269 Example poll response with the 270 extension for a URS lock transaction on the domain.example domain 271 name, with the "before" state. The "before" state is reflected in 272 the block: 274 S: 275 S: 276 S: 277 S: 278 S: 279 S: Command completed successfully; ack to dequeue 280 S: 281 S: 282 S: 2013-10-22T14:25:57.0Z 283 S: Registry initiated update of domain. 284 S: 285 S: 286 S: 288 S: domain.example 289 S: EXAMPLE1-REP 290 S: 291 S: jd1234 292 S: sh8013 293 S: sh8013 294 S: ClientX 295 S: ClientY 296 S: 2012-04-03T22:00:00.0Z 297 S: 2014-04-03T22:00:00.0Z 298 S: 299 S: 300 S: 301 S: 304 S: update 305 S: 2013-10-22T14:25:57.0Z 306 S: 12345-XYZ 307 S: URS Admin 308 S: urs123 309 S: URS Lock 310 S: 311 S: 312 S: 313 S: ABC-12345 314 S: 54321-XYZ 315 S: 316 S: 317 S: 319 Example poll response with the 320 extension for a URS lock transaction on the domain.example domain 321 name, with the "after" state. The "after" state is reflected in the 322 block: 324 S: 325 S: 326 S: 327 S: 328 S: 329 S: Command completed successfully; ack to dequeue 330 S: 331 S: 332 S: 2013-10-22T14:25:57.0Z 333 S: Registry initiated update of domain. 334 S: 335 S: 336 S: 338 S: domain.example 339 S: EXAMPLE1-REP 340 S: 341 S: 342 S: 343 S: jd1234 344 S: sh8013 345 S: sh8013 346 S: ClientX 347 S: ClientY 348 S: 2012-04-03T22:00:00.0Z 349 S: ClientZ 350 S: 2013-10-22T14:25:57.0Z 351 S: 2014-04-03T22:00:00.0Z 352 S: 353 S: 354 S: 355 S: 358 S: update 359 S: 2013-10-22T14:25:57.0Z 360 S: 12345-XYZ 361 S: URS Admin 362 S: urs123 363 S: URS Lock 364 S: 365 S: 366 S: 367 S: ABC-12345 368 S: 54321-XYZ 369 S: 370 S: 371 S: 372 Example poll response with the 373 extension for a custom "sync" operation on the domain.example domain 374 name, with the default "after" state. The "after" state is reflected 375 in the block: 377 S: 378 S: 379 S: 380 S: 381 S: Command completed successfully; ack to dequeue 382 S: 383 S: 384 S: 2013-10-22T14:25:57.0Z 385 S: Registry initiated Sync of Domain Expiration Date 386 S: 387 S: 388 S: 390 S: domain.example 391 S: EXAMPLE1-REP 392 S: 393 S: jd1234 394 S: sh8013 395 S: sh8013 396 S: ClientX 397 S: ClientY 398 S: 2012-04-03T22:00:00.0Z 399 S: ClientZ 400 S: 2013-10-22T14:25:57.0Z 401 S: 2014-04-03T22:00:00.0Z 402 S: 403 S: 404 S: 405 S: 407 S: custom 408 S: 409 S: 2013-10-22T14:25:57.0Z 410 S: 12345-XYZ 411 S: CSR 412 S: Customer sync request 413 S: 414 S: 415 S: 416 S: 417 S: ABC-12345 418 S: 54321-XYZ 419 S: 420 S: 421 S: 422 Example poll response with the 423 extension for a "delete" operation on the domain.example domain name 424 that is immediately purged, with the default "after" state. The 425 "after" state is reflected in the block: 427 S: 428 S: 429 S: 430 S: 431 S: Command completed successfully; ack to dequeue 432 S: 433 S: 434 S: 2013-10-22T14:25:57.0Z 435 S: Registry initiated delete of 436 S: domain resulting in immediate purge. 437 S: 438 S: 439 S: 441 S: domain.example 442 S: EXAMPLE1-REP 443 S: ClientX 444 S: 445 S: 446 S: 447 S: 449 S: 450 S: delete 451 S: 2013-10-22T14:25:57.0Z 452 S: 12345-XYZ 453 S: ClientZ 454 S: Court order 455 S: 456 S: 457 S: 458 S: ABC-12345 459 S: 54321-XYZ 460 S: 461 S: 462 S: 463 Example poll response with the 464 extension for an "autoPurge" operation on the domain.example domain 465 name that previously had the "pendingDelete" status, with the default 466 "after" state. The "after" state is reflected in the 467 block: 469 S: 470 S: 471 S: 472 S: 473 S: Command completed successfully; ack to dequeue 474 S: 475 S: 476 S: 2013-10-22T14:25:57.0Z 477 S: Registry purged domain with pendingDelete status. 478 S: 479 S: 480 S: 482 S: domain.example 483 S: EXAMPLE1-REP 484 S: ClientX 485 S: 486 S: 487 S: 488 S: 490 S: 491 S: autoPurge 492 S: 2013-10-22T14:25:57.0Z 493 S: 12345-XYZ 494 S: Batch 495 S: 496 S: Past pendingDelete 5 day period 497 S: 498 S: 499 S: 500 S: 501 S: ABC-12345 502 S: 54321-XYZ 503 S: 504 S: 505 S: 506 Example poll response with the 507 extension for an "update" operation on the ns1.domain.example host, 508 with the default "after" state. The "after" state is reflected in 509 the block: 511 S: 512 S: 513 S: 514 S: 515 S: Command completed successfully; ack to dequeue 516 S: 517 S: 518 S: 2013-10-22T14:25:57.0Z 519 S: Registry initiated update of host. 520 S: 521 S: 522 S: 524 S: ns1.domain.example 525 S: NS1_EXAMPLE1-REP 526 S: 527 S: 528 S: 529 S: 192.0.2.2 530 S: 1080:0:0:0:8:800:200C:417A 531 S: ClientX 532 S: ClientY 533 S: 2012-04-03T22:00:00.0Z 534 S: ClientY 535 S: 2013-10-22T14:25:57.0Z 536 S: 537 S: 538 S: 539 S: 541 S: update 542 S: 2013-10-22T14:25:57.0Z 543 S: 12345-XYZ 544 S: ClientZ 545 S: Host Lock 546 S: 547 S: 548 S: 549 S: ABC-12345 550 S: 54321-XYZ 551 S: 552 S: 553 S: 555 3.1.3. EPP Command 557 This extension does not add any elements to the EPP query 558 command or response described in the [RFC5730]. 560 3.2. EPP Transform Commands 562 EPP provides five commands to transform objects: to create 563 an instance of an object, to delete an instance of an 564 object, to extend the validity period of an object, 565 to manage object sponsorship changes, and to 566 change information associated with an object. 568 3.2.1. EPP Command 570 This extension does not add any elements to the EPP command 571 or response described in the [RFC5730]. 573 3.2.2. EPP Command 575 This extension does not add any elements to the EPP command 576 or response described in the [RFC5730]. 578 3.2.3. EPP Command 580 This extension does not add any elements to the EPP command 581 or response described in the [RFC5730]. 583 3.2.4. EPP Command 585 This extension does not add any elements to the EPP 586 command or response described in the [RFC5730]. 588 3.2.5. EPP Command 590 This extension does not add any elements to the EPP command 591 or response described in the [RFC5730]. 593 4. Formal Syntax 595 One schema is presented here that is the EPP Change Poll Extension 596 schema. 598 The formal syntax presented here is a complete schema representation 599 of the object mapping suitable for automated validation of EPP XML 600 instances. The BEGIN and END tags are not part of the schema; they 601 are used to note the beginning and ending of the schema for URI 602 registration purposes. 604 4.1. Change Poll Extension Schema 606 BEGIN 607 608 615 618 619 621 622 623 Extensible Provisioning Protocol v1.0 624 Change Poll Mapping Schema. 625 626 628 631 633 636 637 638 639 640 641 642 644 646 647 649 650 653 654 655 656 657 658 659 660 661 662 663 664 665 666 668 671 672 673 674 675 676 678 681 682 683 684 685 686 687 689 692 693 694 695 697 699 700 701 703 706 707 708 709 710 711 712 714 717 718 719 720 721 722 724 727 728 END 730 5. IANA Considerations 732 5.1. XML Namespace 734 This document uses URNs to describe XML namespaces and XML schemas 735 conforming to a registry mechanism described in [RFC3688]. The 736 following URI assignment is requested of IANA: 738 URI: urn:ietf:params:xml:ns:changePoll-1.0 740 Registrant Contact: See the "Author's Address" section of this 741 document. 743 XML: See the "Formal Syntax" section of this document. 745 5.2. EPP Extension Registry 747 The EPP extension described in this document should be registered by 748 the IANA in the EPP Extension Registry described in [RFC7451]. The 749 details of the registration are as follows: 751 Name of Extension: "Change Poll Extension for the Extensible 752 Provisioning Protocol (EPP)" 754 Document status: Standards Track 756 Reference: (insert reference to RFC version of this document) 758 Registrant Name and Email Address: IESG, 760 TLDs: Any 762 IPR Disclosure: None 764 Status: Active 766 Notes: None 768 6. Implementation Status 770 Note to RFC Editor: Please remove this section and the reference to 771 RFC 6982 [RFC6982] before publication. 773 This section records the status of known implementations of the 774 protocol defined by this specification at the time of posting of this 775 Internet-Draft, and is based on a proposal described in RFC 6982 776 [RFC6982]. The description of implementations in this section is 777 intended to assist the IETF in its decision processes in progressing 778 drafts to RFCs. Please note that the listing of any individual 779 implementation here does not imply endorsement by the IETF. 780 Furthermore, no effort has been spent to verify the information 781 presented here that was supplied by IETF contributors. This is not 782 intended as, and must not be construed to be, a catalog of available 783 implementations or their features. Readers are advised to note that 784 other implementations may exist. 786 According to RFC 6982 [RFC6982], "this will allow reviewers and 787 working groups to assign due consideration to documents that have the 788 benefit of running code, which may serve as evidence of valuable 789 experimentation and feedback that have made the implemented protocols 790 more mature. It is up to the individual working groups to use this 791 information as they see fit". 793 6.1. Verisign EPP SDK 795 Organization: Verisign Inc. 797 Name: Verisign EPP SDK 799 Description: The Verisign EPP SDK includes both a full client 800 implementation and a full server stub implementation of draft-ietf- 801 regext-change-poll. 803 Level of maturity: Production 805 Coverage: All aspects of the protocol are implemented. 807 Licensing: GNU Lesser General Public License 809 Contact: jgould@verisign.com 811 URL: https://www.verisign.com/en_US/channel-resources/domain- 812 registry-products/epp-sdks 814 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 816 Organization: Verisign Inc. 818 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 819 System (SRS) 821 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 822 Registry System (SRS) implements the server-side of draft-ietf- 823 regext-change-poll for a variety of Top Level Domains (TLD's). 825 Level of maturity: Production 827 Coverage: The "after" state poll message for an "update" transform 828 operation of a domain name due to server policy. 830 Licensing: Proprietary 832 Contact: jgould@verisign.com 834 6.3. Verisign .COM / .NET SRS 836 Organization: Verisign Inc. 838 Name: Verisign .COM / .NET Shared Registry System (SRS) 839 Description: The Verisign Shared Registry System (SRS) for .COM and 840 .NET implements the server-side of draft-ietf-regext-change-poll. 842 Level of maturity: Production 844 Coverage: The "after" state poll message for an "update" transform 845 operation of a domain name due to server policy. 847 Licensing: Proprietary 849 Contact: jgould@verisign.com 851 6.4. Neustar EPP SDK 853 Organisation: Neustar Inc. 855 Name: Neustar EPP SDK 857 Description: The Neustar EPP SDK includes a full client 858 implementation of draft-ietf-regext-change-poll. 860 Level of maturity: Production 862 Coverage: All client side aspects of the protocol are implemented. 864 Licensing: GNU Lesser General Public License 866 Contact: kal.feher@team.neustar 868 7. Security Considerations 870 The mapping extensions described in this document do not provide any 871 security services beyond those described by EPP [RFC5730] and 872 protocol layers used by EPP. The security considerations described 873 in these other specifications apply to this specification as well. 875 8. Acknowledgements 877 The authors wish to acknowledge the original concept for this draft 878 and the efforts in the initial versions of this draft by Trung Tran 879 and Sharon Wodjenski. 881 Special suggestions that have been incorporated into this document 882 were provided by Michael Holloway and Patrick Mevzek. 884 9. Normative References 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, 888 DOI 10.17487/RFC2119, March 1997, . 891 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 892 DOI 10.17487/RFC3688, January 2004, . 895 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 896 the Extensible Provisioning Protocol (EPP)", RFC 3915, 897 DOI 10.17487/RFC3915, September 2004, . 900 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 901 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 902 . 904 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 905 Domain Name Mapping", STD 69, RFC 5731, 906 DOI 10.17487/RFC5731, August 2009, . 909 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 910 Code: The Implementation Status Section", RFC 6982, 911 DOI 10.17487/RFC6982, July 2013, . 914 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 915 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 916 February 2015, . 918 [W3C.REC-xmlschema-2-20041028] 919 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 920 Second Edition", World Wide Web Consortium Recommendation 921 REC-xmlschema-2-20041028, October 2004, 922 . 924 Appendix A. Change History 926 A.1. Change from 00 to 01 928 1. Added an optional caseId element that defines the case identifier 929 from UDRP, URS, or custom case, based on feedback from Michael 930 Holloway. 932 A.2. Change from 01 to 02 934 1. Amended XML Namespace section of IANA Considerations, added EPP 935 Extension Registry section. 936 2. Moved Change History to the back section as an Appendix. 938 A.3. Change from 02 to 03 940 1. Fixed "before" state example to use the "before" state value 941 based on feedback from Patrick Mevzek. 943 A.4. Change from 03 to 04 945 1. Updated the authors for the draft. 947 A.5. Change from 04 to 05 949 1. Ping update. 951 A.6. Change from 05 to REGEXT 00 953 1. Changed to regext working group draft by changing draft-gould- 954 change-poll to draft-ietf-regext-change-poll. 956 A.7. Change from REGEXT 00 to REGEXT 01 958 1. Ping update. 960 A.8. Change from REGEXT 01 to REGEXT 02 962 1. Added the Implementation Status section. 964 A.9. Change from REGEXT 02 to REGEXT 03 966 1. Changed Neustar author to Kal Feher. 968 A.10. Change from REGEXT 03 to REGEXT 04 970 1. Added Neustar implementation to the Implementation Status 971 section. 973 A.11. Change from REGEXT 04 to REGEXT 05 975 1. Updates based on feedback from Patrick Mevzek, that include: 977 1. Added a missing comma to "Using this extension, clients" in 978 the Introduction section. 980 2. Modified the description of the "transfer", "restore", and 981 "custom" operations to include "MUST set the "op" attribute" 982 language. 983 3. Rephrased the first sentence of the Who section. 984 4. Added references to the element in the Who 985 section. 986 5. Revise the sentence that describes how the extension extends 987 the info response in the EPP Command section. 988 6. Refer to EPP Object Mapping as EPP object mapping throughout 989 the document. 990 7. Add a Dates and Times section to the Object Attributes 991 section. 993 Authors' Addresses 995 James Gould 996 VeriSign, Inc. 997 12061 Bluemont Way 998 Reston, VA 20190 999 US 1001 Email: jgould@verisign.com 1002 URI: http://www.verisigninc.com 1004 Kal Feher 1005 Neustar 1006 lvl 8/10 Queens Road 1007 Melbourne, VIC 3004 1008 AU 1010 Email: kal.feher@team.neustar 1011 URI: http://www.neustar.biz