idnits 2.17.1 draft-ietf-regext-epp-registry-maintenance-00.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 (February 15, 2020) is 1494 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 (IETF) T. Sattler 2 Internet-Draft 3 Intended status: Standards Track R. Carney 4 Expires: August 14, 2020 J. Kolker 5 GoDaddy Inc. 6 February 15, 2020 8 Registry Maintenance Notifications for the 9 Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-registry-maintenance-00 12 Abstract 13 This document describes an Extensible Provision Protocol (EPP) 14 mapping for domain name registry's maintenance notifications. 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 August 14, 2020. 32 Copyright Notice 33 Copyright (c) 2020 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 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 69 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 17 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 74 8.2. Informative References . . . . . . . . . . . . . . . . . 18 75 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 76 A.1. Change from draft-sattler-epp-poll-maintenance-response to 77 draft-sattler-epp-registry-maintenance . . . . . . . . . 19 78 A.2. Change from draft-sattler-epp-registry-maintenance to 79 draft-ietf-regext-epp-registry-maintenance . . . . . . . 19 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 Domain name registries usually conduct maintenances and inform domain 86 name registrars in different ways. Given the expansion of the DNS 87 namespace, it is now desirable to provide a method for EPP servers to 88 notify EPP clients as well as a method for EPP clients to query EPP 89 servers for upcoming maintenances. 91 This document describes an extension mapping for version 1.0 of the 92 Extensible Provision Protocol [RFC5730]. This mapping provides a 93 mechanism by which EPP servers may notify and EPP clients to query 94 for upcoming maintenances. 96 1.1. Terminology and Definitions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119] when 101 specified in their uppercase forms. 103 XML is case sensitive. Unless stated otherwise, XML specifications 104 moreover, examples provided in this document MUST be interpreted in 105 the character case presented to develop a conforming implementation. 107 In examples, "C:" represents lines sent by a protocol client and 108 "S:" represents lines returned by a protocol server. Indentation and 109 white space in examples are provided only to illustrate element 110 relationships and are not a REQUIRED feature of this protocol. 112 2. Object Attributes 114 2.1. Internationalized Domain Names 116 Names of affected hosts MUST be provided in Punycode according to 117 [RFC5891]. 119 2.2. Dates and Times 121 All dates and times attribute values MUST be expressed in Universal 122 Coordinated Time (UTC) using the Gregorian calendar. The extended 123 date-time form using upper case "T" and "Z" characters defined in ISO 124 8601 [RFC3339] MUST be used to represent date-time values. 126 2.3. Maintenance Elements 128 The element describes a single registry maintenance 129 event during a specific period. This element will be used at EPP 130 messages and to extend the EPP command. 132 For creating a new maintenance the attribute MUST be 133 'active', the attribute MUST be set and the attribute 134 SHALL NOT be present. 136 For updating a maintenance the attribute MUST be 137 'active', the attributes and MUST be 138 set. 140 For deleting a maintenance the attribute MUST be 141 'inactive', and the attributes and MUST 142 be set. 144 145 MUST be present and a UUID according [RFC4122] and SHALL NOT be 146 changed if maintenance got updated or deleted. A human-readable 147 description of the maintenance is identified via an OPTIONAL 148 "msg" attribute. 150 151 MUST be present and contains one or more elements. 152 The server SHOULD NOT list systems which are not affected by the 153 maintenance. 155 156 MUST be present at least once and is an element of , 157 and . 159 160 MUST be present and indicates the name of the affected system, 161 such as 'EPP', 'WHOIS', 'DNS', 'Portal', etc. 163 164 MUST be present and indicates the affected maintained system 165 (host or IP address). 166 Hostname SHALL be Punycode according [RFC5891]. 167 IPv4 addresses SHALL be dotted-decimal notation. 168 An example of this textual representation is "192.0.2.0". 169 IPv6 addresses SHALL be according [RFC5952]. 170 An example of this textual representation is 171 "2001:db8::1:0:0:1". 173 174 MUST be present and contains the impact level; values SHOULD 175 either be 'blackout' or 'partial'. 177 178 MUST be present and indicates the type of the affected system; 179 values SHOULD either be 'production', 'ote', 'staging' or 'dev'. 181 182 MUST be present and indicates the start of the maintenance 183 according ISO 8601 [RFC3339]. 184 Format: YYYY-MM-DDThh:mm:ssTZ 186 187 MUST be present and indicates the end of the maintenance 188 according to ISO 8601 [RFC3339], and MUST be equal to or greater 189 than . 190 Format: YYYY-MM-DDThh:mm:ssTZ 192 193 MUST be present and contains the reason behind the maintenance; 194 values SHOULD either be 'planned' or 'emergency'. 196 197 MAY be present and contains URI to detailed maintenance 198 description. 200 201 MAY be present and provides a freeform description of the 202 maintenance without having to create and traverse an external 203 resource. The maximum length MUST NOT exceed 1024 bit. 205 206 MUST be present and contains elements. 208 209 MUST be present and contains the affected top-level domain. 210 Punycode encoded according to [RFC5891]. 212 213 MUST be present and contains and 214 . 216 217 MUST be present and indicates if a client needs to do something 218 that is connection-related, such as a reconnect. The value 219 SHALL be boolean. 221 222 MUST be present and indicates if a client needs to do something 223 that is implementation-related, such as a code change. The 224 value SHALL be boolean. 226 227 MUST be present and indicates the status of the maintenance. 228 The value SHALL be either 'active' or 'inactive'. 230 231 MUST be present and contains the creation date of the maintenance 232 according ISO 8601 [RFC3339]. 233 Format: YYYY-MM-DDThh:mm:ssTZ 235 236 MAY be present and contains the updated date of the maintenance 237 according to ISO 8601 [RFC3339], and if set MUST be equal to or 238 greater than . 239 Format: YYYY-MM-DDThh:mm:ssTZ 241 3. EPP Command Mapping 243 A detailed description of the EPP syntax and semantics can be found 244 in the EPP core protocol specification [RFC5730]. The command 245 mappings described here are specifically for the use to notify of 246 Registry Maintenances and Registry Maintenance object mapping. 248 3.1. EPP Query Commands 250 EPP [RFC5730] provides three commands to retrieve object information: 251 to determine if an object is known to the server, to 252 retrieve detailed information associated with an object, and 253 to retrieve object transfer status information. 255 3.1.1. EPP Command 257 Available check semantics do not apply to maintenance objects, so 258 there is no mapping defined for the EPP command. 260 3.1.2. EPP Command 262 Transfer semantics do not apply to maintenance objects, so there is 263 no mapping defined for the EPP command. 265 3.1.3. EPP Command 267 EPP provides the command that is used to retrieve registry 268 maintenance information. In addition to the standard EPP command 269 elements, the command MUST contain a 270 element that identifies the maintenance namespace. The 271 element MUST contain a child element. It is either to 272 retrieve a specific maintenance notification or to 273 query all maintenance notifications. 275 Example command with to get one specific 276 maintenance: 278 C: 279 C: 280 C: 281 C: 282 C: 284 C: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 285 C: 286 C: 287 C: ABC-12345 288 C: 289 C: 291 Example response for one specific maintenance notification: 293 S: 294 S: 295 S: 296 S: 297 S: Command completed successfully 298 S: 299 S: 300 S: 302 S: 303 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 304 S: 305 S: 306 S: 307 S: EPP 308 S: epp.registry.example 309 S: blackout 310 S: 311 S: 312 S: 313 S: 2017-09-30T06:00:00Z 314 S: 2017-09-30T14:25:57Z 315 S: planned 316 S: 317 S: https://www.registry.example/notice?123 318 S: 319 S: free text 320 S: 321 S: example 322 S: test 323 S: 324 S: 325 S: false 326 S: false 327 S: 328 S: active 329 S: 2017-03-08T22:10:00Z 330 S: 331 S: 332 S: 333 S: 334 S: ABC-12345 335 S: 54321-XYZ 336 S: 337 S: 338 S: 340 Example command with to query all maintenances: 342 C: 343 C: 344 C: 345 C: 346 C: 348 C: 349 C: 350 C: 351 C: ABC-12345 352 C: 353 C: 355 Example response querying all maintenances: 357 S: 358 S: 359 S: 360 S: 361 S: Command completed successfully 362 S: 363 S: 364 S: 366 S: 367 S: 368 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 369 S: 370 S: 2017-04-30T06:00:00Z 371 S: 2017-04-30T07:00:00Z 372 S: 2017-02-08T22:10:00Z 373 S: 374 S: 375 S: 91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 376 S: 377 S: 2017-06-15T04:30:00Z 378 S: 2017-06-15T05:30:00Z 379 S: 2017-02-08T22:10:00Z 380 S: 2017-03-08T20:11:00Z 381 S: 382 S: 383 S: 384 S: 385 S: 386 S: ABC-12345 387 S: 54321-XYZ 388 S: 389 S: 390 S: 392 3.1.4. EPP Command 394 The EPP command and response is defined in Section 2.9.2.3 of 395 [RFC5730]. The Registry Maintenance Notification is included in the 396 EPP response of [RFC5730]. 398 For the Registry Maintenance Notification, there are three types of 399 poll messages. The poll messages apply whenever the domain name 400 registry creates, updates, or deletes maintenance. In the case of 401 a Registry Maintenance specific message, a element 402 will be included within the element of the standard 403 response. 405 The element will include a reference to the 406 Registry Maintenance namespace. EPP data contained within the 407 element is formatted according to the 408 maintenance-poll schema. 410 Example command: 412 C: 413 C: 414 C: 415 C: 416 C: ABC-12345 417 C: 418 C: 420 Example response with the Registry Maintenance poll message: 422 S: 423 S: 424 S: 425 S: 426 S: Command completed successfully; ack to dequeue 427 S: 428 S: 429 S: 2017-02-08T22:10:00Z 430 S: Registry Maintenance Notification 431 S: 432 S: 433 S: 435 S: 436 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 437 S: 438 S: 439 S: EPP 440 S: epp.registry.example 441 S: blackout 442 S: 443 S: 444 S: 445 S: 2017-10-30T06:00:00Z 446 S: 2017-10-30T14:25:57Z 447 S: planned 448 S: 449 S: https://www.registry.example/notice?123 450 S: 451 S: 452 S: example 453 S: test 454 S: 455 S: 456 S: false 457 S: false 458 S: 459 S: active 460 S: 2017-02-08T22:10:00Z 461 S: 462 S: 463 S: 464 S: 465 S: ABC-12345 466 S: 54321-XYZ 467 S: 468 S: 469 S: 471 3.2. EPP Transform Commands 473 EPP provides five commands to transform objects: to create 474 an instance of an object, to delete an instance of an 475 object, to extend the validity period of an object, 476 to manage object sponsorship changes, and to 477 change information associated with an object. 479 3.2.1. EPP Command 481 Create semantics do not apply to maintenance objects, so there is no 482 mapping defined for the EPP command. 484 3.2.2. EPP Command 486 Delete semantics do not apply to maintenance objects, so there is no 487 mapping defined for the EPP command. 489 3.2.3. EPP Command 491 Renew semantics do not apply to maintenance objects, so there is no 492 mapping defined for the EPP command. 494 3.2.4. EPP Command 496 Transfer semantics do not apply to maintenance objects, so there is 497 no mapping defined for the EPP command. 499 3.2.5. EPP Command 501 Update semantics do not apply to maintenance objects, so there is no 502 mapping defined for the EPP command. 504 4. Formal Syntax 506 One schema is presented here that is the EPP Registry Maintenance 507 schema. 509 The formal syntax presented here is a complete schema representation 510 of the object mapping suitable for automated validation of EPP XML 511 instances. The BEGIN and END tags are not part of the schema; they 512 are used to note the beginning and end of the schema for URI 513 registration purposes. 515 4.1. Registry Maintenance EPP Mapping Schema 517 BEGIN 518 519 526 529 530 532 533 534 Extensible Provisioning Protocol v1.0 535 Maintenance Mapping Schema. 536 537 539 542 544 547 548 549 550 551 553 554 555 556 557 559 562 563 564 565 566 567 568 570 573 575 578 579 580 581 582 583 585 588 589 590 592 593 595 598 599 600 601 602 603 604 605 606 607 610 611 612 613 614 615 616 617 618 619 621 622 623 624 625 626 627 629 632 633 634 636 637 639 642 643 644 645 646 647 649 652 653 654 655 656 658 661 662 663 664 665 666 667 669 672 673 674 675 676 677 678 679 680 682 685 686 687 688 689 690 691 692 694 697 698 699 700 701 702 704 707 708 709 711 712 713 716 717 718 719 720 721 723 726 727 728 729 730 731 733 736 737 END 739 5. IANA Considerations 741 5.1. XML Namespace 743 This document uses URNs to describe XML namespaces and XML schemas 744 conforming to a registry mechanism defined in [RFC3688]. 746 Registration request for the maintenance namespace: 748 URI: urn:ietf:params:xml:ns:maintenance-1.0 750 Registrant Contact: IESG 752 XML: None. Namespace URIs do not represent an XML specification. 754 Registration request for the maintenance schema: 756 URI: urn:ietf:params:xml:schema:maintenance-1.0 758 Registrant Contact: IESG 760 XML: See the "Formal Syntax" section of this document. 762 5.2. EPP Extension Registry 764 The following registration of the EPP Extension Registry, described 765 in [RFC7451], is requested: 767 Name of Extension: "Registry Maintenance Notifications for the 768 Extensible Provisioning Protocol (EPP)" 770 Document status: Standards Track 772 Reference: (insert the reference to RFC version of this document) 774 Registrant Name and Email Address: IESG, 776 TLDs: Any 778 IPR Disclosure: None 780 Status: Active 782 Notes: None 784 6. Security Considerations 786 The mapping extensions described in this document do not provide any 787 security services beyond those specified by EPP [RFC5730] and 788 protocol layers used by EPP. The security considerations described in 789 these other specifications apply to this specification as well. 791 7. Implementation Status 793 Note to RFC Editor: Please remove this section and the reference to 794 [RFC7942] before publication. 796 This section records the status of known implementations of the 797 protocol defined by this specification at the time of posting of this 798 Internet-Draft, and is based on a proposal described in [RFC7942]. 799 The description of implementations in this section is intended to 800 assist the IETF in its decision processes in progressing drafts to 801 RFCs. Please note that the listing of any individual implementation 802 here does not imply endorsement by the IETF. Furthermore, no effort 803 has been spent to verify the information presented here that was 804 supplied by IETF contributors. This is not intended as, and must not 805 be construed to be, a catalog of available implementations or their 806 features. Readers are advised to note that other implementations may 807 exist. 809 According to [RFC7942], "this will allow reviewers and working groups 810 to assign due consideration to documents that have the benefit of 811 running code, which may serve as evidence of valuable experimentation 812 and feedback that have made the implemented protocols more mature. It 813 is up to the individual working groups to use this information as 814 they see fit". 816 Add implementation details once available. 818 8. References 820 8.1. Normative References 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997, 824 . 826 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 827 DOI 10.17487/RFC3688, January 2004, 828 . 830 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 831 STD 69, RFC 5730, August 2009, 832 . 834 8.2. Informative References 836 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 837 Internet: Timestamps", RFC 3339, July 2002, 838 . 840 [RFC5891] Klensin, J., "Internationalized Domain Names in 841 Applications (IDNA): Protocol", RFC 5891, August 2010, 842 . 844 [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally 845 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 846 2015, 847 . 849 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 850 Address Text Representation", RFC 5952, August 2010, 851 . 853 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 854 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 855 February 2015, . 857 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 858 Running Code: The Implementation Status Section", RFC 859 7942, July 2016, 860 . 862 Appendix A. Change History 864 A.1. Change from draft-sattler-epp-poll-maintenance-response to 865 draft-sattler-epp-registry-maintenance 867 Updated to be EPP based instead of JSON document. 869 A.2. Change from draft-sattler-epp-registry-maintenance to 870 draft-ietf-regext-epp-registry-maintenance 872 Adopted by the REGEXT working group. 874 Acknowledgments 876 The authors wish to thank the following individuals for their 877 feedback and suggestions (sorted alphabetically by company): 879 o Patrick Mevzek 880 o Neal McPherson, 1&1 IONOS 881 o Anthony Eden, DNSimple 882 o Christopher Martens, Donuts 883 o Raymond Zylstra, Neustar 884 o Andreas Huber, united-domains 885 o Craig Marchant, VentraIP 886 o James Gould, Verisign 888 Authors' Addresses 890 Tobias Sattler 892 Email: tobias.sattler@me.com 893 URI: https://tobiassattler.com 895 Roger Carney 896 GoDaddy Inc. 897 14455 N. Hayden Rd. #219 898 Scottsdale, AZ 85260 899 US 901 Email: rcarney@godaddy.com 902 URI: http://www.godaddy.com 904 Jody Kolker 905 GoDaddy Inc. 906 14455 N. Hayden Rd. #219 907 Scottsdale, AZ 85260 908 US 910 Email: jkolker@godaddy.com 911 URI: http://www.godaddy.com