idnits 2.17.1 draft-ietf-regext-epp-registry-maintenance-04.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 (October 23, 2020) is 1274 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: April 22, 2021 J. Kolker 5 GoDaddy Inc. 6 October 23, 2020 8 Registry Maintenance Notifications for the 9 Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-registry-maintenance-04 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 April 22, 2021. 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 . . . . . . . . . . . . . . . . . . . . . 17 68 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 17 69 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 17 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 74 8.2. Informative References . . . . . . . . . . . . . . . . . 19 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 A.6. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 20 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Registries usually conduct maintenances and inform registrars in 90 different ways. Given the expansion of the DNS namespace, it is now 91 desirable to provide a method for EPP servers to notify EPP clients 92 as well as a method for EPP clients to query EPP servers for upcoming 93 maintenances. 95 This document describes an extension mapping for version 1.0 of the 96 Extensible Provision Protocol [RFC5730]. This mapping provides a 97 mechanism by which EPP servers may notify and EPP clients to query 98 for upcoming maintenances. 100 1.1. Terminology and Definitions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119] when 105 specified in their uppercase forms. 107 XML is case sensitive. Unless stated otherwise, XML specifications 108 moreover, examples provided in this document MUST be interpreted in 109 the character case presented to develop a conforming implementation. 111 "maint" is used as an abbreviation for "urn:ietf:params:xml:ns: 112 maintenance-1.0". The XML namespace prefix "maint" is used, but 113 implementations MUST NOT depend on it and instead employ a proper 114 namespace-aware XML parser and serializer to interpret and output 115 the XML documents. 117 In examples, "C:" represents lines sent by a protocol client and 118 "S:" represents lines returned by a protocol server. Indentation and 119 white space in examples are provided only to illustrate element 120 relationships and are not a REQUIRED feature of this protocol. 122 2. Object Attributes 124 2.1. Internationalized Domain Names 126 Names of affected hosts MUST be provided in Punycode according to 127 [RFC5891]. 129 2.2. Dates and Times 131 All dates and times attribute values MUST be expressed in Universal 132 Coordinated Time (UTC) using the Gregorian calendar. The extended 133 date-time form using upper case "T" and "Z" characters defined in ISO 134 8601 [RFC3339] MUST be used to represent date-time values. 136 2.3. Maintenance Elements 138 The element describes a single registry maintenance 139 event during a specific period. This element will be used at EPP 140 messages and to extend the EPP command. 142 For creating a new maintenance the attribute MUST be 143 "active", the attribute MUST be set and the attribute 144 SHALL NOT be present. 146 For updating a maintenance the attribute MUST be 147 "active", the attributes and MUST be 148 set. 150 For deleting a maintenance the attribute MUST be 151 "inactive", and the attributes and MUST 152 be set. 154 155 MUST be present and a server unique id and SHALL NOT be 156 changed if maintenance is updated or deleted. A human-readable 157 description of the maintenance is identified via an OPTIONAL 158 "msg" attribute. 160 161 MUST be present and contains one or more elements. 162 The server SHOULD NOT list systems which are not affected by the 163 maintenance. 165 166 MUST be present at least once and has an element of , 167 and . 169 170 MUST be present and indicates the name of the affected system, 171 such as "EPP", "WHOIS", "DNS", "Portal", etc. 173 174 MUST be present and indicates the affected maintained system 175 contains the hostname and OPTIONAL an IP address. 176 Hostname SHALL be Punycode according [RFC5891]. 177 IPv4 addresses SHALL be dotted-decimal notation. 178 An example of this textual representation is "192.0.2.0". 179 IPv6 addresses SHALL be according [RFC5952]. 180 An example of this textual representation is 181 "2001:db8::1:0:0:1". 183 184 MUST be present and contains the impact level; values MUST 185 either be "full" or "partial". 187 188 MUST be present and indicates the type of the affected system; 189 the attribute type is REQUIRED and SHOULD either be "production", 190 "ote", "staging", "dev" or "custom". And alternatively the 191 attribute name could be used to define a server specific affected 192 system for example. In that case name MUST be set: 193 195 196 SHOULD be present and indicates the start of the maintenance 197 according ISO 8601 [RFC3339]. 198 Format: YYYY-MM-DDThh:mm:ssTZ 200 201 SHOULD be present and indicates the end of the maintenance 202 according to ISO 8601 [RFC3339], and MUST be equal to or greater 203 than . 204 Format: YYYY-MM-DDThh:mm:ssTZ 206 207 MUST be present and contains the reason behind the maintenance; 208 values SHOULD either be "planned" or "emergency". 210 211 MAY be present and contains URI to detailed maintenance 212 description. 214 215 MAY be present and provides a freeform description of the 216 maintenance without having to create and traverse an external 217 resource. 219 220 SHOULD be present and contains elements. 222 223 MUST be present and contains the affected top-level domain. 224 Punycode encoded according to [RFC5891]. 226 227 SHOULD be present and contains and 228 . 230 231 SHOULD be present and indicates if a client needs to do 232 something that is connection-related, such as a reconnect. The 233 value SHALL be boolean. 235 236 MUST be present and indicates if a client needs to do something 237 that is implementation-related, such as a code change. The 238 value SHALL be boolean. 240 241 MUST be present and indicates the status of the maintenance. 242 The value SHALL be either "active" or "inactive". 244 245 MUST be present and contains the creation date of the maintenance 246 according ISO 8601 [RFC3339]. 247 Format: YYYY-MM-DDThh:mm:ssTZ 249 250 MAY be present and contains the updated date of the maintenance 251 according to ISO 8601 [RFC3339], and if set MUST be equal to or 252 greater than . 253 Format: YYYY-MM-DDThh:mm:ssTZ 255 3. EPP Command Mapping 257 A detailed description of the EPP syntax and semantics can be found 258 in the EPP core protocol specification [RFC5730]. The command 259 mappings described here are specifically for the use to notify of 260 Registry Maintenances and Registry Maintenance object mapping. 262 3.1. EPP Query Commands 264 EPP [RFC5730] provides three commands to retrieve object information: 265 to determine if an object is known to the server, to 266 retrieve detailed information associated with an object, and 267 to retrieve object transfer status information. 269 3.1.1. EPP Command 271 Available check semantics do not apply to maintenance objects, so 272 there is no mapping defined for the EPP command. 274 3.1.2. EPP Command 276 Transfer semantics do not apply to maintenance objects, so there is 277 no mapping defined for the EPP command. 279 3.1.3. EPP Command 281 EPP provides the command that is used to retrieve registry 282 maintenance information. In addition to the standard EPP command 283 elements, the command MUST contain a 284 element that identifies the maintenance namespace. 286 The element MUST contain a child element. It is either 287 to retrieve a specific maintenance notification or 288 to query all maintenance notifications. 290 If a is send with a that does not exist on 291 the server side, then the result code 2303 MUST be responded. 293 Please see the defintion of elements in Section 2.3. 295 Example command with explicit to get one specific 296 maintenance: 298 C: 299 C: 300 C: 301 C: 302 C: 304 C: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 305 C: 306 C: 307 C: ABC-12345 308 C: 309 C: 311 Example response for one specific maintenance notification, 312 which was requested with a explicit . In this case, it 313 provides the all "required" elements and additional elements 314 , , , , 315 , . 317 S: 318 S: 319 S: 320 S: 321 S: Command completed successfully 322 S: 323 S: 324 S: 326 S: 327 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 328 S: 329 S: 330 S: 331 S: EPP 332 S: epp.registry.example 333 S: 334 S: blackout 335 S: 336 S: 337 S: 338 S: 2017-09-30T06:00:00Z 339 S: 2017-09-30T14:25:57Z 340 S: planned 341 S: 342 S: https://www.registry.example/notice?123 343 S: 344 S: free text 345 S: 346 S: 347 S: example 348 S: test 349 S: 350 S: 351 S: false 352 S: false 353 S: 354 S: active 355 S: 2017-03-08T22:10:00Z 356 S: 357 S: 358 S: 359 S: 360 S: ABC-12345 361 S: 54321-XYZ 362 S: 363 S: 364 S: 366 Example command with to query all maintenances 367 subject to server policy: 369 C: 370 C: 371 C: 372 C: 373 C: 375 C: 376 C: 377 C: 378 C: ABC-12345 379 C: 380 C: 382 Example response querying all maintenances subject to server 383 policy. In this case, all the "required" elements will be returned 384 and additional . 386 S: 387 S: 388 S: 389 S: 390 S: Command completed successfully 391 S: 392 S: 393 S: 395 S: 396 S: 397 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 398 S: 399 S: 2017-04-30T06:00:00Z 400 S: 2017-04-30T07:00:00Z 401 S: 2017-02-08T22:10:00Z 402 S: 403 S: 404 S: 91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 405 S: 406 S: 2017-06-15T04:30:00Z 407 S: 2017-06-15T05:30:00Z 408 S: 2017-02-08T22:10:00Z 409 S: 2017-03-08T20:11:00Z 410 S: 411 S: 412 S: 413 S: 414 S: 415 S: ABC-12345 416 S: 54321-XYZ 417 S: 418 S: 419 S: 421 3.1.4. EPP Command 423 The EPP command and response is defined in Section 2.9.2.3 of 424 [RFC5730]. The Registry Maintenance Notification is included in the 425 EPP response of [RFC5730]. 427 For the Registry Maintenance Notification, there are three types of 428 poll messages. The poll message applies whenever the domain name 429 registry creates, updates, or deletes maintenance. In the case of 430 a Registry Maintenance specific message, a element 431 will be included within the element of the standard 432 response. 434 The element will include a reference to the 435 Registry Maintenance namespace. EPP data contained within the 436 element is formatted according to the 437 maintenance-poll schema. 439 Please see the defintion of elements in Section 2.3. 441 Example command: 443 C: 444 C: 445 C: 446 C: 447 C: ABC-12345 448 C: 449 C: 451 Example response with the Registry Maintenance poll message: 453 S: 454 S: 455 S: 456 S: 457 S: Command completed successfully; ack to dequeue 458 S: 459 S: 460 S: 2017-02-08T22:10:00Z 461 S: Registry Maintenance Notification 462 S: 463 S: 464 S: 466 S: 467 S: 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 468 S: 469 S: 470 S: EPP 471 S: epp.registry.example 472 S: 473 S: blackout 474 S: 475 S: 476 S: 477 S: 2017-10-30T06:00:00Z 478 S: 2017-10-30T14:25:57Z 479 S: planned 480 S: 481 S: https://www.registry.example/notice?123 482 S: 483 S: 484 S: example 485 S: test 486 S: 487 S: 488 S: false 489 S: false 490 S: 491 S: active 492 S: 2017-02-08T22:10:00Z 493 S: 494 S: 495 S: 496 S: 497 S: ABC-12345 498 S: 54321-XYZ 499 S: 500 S: 501 S: 503 3.2. EPP Transform Commands 505 EPP provides five commands to transform objects: to create 506 an instance of an object, to delete an instance of an 507 object, to extend the validity period of an object, 508 to manage object sponsorship changes, and to 509 change information associated with an object. 511 3.2.1. EPP Command 513 Create semantics do not apply to maintenance objects, so there is no 514 mapping defined for the EPP command. 516 3.2.2. EPP Command 518 Delete semantics do not apply to maintenance objects, so there is no 519 mapping defined for the EPP command. 521 3.2.3. EPP Command 523 Renew semantics do not apply to maintenance objects, so there is no 524 mapping defined for the EPP command. 526 3.2.4. EPP Command 528 Transfer semantics do not apply to maintenance objects, so there is 529 no mapping defined for the EPP command. 531 3.2.5. EPP Command 533 Update semantics do not apply to maintenance objects, so there is no 534 mapping defined for the EPP command. 536 4. Formal Syntax 538 One schema is presented here that is the EPP Registry Maintenance 539 schema. 541 The formal syntax presented here is a complete schema representation 542 of the object mapping suitable for automated validation of EPP XML 543 instances. The BEGIN and END tags are not part of the schema; they 544 are used to note the beginning and end of the schema for URI 545 registration purposes. 547 4.1. Registry Maintenance EPP Mapping Schema 549 BEGIN 550 551 558 561 562 564 565 566 Extensible Provisioning Protocol v1.0 567 Maintenance Mapping Schema. 568 569 571 574 576 579 580 581 582 583 584 585 586 587 590 591 592 593 594 595 596 597 599 602 604 607 608 609 610 611 612 614 617 618 619 621 622 624 627 628 629 630 631 632 633 634 635 636 639 640 641 642 643 644 645 646 647 648 650 651 653 654 655 656 657 659 662 663 664 666 667 669 672 673 674 675 676 677 679 682 683 684 685 686 687 688 689 692 693 694 695 696 697 698 700 703 704 705 706 707 708 709 711 712 713 714 715 716 718 719 720 721 722 723 725 728 729 730 731 732 733 734 735 736 737 740 741 742 743 744 745 746 747 749 752 753 754 755 756 757 759 762 763 764 766 767 769 772 773 774 775 776 777 779 782 783 784 785 786 787 788 791 792 END 794 5. IANA Considerations 796 5.1. XML Namespace 798 This document uses URNs to describe XML namespaces and XML schemas 799 conforming to a registry mechanism defined in [RFC3688]. 801 Registration request for the maintenance namespace: 803 URI: urn:ietf:params:xml:ns:maintenance-1.0 805 Registrant Contact: IESG 807 XML: None. Namespace URIs do not represent an XML specification. 809 Registration request for the maintenance schema: 811 URI: urn:ietf:params:xml:schema:maintenance-1.0 813 Registrant Contact: IESG 815 XML: See the "Formal Syntax" section of this document. 817 5.2. EPP Extension Registry 819 The following registration of the EPP Extension Registry, described 820 in [RFC7451], is requested: 822 Name of Extension: "Registry Maintenance Notifications for the 823 Extensible Provisioning Protocol (EPP)" 825 Document status: Standards Track 827 Reference: (insert the reference to RFC version of this document) 829 Registrant Name and Email Address: IESG, 831 TLDs: Any 833 IPR Disclosure: None 835 Status: Active 837 Notes: None 839 6. Security Considerations 841 The mapping extensions described in this document do not provide any 842 security services beyond those specified by EPP [RFC5730] and 843 protocol layers used by EPP. The security considerations described in 844 these other specifications apply to this specification as well. 846 7. Implementation Status 848 Note to RFC Editor: Please remove this section and the reference to 849 [RFC7942] before publication. 851 This section records the status of known implementations of the 852 protocol defined by this specification at the time of posting of this 853 Internet-Draft, and is based on a proposal described in [RFC7942]. 854 The description of implementations in this section is intended to 855 assist the IETF in its decision processes in progressing drafts to 856 RFCs. Please note that the listing of any individual implementation 857 here does not imply endorsement by the IETF. Furthermore, no effort 858 has been spent to verify the information presented here that was 859 supplied by IETF contributors. This is not intended as, and must not 860 be construed to be, a catalog of available implementations or their 861 features. Readers are advised to note that other implementations may 862 exist. 864 According to [RFC7942], "this will allow reviewers and working groups 865 to assign due consideration to documents that have the benefit of 866 running code, which may serve as evidence of valuable experimentation 867 and feedback that have made the implemented protocols more mature. It 868 is up to the individual working groups to use this information as 869 they see fit". 871 Add implementation details once available. 873 8. References 875 8.1. Normative References 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997, 879 . 881 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 882 DOI 10.17487/RFC3688, January 2004, 883 . 885 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 886 STD 69, RFC 5730, August 2009, 887 . 889 8.2. Informative References 891 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 892 Internet: Timestamps", RFC 3339, July 2002, 893 . 895 [RFC5891] Klensin, J., "Internationalized Domain Names in 896 Applications (IDNA): Protocol", RFC 5891, August 2010, 897 . 899 [RFC5952] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6 900 Address Text Representation", RFC 5952, August 2010, 901 . 903 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 904 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 905 February 2015, . 907 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 908 Running Code: The Implementation Status Section", RFC 909 7942, July 2016, 910 . 912 Appendix A. Change History 914 A.1. Change from draft-sattler-epp-poll-maintenance-response to 915 draft-sattler-epp-registry-maintenance 917 Updated to be EPP based instead of JSON document. 919 A.2. Change from draft-sattler-epp-registry-maintenance to 920 draft-ietf-regext-epp-registry-maintenance 922 Adopted by the REGEXT working group. 924 A.3. Change from 00 to 01 926 Clarified maint:description and maint:environment. Changed 927 maint:description from complexType to simpleType. Fixed typo. 928 Added acknowledgment. 930 A.4. Change from 01 to 02 932 Update language from Domain Name Registry to Registry. Clarified 933 XML namespace urn:ietf:params:xml:ns:maintenance-1.0. Changed host 934 to contain hostName and hostAddr. Changed maint:tlds from MUST to 935 SHOULD. Fixed maint:status in Schema. Changed UUID to a server 936 unique id. 938 A.5. Change from 02 to 03 940 Changed maint:connection from MUST to SHOULD. 942 A.6. Change from 03 to 04 944 A lot of clarifications and editoral changes. 946 Acknowledgments 948 The authors wish to thank the following individuals for their 949 feedback and suggestions (sorted alphabetically by company): 951 o Patrick Mevzek 952 o Neal McPherson, 1&1 IONOS 953 o Anthony Eden, DNSimple 954 o Christopher Martens, Donuts 955 o Quoc-Anh Pham, Neustar 956 o Raymond Zylstra, Neustar 957 o Andreas Huber, united-domains 958 o Craig Marchant, VentraIP 959 o James Gould, Verisign 961 Authors' Addresses 963 Tobias Sattler 965 Email: tobias.sattler@me.com 966 URI: https://tobiassattler.com 968 Roger Carney 969 GoDaddy Inc. 970 14455 N. Hayden Rd. #219 971 Scottsdale, AZ 85260 972 US 974 Email: rcarney@godaddy.com 975 URI: http://www.godaddy.com 977 Jody Kolker 978 GoDaddy Inc. 979 14455 N. Hayden Rd. #219 980 Scottsdale, AZ 85260 981 US 983 Email: jkolker@godaddy.com 984 URI: http://www.godaddy.com