idnits 2.17.1 draft-ietf-regext-change-poll-11.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 (December 10, 2018) is 1957 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: June 13, 2019 Neustar 6 December 10, 2018 8 Change Poll Extension for the Extensible Provisioning Protocol (EPP) 9 draft-ietf-regext-change-poll-11 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 June 13, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 5 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 113 1. Introduction 115 This document describes an extension mapping for version 1.0 of the 116 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 117 extension to EPP object mappings like the EPP domain name mapping 118 [RFC5731], is used to notify clients of operations they are not 119 directly involved in, on objects that the client sponsors. It is up 120 to server policy to determine what transform operations and clients 121 to notify. Using this extension, clients can more easily keep their 122 systems in-sync with the objects stored in the server. When a change 123 occurs that a client needs to be notified of, a poll message can be 124 inserted by the server for consumption by the client using the EPP 125 command and response defined in [RFC5730]. The extension 126 supports including a "before" operation poll message and an "after" 127 operation poll message. The extension only extends the EPP 128 response in [RFC5730] and does not extend the EPP command. 129 Please refer to [RFC5730] for information and examples of the EPP 130 command. 132 1.1. Conventions Used in This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 XML is case sensitive. Unless stated otherwise, XML specifications 141 and examples provided in this document MUST be interpreted in the 142 character case presented in order to develop a conforming 143 implementation. 145 In examples, "C:" represents lines sent by a protocol client and "S:" 146 represents lines returned by a protocol server. Indentation and 147 white space in examples are provided only to illustrate element 148 relationships and are not a REQUIRED feature of this protocol. 150 The XML namespace prefix "changePoll" is used for the namespace 151 "urn:ietf:params:xml:ns:changePoll-1.0", but implementations MUST NOT 152 depend on it and instead employ a proper namespace-aware XML parser 153 and serializer to interpret and output the XML documents. 155 2. Object Attributes 157 This extension adds additional elements to EPP object mappings like 158 the EPP domain name mapping [RFC5731]. Only those new elements are 159 described here. 161 2.1. Operation 163 An operation consists of any transform operation that impacts objects 164 that the client sponsers and should be notified of. The 165 element defines the operation. The OPTIONAL 166 "op" attribute is an identifier, represented in the 7-bit US-ASCII 167 character set defined in [RFC0020], that is used to define a sub- 168 operation or the name of a "custom" operation. The enumerated list 169 of values is: 171 "create": Create operation as defined in [RFC5730]. 172 "delete": Delete operation as defined in [RFC5730]. If the delete 173 operation results in an immediate purge of the object, then the 174 "op" attribute MUST be set to "purge". 175 "renew": Renew operation as defined in [RFC5730]. 176 "transfer": Transfer operation as defined in [RFC5730] that MUST set 177 the "op" attribute with one of the possible transfer type values 178 that include "request", "approve", "cancel", or "reject". 179 "update": Update operation as defined in [RFC5730]. 180 "restore": Restore operation as defined in [RFC3915] that MUST set 181 the "op" attribute with one of the possible restore type values 182 that include "request" or "report". 183 "autoRenew": Auto renew operation executed by the server. 184 "autoDelete": Auto delete operation executed by the server. If the 185 "autoDelete" operation results in an immediate purge of the 186 object, then the "op" attribute MUST be set to "purge". 187 "autoPurge": Auto purge operation executed by the server when 188 removing the object after it had the "pendingDelete" status. 189 "custom": Custom operation that MUST set the "op" attribute with the 190 custom operation name. The custom operations supported is up to 191 server policy. 193 2.2. State 195 The state attribute reflects the state of the object "before" or 196 "after" the operation. The state is defined using the OPTIONAL 197 "state" attribute of the element, with the 198 possible values "before" or "after" and with a default value of 199 "after". The server MAY support both the "before" state and the 200 "after" state of the operation, by using one poll message for the 201 "before" state and one poll message for the "after" state. The 202 "before" state poll message MUST be inserted into the message queue 203 prior to the "after" state poll message. 205 For operations in Section 2.1 that don't have an "after" state, the 206 server MUST use the "before" state poll message. For example, for 207 the "delete" operation with the "op" attribute set to "purge", or the 208 "autoPurge" operation, the server includes the state of the object 209 prior to being purged in the "before" state poll message. 211 For operations in Section 2.1 that don't have a "before" state, the 212 server MUST use the "after" state poll message. For example, for the 213 "create" operation, the server includes the state of the object after 214 creation in the "after" state poll message. 216 2.3. Who 218 The element defines who executed the operation for 219 audit purposes. The scheme used for the possible set of 220 element values is up to server policy. The server 221 MAY identify the element value based on: 223 "Identifier": Unique user identifier of the user that executed the 224 operation. An example is "ClientX". 225 "Name": Name of the user that executed the operation. An example is 226 "John Doe". 227 "Role": Role of the user that executed operation. An example is 228 "CSR" for a Customer Support Representative or "Batch" for a 229 server batch. 231 2.4. Dates and Times 233 Date and time attribute values MUST be represented in Universal 234 Coordinated Time (UTC) using the Gregorian calendar. The extended 235 date-time form using upper case "T" and "Z" characters defined in 236 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 237 values, as XML Schema does not support truncated date-time forms or 238 lower case "T" and "Z" characters. 240 3. EPP Command Mapping 242 A detailed description of the EPP syntax and semantics can be found 243 in the EPP core protocol specification [RFC5730]. 245 3.1. EPP Query Commands 247 EPP provides three commands to retrieve object information: 248 to determine if an object is known to the server, to retrieve 249 detailed information associated with an object, and to 250 retrieve object transfer status information. 252 3.1.1. EPP Command 254 This extension does not add any elements to the EPP command 255 or response described in the [RFC5730]. 257 3.1.2. EPP Command 259 This extension does not add any elements to the EPP command 260 described in the [RFC5730]. 262 This extension adds operation detail of EPP object mapping operations 263 Section 2.1 to an EPP poll response, as described in [RFC5730]. The 264 extension is an extension of the EPP object mapping info response. 265 Any transform operation to an object defined in an EPP object mapping 266 by a client other than the sponsoring client MAY result in extending 267 the response of the object for inserting an EPP poll message 268 with the operation detail. The sponsoring client will then receive 269 the state of the object with operation detail like what, who, when, 270 and why the object was changed. The element 271 contains the operation detail along with an indication of whether the 272 object reflects the state before or after the operation as defined in 273 Section 2.2. The element includes the 274 operation detail with the following child elements: 276 : Transform operation executed on the object 277 as defined in Section 2.1. 278 : Date and time when the operation was executed. 279 : Server transaction identifier of the operation. 280 : Who executed the operation as defined in 281 Section 2.3. 282 : OPTIONAL case identifer associated with the 283 operation. The required "type" attribute defines the type of 284 case. The OPTIONAL "name" attribute is an identifier, 285 represented in the 7-bit US-ASCII character set defined in 286 [RFC0020], that is used to define the name of the "custom" case 287 type. The enumerated list of case types is: 289 udrp: a Uniform Domain-Name Dispute-Resolution Policy (UDRP) 290 case. 291 urs: a Uniform Rapid Suspension (URS) case. 292 custom: A custom case that is defined using the "name" 293 attribute. 294 : OPTIONAL reason for executing the operation. 295 If present, this element contains the server-specific text to 296 help explain the reason the operation was executed. This text 297 MUST be represented in the response language previously 298 negotiated with the client; an OPTIONAL "lang" attribute MAY be 299 present to identify the language if the negotiated value is 300 something other than the default value of "en" (English). 302 Example poll response with the 303 extension for a URS lock transaction on the domain.example domain 304 name, with the "before" state. The "before" state is reflected in 305 the block: 307 S: 308 S: 309 S: 310 S: 311 S: 312 S: Command completed successfully; ack to dequeue 313 S: 314 S: 315 S: 2013-10-22T14:25:57.0Z 316 S: Registry initiated update of domain. 317 S: 318 S: 319 S: 321 S: domain.example 322 S: EXAMPLE1-REP 323 S: 324 S: jd1234 325 S: sh8013 326 S: sh8013 327 S: ClientX 328 S: ClientY 329 S: 2012-04-03T22:00:00.0Z 330 S: 2014-04-03T22:00:00.0Z 331 S: 332 S: 333 S: 334 S: 337 S: update 338 S: 2013-10-22T14:25:57.0Z 339 S: 12345-XYZ 340 S: URS Admin 341 S: urs123 342 S: URS Lock 343 S: 344 S: 345 S: 346 S: ABC-12345 347 S: 54321-XYZ 348 S: 349 S: 350 S: 352 Example poll response with the 353 extension for a URS lock transaction on the domain.example domain 354 name, with the "after" state. The "after" state is reflected in the 355 block: 357 S: 358 S: 359 S: 360 S: 361 S: 362 S: Command completed successfully; ack to dequeue 363 S: 364 S: 365 S: 2013-10-22T14:25:57.0Z 366 S: Registry initiated update of domain. 367 S: 368 S: 369 S: 371 S: domain.example 372 S: EXAMPLE1-REP 373 S: 374 S: 375 S: 376 S: jd1234 377 S: sh8013 378 S: sh8013 379 S: ClientX 380 S: ClientY 381 S: 2012-04-03T22:00:00.0Z 382 S: ClientZ 383 S: 2013-10-22T14:25:57.0Z 384 S: 2014-04-03T22:00:00.0Z 385 S: 386 S: 387 S: 388 S: 391 S: update 392 S: 2013-10-22T14:25:57.0Z 393 S: 12345-XYZ 394 S: URS Admin 395 S: urs123 396 S: URS Lock 397 S: 398 S: 399 S: 400 S: ABC-12345 401 S: 54321-XYZ 402 S: 403 S: 404 S: 405 Example poll response with the 406 extension for a custom "sync" operation on the domain.example domain 407 name, with the default "after" state. The "after" state is reflected 408 in the block: 410 S: 411 S: 412 S: 413 S: 414 S: Command completed successfully; ack to dequeue 415 S: 416 S: 417 S: 2013-10-22T14:25:57.0Z 418 S: Registry initiated Sync of Domain Expiration Date 419 S: 420 S: 421 S: 423 S: domain.example 424 S: EXAMPLE1-REP 425 S: 426 S: jd1234 427 S: sh8013 428 S: sh8013 429 S: ClientX 430 S: ClientY 431 S: 2012-04-03T22:00:00.0Z 432 S: ClientZ 433 S: 2013-10-22T14:25:57.0Z 434 S: 2014-04-03T22:00:00.0Z 435 S: 436 S: 437 S: 438 S: 440 S: custom 441 S: 442 S: 2013-10-22T14:25:57.0Z 443 S: 12345-XYZ 444 S: CSR 445 S: Customer sync request 446 S: 447 S: 448 S: 449 S: 450 S: ABC-12345 451 S: 54321-XYZ 452 S: 453 S: 454 S: 455 Example poll response with the 456 extension for a "delete" operation on the domain.example domain name 457 that is immediately purged, with the "before" state. The "before" 458 state is reflected in the block: 460 S: 461 S: 462 S: 463 S: 464 S: Command completed successfully; ack to dequeue 465 S: 466 S: 467 S: 2013-10-22T14:25:57.0Z 468 S: Registry initiated delete of 469 S: domain resulting in immediate purge. 470 S: 471 S: 472 S: 474 S: domain.example 475 S: EXAMPLE1-REP 476 S: ClientX 477 S: 478 S: 479 S: 480 S: 483 S: delete 484 S: 485 S: 2013-10-22T14:25:57.0Z 486 S: 487 S: 12345-XYZ 488 S: 489 S: ClientZ 490 S: 491 S: Court order 492 S: 493 S: 494 S: 495 S: 496 S: ABC-12345 497 S: 54321-XYZ 498 S: 499 S: 500 S: 501 Example poll response with the 502 extension for an "autoPurge" operation on the domain.example domain 503 name that previously had the "pendingDelete" status, with the 504 "before" state. The "before" state is reflected in the 505 block: 507 S: 508 S: 509 S: 510 S: 511 S: Command completed successfully; ack to dequeue 512 S: 513 S: 514 S: 515 S: 2013-10-22T14:25:57.0Z 516 S: Registry purged domain with pendingDelete status. 517 S: 518 S: 519 S: 520 S: 522 S: domain.example 523 S: EXAMPLE1-REP 524 S: ClientX 525 S: 526 S: 527 S: 528 S: 531 S: autoPurge 532 S: 533 S: 2013-10-22T14:25:57.0Z 534 S: 535 S: 12345-XYZ 536 S: 537 S: Batch 538 S: 539 S: Past pendingDelete 5 day period 540 S: 541 S: 542 S: 543 S: 544 S: ABC-12345 545 S: 54321-XYZ 546 S: 547 S: 548 S: 549 Example poll response with the 550 extension for an "update" operation on the ns1.domain.example host, 551 with the default "after" state. The "after" state is reflected in 552 the block: 554 S: 555 S: 556 S: 557 S: 558 S: Command completed successfully; ack to dequeue 559 S: 560 S: 561 S: 2013-10-22T14:25:57.0Z 562 S: Registry initiated update of host. 563 S: 564 S: 565 S: 567 S: ns1.domain.example 568 S: NS1_EXAMPLE1-REP 569 S: 570 S: 571 S: 572 S: 192.0.2.2 573 S: 2001:db8:0:0:1:0:0:1 574 S: ClientX 575 S: ClientY 576 S: 2012-04-03T22:00:00.0Z 577 S: ClientY 578 S: 2013-10-22T14:25:57.0Z 579 S: 580 S: 581 S: 582 S: 584 S: update 585 S: 2013-10-22T14:25:57.0Z 586 S: 12345-XYZ 587 S: ClientZ 588 S: Host Lock 589 S: 590 S: 591 S: 592 S: ABC-12345 593 S: 54321-XYZ 594 S: 595 S: 596 S: 598 3.1.3. EPP Command 600 This extension does not add any elements to the EPP query 601 command or response described in the [RFC5730]. 603 3.2. EPP Transform Commands 605 EPP provides five commands to transform objects: to create 606 an instance of an object, to delete an instance of an 607 object, to extend the validity period of an object, 608 to manage object sponsorship changes, and to 609 change information associated with an object. 611 3.2.1. EPP Command 613 This extension does not add any elements to the EPP command 614 or response described in the [RFC5730]. 616 3.2.2. EPP Command 618 This extension does not add any elements to the EPP command 619 or response described in the [RFC5730]. 621 3.2.3. EPP Command 623 This extension does not add any elements to the EPP command 624 or response described in the [RFC5730]. 626 3.2.4. EPP Command 628 This extension does not add any elements to the EPP 629 command or response described in the [RFC5730]. 631 3.2.5. EPP Command 633 This extension does not add any elements to the EPP command 634 or response described in the [RFC5730]. 636 4. Formal Syntax 638 One schema is presented here that is the EPP Change Poll Extension 639 schema. 641 The formal syntax presented here is a complete schema representation 642 of the object mapping suitable for automated validation of EPP XML 643 instances. The BEGIN and END tags are not part of the schema; they 644 are used to note the beginning and ending of the schema for URI 645 registration purposes. 647 4.1. Change Poll Extension Schema 649 BEGIN 650 651 658 661 662 664 665 666 Extensible Provisioning Protocol v1.0 667 Change Poll Mapping Schema. 668 669 671 674 676 679 680 681 682 683 684 685 687 689 690 692 693 696 697 698 699 700 701 702 703 704 705 706 707 708 709 711 714 715 716 717 718 719 721 724 725 726 727 728 729 730 732 735 736 737 738 740 742 743 744 746 749 750 751 752 753 754 755 757 760 761 762 763 764 765 767 770 771 END 773 5. IANA Considerations 775 5.1. XML Namespace 777 This document uses URNs to describe XML namespaces and XML schemas 778 conforming to a registry mechanism described in [RFC3688]. The 779 following URI assignment is requested of IANA: 781 Registration request for the changePoll namespace: 783 URI: urn:ietf:params:xml:ns:changePoll-1.0 784 Registrant Contact: IESG 785 XML: None. Namespace URIs do not represent an XML specification. 787 Registration request for the changePoll XML schema: 789 URI: urn:ietf:params:xml:ns:changePoll-1.0 790 Registrant Contact: IESG 791 XML: See the "Formal Syntax" section of this document. 793 5.2. EPP Extension Registry 795 The EPP extension described in this document should be registered by 796 the IANA in the EPP Extension Registry described in [RFC7451]. The 797 details of the registration are as follows: 799 Name of Extension: "Change Poll Extension for the Extensible 800 Provisioning Protocol (EPP)" 802 Document status: Standards Track 804 Reference: (insert reference to RFC version of this document) 806 Registrant Name and Email Address: IESG, 808 TLDs: Any 810 IPR Disclosure: None 812 Status: Active 814 Notes: None 816 6. Implementation Status 818 Note to RFC Editor: Please remove this section and the reference to 819 RFC 7942 [RFC7942] before publication. 821 This section records the status of known implementations of the 822 protocol defined by this specification at the time of posting of this 823 Internet-Draft, and is based on a proposal described in RFC 7942 824 [RFC7942]. The description of implementations in this section is 825 intended to assist the IETF in its decision processes in progressing 826 drafts to RFCs. Please note that the listing of any individual 827 implementation here does not imply endorsement by the IETF. 828 Furthermore, no effort has been spent to verify the information 829 presented here that was supplied by IETF contributors. This is not 830 intended as, and must not be construed to be, a catalog of available 831 implementations or their features. Readers are advised to note that 832 other implementations may exist. 834 According to RFC 7942 [RFC7942], "this will allow reviewers and 835 working groups to assign due consideration to documents that have the 836 benefit of running code, which may serve as evidence of valuable 837 experimentation and feedback that have made the implemented protocols 838 more mature. It is up to the individual working groups to use this 839 information as they see fit". 841 6.1. Verisign EPP SDK 843 Organization: Verisign Inc. 845 Name: Verisign EPP SDK 847 Description: The Verisign EPP SDK includes both a full client 848 implementation and a full server stub implementation of draft-ietf- 849 regext-change-poll. 851 Level of maturity: Production 853 Coverage: All aspects of the protocol are implemented. 855 Licensing: GNU Lesser General Public License 857 Contact: jgould@verisign.com 859 URL: https://www.verisign.com/en_US/channel-resources/domain- 860 registry-products/epp-sdks 862 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS 864 Organization: Verisign Inc. 866 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 867 System (SRS) 869 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 870 Registry System (SRS) implements the server-side of draft-ietf- 871 regext-change-poll for a variety of Top Level Domains (TLD's). 873 Level of maturity: Production 875 Coverage: The "after" state poll message for an "update" transform 876 operation of a domain name due to server policy. 878 Licensing: Proprietary 880 Contact: jgould@verisign.com 882 6.3. Verisign .COM / .NET SRS 884 Organization: Verisign Inc. 886 Name: Verisign .COM / .NET Shared Registry System (SRS) 888 Description: The Verisign Shared Registry System (SRS) for .COM and 889 .NET implements the server-side of draft-ietf-regext-change-poll. 891 Level of maturity: Production 893 Coverage: The "after" state poll message for an "update" transform 894 operation of a domain name due to server policy. 896 Licensing: Proprietary 898 Contact: jgould@verisign.com 900 6.4. Neustar EPP SDK 902 Organisation: Neustar Inc. 904 Name: Neustar EPP SDK 906 Description: The Neustar EPP SDK includes a full client 907 implementation of draft-ietf-regext-change-poll. 909 Level of maturity: Production 911 Coverage: All client side aspects of the protocol are implemented. 913 Licensing: GNU Lesser General Public License 915 Contact: quoc-anh.np@team.neustar 917 7. Security Considerations 919 The mapping extensions described in this document do not provide any 920 security services beyond those described by EPP [RFC5730] and 921 protocol layers used by EPP. The security considerations described 922 in these other specifications apply to this specification as well. 924 8. Acknowledgements 926 The authors wish to acknowledge the original concept for this draft 927 and the efforts in the initial versions of this draft by Trung Tran 928 and Sharon Wodjenski. 930 Special suggestions that have been incorporated into this document 931 were provided by Scott Hollenbeck, Michael Holloway, and Patrick 932 Mevzek. 934 9. References 936 9.1. Normative References 938 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 939 RFC 20, DOI 10.17487/RFC0020, October 1969, 940 . 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, 944 DOI 10.17487/RFC2119, March 1997, . 947 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 948 DOI 10.17487/RFC3688, January 2004, . 951 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 952 the Extensible Provisioning Protocol (EPP)", RFC 3915, 953 DOI 10.17487/RFC3915, September 2004, . 956 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 957 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 958 . 960 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 961 Domain Name Mapping", STD 69, RFC 5731, 962 DOI 10.17487/RFC5731, August 2009, . 965 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 966 Code: The Implementation Status Section", BCP 205, 967 RFC 7942, DOI 10.17487/RFC7942, July 2016, 968 . 970 [W3C.REC-xmlschema-2-20041028] 971 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 972 Second Edition", World Wide Web Consortium Recommendation 973 REC-xmlschema-2-20041028, October 2004, 974 . 976 9.2. Informative References 978 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 979 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 980 February 2015, . 982 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 983 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 984 May 2017, . 986 Appendix A. Change History 988 A.1. Change from 00 to 01 990 1. Added an optional caseId element that defines the case identifier 991 from UDRP, URS, or custom case, based on feedback from Michael 992 Holloway. 994 A.2. Change from 01 to 02 996 1. Amended XML Namespace section of IANA Considerations, added EPP 997 Extension Registry section. 998 2. Moved Change History to the back section as an Appendix. 1000 A.3. Change from 02 to 03 1002 1. Fixed "before" state example to use the "before" state value 1003 based on feedback from Patrick Mevzek. 1005 A.4. Change from 03 to 04 1007 1. Updated the authors for the draft. 1009 A.5. Change from 04 to 05 1011 1. Ping update. 1013 A.6. Change from 05 to REGEXT 00 1015 1. Changed to regext working group draft by changing draft-gould- 1016 change-poll to draft-ietf-regext-change-poll. 1018 A.7. Change from REGEXT 00 to REGEXT 01 1020 1. Ping update. 1022 A.8. Change from REGEXT 01 to REGEXT 02 1024 1. Added the Implementation Status section. 1026 A.9. Change from REGEXT 02 to REGEXT 03 1028 1. Changed Neustar author to Kal Feher. 1030 A.10. Change from REGEXT 03 to REGEXT 04 1032 1. Added Neustar implementation to the Implementation Status 1033 section. 1035 A.11. Change from REGEXT 04 to REGEXT 05 1037 1. Updates based on feedback from Patrick Mevzek, that include: 1039 1. Added a missing comma to "Using this extension, clients" in 1040 the Introduction section. 1041 2. Modified the description of the "transfer", "restore", and 1042 "custom" operations to include "MUST set the "op" attribute" 1043 language. 1044 3. Rephrased the first sentence of the Who section. 1045 4. Added references to the element in the Who 1046 section. 1047 5. Revise the sentence that describes how the extension extends 1048 the info response in the EPP Command section. 1049 6. Refer to EPP Object Mapping as EPP object mapping throughout 1050 the document. 1051 7. Add a Dates and Times section to the Object Attributes 1052 section. 1054 A.12. Change from REGEXT 05 to REGEXT 06 1056 1. Added the "State" sub-section to the "Object Attributes" section 1057 to describe the expected behavior for the "before" and "after" 1058 states, based on feedback from Patrick Mevzek. 1059 2. Added a colon suffix to each hangText entry to provide better 1060 separation. 1062 A.13. Change from REGEXT 06 to REGEXT 07 1064 1. Updates based on feedback from Scott Hollenbeck, that include: 1066 1. Changed MAY to may in the Abstract. 1067 2. Revised the "IANA Considerations" section to include the 1068 registration of the XML schema. 1070 3. Revised the description of the "name" 1071 attribute and the "changePoll:operation> "op" attribute as 1072 containing 7-bit US-ASCII identifiers for the case type or 1073 the operation type, respectively. 1075 A.14. Change from REGEXT 07 to REGEXT 08 1077 1. Updated obsoleted RFC 6982 to RFC 7942. 1078 2. Moved RFC 7451 to an informational reference based on a check 1079 done by the Idnits Tool. 1080 3. Changed Kal Feher's contact e-mail address. 1081 4. Changed Neustar's Implementation Status contact e-mail address. 1083 A.15. Change from REGEXT 08 to REGEXT 09 1085 1. Fixed Section 1.1 (Conventions) to contain the updated language 1086 (e.g. "NOT RECOMMENDED", RFC 8174, BCP 14), based on feedback 1087 from the Document Shepherd. 1089 A.16. Change from REGEXT 09 to REGEXT 10 1091 1. Updates based on the AD review by Adam Roach, that include: 1093 1. Fix the "purge" and "autoPurge" examples to use the 1094 normative "before" state instead of the default "after" 1095 state. 1096 2. Added the sentences "The extension only extends the EPP 1097 response in [RFC5730] and does not extend the EPP 1098 command. Please refer to [RFC5730] for information 1099 and examples of the EPP command." in the 1100 "Introduction" to clarify what is extended and reference 1101 [RFC5730] for the EPP command. 1102 3. Added missing hyphens to "client-sponsored" and "court- 1103 directed". 1104 4. Removed "changePoll-1.0" is used as an abbreviation for 1105 "urn:ietf:params:xml:ns:changePoll-1.0" and replaced the 1106 paragraph based on what was done in draft-ietf-regext- 1107 allocation-token. 1108 5. Changed normative "SHOULD" to non-normative "should" in "An 1109 operation consists of any transform operation that impacts 1110 objects that the client sponsers and should be notified of." 1111 6. Added normative reference to [RFC0020] to define "7-bit US- 1112 ASCII". 1113 7. Added the sentence "The custom operations supported is up to 1114 server policy." to the description of the "custom" 1115 operation. 1117 8. Broke up the "This extension adds operation detail..." 1118 sentence into two seperate sentences to address the "does" 1119 and the "is" seperately. 1120 9. Removed the commas from "Any transform operation to an 1121 object..." sentence. 1122 10. Changed to use an IPv6 address from the documentation-only 1123 prefix "2001:DB8::/32" in RFC 3849. The IPv6 address 1124 2001:db8:0:0:1:0:0:1 was used. 1126 A.17. Change from REGEXT 10 to REGEXT 11 1128 1. Updates based on the review by Benjamin Kaduk, that include: 1130 1. Change references of "The enumerated list ... include:" to 1131 "The enumerated list ... is:". 1132 2. In section 2.2, explicitly state what the message is inserted 1133 into, with the change of "... MUST be inserted prior to ..." 1134 to "... MUST be inserted into the message queue prior to 1135 ...". 1137 Authors' Addresses 1139 James Gould 1140 VeriSign, Inc. 1141 12061 Bluemont Way 1142 Reston, VA 20190 1143 US 1145 Email: jgould@verisign.com 1146 URI: http://www.verisign.com 1148 Kal Feher 1149 Neustar 1150 lvl 8/10 Queens Road 1151 Melbourne, VIC 3004 1152 AU 1154 Email: ietf@feherfamily.org 1155 URI: http://www.neustar.biz