idnits 2.17.1 draft-sattler-epp-registry-maintenance-02.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 17, 2018) is 2284 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. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Sattler 2 Internet-Draft January 17, 2018 3 Intended status: Standard Track 4 Expires: July 16, 2018 6 Registry Maintenance Notifications for the 7 Extensible Provisioning Protocol (EPP) 8 draft-sattler-epp-registry-maintenance-02 10 Abstract 11 This document describes an Extensible Provision Protocol (EPP) 12 mapping for the Registry Maintenance Notifications used when Domain 13 Name Registries will conduct a maintenance, and for retrieving these 14 information. 16 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 This Internet-Draft will expire on July 16, 2018. 32 Copyright Notice 33 Copyright (c) 2018 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3 49 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Internationalized Domain Names . . . . . . . . . . . . . 3 51 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 52 2.3. Maintenance Elements . . . . . . . . . . . . . . . . . . 4 53 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 54 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 55 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 56 3.1.2. EPP Command . . . . . . . . . . . . . . . 6 57 3.1.3. EPP Command . . . . . . . . . . . . . . . . . 6 58 3.1.4. EPP Command . . . . . . . . . . . . . . . . . 9 59 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11 60 3.2.1. EPP Command . . . . . . . . . . . . . . . . 11 61 3.2.2. EPP Command . . . . . . . . . . . . . . . . 11 62 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 63 3.2.4. EPP Command . . . . . . . . . . . . . . . 11 64 3.2.5. EPP Command . . . . . . . . . . . . . . . . 11 65 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.1. Registry Maintenance EPP Mapping Schema . . . . . . . . . 12 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 73 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18 74 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 18 75 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 18 76 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 18 77 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 18 78 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 18 79 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 19 80 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 19 81 A.8. Change from 07 to EPPMAINT 00 . . . . . . . . . . . . . . 19 82 A.9. Change from EPPMAINT 00 to EPPMAINT 01 . . . . . . . . . 19 83 A.10. Change from EPPMAINT 01 to EPPMAINT 02 . . . . . . . . . 19 84 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 This document describes an Extensible Provision Protocol (EPP) 90 [RFC5730] mapping for the Registry Maintenance Notifications used 91 when Domain Name Registries will conduct a maintenance, and for 92 retrieving these information. 94 1.1. Terminology and Definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119] when 99 specified in their uppercase forms. 101 XML is case sensitive. Unless stated otherwise, XML specifications 102 and examples provided in this document MUST be interpreted in the 103 character case presented in order to develop a conforming 104 implementation. 106 In examples, "C:" represents lines sent by a protocol client and 107 "S:" represents lines returned by a protocol server. Indentation and 108 white space in examples are provided only to illustrate element 109 relationships and are not a REQUIRED feature of this protocol. 111 2. Object Attributes 113 2.1. Internationalized Domain Names 115 Names of affected hosts MUST be provided in Punycode according to 116 [RFC3492]. 118 2.2. Dates and Times 120 All dates and times attribute values MUST be expressed in Universal 121 Coordinated Time (UTC) using the Gregorian calendar. The extended 122 date-time form using upper case "T" and "Z" characters defined in ISO 123 8601 [RFC3339] MUST be used to represent date-time values. 125 2.3. Maintenance Elements 127 The element describes a single domain name registry 128 maintenance event during a specific time period. This element will 129 be used at EPP messages and to extend the EPP command. 131 For creating a new maintenance the attribute MUST be 132 'active', the attribute MUST be set and the attribute 133 SHALL NOT be present. 135 For updating a maintenance the attribute MUST be 136 'active', the attributes and MUST be 137 set. 139 For deleting a maintenance the attribute MUST be 140 'inactive' the attributes and MUST be 141 set. 143 144 MUST be present and an UUID according [RFC4122], SHALL NOT be 145 changed if maintenance got updated or deleted 147 148 MUST be present and contains one or more elements. 149 The server SHOULD NOT list systems which are not affected by the 150 maintenance. 152 153 MUST be present at least once and is an element of , 154 and 156 157 MUST be present and indicates the name of the affected system, 158 such as 'EPP', 'WHOIS', 'DNS', 'Portal', etc. 160 161 MUST be present and indicates the affected maintained system 162 (host or IP address). 163 Hostname SHALL be Punycode according [RFC3492]. 164 IPv4 addresses SHALL be dotted-decimal notation. 165 An example of this textual representation is "192.0.2.0". 166 IPv6 addresses SHALL be according [RFC5952]. 167 An example of this textual representation is 168 "2001:db8::1:0:0:1". 170 171 MUST be present and contains the impact level; values SHOULD 172 either be 'blackout' or 'partial' 174 175 MUST be present and indicates the type of the affected system; 176 values SHOULD either be 'production', 'ote', 'staging' or 'dev' 178 179 MUST be present and indicates the start of the maintenance 180 according ISO 8601 [RFC3339] 181 Format: YYYY-MM-DDThh:mm:ssTZ 183 184 MUST be present and indicates the end of the maintenance 185 according ISO 8601 [RFC3339] 186 Format: YYYY-MM-DDThh:mm:ssTZ 188 189 MUST be present and contains the reason behind the maintenance; 190 values SHOULD either be 'planned' or 'emergency' 192 193 MAY be present and contains URI to detailed maintenance 194 description 196 197 MUST be present and contains elements 199 200 MUST be present and contains the affected top-level domain. 201 Punycode encoded according [RFC3492] 203 204 MUST be present and contains and 205 207 208 MUST be present and indicates if a client needs to do something 209 that is connection related, such as a reconnect. The value 210 SHALL boolean. 212 213 MUST be present and indicates if a client needs to do something 214 that is implementation related, such as a code changes. The 215 value SHALL be boolean. 217 218 MUST be present and indicates the status of the maintenance. 219 values SHALL be either 'active' or 'inactive' 221 222 MUST be present and contains the creation date of the maintenance 223 according ISO 8601 [RFC3339] 224 Format: YYYY-MM-DDThh:mm:ssTZ 226 227 MAY be present and contains the updated date of the maintenance 228 according ISO 8601 [RFC3339]. 229 Format: YYYY-MM-DDThh:mm:ssTZ 231 3. EPP Command Mapping 233 A detailed description of the EPP syntax and semantics can be found 234 in the EPP core protocol specification [RFC5730]. The command 235 mappings described here are specifically for the use to notify of 236 Registry Maintenances and Registry Maintenance object mapping. 238 3.1. EPP Query Commands 240 EPP [RFC5730] provides three commands to retrieve object information: 241 to determine if an object is known to the server, to 242 retrieve detailed information associated with an object, and 243 to retrieve object transfer status information. 245 3.1.1. EPP Command 247 Available check semantics do not apply to maintenance objects, so 248 there is no mapping defined for the EPP command. 250 3.1.2. EPP Command 252 Transfer semantics do not apply to maintenance objects, so there is 253 no mapping defined for the EPP command. 255 3.1.3. EPP Command 257 EPP provides the command that is used to retrieve registry 258 maintenance information. In addition to the standard EPP command 259 elements, the command MUST contain a 260 element that identifies the maintenance namespace. The 261 element MUST contain a child element. It is either to 262 retrieve a specific maintenance notification or to 263 query all maintenance notifications. 265 Example command with to get one specific 266 maintenance: 268 C: 269 C: 270 C: 271 C: 272 C: 274 C: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 275 C: 276 C: 277 C: ABC-12345 278 C: 279 C: 281 Example response for one specific maintenance notification: 283 S: 284 S: 285 S: 286 S: 287 S: Command completed successfully 288 S: 289 S: 290 S: 292 S: 293 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 294 S: 295 S: 296 S: 297 S: EPP 298 S: epp.registry.example 299 S: blackout 300 S: 301 S: 302 S: 303 S: 2017-04-30T06:00:00Z 304 S: 2013-10-22T14:25:57Z 305 S: planned 306 S: 307 S: https://www.registry.example/notice?123 308 S: 309 S: 310 S: example 311 S: test 312 S: 313 S: 314 S: false 315 S: false 316 S: 317 S: active 318 S: 2017-02-08T22:10:00Z 319 S: 320 S: 321 S: 322 S: 323 S: ABC-12345 324 S: 54321-XYZ 325 S: 326 S: 327 S: 329 Example command with to query all maintenances: 331 C: 332 C: 333 C: 334 C: 335 C: 337 C: 338 C: 339 C: 340 C: ABC-12345 341 C: 342 C: 344 Example response querying all maintenances: 346 S: 347 S: 348 S: 349 S: 350 S: Command completed successfully 351 S: 352 S: 353 S: 355 S: 356 S: 357 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 358 S: 359 S: 2017-04-30T06:00:00Z 360 S: 2017-04-30T07:00:00Z 361 S: 2017-02-08T22:10:00Z 362 S: 363 S: 364 S: 91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 365 S: 366 S: 2017-06-15T04:30:00Z 367 S: 2017-06-15T05:30:00Z 368 S: 2017-02-08T22:10:00Z 369 S: 2017-03-08T20:11:00Z 370 S: 371 S: 372 S: 373 S: 374 S: 375 S: ABC-12345 376 S: 54321-XYZ 377 S: 378 S: 379 S: 381 3.1.4. EPP Command 383 The EPP command and response is defined in Section 2.9.2.3 of 384 [RFC5730]. The Registry Maintenance Notification is included in the 385 EPP response of [RFC5730]. 387 For the Registry Maintenance Notification, there are three types of 388 poll messages. The poll messages apply whenever the domain name 389 registry creates, updates or deletes a maintenance. In the case of 390 a Registry Maintenance specific message, a element 391 will be included within the element of the standard 392 response. 394 The element will include a reference to the 395 Registry Maintenance namespace. EPP data contained within the 396 element is formatted according to the 397 maintenance-poll schema. 399 Example command: 401 C: 402 C: 403 C: 404 C: 405 C: ABC-12345 406 C: 407 C: 409 Example response with the Registry Maintenance poll message: 411 S: 412 S: 413 S: 414 S: 415 S: Command completed successfully; ack to dequeue 416 S: 417 S: 418 S: 2017-02-08T22:10:00Z 419 S: Registry Maintenance Notification 420 S: 421 S: 422 S: 424 S: 425 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 426 S: 427 S: 428 S: EPP 429 S: epp.registry.example 430 S: blackout 431 S: 432 S: 433 S: 434 S: 2017-04-30T06:00:00Z 435 S: 2013-10-22T14:25:57Z 436 S: planned 437 S: 438 S: https://www.registry.example/notice?123 439 S: 440 S: 441 S: example 442 S: test 443 S: 444 S: 445 S: false 446 S: false 447 S: 448 S: active 449 S: 2017-02-08T22:10:00Z 450 S: 451 S: 452 S: 453 S: 454 S: ABC-12345 455 S: 54321-XYZ 456 S: 457 S: 458 S: 460 3.2. EPP Transform Commands 462 EPP provides five commands to transform objects: to create 463 an instance of an object, to delete an instance of an 464 object, to extend the validity period of an object, 465 to manage object sponsorship changes, and to 466 change information associated with an object. 468 3.2.1. EPP Command 470 Create semantics do not apply to maintenance objects, so there is no 471 mapping defined for the EPP command. 473 3.2.2. EPP Command 475 Delete semantics do not apply to maintenance objects, so there is no 476 mapping defined for the EPP command. 478 3.2.3. EPP Command 480 Renew semantics do not apply to maintenance objects, so there is no 481 mapping defined for the EPP command. 483 3.2.4. EPP Command 485 Transfer semantics do not apply to maintenance objects, so there is 486 no mapping defined for the EPP command. 488 3.2.5. EPP Command 490 Update semantics do not apply to maintenance objects, so there is no 491 mapping defined for the EPP command. 493 4. Formal Syntax 495 One schema is presented here that is the EPP Registry Maintenance 496 schema. 498 The formal syntax presented here is a complete schema representation 499 of the object mapping suitable for automated validation of EPP XML 500 instances. The BEGIN and END tags are not part of the schema; they 501 are used to note the beginning and ending of the schema for URI 502 registration purposes. 504 4.1. Registry Maintenance EPP Mapping Schema 506 BEGIN 507 508 515 518 519 521 522 523 Extensible Provisioning Protocol v1.0 524 Maintenance Mapping Schema. 525 526 528 531 533 536 537 538 539 540 541 542 543 544 545 547 550 552 555 556 557 558 559 560 562 565 566 567 569 570 572 575 576 577 578 579 580 581 582 583 584 587 588 589 590 592 594 595 596 598 599 601 603 604 605 606 607 609 612 613 614 616 617 619 622 623 624 625 626 627 629 632 633 634 635 636 637 638 640 643 644 645 646 647 648 649 650 651 653 656 657 658 659 660 661 662 663 665 668 669 670 671 672 673 675 678 679 680 682 683 684 687 688 689 690 691 692 694 697 698 699 700 701 702 704 707 708 END 710 5. IANA Considerations 712 TBD 714 6. Security Considerations 716 The mapping extensions described in this document do not provide any 717 security services beyond those described by EPP [RFC5730] and 718 protocol layers used by EPP. The security considerations described in 719 these other specifications apply to this specification as well. 721 7. Implementation Status 723 Note to RFC Editor: Please remove this section and the reference to 724 [RFC7942] before publication. 726 This section records the status of known implementations of the 727 protocol defined by this specification at the time of posting of this 728 Internet-Draft, and is based on a proposal described in [RFC7942]. 729 The description of implementations in this section is intended to 730 assist the IETF in its decision processes in progressing drafts to 731 RFCs. Please note that the listing of any individual implementation 732 here does not imply endorsement by the IETF. Furthermore, no effort 733 has been spent to verify the information presented here that was 734 supplied by IETF contributors. This is not intended as, and must not 735 be construed to be, a catalog of available implementations or their 736 features. Readers are advised to note that other implementations may 737 exist. 739 According to [RFC7942], "this will allow reviewers and working groups 740 to assign due consideration to documents that have the benefit of 741 running code, which may serve as evidence of valuable experimentation 742 and feedback that have made the implemented protocols more mature. It 743 is up to the individual working groups to use this information as 744 they see fit". 746 Add implementation details once available. 748 8. References 750 8.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997, 754 . 756 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 757 STD 69, RFC 5730, August 2009, 758 . 760 8.2. Informative References 762 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 763 Internet: Timestamps", RFC 3339, July 2002, 764 . 766 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 767 for Internationalized Domain Names in Applications (IDNA) 768 ", RFC 3492, March 2003, 769 . 771 [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally 772 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 773 2015, 774 . 776 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 777 Address Text Representation", RFC 5952, August 2010, 778 . 780 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 781 Running Code: The Implementation Status Section", RFC 782 7942, July 2016, 783 785 Appendix A. Change History 787 A.1. Change from 00 to 01 789 Removed JSON Schema. Clarified unique id with UUID. Added Common Data 790 Structures for better explanation. Fixed EPP poll response example. 791 Added und fixed References. 793 A.2. Change from 01 to 02 795 Clarified host field. Added TLDs to Common Data Structure. Added 796 Internationalization Considerations. Changed authors address and 797 contact details. 799 A.3. Change from 02 to 03 801 Added date-time Values to Internationalization Considerations. Sorted 802 Terminology and Definitions alphabetically. Changed start and end 803 date-time. Changed Reference URI to HTTPS. 805 A.4. Change from 03 to 04 807 Added Acknowledgements. Clarified UUID field to be not changed at all 808 Clarified environment field with production, ote, staging and dev. 809 Clarified connection and implementation fields. Fixed writing of 810 systems field. Removed author's private address. Moved this draft 811 from Experimental to Standard Track. 813 A.5. Change from 04 to 05 815 Changed title of this draft to be more specific. Added Change Log. 816 Split References into Normative and Informative References. Clarified 817 Common Data Types. Rephrased Abstract and Introduction. Added 818 Implementation Status Section. 820 A.6. Change from 05 to 06 822 Added IANA Considerations. Changed URIs from http to https. Added 823 new main Section 4. EPP Command Mapping. Added new JSON field purpose 824 for announce, change or cancel of a maintenance notification. 826 A.7. Change from 06 to 07 828 Fixed typo in Section 3.4. and added missing comma in the example of 829 Section 4.1. Added the field specification to help facilitate the 830 adoption of this document. Changed possible purposes to create, 831 update and delete to be closer to the EPP syntax. Cleaned 832 whitespaces. Updated Acknowledgements. 834 A.8. Change from 07 to EPPMAINT 00 836 Removed JSON payload in message and switched to specific 837 EPP message. Extended EPP command to provide details 838 on specific maintenance or list all maintenances. 840 A.9. Change from EPPMAINT 00 to EPPMAINT 01 842 Fixed typos and added missing change log text for EPPMAINT 00. 843 Added BEGIN and END flag to XML schema. Removed Character Encoding 844 Section. Fixed indentation in Section 2.3. 846 A.10. Change from EPPMAINT 01 to EPPMAINT 02 848 Changed the element to . Fixed 849 indentation in Section 4.1. Cleaned up whitespaces. 851 Appendix B. Acknowledgements 853 The author wishes to thank the following persons for their feedback 854 and suggestions (sorted alphabetically by company): 856 * Neal McPherson of 1&1 Internet 857 * Christopher Martens of Donuts 858 * Jody Kolker and Roger Carney of GoDaddy 859 * Raymond Zylstra of Neustar 860 * Andreas Huber of united-domains 861 * Craig Marchant of VentraIP 862 * James Gould of Verisign 864 Author's Address 866 Tobias Sattler 868 Email: tobias.sattler@me.com 869 URI: https://tobiassattler.com