idnits 2.17.1 draft-ietf-regext-change-poll-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 237 has weird spacing: '... udrp a Uni...' -- The document date (April 17, 2017) is 2565 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) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track S. Wodjenski 5 Expires: October 19, 2017 Neustar 6 April 17, 2017 8 Change Poll Extension for the Extensible Provisioning Protocol (EPP) 9 draft-ietf-regext-change-poll-01 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 October 19, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 68 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 69 3.1.3. EPP Command . . . . . . . . . . . . . . . 15 70 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 71 3.2.1. EPP Command . . . . . . . . . . . . . . . . 15 72 3.2.2. EPP Command . . . . . . . . . . . . . . . . 15 73 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 15 74 3.2.4. EPP Command . . . . . . . . . . . . . . . 15 75 3.2.5. EPP Command . . . . . . . . . . . . . . . . 15 76 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 77 4.1. Change Poll Extension Schema . . . . . . . . . . . . . . 16 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18 80 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 83 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 85 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 86 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 87 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 20 88 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 20 89 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 20 90 A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 21 91 A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 This document describes an extension mapping for version 1.0 of the 97 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 98 extension to EPP object mappings like the EPP domain name mapping 99 [RFC5731], is used to notify clients of operations they are not 100 directly involved in, on objects that the client sponsors. It is up 101 to server policy to determine what transform operations and clients 102 to notify. Using this extension clients can more easily keep their 103 systems in-sync with the objects stored in the server. When a change 104 occurs that a client needs to be notified of, a poll message can be 105 inserted by the server for consumption by the client using the EPP 106 command and response defined in [RFC5730]. The extension 107 supports including a "before" operation poll message and an "after" 108 operation poll message. 110 1.1. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 XML is case sensitive. Unless stated otherwise, XML specifications 117 and examples provided in this document MUST be interpreted in the 118 character case presented in order to develop a conforming 119 implementation. 121 In examples, "C:" represents lines sent by a protocol client and "S:" 122 represents lines returned by a protocol server. Indentation and 123 white space in examples are provided only to illustrate element 124 relationships and are not a REQUIRED feature of this protocol. 126 "changePoll-1.0" is used as an abbreviation for 127 "urn:ietf:params:xml:ns:changePoll-1.0". The XML namespace prefix 128 "changePoll" is used, but implementations MUST NOT depend on it and 129 instead employ a proper namespace-aware XML parser and serializer to 130 interpret and output the XML documents. 132 2. Object Attributes 134 This extension adds additional elements to EPP object mappings like 135 the EPP domain name mapping [RFC5731]. Only those new elements are 136 described here. 138 2.1. Operation 140 An operation consists of any transform operation that impacts objects 141 that the client sponsers and SHOULD be notified of. The 142 element defines the operation. The OPTIONAL 143 "op" attribute is used to define a sub-operation or the name of a 144 "custom" operation. The enumerated list of 145 values include: 147 "create" Create operation as defined in [RFC5730]. 148 "delete" Delete operation as defined in [RFC5730]. If the delete 149 operation results in an immediate purge of the object, then the 150 "op" attribute MUST be set to "purge". 151 "renew" Renew operation as defined in [RFC5730]. 152 "transfer" Transfer operation as defined in [RFC5730] with the 153 OPTIONAL "op" attribute defining the transfer type with the 154 possible values of "request", "approve", "cancel", and "reject". 155 "update" Update operation as defined in [RFC5730]. 156 "restore" Restore operation as defined in [RFC3915] with the 157 OPTIONAL "op" attribute defining the restore type with the 158 possible values of "request" and "report". 159 "autoRenew" Auto renew operation executed by the server. 160 "autoDelete" Auto delete operation executed by the server. If the 161 "autoDelete" operation results in an immediate purge of the 162 object, then the "op" attribute MUST be set to "purge". 163 "autoPurge" Auto purge operation executed by the server when 164 removing the object after it had the "pendingDelete" status. 165 "custom" Custom operation that uses the "op" attribute to define the 166 custom operation name. 168 2.2. Who 170 Who defines who executed the operation for audit purposes, and is 171 represented using the element. The scheme used for 172 the possible set of Who values is up to server policy. The server 173 MAY identify Who based on: 175 "Identifier" Unique user identifier of the user that executed the 176 operation. An example is "ClientX". 177 "Name" Name of the user that executed the operation. An example is 178 "John Doe". 179 "Role" Role of the user that executed operation. An example is 180 "CSR" for a Customer Support Representative or "Batch" for a 181 server batch. 183 3. EPP Command Mapping 185 A detailed description of the EPP syntax and semantics can be found 186 in the EPP core protocol specification [RFC5730]. 188 3.1. EPP Query Commands 190 EPP provides three commands to retrieve object information: 191 to determine if an object is known to the server, to retrieve 192 detailed information associated with an object, and to 193 retrieve object transfer status information. 195 3.1.1. EPP Command 197 This extension does not add any elements to the EPP command 198 or response described in the [RFC5730]. 200 3.1.2. EPP Command 202 This extension does not add any elements to the EPP command 203 described in the [RFC5730]. 205 This extension adds transaction detail of the operations to the EPP 206 poll response, as described in [RFC5730], of an EPP Object 207 Mapping like [RFC5731]. Any transform operation to an object defined 208 in an EPP Object Mapping, by a client other than the sponsoring 209 client, MAY result in extending the response of the object for 210 inserting an EPP poll message with the operation detail. The 211 sponsoring client will then receive the state of the object with 212 operation detail like what, who, when, and why the object was 213 changed. The element contains the operation 214 detail along with an indication of whether the object reflects the 215 state before or after the operation, using the OPTIONAL "state" 216 attribute, with the possible values of "before" or "after", and with 217 a default value of "after". The "state" attribute describes the 218 state of the response data or block returned in the poll 219 response. The server MAY support providing the "before" state and 220 "after" state to the operation, by using one poll message for the 221 "before" state and one poll message for the "after" state. When 222 using the "before" state poll message, it MUST be inserted prior to 223 the "after" state poll message. The element 224 includes the operation detail with the following child elements: 226 Transform operation executed on the object as 227 defined in Section 2.1. 228 Date and time when the operation was executed. 229 Server transaction identifier of the operation. 231 Who executed the operation as defined in 232 Section 2.2. 233 OPTIONAL case identifer associated with the 234 operation. The required "type" attribute defines the type of 235 case with an enumerated list of case types including: 237 udrp a Uniform Domain-Name Dispute-Resolution Policy (UDRP) 238 case. 239 urs a Uniform Rapid Suspension (URS) case. 240 custom A custom case that is defined using the "name" attribute. 241 OPTIONAL reason for executing the operation. If 242 present, this element contains the server-specific text to help 243 explain the reason the operation was executed. This text MUST be 244 represented in the response language previously negotiated with 245 the client; an OPTIONAL "lang" attribute MAY be present to 246 identify the language if the negotiated value is something other 247 than the default value of "en" (English). 249 Example poll response with the 250 extension for a URS lock transaction on the domain.example domain 251 name, with the "before" state. The "before" state is reflected in 252 the block: 254 S: 255 S: 256 S: 257 S: 258 S: 259 S: Command completed successfully; ack to dequeue 260 S: 261 S: 262 S: 2013-10-22T14:25:57.0Z 263 S: Registry initiated update of domain. 264 S: 265 S: 266 S: 268 S: domain.example 269 S: EXAMPLE1-REP 270 S: 271 S: jd1234 272 S: sh8013 273 S: sh8013 274 S: ClientX 275 S: ClientY 276 S: 2012-04-03T22:00:00.0Z 277 S: 2014-04-03T22:00:00.0Z 278 S: 279 S: 280 S: 281 S: 284 S: update 285 S: 2013-10-22T14:25:57.0Z 286 S: 12345-XYZ 287 S: URS Admin 288 S: urs123 289 S: URS Lock 290 S: 291 S: 292 S: 293 S: ABC-12345 294 S: 54321-XYZ 295 S: 296 S: 297 S: 299 Example poll response with the 300 extension for a URS lock transaction on the domain.example domain 301 name, with the "after" state. The "after" state is reflected in the 302 block: 304 S: 305 S: 306 S: 307 S: 308 S: 309 S: Command completed successfully; ack to dequeue 310 S: 311 S: 312 S: 2013-10-22T14:25:57.0Z 313 S: Registry initiated update of domain. 314 S: 315 S: 316 S: 318 S: domain.example 319 S: EXAMPLE1-REP 320 S: 321 S: 322 S: 323 S: jd1234 324 S: sh8013 325 S: sh8013 326 S: ClientX 327 S: ClientY 328 S: 2012-04-03T22:00:00.0Z 329 S: ClientZ 330 S: 2013-10-22T14:25:57.0Z 331 S: 2014-04-03T22:00:00.0Z 332 S: 333 S: 334 S: 335 S: 338 S: update 339 S: 2013-10-22T14:25:57.0Z 340 S: 12345-XYZ 341 S: URS Admin 342 S: urs123 343 S: URS Lock 344 S: 345 S: 346 S: 347 S: ABC-12345 348 S: 54321-XYZ 349 S: 350 S: 351 S: 352 Example poll response with the 353 extension for a custom "sync" operation on the domain.example domain 354 name, with the default "after" state. The "after" state is reflected 355 in the block: 357 S: 358 S: 359 S: 360 S: 361 S: Command completed successfully; ack to dequeue 362 S: 363 S: 364 S: 2013-10-22T14:25:57.0Z 365 S: Registry initiated Sync of Domain Expiration Date 366 S: 367 S: 368 S: 370 S: domain.example 371 S: EXAMPLE1-REP 372 S: 373 S: jd1234 374 S: sh8013 375 S: sh8013 376 S: ClientX 377 S: ClientY 378 S: 2012-04-03T22:00:00.0Z 379 S: ClientZ 380 S: 2013-10-22T14:25:57.0Z 381 S: 2014-04-03T22:00:00.0Z 382 S: 383 S: 384 S: 385 S: 387 S: custom 388 S: 389 S: 2013-10-22T14:25:57.0Z 390 S: 12345-XYZ 391 S: CSR 392 S: Customer sync request 393 S: 394 S: 395 S: 396 S: 397 S: ABC-12345 398 S: 54321-XYZ 399 S: 400 S: 401 S: 402 Example poll response with the 403 extension for a "delete" operation on the domain.example domain name 404 that is immediately purged, with the default "after" state. The 405 "after" state is reflected in the block: 407 S: 408 S: 409 S: 410 S: 411 S: Command completed successfully; ack to dequeue 412 S: 413 S: 414 S: 2013-10-22T14:25:57.0Z 415 S: Registry initiated delete of 416 S: domain resulting in immediate purge. 417 S: 418 S: 419 S: 421 S: domain.example 422 S: EXAMPLE1-REP 423 S: ClientX 424 S: 425 S: 426 S: 427 S: 429 S: 430 S: delete 431 S: 2013-10-22T14:25:57.0Z 432 S: 12345-XYZ 433 S: ClientZ 434 S: Court order 435 S: 436 S: 437 S: 438 S: ABC-12345 439 S: 54321-XYZ 440 S: 441 S: 442 S: 443 Example poll response with the 444 extension for an "autoPurge" operation on the domain.example domain 445 name that previously had the "pendingDelete" status, with the default 446 "after" state. The "after" state is reflected in the 447 block: 449 S: 450 S: 451 S: 452 S: 453 S: Command completed successfully; ack to dequeue 454 S: 455 S: 456 S: 2013-10-22T14:25:57.0Z 457 S: Registry purged domain with pendingDelete status. 458 S: 459 S: 460 S: 462 S: domain.example 463 S: EXAMPLE1-REP 464 S: ClientX 465 S: 466 S: 467 S: 468 S: 470 S: 471 S: autoPurge 472 S: 2013-10-22T14:25:57.0Z 473 S: 12345-XYZ 474 S: Batch 475 S: 476 S: Past pendingDelete 5 day period 477 S: 478 S: 479 S: 480 S: 481 S: ABC-12345 482 S: 54321-XYZ 483 S: 484 S: 485 S: 486 Example poll response with the 487 extension for an "update" operation on the ns1.domain.example host, 488 with the default "after" state. The "after" state is reflected in 489 the block: 491 S: 492 S: 493 S: 494 S: 495 S: Command completed successfully; ack to dequeue 496 S: 497 S: 498 S: 2013-10-22T14:25:57.0Z 499 S: Registry initiated update of host. 500 S: 501 S: 502 S: 504 S: ns1.domain.example 505 S: NS1_EXAMPLE1-REP 506 S: 507 S: 508 S: 509 S: 192.0.2.2 510 S: 1080:0:0:0:8:800:200C:417A 511 S: ClientX 512 S: ClientY 513 S: 2012-04-03T22:00:00.0Z 514 S: ClientY 515 S: 2013-10-22T14:25:57.0Z 516 S: 517 S: 518 S: 519 S: 521 S: update 522 S: 2013-10-22T14:25:57.0Z 523 S: 12345-XYZ 524 S: ClientZ 525 S: Host Lock 526 S: 527 S: 528 S: 529 S: ABC-12345 530 S: 54321-XYZ 531 S: 532 S: 533 S: 535 3.1.3. EPP Command 537 This extension does not add any elements to the EPP query 538 command or response described in the [RFC5730]. 540 3.2. EPP Transform Commands 542 EPP provides five commands to transform objects: to create 543 an instance of an object, to delete an instance of an 544 object, to extend the validity period of an object, 545 to manage object sponsorship changes, and to 546 change information associated with an object. 548 3.2.1. EPP Command 550 This extension does not add any elements to the EPP command 551 or response described in the [RFC5730]. 553 3.2.2. EPP Command 555 This extension does not add any elements to the EPP command 556 or response described in the [RFC5730]. 558 3.2.3. EPP Command 560 This extension does not add any elements to the EPP command 561 or response described in the [RFC5730]. 563 3.2.4. EPP Command 565 This extension does not add any elements to the EPP 566 command or response described in the [RFC5730]. 568 3.2.5. EPP Command 570 This extension does not add any elements to the EPP command 571 or response described in the [RFC5730]. 573 4. Formal Syntax 575 One schema is presented here that is the EPP Change Poll Extension 576 schema. 578 The formal syntax presented here is a complete schema representation 579 of the object mapping suitable for automated validation of EPP XML 580 instances. The BEGIN and END tags are not part of the schema; they 581 are used to note the beginning and ending of the schema for URI 582 registration purposes. 584 4.1. Change Poll Extension Schema 586 BEGIN 587 588 595 598 599 601 602 603 Extensible Provisioning Protocol v1.0 604 Change Poll Mapping Schema. 605 606 608 611 613 616 617 618 619 620 621 622 624 626 627 629 630 633 634 635 636 637 638 639 640 641 642 643 644 645 646 648 651 652 653 654 655 656 658 661 662 663 664 665 666 667 669 672 673 674 675 677 679 680 681 683 686 687 688 689 690 691 692 694 697 698 699 700 701 702 704 707 708 END 710 5. IANA Considerations 712 5.1. XML Namespace 714 This document uses URNs to describe XML namespaces and XML schemas 715 conforming to a registry mechanism described in [RFC3688]. The 716 following URI assignment is requested of IANA: 718 URI: urn:ietf:params:xml:ns:changePoll-1.0 720 Registrant Contact: See the "Author's Address" section of this 721 document. 723 XML: See the "Formal Syntax" section of this document. 725 5.2. EPP Extension Registry 727 The EPP extension described in this document should be registered by 728 the IANA in the EPP Extension Registry described in [RFC7451]. The 729 details of the registration are as follows: 731 Name of Extension: "Change Poll Extension for the Extensible 732 Provisioning Protocol (EPP)" 734 Document status: Standards Track 736 Reference: (insert reference to RFC version of this document) 738 Registrant Name and Email Address: IESG, 740 TLDs: Any 742 IPR Disclosure: None 744 Status: Active 746 Notes: None 748 6. Security Considerations 750 The mapping extensions described in this document do not provide any 751 security services beyond those described by EPP [RFC5730] and 752 protocol layers used by EPP. The security considerations described 753 in these other specifications apply to this specification as well. 755 7. Acknowledgements 757 The authors wish to acknowledge the original concept for this draft 758 and the efforts in the initial versions of this draft by Trung Tran. 760 Special suggestions that have been incorporated into this document 761 were provided by Michael Holloway. 763 8. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 771 DOI 10.17487/RFC3688, January 2004, 772 . 774 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 775 the Extensible Provisioning Protocol (EPP)", RFC 3915, 776 DOI 10.17487/RFC3915, September 2004, 777 . 779 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 780 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 781 . 783 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 784 Domain Name Mapping", STD 69, RFC 5731, 785 DOI 10.17487/RFC5731, August 2009, 786 . 788 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 789 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 790 February 2015, . 792 Appendix A. Change History 794 A.1. Change from 00 to 01 796 1. Added an optional caseId element that defines the case identifier 797 from UDRP, URS, or custom case, based on feedback from Michael 798 Holloway. 800 A.2. Change from 01 to 02 802 1. Amended XML Namespace section of IANA Considerations, added EPP 803 Extension Registry section. 804 2. Moved Change History to the back section as an Appendix. 806 A.3. Change from 02 to 03 808 1. Fixed "before" state example to use the "before" state value 809 based on feedback from Patrick Mevzek. 811 A.4. Change from 03 to 04 813 1. Updated the authors for the draft. 815 A.5. Change from 04 to 05 817 1. Ping update. 819 A.6. Change from 05 to REGEXT 00 821 1. Changed to regext working group draft by changing draft-gould- 822 change-poll to draft-ietf-regext-change-poll. 824 A.7. Change from REGEXT 00 to REGEXT 01 826 1. Ping update. 828 Authors' Addresses 830 James Gould 831 VeriSign, Inc. 832 12061 Bluemont Way 833 Reston, VA 20190 834 US 836 Email: jgould@verisign.com 837 URI: http://www.verisigninc.com 839 Sharon Wodjenski 840 Neustar 841 21575 Ridgetop Circle 842 Sterling, VA 20166 843 US 845 Email: Sharon.Wodjenski@neustar.biz 846 URI: http://www.neustar.biz