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