idnits 2.17.1 draft-ietf-regext-epp-registry-maintenance-03.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 (June 30, 2020) is 1396 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: December 29, 2020 J. Kolker 5 GoDaddy Inc. 6 June 30, 2020 8 Registry Maintenance Notifications for the 9 Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-registry-maintenance-03 12 Abstract 13 This document describes an Extensible Provision Protocol (EPP) 14 mapping for 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 December 29, 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 A.4. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 82 A.5. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 19 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 Registries usually conduct maintenances and inform registrars in 89 different ways. Given the expansion of the DNS namespace, it is now 90 desirable to provide a method for EPP servers to notify EPP clients 91 as well as a method for EPP clients to query EPP servers for upcoming 92 maintenances. 94 This document describes an extension mapping for version 1.0 of the 95 Extensible Provision Protocol [RFC5730]. This mapping provides a 96 mechanism by which EPP servers may notify and EPP clients to query 97 for upcoming maintenances. 99 1.1. Terminology and Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] when 104 specified in their uppercase forms. 106 XML is case sensitive. Unless stated otherwise, XML specifications 107 moreover, examples provided in this document MUST be interpreted in 108 the character case presented to develop a conforming implementation. 110 "maint" is used as an abbreviation for "urn:ietf:params:xml:ns: 111 maintenance-1.0". The XML namespace prefix "maint" is used, but 112 implementations MUST NOT depend on it and instead employ a proper 113 namespace-aware XML parser and serializer to interpret and output 114 the XML documents. 116 In examples, "C:" represents lines sent by a protocol client and 117 "S:" represents lines returned by a protocol server. Indentation and 118 white space in examples are provided only to illustrate element 119 relationships and are not a REQUIRED feature of this protocol. 121 2. Object Attributes 123 2.1. Internationalized Domain Names 125 Names of affected hosts MUST be provided in Punycode according to 126 [RFC5891]. 128 2.2. Dates and Times 130 All dates and times attribute values MUST be expressed in Universal 131 Coordinated Time (UTC) using the Gregorian calendar. The extended 132 date-time form using upper case "T" and "Z" characters defined in ISO 133 8601 [RFC3339] MUST be used to represent date-time values. 135 2.3. Maintenance Elements 137 The element describes a single registry maintenance 138 event during a specific period. This element will be used at EPP 139 messages and to extend the EPP command. 141 For creating a new maintenance the attribute MUST be 142 'active', the attribute MUST be set and the attribute 143 SHALL NOT be present. 145 For updating a maintenance the attribute MUST be 146 'active', the attributes and MUST be 147 set. 149 For deleting a maintenance the attribute MUST be 150 'inactive', and the attributes and MUST 151 be set. 153 154 MUST be present and a server unique id and SHALL NOT be 155 changed if maintenance is updated or deleted. A human-readable 156 description of the maintenance is identified via an OPTIONAL 157 "msg" attribute. 159 160 MUST be present and contains one or more elements. 161 The server SHOULD NOT list systems which are not affected by the 162 maintenance. 164 165 MUST be present at least once and is an element of , 166 and . 168 169 MUST be present and indicates the name of the affected system, 170 such as 'EPP', 'WHOIS', 'DNS', 'Portal', etc. 172 173 MUST be present and indicates the affected maintained system 174 contains or . 176 177 Hostname SHALL be Punycode according [RFC5891]. 179 180 IPv4 addresses SHALL be dotted-decimal notation. 181 An example of this textual representation is "192.0.2.0". 183 184 IPv6 addresses SHALL be according [RFC5952]. 185 An example of this textual representation is 186 "2001:db8::1:0:0:1". 188 189 MUST be present and contains the impact level; values SHOULD 190 either be 'blackout' or 'partial'. 192 193 MUST be present and indicates the type of the affected system; 194 the attribute type is REQUIRED and SHOULD either be 'production', 195 'ote', 'staging', 'dev' or 'custom'. And alternatively the 196 attribute name could be used to define a server specific affected 197 system for example: 198 200 201 SHOULD be present and indicates the start of the maintenance 202 according ISO 8601 [RFC3339]. 203 Format: YYYY-MM-DDThh:mm:ssTZ 205 206 SHOULD be present and indicates the end of the maintenance 207 according to ISO 8601 [RFC3339], and MUST be equal to or greater 208 than . 209 Format: YYYY-MM-DDThh:mm:ssTZ 211 212 MUST be present and contains the reason behind the maintenance; 213 values SHOULD either be 'planned' or 'emergency'. 215 216 MAY be present and contains URI to detailed maintenance 217 description. 219 220 MAY be present and provides a freeform description of the 221 maintenance without having to create and traverse an external 222 resource. The maximum length MUST NOT exceed 1024 characters. 224 225 SHOULD be present and contains elements. 227 228 MUST be present and contains the affected top-level domain. 229 Punycode encoded according to [RFC5891]. 231 232 SHOULD be present and contains and 233 . 235 236 SHOULD be present and indicates if a client needs to do 237 something that is connection-related, such as a reconnect. The 238 value SHALL be boolean. 240 241 MUST be present and indicates if a client needs to do something 242 that is implementation-related, such as a code change. The 243 value SHALL be boolean. 245 246 MUST be present and indicates the status of the maintenance. 247 The value SHALL be either 'active' or 'inactive'. 249 250 MUST be present and contains the creation date of the maintenance 251 according ISO 8601 [RFC3339]. 252 Format: YYYY-MM-DDThh:mm:ssTZ 254 255 MAY be present and contains the updated date of the maintenance 256 according to ISO 8601 [RFC3339], and if set MUST be equal to or 257 greater than . 258 Format: YYYY-MM-DDThh:mm:ssTZ 260 3. EPP Command Mapping 262 A detailed description of the EPP syntax and semantics can be found 263 in the EPP core protocol specification [RFC5730]. The command 264 mappings described here are specifically for the use to notify of 265 Registry Maintenances and Registry Maintenance object mapping. 267 3.1. EPP Query Commands 269 EPP [RFC5730] provides three commands to retrieve object information: 270 to determine if an object is known to the server, to 271 retrieve detailed information associated with an object, and 272 to retrieve object transfer status information. 274 3.1.1. EPP Command 276 Available check semantics do not apply to maintenance objects, so 277 there is no mapping defined for the EPP command. 279 3.1.2. EPP Command 281 Transfer semantics do not apply to maintenance objects, so there is 282 no mapping defined for the EPP command. 284 3.1.3. EPP Command 286 EPP provides the command that is used to retrieve registry 287 maintenance information. In addition to the standard EPP command 288 elements, the command MUST contain a 289 element that identifies the maintenance namespace. The 290 element MUST contain a child element. It is either to 291 retrieve a specific maintenance notification or to 292 query all maintenance notifications. 294 Example command with to get one specific 295 maintenance: 297 C: 298 C: 299 C: 300 C: 301 C: 303 C: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 304 C: 305 C: 306 C: ABC-12345 307 C: 308 C: 310 Example response for one specific maintenance notification: 312 S: 313 S: 314 S: 315 S: 316 S: Command completed successfully 317 S: 318 S: 319 S: 321 S: 322 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 323 S: 324 S: 325 S: 326 S: EPP 327 S: 328 S: epp.registry.example 329 S: 330 S: 331 S: blackout 332 S: 333 S: 334 S: 335 S: 2017-09-30T06:00:00Z 336 S: 2017-09-30T14:25:57Z 337 S: planned 338 S: 339 S: https://www.registry.example/notice?123 340 S: 341 S: free text 342 S: 343 S: example 344 S: test 345 S: 346 S: 347 S: false 348 S: false 349 S: 350 S: active 351 S: 2017-03-08T22:10:00Z 352 S: 353 S: 354 S: 355 S: 356 S: ABC-12345 357 S: 54321-XYZ 358 S: 359 S: 360 S: 362 Example command with to query all maintenances 363 subject to server policy: 365 C: 366 C: 367 C: 368 C: 369 C: 371 C: 372 C: 373 C: 374 C: ABC-12345 375 C: 376 C: 378 Example response querying all maintenances subject to server 379 policy: 381 S: 382 S: 383 S: 384 S: 385 S: Command completed successfully 386 S: 387 S: 388 S: 390 S: 391 S: 392 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 393 S: 394 S: 2017-04-30T06:00:00Z 395 S: 2017-04-30T07:00:00Z 396 S: 2017-02-08T22:10:00Z 397 S: 398 S: 399 S: 91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 400 S: 401 S: 2017-06-15T04:30:00Z 402 S: 2017-06-15T05:30:00Z 403 S: 2017-02-08T22:10:00Z 404 S: 2017-03-08T20:11:00Z 405 S: 406 S: 407 S: 408 S: 409 S: 410 S: ABC-12345 411 S: 54321-XYZ 412 S: 413 S: 414 S: 416 3.1.4. EPP Command 418 The EPP command and response is defined in Section 2.9.2.3 of 419 [RFC5730]. The Registry Maintenance Notification is included in the 420 EPP response of [RFC5730]. 422 For the Registry Maintenance Notification, there are three types of 423 poll messages. The poll messages apply whenever the domain name 424 registry creates, updates, or deletes maintenance. In the case of 425 a Registry Maintenance specific message, a element 426 will be included within the element of the standard 427 response. 429 The element will include a reference to the 430 Registry Maintenance namespace. EPP data contained within the 431 element is formatted according to the 432 maintenance-poll schema. 434 Example command: 436 C: 437 C: 438 C: 439 C: 440 C: ABC-12345 441 C: 442 C: 444 Example response with the Registry Maintenance poll message: 446 S: 447 S: 448 S: 449 S: 450 S: Command completed successfully; ack to dequeue 451 S: 452 S: 453 S: 2017-02-08T22:10:00Z 454 S: Registry Maintenance Notification 455 S: 456 S: 457 S: 459 S: 460 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 461 S: 462 S: 463 S: EPP 464 S: 465 S: epp.registry.example 466 S: 467 S: 468 S: blackout 469 S: 470 S: 471 S: 472 S: 2017-10-30T06:00:00Z 473 S: 2017-10-30T14:25:57Z 474 S: planned 475 S: 476 S: https://www.registry.example/notice?123 477 S: 478 S: 479 S: example 480 S: test 481 S: 482 S: 483 S: false 484 S: false 485 S: 486 S: active 487 S: 2017-02-08T22:10:00Z 488 S: 489 S: 490 S: 491 S: 492 S: ABC-12345 493 S: 54321-XYZ 494 S: 495 S: 496 S: 498 3.2. EPP Transform Commands 500 EPP provides five commands to transform objects: to create 501 an instance of an object, to delete an instance of an 502 object, to extend the validity period of an object, 503 to manage object sponsorship changes, and to 504 change information associated with an object. 506 3.2.1. EPP Command 508 Create semantics do not apply to maintenance objects, so there is no 509 mapping defined for the EPP command. 511 3.2.2. EPP Command 513 Delete semantics do not apply to maintenance objects, so there is no 514 mapping defined for the EPP command. 516 3.2.3. EPP Command 518 Renew semantics do not apply to maintenance objects, so there is no 519 mapping defined for the EPP command. 521 3.2.4. EPP Command 523 Transfer semantics do not apply to maintenance objects, so there is 524 no mapping defined for the EPP command. 526 3.2.5. EPP Command 528 Update semantics do not apply to maintenance objects, so there is no 529 mapping defined for the EPP command. 531 4. Formal Syntax 533 One schema is presented here that is the EPP Registry Maintenance 534 schema. 536 The formal syntax presented here is a complete schema representation 537 of the object mapping suitable for automated validation of EPP XML 538 instances. The BEGIN and END tags are not part of the schema; they 539 are used to note the beginning and end of the schema for URI 540 registration purposes. 542 4.1. Registry Maintenance EPP Mapping Schema 544 BEGIN 545 546 553 556 557 559 560 561 Extensible Provisioning Protocol v1.0 562 Maintenance Mapping Schema. 563 564 566 569 571 574 575 576 577 578 580 581 582 583 584 586 589 590 591 592 593 594 595 597 600 602 605 606 607 608 609 610 612 615 616 617 619 620 622 625 626 627 628 629 630 631 632 633 634 637 638 639 640 641 642 643 644 645 646 648 649 650 651 652 653 654 656 659 660 661 663 664 666 669 670 671 672 673 674 676 679 680 681 682 683 685 688 689 690 691 692 693 694 696 699 700 701 702 703 704 706 709 710 711 712 713 714 715 716 717 719 722 723 724 725 726 727 728 729 731 734 735 736 737 738 739 740 743 744 745 747 748 750 753 754 755 756 757 758 760 763 764 765 766 767 768 770 773 774 END 776 5. IANA Considerations 778 5.1. XML Namespace 780 This document uses URNs to describe XML namespaces and XML schemas 781 conforming to a registry mechanism defined in [RFC3688]. 783 Registration request for the maintenance namespace: 785 URI: urn:ietf:params:xml:ns:maintenance-1.0 787 Registrant Contact: IESG 789 XML: None. Namespace URIs do not represent an XML specification. 791 Registration request for the maintenance schema: 793 URI: urn:ietf:params:xml:schema:maintenance-1.0 795 Registrant Contact: IESG 797 XML: See the "Formal Syntax" section of this document. 799 5.2. EPP Extension Registry 801 The following registration of the EPP Extension Registry, described 802 in [RFC7451], is requested: 804 Name of Extension: "Registry Maintenance Notifications for the 805 Extensible Provisioning Protocol (EPP)" 807 Document status: Standards Track 809 Reference: (insert the reference to RFC version of this document) 811 Registrant Name and Email Address: IESG, 813 TLDs: Any 815 IPR Disclosure: None 817 Status: Active 819 Notes: None 821 6. Security Considerations 823 The mapping extensions described in this document do not provide any 824 security services beyond those specified by EPP [RFC5730] and 825 protocol layers used by EPP. The security considerations described in 826 these other specifications apply to this specification as well. 828 7. Implementation Status 830 Note to RFC Editor: Please remove this section and the reference to 831 [RFC7942] before publication. 833 This section records the status of known implementations of the 834 protocol defined by this specification at the time of posting of this 835 Internet-Draft, and is based on a proposal described in [RFC7942]. 836 The description of implementations in this section is intended to 837 assist the IETF in its decision processes in progressing drafts to 838 RFCs. Please note that the listing of any individual implementation 839 here does not imply endorsement by the IETF. Furthermore, no effort 840 has been spent to verify the information presented here that was 841 supplied by IETF contributors. This is not intended as, and must not 842 be construed to be, a catalog of available implementations or their 843 features. Readers are advised to note that other implementations may 844 exist. 846 According to [RFC7942], "this will allow reviewers and working groups 847 to assign due consideration to documents that have the benefit of 848 running code, which may serve as evidence of valuable experimentation 849 and feedback that have made the implemented protocols more mature. It 850 is up to the individual working groups to use this information as 851 they see fit". 853 Add implementation details once available. 855 8. References 857 8.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997, 861 . 863 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 864 DOI 10.17487/RFC3688, January 2004, 865 . 867 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 868 STD 69, RFC 5730, August 2009, 869 . 871 8.2. Informative References 873 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 874 Internet: Timestamps", RFC 3339, July 2002, 875 . 877 [RFC5891] Klensin, J., "Internationalized Domain Names in 878 Applications (IDNA): Protocol", RFC 5891, August 2010, 879 . 881 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 882 Address Text Representation", RFC 5952, August 2010, 883 . 885 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 886 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 887 February 2015, . 889 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 890 Running Code: The Implementation Status Section", RFC 891 7942, July 2016, 892 . 894 Appendix A. Change History 896 A.1. Change from draft-sattler-epp-poll-maintenance-response to 897 draft-sattler-epp-registry-maintenance 899 Updated to be EPP based instead of JSON document. 901 A.2. Change from draft-sattler-epp-registry-maintenance to 902 draft-ietf-regext-epp-registry-maintenance 904 Adopted by the REGEXT working group. 906 A.3. Change from 00 to 01 908 Clarified maint:description and maint:environment. Changed 909 maint:description from complexType to simpleType. Fixed typo. 910 Added acknowledgment. 912 A.4. Change from 01 to 02 914 Update language from Domain Name Registry to Registry. Clarified 915 XML namespace urn:ietf:params:xml:ns:maintenance-1.0. Changed host 916 to contain hostName and hostAddr. Changed maint:tlds from MUST to 917 SHOULD. Fixed maint:status in Schema. Changed UUID to a server 918 unique id. 920 A.5. Change from 02 to 03 922 Changed maint:connection from MUST to SHOULD. 924 Acknowledgments 926 The authors wish to thank the following individuals for their 927 feedback and suggestions (sorted alphabetically by company): 929 o Patrick Mevzek 930 o Neal McPherson, 1&1 IONOS 931 o Anthony Eden, DNSimple 932 o Christopher Martens, Donuts 933 o Quoc-Anh Pham, Neustar 934 o Raymond Zylstra, Neustar 935 o Andreas Huber, united-domains 936 o Craig Marchant, VentraIP 937 o James Gould, Verisign 939 Authors' Addresses 941 Tobias Sattler 943 Email: tobias.sattler@me.com 944 URI: https://tobiassattler.com 946 Roger Carney 947 GoDaddy Inc. 948 14455 N. Hayden Rd. #219 949 Scottsdale, AZ 85260 950 US 952 Email: rcarney@godaddy.com 953 URI: http://www.godaddy.com 955 Jody Kolker 956 GoDaddy Inc. 957 14455 N. Hayden Rd. #219 958 Scottsdale, AZ 85260 959 US 961 Email: jkolker@godaddy.com 962 URI: http://www.godaddy.com