idnits 2.17.1 draft-ietf-regext-change-poll-12.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 4, 2019) is 1939 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) No issues found here. Summary: 0 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 8, 2019 Neustar 6 January 4, 2019 8 Change Poll Extension for the Extensible Provisioning Protocol (EPP) 9 draft-ietf-regext-change-poll-12 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 8, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 22 87 6.4. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 22 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 92 9.2. Informative References . . . . . . . . . . . . . . . . . 24 93 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24 94 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24 95 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24 96 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24 97 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 24 98 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 24 99 A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 24 100 A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 24 101 A.8. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 25 102 A.9. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 25 103 A.10. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 25 104 A.11. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 25 105 A.12. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 25 106 A.13. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 25 107 A.14. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 26 108 A.15. Change from REGEXT 08 to REGEXT 09 . . . . . . . . . . . 26 109 A.16. Change from REGEXT 09 to REGEXT 10 . . . . . . . . . . . 26 110 A.17. Change from REGEXT 10 to REGEXT 11 . . . . . . . . . . . 27 111 A.18. Change from REGEXT 11 to REGEXT 12 . . . . . . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 This document describes an extension mapping for version 1.0 of the 117 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 118 extension to EPP object mappings like the EPP domain name mapping 119 [RFC5731], is used to notify clients of operations they are not 120 directly involved in, on objects that the client sponsors. It is up 121 to server policy to determine what transform operations and clients 122 to notify. Using this extension, clients can more easily keep their 123 systems in-sync with the objects stored in the server. When a change 124 occurs that a client needs to be notified of, a poll message can be 125 inserted by the server for consumption by the client using the EPP 126 command and response defined in [RFC5730]. The extension 127 supports including a "before" operation poll message and an "after" 128 operation poll message. The extension only extends the EPP 129 response in [RFC5730] and does not extend the EPP command. 130 Please refer to [RFC5730] for information and examples of the EPP 131 command. 133 1.1. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 XML is case sensitive. Unless stated otherwise, XML specifications 142 and examples provided in this document MUST be interpreted in the 143 character case presented in order to develop a conforming 144 implementation. 146 In examples, "C:" represents lines sent by a protocol client and "S:" 147 represents lines returned by a protocol server. Indentation and 148 white space in examples are provided only to illustrate element 149 relationships and are not a REQUIRED feature of this protocol. 151 The XML namespace prefix "changePoll" is used for the namespace 152 "urn:ietf:params:xml:ns:changePoll-1.0", but implementations MUST NOT 153 depend on it and instead employ a proper namespace-aware XML parser 154 and serializer to interpret and output the XML documents. 156 2. Object Attributes 158 This extension adds additional elements to EPP object mappings like 159 the EPP domain name mapping [RFC5731]. Only those new elements are 160 described here. 162 2.1. Operation 164 An operation consists of any transform operation that impacts objects 165 that the client sponsers and should be notified of. The 166 element defines the operation. The OPTIONAL 167 "op" attribute is an identifier, represented in the 7-bit US-ASCII 168 character set defined in [RFC0020], that is used to define a sub- 169 operation or the name of a "custom" operation. The enumerated list 170 of values is: 172 "create": Create operation as defined in [RFC5730]. 173 "delete": Delete operation as defined in [RFC5730]. If the delete 174 operation results in an immediate purge of the object, then the 175 "op" attribute MUST be set to "purge". 176 "renew": Renew operation as defined in [RFC5730]. 177 "transfer": Transfer operation as defined in [RFC5730] that MUST set 178 the "op" attribute with one of the possible transfer type values 179 that include "request", "approve", "cancel", or "reject". 180 "update": Update operation as defined in [RFC5730]. 181 "restore": Restore operation as defined in [RFC3915] that MUST set 182 the "op" attribute with one of the possible restore type values 183 that include "request" or "report". 184 "autoRenew": Auto renew operation executed by the server. 185 "autoDelete": Auto delete operation executed by the server. If the 186 "autoDelete" operation results in an immediate purge of the 187 object, then the "op" attribute MUST be set to "purge". 188 "autoPurge": Auto purge operation executed by the server when 189 removing the object after it had the "pendingDelete" status. 191 "custom": Custom operation that MUST set the "op" attribute with the 192 custom operation name. The custom operations supported is up to 193 server policy. 195 2.2. State 197 The state attribute reflects the state of the object "before" or 198 "after" the operation. The state is defined using the OPTIONAL 199 "state" attribute of the element, with the 200 possible values "before" or "after" and with a default value of 201 "after". The server MAY support both the "before" state and the 202 "after" state of the operation, by using one poll message for the 203 "before" state and one poll message for the "after" state. The 204 "before" state poll message MUST be inserted into the message queue 205 prior to the "after" state poll message. 207 For operations in Section 2.1 that don't have an "after" state, the 208 server MUST use the "before" state poll message. For example, for 209 the "delete" operation with the "op" attribute set to "purge", or the 210 "autoPurge" operation, the server includes the state of the object 211 prior to being purged in the "before" state poll message. 213 For operations in Section 2.1 that don't have a "before" state, the 214 server MUST use the "after" state poll message. For example, for the 215 "create" operation, the server includes the state of the object after 216 creation in the "after" state poll message. 218 2.3. Who 220 The element defines who executed the operation for 221 audit purposes. It is a freeform value that is strictly meant for 222 audit purposes and not meant to drive client-side logic. The scheme 223 used for the possible set of element values is up to 224 server policy. The server MAY identify the element 225 value based on: 227 "Identifier": Unique user identifier of the user that executed the 228 operation. An example is "ClientX". 229 "Name": Name of the user that executed the operation. An example is 230 "John Doe". 231 "Role": Role of the user that executed operation. An example is 232 "CSR" for a Customer Support Representative or "Batch" for a 233 server batch. 235 2.4. Dates and Times 237 Date and time attribute values MUST be represented in Universal 238 Coordinated Time (UTC) using the Gregorian calendar. The extended 239 date-time form using upper case "T" and "Z" characters defined in 240 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 241 values, as XML Schema does not support truncated date-time forms or 242 lower case "T" and "Z" characters. 244 3. EPP Command Mapping 246 A detailed description of the EPP syntax and semantics can be found 247 in the EPP core protocol specification [RFC5730]. 249 3.1. EPP Query Commands 251 EPP provides three commands to retrieve object information: 252 to determine if an object is known to the server, to retrieve 253 detailed information associated with an object, and to 254 retrieve object transfer status information. 256 3.1.1. EPP Command 258 This extension does not add any elements to the EPP command 259 or response described in the [RFC5730]. 261 3.1.2. EPP Command 263 This extension does not add any elements to the EPP command 264 described in the [RFC5730]. 266 This extension adds operation detail of EPP object mapping operations 267 Section 2.1 to an EPP poll response, as described in [RFC5730]. The 268 extension is an extension of the EPP object mapping info response. 269 Any transform operation to an object defined in an EPP object mapping 270 by a client other than the sponsoring client MAY result in extending 271 the response of the object for inserting an EPP poll message 272 with the operation detail. The sponsoring client will then receive 273 the state of the object with operation detail like what, who, when, 274 and why the object was changed. The element 275 contains the operation detail along with an indication of whether the 276 object reflects the state before or after the operation as defined in 277 Section 2.2. The element includes the 278 operation detail with the following child elements: 280 : Transform operation executed on the object 281 as defined in Section 2.1. 282 : Date and time when the operation was executed. 284 : Server transaction identifier of the operation. 285 : Who executed the operation as defined in 286 Section 2.3. 287 : OPTIONAL case identifer associated with the 288 operation. The required "type" attribute defines the type of 289 case. The OPTIONAL "name" attribute is an identifier, 290 represented in the 7-bit US-ASCII character set defined in 291 [RFC0020], that is used to define the name of the "custom" case 292 type. The enumerated list of case types is: 294 udrp: a Uniform Domain-Name Dispute-Resolution Policy (UDRP) 295 case. 296 urs: a Uniform Rapid Suspension (URS) case. 297 custom: A custom case that is defined using the "name" 298 attribute. 299 : OPTIONAL reason for executing the operation. 300 If present, this element contains the server-specific text to 301 help explain the reason the operation was executed. This text 302 MUST be represented in the response language previously 303 negotiated with the client; an OPTIONAL "lang" attribute MAY be 304 present to identify the language if the negotiated value is 305 something other than the default value of "en" (English). 307 Example poll response with the 308 extension for a URS lock transaction on the domain.example domain 309 name, with the "before" state. The "before" state is reflected in 310 the block: 312 S: 313 S: 314 S: 315 S: 316 S: 317 S: Command completed successfully; ack to dequeue 318 S: 319 S: 320 S: 2013-10-22T14:25:57.0Z 321 S: Registry initiated update of domain. 322 S: 323 S: 324 S: 326 S: domain.example 327 S: EXAMPLE1-REP 328 S: 329 S: jd1234 330 S: sh8013 331 S: sh8013 332 S: ClientX 333 S: ClientY 334 S: 2012-04-03T22:00:00.0Z 335 S: 2014-04-03T22:00:00.0Z 336 S: 337 S: 338 S: 339 S: 342 S: update 343 S: 2013-10-22T14:25:57.0Z 344 S: 12345-XYZ 345 S: URS Admin 346 S: urs123 347 S: URS Lock 348 S: 349 S: 350 S: 351 S: ABC-12345 352 S: 54321-XYZ 353 S: 354 S: 355 S: 357 Example poll response with the 358 extension for a URS lock transaction on the domain.example domain 359 name, with the "after" state. The "after" state is reflected in the 360 block: 362 S: 363 S: 364 S: 365 S: 366 S: 367 S: Command completed successfully; ack to dequeue 368 S: 369 S: 370 S: 2013-10-22T14:25:57.0Z 371 S: Registry initiated update of domain. 372 S: 373 S: 374 S: 376 S: domain.example 377 S: EXAMPLE1-REP 378 S: 379 S: 380 S: 381 S: jd1234 382 S: sh8013 383 S: sh8013 384 S: ClientX 385 S: ClientY 386 S: 2012-04-03T22:00:00.0Z 387 S: ClientZ 388 S: 2013-10-22T14:25:57.0Z 389 S: 2014-04-03T22:00:00.0Z 390 S: 391 S: 392 S: 393 S: 396 S: update 397 S: 2013-10-22T14:25:57.0Z 398 S: 12345-XYZ 399 S: URS Admin 400 S: urs123 401 S: URS Lock 402 S: 403 S: 404 S: 405 S: ABC-12345 406 S: 54321-XYZ 407 S: 408 S: 409 S: 410 Example poll response with the 411 extension for a custom "sync" operation on the domain.example domain 412 name, with the default "after" state. The "after" state is reflected 413 in the block: 415 S: 416 S: 417 S: 418 S: 419 S: Command completed successfully; ack to dequeue 420 S: 421 S: 422 S: 2013-10-22T14:25:57.0Z 423 S: Registry initiated Sync of Domain Expiration Date 424 S: 425 S: 426 S: 428 S: domain.example 429 S: EXAMPLE1-REP 430 S: 431 S: jd1234 432 S: sh8013 433 S: sh8013 434 S: ClientX 435 S: ClientY 436 S: 2012-04-03T22:00:00.0Z 437 S: ClientZ 438 S: 2013-10-22T14:25:57.0Z 439 S: 2014-04-03T22:00:00.0Z 440 S: 441 S: 442 S: 443 S: 445 S: custom 446 S: 447 S: 2013-10-22T14:25:57.0Z 448 S: 12345-XYZ 449 S: CSR 450 S: Customer sync request 451 S: 452 S: 453 S: 454 S: 455 S: ABC-12345 456 S: 54321-XYZ 457 S: 458 S: 459 S: 460 Example poll response with the 461 extension for a "delete" operation on the domain.example domain name 462 that is immediately purged, with the "before" state. The "before" 463 state is reflected in the block: 465 S: 466 S: 467 S: 468 S: 469 S: Command completed successfully; ack to dequeue 470 S: 471 S: 472 S: 2013-10-22T14:25:57.0Z 473 S: Registry initiated delete of 474 S: domain resulting in immediate purge. 475 S: 476 S: 477 S: 479 S: domain.example 480 S: EXAMPLE1-REP 481 S: ClientX 482 S: 483 S: 484 S: 485 S: 488 S: delete 489 S: 490 S: 2013-10-22T14:25:57.0Z 491 S: 492 S: 12345-XYZ 493 S: 494 S: ClientZ 495 S: 496 S: Court order 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 "autoPurge" operation on the domain.example domain 508 name that previously had the "pendingDelete" status, with the 509 "before" state. The "before" state is reflected in the 510 block: 512 S: 513 S: 514 S: 515 S: 516 S: Command completed successfully; ack to dequeue 517 S: 518 S: 519 S: 520 S: 2013-10-22T14:25:57.0Z 521 S: Registry purged domain with pendingDelete status. 522 S: 523 S: 524 S: 525 S: 527 S: domain.example 528 S: EXAMPLE1-REP 529 S: ClientX 530 S: 531 S: 532 S: 533 S: 536 S: autoPurge 537 S: 538 S: 2013-10-22T14:25:57.0Z 539 S: 540 S: 12345-XYZ 541 S: 542 S: Batch 543 S: 544 S: Past pendingDelete 5 day period 545 S: 546 S: 547 S: 548 S: 549 S: ABC-12345 550 S: 54321-XYZ 551 S: 552 S: 553 S: 554 Example poll response with the 555 extension for an "update" operation on the ns1.domain.example host, 556 with the default "after" state. The "after" state is reflected in 557 the block: 559 S: 560 S: 561 S: 562 S: 563 S: Command completed successfully; ack to dequeue 564 S: 565 S: 566 S: 2013-10-22T14:25:57.0Z 567 S: Registry initiated update of host. 568 S: 569 S: 570 S: 572 S: ns1.domain.example 573 S: NS1_EXAMPLE1-REP 574 S: 575 S: 576 S: 577 S: 192.0.2.2 578 S: 2001:db8:0:0:1:0:0:1 579 S: ClientX 580 S: ClientY 581 S: 2012-04-03T22:00:00.0Z 582 S: ClientY 583 S: 2013-10-22T14:25:57.0Z 584 S: 585 S: 586 S: 587 S: 589 S: update 590 S: 2013-10-22T14:25:57.0Z 591 S: 12345-XYZ 592 S: ClientZ 593 S: Host Lock 594 S: 595 S: 596 S: 597 S: ABC-12345 598 S: 54321-XYZ 599 S: 600 S: 601 S: 603 3.1.3. EPP Command 605 This extension does not add any elements to the EPP query 606 command or response described in the [RFC5730]. 608 3.2. EPP Transform Commands 610 EPP provides five commands to transform objects: to create 611 an instance of an object, to delete an instance of an 612 object, to extend the validity period of an object, 613 to manage object sponsorship changes, and to 614 change information associated with an object. 616 3.2.1. EPP Command 618 This extension does not add any elements to the EPP command 619 or response described in the [RFC5730]. 621 3.2.2. EPP Command 623 This extension does not add any elements to the EPP command 624 or response described in the [RFC5730]. 626 3.2.3. EPP Command 628 This extension does not add any elements to the EPP command 629 or response described in the [RFC5730]. 631 3.2.4. EPP Command 633 This extension does not add any elements to the EPP 634 command or response described in the [RFC5730]. 636 3.2.5. EPP Command 638 This extension does not add any elements to the EPP command 639 or response described in the [RFC5730]. 641 4. Formal Syntax 643 One schema is presented here that is the EPP Change Poll Extension 644 schema. 646 The formal syntax presented here is a complete schema representation 647 of the object mapping suitable for automated validation of EPP XML 648 instances. The BEGIN and END tags are not part of the schema; they 649 are used to note the beginning and ending of the schema for URI 650 registration purposes. 652 4.1. Change Poll Extension Schema 654 BEGIN 655 656 663 666 667 669 670 671 Extensible Provisioning Protocol v1.0 672 Change Poll Mapping Schema. 673 674 676 679 681 684 685 686 687 688 689 690 692 694 695 697 698 701 702 703 704 705 706 707 708 709 710 711 712 713 714 716 719 720 721 722 723 724 726 729 730 731 732 733 734 735 737 740 741 742 743 745 747 748 749 751 754 755 756 757 758 759 760 762 765 766 767 768 769 770 772 775 776 END 778 5. IANA Considerations 780 5.1. XML Namespace 782 This document uses URNs to describe XML namespaces and XML schemas 783 conforming to a registry mechanism described in [RFC3688]. The 784 following URI assignment is requested of IANA: 786 Registration request for the changePoll namespace: 788 URI: urn:ietf:params:xml:ns:changePoll-1.0 789 Registrant Contact: IESG 790 XML: None. Namespace URIs do not represent an XML specification. 792 Registration request for the changePoll XML schema: 794 URI: urn:ietf:params:xml:ns:changePoll-1.0 795 Registrant Contact: IESG 796 XML: See the "Formal Syntax" section of this document. 798 5.2. EPP Extension Registry 800 The EPP extension described in this document should be registered by 801 the IANA in the EPP Extension Registry described in [RFC7451]. The 802 details of the registration are as follows: 804 Name of Extension: "Change Poll Extension for the Extensible 805 Provisioning Protocol (EPP)" 807 Document status: Standards Track 809 Reference: (insert reference to RFC version of this document) 811 Registrant Name and Email Address: IESG, 813 TLDs: Any 815 IPR Disclosure: None 817 Status: Active 819 Notes: None 821 6. Implementation Status 823 Note to RFC Editor: Please remove this section and the reference to 824 RFC 7942 [RFC7942] before publication. 826 This section records the status of known implementations of the 827 protocol defined by this specification at the time of posting of this 828 Internet-Draft, and is based on a proposal described in RFC 7942 829 [RFC7942]. The description of implementations in this section is 830 intended to assist the IETF in its decision processes in progressing 831 drafts to RFCs. Please note that the listing of any individual 832 implementation here does not imply endorsement by the IETF. 833 Furthermore, no effort has been spent to verify the information 834 presented here that was supplied by IETF contributors. This is not 835 intended as, and must not be construed to be, a catalog of available 836 implementations or their features. Readers are advised to note that 837 other implementations may exist. 839 According to RFC 7942 [RFC7942], "this will allow reviewers and 840 working groups to assign due consideration to documents that have the 841 benefit of running code, which may serve as evidence of valuable 842 experimentation and feedback that have made the implemented protocols 843 more mature. It is up to the individual working groups to use this 844 information as they see fit". 846 6.1. Verisign EPP SDK 848 Organization: Verisign Inc. 850 Name: Verisign EPP SDK 852 Description: The Verisign EPP SDK includes both a full client 853 implementation and a full server stub implementation of draft-ietf- 854 regext-change-poll. 856 Level of maturity: Production 858 Coverage: All aspects of the protocol are implemented. 860 Licensing: GNU Lesser General Public License 862 Contact: jgould@verisign.com 864 URL: https://www.verisign.com/en_US/channel-resources/domain- 865 registry-products/epp-sdks 867 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 869 Organization: Verisign Inc. 871 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 872 System (SRS) 874 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 875 Registry System (SRS) implements the server-side of draft-ietf- 876 regext-change-poll for a variety of Top Level Domains (TLD's). 878 Level of maturity: Production 880 Coverage: The "after" state poll message for an "update" transform 881 operation of a domain name due to server policy. 883 Licensing: Proprietary 885 Contact: jgould@verisign.com 887 6.3. Verisign .COM / .NET SRS 889 Organization: Verisign Inc. 891 Name: Verisign .COM / .NET Shared Registry System (SRS) 893 Description: The Verisign Shared Registry System (SRS) for .COM and 894 .NET implements the server-side of draft-ietf-regext-change-poll. 896 Level of maturity: Production 898 Coverage: The "after" state poll message for an "update" transform 899 operation of a domain name due to server policy. 901 Licensing: Proprietary 903 Contact: jgould@verisign.com 905 6.4. Neustar EPP SDK 907 Organisation: Neustar Inc. 909 Name: Neustar EPP SDK 911 Description: The Neustar EPP SDK includes a full client 912 implementation of draft-ietf-regext-change-poll. 914 Level of maturity: Production 916 Coverage: All client side aspects of the protocol are implemented. 918 Licensing: GNU Lesser General Public License 920 Contact: quoc-anh.np@team.neustar 922 7. Security Considerations 924 The mapping extensions described in this document do not provide any 925 security services beyond those described by EPP [RFC5730] and 926 protocol layers used by EPP. The security considerations described 927 in these other specifications apply to this specification as well. 929 8. Acknowledgements 931 The authors wish to acknowledge the original concept for this draft 932 and the efforts in the initial versions of this draft by Trung Tran 933 and Sharon Wodjenski. 935 Special suggestions that have been incorporated into this document 936 were provided by Scott Hollenbeck, Michael Holloway, and Patrick 937 Mevzek. 939 9. References 941 9.1. Normative References 943 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 944 RFC 20, DOI 10.17487/RFC0020, October 1969, 945 . 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, 949 DOI 10.17487/RFC2119, March 1997, . 952 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 953 DOI 10.17487/RFC3688, January 2004, . 956 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 957 the Extensible Provisioning Protocol (EPP)", RFC 3915, 958 DOI 10.17487/RFC3915, September 2004, . 961 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 962 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 963 . 965 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 966 Domain Name Mapping", STD 69, RFC 5731, 967 DOI 10.17487/RFC5731, August 2009, . 970 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 971 Code: The Implementation Status Section", BCP 205, 972 RFC 7942, DOI 10.17487/RFC7942, July 2016, 973 . 975 [W3C.REC-xmlschema-2-20041028] 976 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 977 Second Edition", World Wide Web Consortium Recommendation 978 REC-xmlschema-2-20041028, October 2004, 979 . 981 9.2. Informative References 983 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 984 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 985 February 2015, . 987 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 988 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 989 May 2017, . 991 Appendix A. Change History 993 A.1. Change from 00 to 01 995 1. Added an optional caseId element that defines the case identifier 996 from UDRP, URS, or custom case, based on feedback from Michael 997 Holloway. 999 A.2. Change from 01 to 02 1001 1. Amended XML Namespace section of IANA Considerations, added EPP 1002 Extension Registry section. 1003 2. Moved Change History to the back section as an Appendix. 1005 A.3. Change from 02 to 03 1007 1. Fixed "before" state example to use the "before" state value 1008 based on feedback from Patrick Mevzek. 1010 A.4. Change from 03 to 04 1012 1. Updated the authors for the draft. 1014 A.5. Change from 04 to 05 1016 1. Ping update. 1018 A.6. Change from 05 to REGEXT 00 1020 1. Changed to regext working group draft by changing draft-gould- 1021 change-poll to draft-ietf-regext-change-poll. 1023 A.7. Change from REGEXT 00 to REGEXT 01 1025 1. Ping update. 1027 A.8. Change from REGEXT 01 to REGEXT 02 1029 1. Added the Implementation Status section. 1031 A.9. Change from REGEXT 02 to REGEXT 03 1033 1. Changed Neustar author to Kal Feher. 1035 A.10. Change from REGEXT 03 to REGEXT 04 1037 1. Added Neustar implementation to the Implementation Status 1038 section. 1040 A.11. Change from REGEXT 04 to REGEXT 05 1042 1. Updates based on feedback from Patrick Mevzek, that include: 1044 1. Added a missing comma to "Using this extension, clients" in 1045 the Introduction section. 1046 2. Modified the description of the "transfer", "restore", and 1047 "custom" operations to include "MUST set the "op" attribute" 1048 language. 1049 3. Rephrased the first sentence of the Who section. 1050 4. Added references to the element in the Who 1051 section. 1052 5. Revise the sentence that describes how the extension extends 1053 the info response in the EPP Command section. 1054 6. Refer to EPP Object Mapping as EPP object mapping throughout 1055 the document. 1056 7. Add a Dates and Times section to the Object Attributes 1057 section. 1059 A.12. Change from REGEXT 05 to REGEXT 06 1061 1. Added the "State" sub-section to the "Object Attributes" section 1062 to describe the expected behavior for the "before" and "after" 1063 states, based on feedback from Patrick Mevzek. 1064 2. Added a colon suffix to each hangText entry to provide better 1065 separation. 1067 A.13. Change from REGEXT 06 to REGEXT 07 1069 1. Updates based on feedback from Scott Hollenbeck, that include: 1071 1. Changed MAY to may in the Abstract. 1072 2. Revised the "IANA Considerations" section to include the 1073 registration of the XML schema. 1075 3. Revised the description of the "name" 1076 attribute and the "changePoll:operation> "op" attribute as 1077 containing 7-bit US-ASCII identifiers for the case type or 1078 the operation type, respectively. 1080 A.14. Change from REGEXT 07 to REGEXT 08 1082 1. Updated obsoleted RFC 6982 to RFC 7942. 1083 2. Moved RFC 7451 to an informational reference based on a check 1084 done by the Idnits Tool. 1085 3. Changed Kal Feher's contact e-mail address. 1086 4. Changed Neustar's Implementation Status contact e-mail address. 1088 A.15. Change from REGEXT 08 to REGEXT 09 1090 1. Fixed Section 1.1 (Conventions) to contain the updated language 1091 (e.g. "NOT RECOMMENDED", RFC 8174, BCP 14), based on feedback 1092 from the Document Shepherd. 1094 A.16. Change from REGEXT 09 to REGEXT 10 1096 1. Updates based on the AD review by Adam Roach, that include: 1098 1. Fix the "purge" and "autoPurge" examples to use the 1099 normative "before" state instead of the default "after" 1100 state. 1101 2. Added the sentences "The extension only extends the EPP 1102 response in [RFC5730] and does not extend the EPP 1103 command. Please refer to [RFC5730] for information 1104 and examples of the EPP command." in the 1105 "Introduction" to clarify what is extended and reference 1106 [RFC5730] for the EPP command. 1107 3. Added missing hyphens to "client-sponsored" and "court- 1108 directed". 1109 4. Removed "changePoll-1.0" is used as an abbreviation for 1110 "urn:ietf:params:xml:ns:changePoll-1.0" and replaced the 1111 paragraph based on what was done in draft-ietf-regext- 1112 allocation-token. 1113 5. Changed normative "SHOULD" to non-normative "should" in "An 1114 operation consists of any transform operation that impacts 1115 objects that the client sponsers and should be notified of." 1116 6. Added normative reference to [RFC0020] to define "7-bit US- 1117 ASCII". 1118 7. Added the sentence "The custom operations supported is up to 1119 server policy." to the description of the "custom" 1120 operation. 1122 8. Broke up the "This extension adds operation detail..." 1123 sentence into two seperate sentences to address the "does" 1124 and the "is" seperately. 1125 9. Removed the commas from "Any transform operation to an 1126 object..." sentence. 1127 10. Changed to use an IPv6 address from the documentation-only 1128 prefix "2001:DB8::/32" in RFC 3849. The IPv6 address 1129 2001:db8:0:0:1:0:0:1 was used. 1131 A.17. Change from REGEXT 10 to REGEXT 11 1133 1. Updates based on the review by Benjamin Kaduk, that include: 1135 1. Change references of "The enumerated list ... include:" to 1136 "The enumerated list ... is:". 1137 2. In section 2.2, explicitly state what the message is inserted 1138 into, with the change of "... MUST be inserted prior to ..." 1139 to "... MUST be inserted into the message queue prior to 1140 ...". 1142 A.18. Change from REGEXT 11 to REGEXT 12 1144 1. Added clarification for the element based on the 1145 feedback from Benjamin Kaduk. 1147 Authors' Addresses 1149 James Gould 1150 VeriSign, Inc. 1151 12061 Bluemont Way 1152 Reston, VA 20190 1153 US 1155 Email: jgould@verisign.com 1156 URI: http://www.verisign.com 1158 Kal Feher 1159 Neustar 1160 lvl 8/10 Queens Road 1161 Melbourne, VIC 3004 1162 AU 1164 Email: ietf@feherfamily.org 1165 URI: http://www.neustar.biz