idnits 2.17.1 draft-ietf-regext-epp-registry-maintenance-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 -- The document date (May 8, 2020) is 1447 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: November 7, 2020 J. Kolker 5 GoDaddy Inc. 6 May 8, 2020 8 Registry Maintenance Notifications for the 9 Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-registry-maintenance-01 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 November 7, 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 A.3. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 Domain name registries usually conduct maintenances and inform domain 87 name registrars in different ways. Given the expansion of the DNS 88 namespace, it is now desirable to provide a method for EPP servers to 89 notify EPP clients as well as a method for EPP clients to query EPP 90 servers for upcoming maintenances. 92 This document describes an extension mapping for version 1.0 of the 93 Extensible Provision Protocol [RFC5730]. This mapping provides a 94 mechanism by which EPP servers may notify and EPP clients to query 95 for upcoming maintenances. 97 1.1. Terminology and Definitions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119] when 102 specified in their uppercase forms. 104 XML is case sensitive. Unless stated otherwise, XML specifications 105 moreover, examples provided in this document MUST be interpreted in 106 the character case presented to develop a conforming implementation. 108 In examples, "C:" represents lines sent by a protocol client and 109 "S:" represents lines returned by a protocol server. Indentation and 110 white space in examples are provided only to illustrate element 111 relationships and are not a REQUIRED feature of this protocol. 113 2. Object Attributes 115 2.1. Internationalized Domain Names 117 Names of affected hosts MUST be provided in Punycode according to 118 [RFC5891]. 120 2.2. Dates and Times 122 All dates and times attribute values MUST be expressed in Universal 123 Coordinated Time (UTC) using the Gregorian calendar. The extended 124 date-time form using upper case "T" and "Z" characters defined in ISO 125 8601 [RFC3339] MUST be used to represent date-time values. 127 2.3. Maintenance Elements 129 The element describes a single registry maintenance 130 event during a specific period. This element will be used at EPP 131 messages and to extend the EPP command. 133 For creating a new maintenance the attribute MUST be 134 'active', the attribute MUST be set and the attribute 135 SHALL NOT be present. 137 For updating a maintenance the attribute MUST be 138 'active', the attributes and MUST be 139 set. 141 For deleting a maintenance the attribute MUST be 142 'inactive', and the attributes and MUST 143 be set. 145 146 MUST be present and a UUID according [RFC4122] and SHALL NOT be 147 changed if maintenance is updated or deleted. A human-readable 148 description of the maintenance is identified via an OPTIONAL 149 "msg" attribute. 151 152 MUST be present and contains one or more elements. 153 The server SHOULD NOT list systems which are not affected by the 154 maintenance. 156 157 MUST be present at least once and is an element of , 158 and . 160 161 MUST be present and indicates the name of the affected system, 162 such as 'EPP', 'WHOIS', 'DNS', 'Portal', etc. 164 165 MUST be present and indicates the affected maintained system 166 (host or IP address). 167 Hostname SHALL be Punycode according [RFC5891]. 168 IPv4 addresses SHALL be dotted-decimal notation. 169 An example of this textual representation is "192.0.2.0". 170 IPv6 addresses SHALL be according [RFC5952]. 171 An example of this textual representation is 172 "2001:db8::1:0:0:1". 174 175 MUST be present and contains the impact level; values SHOULD 176 either be 'blackout' or 'partial'. 178 179 MUST be present and indicates the type of the affected system; 180 the attribute type is REQUIRED and SHOULD either be 'production', 181 'ote', 'staging', 'dev' or 'custom'. And alternatively the 182 attribute name could be used to define a server specific affected 183 system for example: 184 186 187 MUST be present and indicates the start of the maintenance 188 according ISO 8601 [RFC3339]. 189 Format: YYYY-MM-DDThh:mm:ssTZ 191 192 MUST be present and indicates the end of the maintenance 193 according to ISO 8601 [RFC3339], and MUST be equal to or greater 194 than . 195 Format: YYYY-MM-DDThh:mm:ssTZ 197 198 MUST be present and contains the reason behind the maintenance; 199 values SHOULD either be 'planned' or 'emergency'. 201 202 MAY be present and contains URI to detailed maintenance 203 description. 205 206 MAY be present and provides a freeform description of the 207 maintenance without having to create and traverse an external 208 resource. The maximum length MUST NOT exceed 1024 characters. 210 211 MUST be present and contains elements. 213 214 MUST be present and contains the affected top-level domain. 215 Punycode encoded according to [RFC5891]. 217 218 MUST be present and contains and 219 . 221 222 MUST be present and indicates if a client needs to do something 223 that is connection-related, such as a reconnect. The value 224 SHALL be boolean. 226 227 MUST be present and indicates if a client needs to do something 228 that is implementation-related, such as a code change. The 229 value SHALL be boolean. 231 232 MUST be present and indicates the status of the maintenance. 233 The value SHALL be either 'active' or 'inactive'. 235 236 MUST be present and contains the creation date of the maintenance 237 according ISO 8601 [RFC3339]. 238 Format: YYYY-MM-DDThh:mm:ssTZ 240 241 MAY be present and contains the updated date of the maintenance 242 according to ISO 8601 [RFC3339], and if set MUST be equal to or 243 greater than . 244 Format: YYYY-MM-DDThh:mm:ssTZ 246 3. EPP Command Mapping 248 A detailed description of the EPP syntax and semantics can be found 249 in the EPP core protocol specification [RFC5730]. The command 250 mappings described here are specifically for the use to notify of 251 Registry Maintenances and Registry Maintenance object mapping. 253 3.1. EPP Query Commands 255 EPP [RFC5730] provides three commands to retrieve object information: 256 to determine if an object is known to the server, to 257 retrieve detailed information associated with an object, and 258 to retrieve object transfer status information. 260 3.1.1. EPP Command 262 Available check semantics do not apply to maintenance objects, so 263 there is no mapping defined for the EPP command. 265 3.1.2. EPP Command 267 Transfer semantics do not apply to maintenance objects, so there is 268 no mapping defined for the EPP command. 270 3.1.3. EPP Command 272 EPP provides the command that is used to retrieve registry 273 maintenance information. In addition to the standard EPP command 274 elements, the command MUST contain a 275 element that identifies the maintenance namespace. The 276 element MUST contain a child element. It is either to 277 retrieve a specific maintenance notification or to 278 query all maintenance notifications. 280 Example command with to get one specific 281 maintenance: 283 C: 284 C: 285 C: 286 C: 287 C: 289 C: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 290 C: 291 C: 292 C: ABC-12345 293 C: 294 C: 296 Example response for one specific maintenance notification: 298 S: 299 S: 300 S: 301 S: 302 S: Command completed successfully 303 S: 304 S: 305 S: 307 S: 308 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 309 S: 310 S: 311 S: 312 S: EPP 313 S: epp.registry.example 314 S: blackout 315 S: 316 S: 317 S: 318 S: 2017-09-30T06:00:00Z 319 S: 2017-09-30T14:25:57Z 320 S: planned 321 S: 322 S: https://www.registry.example/notice?123 323 S: 324 S: free text 325 S: 326 S: example 327 S: test 328 S: 329 S: 330 S: false 331 S: false 332 S: 333 S: active 334 S: 2017-03-08T22:10:00Z 335 S: 336 S: 337 S: 338 S: 339 S: ABC-12345 340 S: 54321-XYZ 341 S: 342 S: 343 S: 345 Example command with to query all maintenances: 347 C: 348 C: 349 C: 350 C: 351 C: 353 C: 354 C: 355 C: 356 C: ABC-12345 357 C: 358 C: 360 Example response querying all maintenances: 362 S: 363 S: 364 S: 365 S: 366 S: Command completed successfully 367 S: 368 S: 369 S: 371 S: 372 S: 373 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 374 S: 375 S: 2017-04-30T06:00:00Z 376 S: 2017-04-30T07:00:00Z 377 S: 2017-02-08T22:10:00Z 378 S: 379 S: 380 S: 91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 381 S: 382 S: 2017-06-15T04:30:00Z 383 S: 2017-06-15T05:30:00Z 384 S: 2017-02-08T22:10:00Z 385 S: 2017-03-08T20:11:00Z 386 S: 387 S: 388 S: 389 S: 390 S: 391 S: ABC-12345 392 S: 54321-XYZ 393 S: 394 S: 395 S: 397 3.1.4. EPP Command 399 The EPP command and response is defined in Section 2.9.2.3 of 400 [RFC5730]. The Registry Maintenance Notification is included in the 401 EPP response of [RFC5730]. 403 For the Registry Maintenance Notification, there are three types of 404 poll messages. The poll messages apply whenever the domain name 405 registry creates, updates, or deletes maintenance. In the case of 406 a Registry Maintenance specific message, a element 407 will be included within the element of the standard 408 response. 410 The element will include a reference to the 411 Registry Maintenance namespace. EPP data contained within the 412 element is formatted according to the 413 maintenance-poll schema. 415 Example command: 417 C: 418 C: 419 C: 420 C: 421 C: ABC-12345 422 C: 423 C: 425 Example response with the Registry Maintenance poll message: 427 S: 428 S: 429 S: 430 S: 431 S: Command completed successfully; ack to dequeue 432 S: 433 S: 434 S: 2017-02-08T22:10:00Z 435 S: Registry Maintenance Notification 436 S: 437 S: 438 S: 440 S: 441 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 442 S: 443 S: 444 S: EPP 445 S: epp.registry.example 446 S: blackout 447 S: 448 S: 449 S: 450 S: 2017-10-30T06:00:00Z 451 S: 2017-10-30T14:25:57Z 452 S: planned 453 S: 454 S: https://www.registry.example/notice?123 455 S: 456 S: 457 S: example 458 S: test 459 S: 460 S: 461 S: false 462 S: false 463 S: 464 S: active 465 S: 2017-02-08T22:10:00Z 466 S: 467 S: 468 S: 469 S: 470 S: ABC-12345 471 S: 54321-XYZ 472 S: 473 S: 474 S: 476 3.2. EPP Transform Commands 478 EPP provides five commands to transform objects: to create 479 an instance of an object, to delete an instance of an 480 object, to extend the validity period of an object, 481 to manage object sponsorship changes, and to 482 change information associated with an object. 484 3.2.1. EPP Command 486 Create semantics do not apply to maintenance objects, so there is no 487 mapping defined for the EPP command. 489 3.2.2. EPP Command 491 Delete semantics do not apply to maintenance objects, so there is no 492 mapping defined for the EPP command. 494 3.2.3. EPP Command 496 Renew semantics do not apply to maintenance objects, so there is no 497 mapping defined for the EPP command. 499 3.2.4. EPP Command 501 Transfer semantics do not apply to maintenance objects, so there is 502 no mapping defined for the EPP command. 504 3.2.5. EPP Command 506 Update semantics do not apply to maintenance objects, so there is no 507 mapping defined for the EPP command. 509 4. Formal Syntax 511 One schema is presented here that is the EPP Registry Maintenance 512 schema. 514 The formal syntax presented here is a complete schema representation 515 of the object mapping suitable for automated validation of EPP XML 516 instances. The BEGIN and END tags are not part of the schema; they 517 are used to note the beginning and end of the schema for URI 518 registration purposes. 520 4.1. Registry Maintenance EPP Mapping Schema 522 BEGIN 523 524 531 534 535 537 538 539 Extensible Provisioning Protocol v1.0 540 Maintenance Mapping Schema. 541 542 544 547 549 552 553 554 555 556 558 559 560 561 562 564 567 568 569 570 571 572 573 575 578 580 583 584 585 586 587 588 590 593 594 595 597 598 600 603 604 605 606 607 608 609 610 611 612 615 616 617 618 619 620 621 622 623 624 626 627 628 629 630 631 632 634 637 638 639 641 642 644 647 648 649 650 651 652 654 657 658 659 660 661 663 666 667 668 669 670 671 672 674 677 678 679 680 681 682 683 684 685 687 690 691 692 693 694 695 696 697 699 702 703 704 705 706 707 709 712 713 714 716 717 718 721 722 723 724 725 726 728 731 732 733 734 735 736 738 741 742 END 744 5. IANA Considerations 746 5.1. XML Namespace 748 This document uses URNs to describe XML namespaces and XML schemas 749 conforming to a registry mechanism defined in [RFC3688]. 751 Registration request for the maintenance namespace: 753 URI: urn:ietf:params:xml:ns:maintenance-1.0 755 Registrant Contact: IESG 757 XML: None. Namespace URIs do not represent an XML specification. 759 Registration request for the maintenance schema: 761 URI: urn:ietf:params:xml:schema:maintenance-1.0 763 Registrant Contact: IESG 765 XML: See the "Formal Syntax" section of this document. 767 5.2. EPP Extension Registry 769 The following registration of the EPP Extension Registry, described 770 in [RFC7451], is requested: 772 Name of Extension: "Registry Maintenance Notifications for the 773 Extensible Provisioning Protocol (EPP)" 775 Document status: Standards Track 777 Reference: (insert the reference to RFC version of this document) 779 Registrant Name and Email Address: IESG, 781 TLDs: Any 783 IPR Disclosure: None 785 Status: Active 787 Notes: None 789 6. Security Considerations 791 The mapping extensions described in this document do not provide any 792 security services beyond those specified by EPP [RFC5730] and 793 protocol layers used by EPP. The security considerations described in 794 these other specifications apply to this specification as well. 796 7. Implementation Status 798 Note to RFC Editor: Please remove this section and the reference to 799 [RFC7942] before publication. 801 This section records the status of known implementations of the 802 protocol defined by this specification at the time of posting of this 803 Internet-Draft, and is based on a proposal described in [RFC7942]. 804 The description of implementations in this section is intended to 805 assist the IETF in its decision processes in progressing drafts to 806 RFCs. Please note that the listing of any individual implementation 807 here does not imply endorsement by the IETF. Furthermore, no effort 808 has been spent to verify the information presented here that was 809 supplied by IETF contributors. This is not intended as, and must not 810 be construed to be, a catalog of available implementations or their 811 features. Readers are advised to note that other implementations may 812 exist. 814 According to [RFC7942], "this will allow reviewers and working groups 815 to assign due consideration to documents that have the benefit of 816 running code, which may serve as evidence of valuable experimentation 817 and feedback that have made the implemented protocols more mature. It 818 is up to the individual working groups to use this information as 819 they see fit". 821 Add implementation details once available. 823 8. References 825 8.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, March 1997, 829 . 831 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 832 DOI 10.17487/RFC3688, January 2004, 833 . 835 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 836 STD 69, RFC 5730, August 2009, 837 . 839 8.2. Informative References 841 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 842 Internet: Timestamps", RFC 3339, July 2002, 843 . 845 [RFC5891] Klensin, J., "Internationalized Domain Names in 846 Applications (IDNA): Protocol", RFC 5891, August 2010, 847 . 849 [RFC4122] Leach, P., Mealling, M. and Salz, R., "A Universally 850 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 851 2015, 852 . 854 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 855 Address Text Representation", RFC 5952, August 2010, 856 . 858 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 859 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 860 February 2015, . 862 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 863 Running Code: The Implementation Status Section", RFC 864 7942, July 2016, 865 . 867 Appendix A. Change History 869 A.1. Change from draft-sattler-epp-poll-maintenance-response to 870 draft-sattler-epp-registry-maintenance 872 Updated to be EPP based instead of JSON document. 874 A.2. Change from draft-sattler-epp-registry-maintenance to 875 draft-ietf-regext-epp-registry-maintenance 877 Adopted by the REGEXT working group. 879 A.3. Change from 00 to 01 881 Clarified maint:description and maint:environment. Changed 882 maint:description from complexType to simpleType. Fixed typo. 883 Added acknowledgment. 885 Acknowledgments 887 The authors wish to thank the following individuals for their 888 feedback and suggestions (sorted alphabetically by company): 890 o Patrick Mevzek 891 o Neal McPherson, 1&1 IONOS 892 o Anthony Eden, DNSimple 893 o Christopher Martens, Donuts 894 o Quoc-Anh Pham, Neustar 895 o Raymond Zylstra, Neustar 896 o Andreas Huber, united-domains 897 o Craig Marchant, VentraIP 898 o James Gould, Verisign 900 Authors' Addresses 902 Tobias Sattler 904 Email: tobias.sattler@me.com 905 URI: https://tobiassattler.com 907 Roger Carney 908 GoDaddy Inc. 909 14455 N. Hayden Rd. #219 910 Scottsdale, AZ 85260 911 US 913 Email: rcarney@godaddy.com 914 URI: http://www.godaddy.com 916 Jody Kolker 917 GoDaddy Inc. 918 14455 N. Hayden Rd. #219 919 Scottsdale, AZ 85260 920 US 922 Email: jkolker@godaddy.com 923 URI: http://www.godaddy.com