idnits 2.17.1 draft-ietf-regext-unhandled-namespaces-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 (8 September 2020) is 1323 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NAMESPACE-URI' is mentioned on line 337, but not defined == Missing Reference: 'NAMESPACE-XML' is mentioned on line 334, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3735 ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.G. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Best Current Practice M.C. Casanova 5 Expires: 12 March 2021 SWITCH 6 8 September 2020 8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces 9 draft-ietf-regext-unhandled-namespaces-03 11 Abstract 13 The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, 14 includes a method for the client and server to determine the objects 15 to be managed during a session and the object extensions to be used 16 during a session. The services are identified using namespace URIs. 17 How should the server handle service data that needs to be returned 18 in the response when the client does not support the required service 19 namespace URI, which is referred to as an unhandled namespace? An 20 unhandled namespace is a significant issue for the processing of RFC 21 5730 poll messages, since poll messages are inserted by the server 22 prior to knowing the supported client services, and the client needs 23 to be capable of processing all poll messages. This document defines 24 an operational practice that enables the server to return information 25 associated with unhandled namespace URIs that is compliant with the 26 negotiated services defined in RFC 5730. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 12 March 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Unhandled Namespaces . . . . . . . . . . . . . . . . . . . . 4 64 3. Use of EPP for Unhandled Namespace Data . . . . . 4 65 3.1. Unhandled Object-Level Extension . . . . . . . . . . . . 5 66 3.2. Unhandled Command-Response Extension . . . . . . . . . . 7 67 4. Signaling Client and Server Support . . . . . . . . . . . . . 10 68 5. Usage with General EPP Responses . . . . . . . . . . . . . . 10 69 6. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 72 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 73 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 74 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 75 8.2. SWITCH Automated DNSSEC Provisioning Process . . . . . . 17 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 79 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 80 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 81 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 82 A.3. Change from 02 to REGEXT 00 . . . . . . . . . . . . . . . 19 83 A.4. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 19 84 A.5. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 19 85 A.6. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], 91 includes a method for the client and server to determine the objects 92 to be managed during a session and the object extensions to be used 93 during a session. The services are identified using namespace URIs. 94 How should the server handle service data that needs to be returned 95 in the response when the client does not support the required service 96 namespace URI, which is referred to as an unhandled namespace? An 97 unhandled namespace is a significant issue for the processing of 99 [RFC5730] poll messages, since poll messages are inserted by the 100 server prior to knowing the supported client services, and the client 101 needs to be capable of processing all poll messages. An unhandled 102 namespace is an issue also for general EPP responses when the server 103 has information that it cannot return to the client due to the 104 client's supported services. The server should be able to return 105 unhandled namespace information that the client can process later. 106 This document defines an operational practice that enables the server 107 to return information associated with unhandled namespace URIs that 108 is compliant with the negotiated services defined in [RFC5730]. 110 1.1. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 XML is case sensitive. Unless stated otherwise, XML specifications 117 and examples provided in this document MUST be interpreted in the 118 character case presented in order to develop a conforming 119 implementation. 121 In examples, "S:" represents lines returned by a protocol server. 122 Indentation and white space in examples are provided only to 123 illustrate element relationships and are not a REQUIRED feature of 124 this protocol. 126 The examples reference XML namespace prefixes that are used for the 127 associated XML namespaces. Implementations MUST NOT depend on the 128 example XML namespaces and instead employ a proper namespace-aware 129 XML parser and serializer to interpret and output the XML documents. 130 The example namespace prefixes used and their associated XML 131 namespaces include: 133 "changePoll": urn:ietf:params:xml:ns:changePoll-1.0 134 "domain": urn:ietf:params:xml:ns:domain-1.0 135 "secDNS": urn:ietf:params:xml:ns:secDNS-1.1 137 In the template example XML, placeholder content is represented by 138 the following variables: 140 "[NAMESPACE-XML]": XML content associated with a login service 141 namespace URI. An example is the element 142 content in [RFC5731]. 143 "[NAMESPACE-URI]": XML namespace URI associated with the [NAMESPACE- 144 XML] XML content. An example is "urn:ietf:params:xml:ns:domain- 145 1.0" in [RFC5731]. 147 2. Unhandled Namespaces 149 An Unhandled Namespace is an XML namespace that is associated with a 150 response extension that is not included in the client-specified EPP 151 login services of [RFC5730]. The EPP login services consists of the 152 set of XML namespace URIs included in the or 153 elements of the [RFC5730] EPP command. The services 154 supported by the server are included in the and 155 elements of the [RFC5730] EPP , which should be a superset 156 of the login services included in the EPP command. A server 157 may have information associated with a specific namespace that it 158 needs to return in the response to a client. The unhandled 159 namespaces problem exists when the server has information, that it 160 needs to return to the client, that is not supported by the client 161 based on the negotiated EPP command services. 163 3. Use of EPP for Unhandled Namespace Data 165 When a server has data to return to the client, that the client does 166 not support based on the login services, the server MAY return a 167 successful response, with the data for each unsupported namespace 168 moved into an [RFC5730] element. The unhandled namespace 169 will not cause an error response, but the unhandled namespace data 170 will instead be moved to an element, along with a reason 171 why the unhandled namespace data could not be included in the 172 appropriate location of the response. The element XML 173 will not be processed by the XML processor. The element 174 contains the following child elements: 176 : Contains a child-element with the unhandled namespace XML. 177 The XML namespace and namespace prefix of the child element MUST 178 be defined, which MAY be defined in the element or in the 179 the child element. XML processing of the element is 180 disabled in [RFC5730], so the information can safely be returned 181 in the element. 182 : A formatted human-readable message that indicates the 183 reason the unhandled namespace data was not returned in the 184 appropriate location of the response. The formatted reason 185 SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar 186 [RFC5234] format: NAMESPACE-URI "not in login services", where 187 NAMESPACE-URI is the unhandled XML namespace like 188 "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. 190 This document supports handling of unsupported namespaces for 191 [RFC3735] object-level extensions and command-response extensions. 192 This document does not support [RFC3735] protocol-level extensions or 193 authentication information extensions. Refer to the following 194 sections on how to handle an unsupported object-level extension 195 namespace or an unsupported command-response extension namespace. 197 3.1. Unhandled Object-Level Extension 199 An object-level extension in [RFC5730] is a child element of the 200 element. If the client does not handle the namespace of 201 the object-level extension, then the element is removed and 202 its object-level extension child element is moved into a [RFC5730] 203 element, with the namespace URI included in the 204 corresponding element. The response becomes a 205 general EPP response without the element. 207 Template response for a supported object-level extension. The 208 [NAMESPACE-XML] variable represents the object-level extension XML. 210 S: 211 S: 212 S: 213 S: 214 S: Command completed successfully 215 S: 216 S: 217 S: [NAMESPACE-XML] 218 S: 219 S: 220 S: ABC-12345 221 S: 54322-XYZ 222 S: 223 S: 224 S: 226 Template unhandled namespace response for an unsupported object-level 227 extension. The [NAMESPACE-XML] variable represents the object-level 228 extension XML and the [NAMESPACE-URI] variable represents the object- 229 level extension XML namespace URI. 231 S: 232 S: 233 S: 234 S: 235 S: Command completed successfully 236 S: 237 S: 238 S: [NAMESPACE-XML] 239 S: 240 S: 241 S: [NAMESPACE-URI] not in login services 242 S: 243 S: 244 S: 245 S: 246 S: ABC-12345 247 S: 54322-XYZ 248 S: 249 S: 250 S: 252 The EPP response is converted from an object response to a general 253 EPP response by the server when the client does not support the 254 object-level extension namespace URI. Below is example of converting 255 the query response example in [RFC5731] to an unhandled 256 namespace response. 258 [RFC5731] example query response converted into an 259 unhandled namespace response. 261 S: 262 S: 263 S: 264 S: 265 S: Command completed successfully 266 S: 267 S: 268 S: 270 S: example.com 271 S: pending 272 S: ClientX 273 S: 2000-06-06T22:00:00.0Z 274 S: ClientY 275 S: 2000-06-11T22:00:00.0Z 276 S: 2002-09-08T22:00:00.0Z 277 S: 278 S: 279 S: 280 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 281 S: 282 S: 283 S: 284 S: 285 S: ABC-12345 286 S: 54322-XYZ 287 S: 288 S: 289 S: 291 3.2. Unhandled Command-Response Extension 293 A command-response extension in [RFC5730] is a child element of the 294 element. If the client does not handle the namespace of 295 the command-response extension, the command-response child element is 296 moved into a [RFC5730] element, with the namespace 297 URI included in the corresponding element. If 298 after moving the command-response child element there are no 299 additional command-response child elements, the element 300 MUST be removed. 302 Template response for a supported command-response extension. The 303 [NAMESPACE-XML] variable represents the command-response extension 304 XML. 306 S: 307 S: 308 S: 309 S: 310 S: Command completed successfully 311 S: 312 S: 313 S: [NAMESPACE-XML] 314 S: 315 S: 316 S: ABC-12345 317 S: 54322-XYZ 318 S: 319 S: 320 S: 322 Template unhandled namespace response for an unsupported command- 323 response extension. The [NAMESPACE-XML] variable represents the 324 command-response extension XML and the [NAMESPACE-URI] variable 325 represents the command-response extension XML namespace URI. 327 S: 328 S: 329 S: 330 S: 331 S: Command completed successfully 332 S: 333 S: 334 S: [NAMESPACE-XML] 335 S: 336 S: 337 S: [NAMESPACE-URI] not in login services 338 S: 339 S: 340 S: 341 S: 342 S: ABC-12345 343 S: 54322-XYZ 344 S: 345 S: 346 S: 348 The EPP response is converted to an unhandled namespace response by 349 moving the unhandled command-response extension from under the 350 to an element. Below is example of converting 351 the DS Data Interface response example in [RFC5910] to an 352 unhandled namespace response. 354 [RFC5910] DS Data Interface response converted into an 355 unhandled namespace response. 357 S: 358 S: 359 S: 360 S: 361 S: Command completed successfully 362 S: 363 S: 364 S: 366 S: 367 S: 12345 368 S: 3 369 S: 1 370 S: 49FD46E6C4B45C55D4AC 371 S: 372 S: 373 S: 374 S: 375 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services 376 S: 377 S: 378 S: 379 S: 380 S: 382 S: example.com 383 S: EXAMPLE1-REP 384 S: 385 S: jd1234 386 S: sh8013 387 S: sh8013 388 S: 389 S: ns1.example.com 390 S: ns2.example.com 391 S: 392 S: ns1.example.com 393 S: ns2.example.com 394 S: ClientX 395 S: ClientY 396 S: 1999-04-03T22:00:00.0Z 397 S: ClientX 398 S: 1999-12-03T09:00:00.0Z 399 S: 2005-04-03T22:00:00.0Z 400 S: 2000-04-08T09:00:00.0Z 401 S: 402 S: 2fooBAR 403 S: 404 S: 405 S: 406 S: 407 S: ABC-12345 408 S: 54322-XYZ 409 S: 410 S: 411 S: 413 4. Signaling Client and Server Support 415 This document does not define new protocol but a Best Current 416 Practice (BCP) using the existing EPP protocol, where the client and 417 the server can signal support for the BCP using a namespace URI in 418 the login and greeting extension services. The namespace URI 419 "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to 420 signal support for the BCP. The client includes the namespace URI in 421 an element of the [RFC5730] Command. 422 The server includes the namespace URI in an 423 element of the [RFC5730] Greeting. 425 A client that receives the namespace URI in the server's Greeting 426 extension services, can expect the following supported behavior by 427 the server: 429 1. Support unhandled namespace object-level extensions and command- 430 response extensions in EPP poll messages, per Section 6. 431 2. Support the option of unhandled namespace command-response 432 extensions in general EPP responses, per Section 5. 434 A server that receives the namespace URI in the client's 435 Command extension services, can expect the following supported 436 behavior by the client: 438 1. Support monitoring the EPP poll messages and general EPP 439 responses for unhandled namespaces. 441 5. Usage with General EPP Responses 443 The unhandled namespace approach defined in Section 3 MAY be used for 444 a general EPP response to an EPP command. A general EPP response 445 includes any non-poll message EPP response. The use of the unhandled 446 namespace approach for poll message EPP responses is defined in 447 Section 6. The server MAY exclude the unhandled namespace 448 information in the general EPP response or MAY include it using the 449 unhandled namespace approach. 451 The unhandled namespace approach for general EPP responses SHOULD 452 only be applicable to command-response extensions, defined in 453 Section 3.2, since the server SHOULD NOT accept an object-level EPP 454 command if the client did not include the object-level namespace URI 455 in the login services. An object-level EPP response extension is 456 returned when the server successfully executes an object-level EPP 457 command extension. The server MAY return an unhandled object-level 458 extension to the client as defined in Section 3.1. 460 Returning domain name Redemption Grace Period (RGP) data, based on 461 [RFC3915], provides an example of applying the unhandled namespace 462 approach for a general EPP response. If the client does not include 463 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login 464 services, and the domain response of a domain name does have 465 RGP information, the server MAY exclude the element 466 from the EPP response or MAY include it under in the 467 element per Section 3.2. 469 [RFC5731] domain name response with the unhandled [RFC3915] 470 element included under an element: 472 S: 473 S: 474 S: 475 S: 476 S: Command completed successfully 477 S: 478 S: 479 S: 480 S: 481 S: 482 S: 483 S: 484 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services 485 S: 486 S: 487 S: 488 S: 489 S: 491 S: example.com 492 S: EXAMPLE1-REP 493 S: 494 S: jd1234 495 S: sh8013 496 S: sh8013 497 S: 498 S: ns1.example.com 499 S: ns1.example.net 500 S: 501 S: ns1.example.com 502 S: ns2.example.com 503 S: ClientX 504 S: ClientY 505 S: 1999-04-03T22:00:00.0Z 506 S: ClientX 507 S: 1999-12-03T09:00:00.0Z 508 S: 2005-04-03T22:00:00.0Z 509 S: 2000-04-08T09:00:00.0Z 510 S: 511 S: 2fooBAR 512 S: 513 S: 514 S: 515 S: 516 S: ABC-12345 517 S: 54322-XYZ 518 S: 519 S: 520 S: 522 6. Usage with Poll Message EPP Responses 524 The unhandled namespace approach, defined in Section 3, MUST be used 525 if there is unhandled namespace information included in an EPP 526 message response. The server inserts poll messages into the client's 527 poll queue independent of knowing the supported client login 528 services, therefore there may be unhandled object-level and command- 529 response extensions included in a client's poll queue. In [RFC5730], 530 the command is used by the client to retrieve and acknowledge 531 poll messages that have been inserted by the server. The 532 message response is an EPP response that includes the element 533 that provides poll queue meta-data about the message. The unhandled 534 namespace approach, defined in Section 3, is used for an unhandled 535 object-level extension and for each of the unhandled command-response 536 extensions attached to the message response. The resulting 537 EPP message response MAY have either or both the object-level 538 extension or command-response extensions moved to 539 elements, as defined in Section 3. 541 The Change Poll Message, as defined in [RFC8590], which is an 542 extension of any EPP object, is an example of applying the unhandled 543 namespace approach for EPP message responses. The object that 544 will be used in the examples is a [RFC5731] domain name object. 546 [RFC5731] domain name message response with the 547 unhandled [RFC8590] element included under an 548 element: 550 S: 551 S: 552 S: 553 S: 554 S: Command completed successfully; ack to dequeue 555 S: 556 S: 557 S: 560 S: update 561 S: 562 S: 2013-11-22T05:00:00.000Z 563 S: 12345-XYZ 564 S: URS Admin 565 S: urs123 566 S: 567 S: URS Lock 568 S: 569 S: 570 S: 571 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 572 S: 573 S: 574 S: 575 S: 579 S: 2018-08-24T19:21:51.087Z 580 S: Registry initiated update of domain. 581 S: 582 S: 583 S: 585 S: change-poll.tld 586 S: EXAMPLE1-REP 587 S: 588 S: 589 S: 590 S: jd1234 591 S: sh8013 592 S: sh8013 593 S: ClientX 594 S: ClientY 595 S: 2012-05-03T04:00:00.000Z 596 S: ClientZ 597 S: 2013-11-22T05:00:00.000Z 598 S: 2014-05-03T04:00:00.000Z 599 S: 600 S: 601 S: 602 S: ABC-12345 603 S: 54322-XYZ 604 S: 605 S: 606 S: 608 Unhandled [RFC5731] domain name message response and 609 the unhandled [RFC8590] element included 610 under an element: 612 S: 613 S: 614 S: 615 S: 616 S: Command completed successfully; ack to dequeue 617 S: 618 S: 619 S: 621 S: change-poll.tld 622 S: EXAMPLE1-REP 623 S: 624 S: 625 S: 626 S: jd1234 627 S: sh8013 628 S: sh8013 629 S: ClientX 630 S: ClientY 631 S: 2012-05-03T04:00:00.000Z 632 S: ClientZ 633 S: 2013-11-22T05:00:00.000Z 634 S: 2014-05-03T04:00:00.000Z 635 S: 636 S: 637 S: 638 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 639 S: 640 S: 641 S: 642 S: 643 S: 646 S: update 647 S: 648 S: 2013-11-22T05:00:00.000Z 649 S: 12345-XYZ 650 S: URS Admin 651 S: urs123 652 S: 653 S: URS Lock 654 S: 655 S: 656 S: 657 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 658 S: 659 S: 660 S: 661 S: 665 S: 2018-08-24T19:23:12.822Z 666 S: Registry initiated update of domain. 667 S: 668 S: 669 S: ABC-12345 670 S: 54322-XYZ 671 S: 672 S: 673 S: 675 7. IANA Considerations 677 7.1. XML Namespace 679 This document uses URNs to describe XML namespaces conforming to a 680 registry mechanism described in [RFC3688]. The following URI 681 assignment is requested of IANA: 683 Registration request for the unhandled namespaces namespace: 685 URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0 686 Registrant Contact: IESG 687 XML: None. Namespace URIs do not represent an XML specification. 689 7.2. EPP Extension Registry 691 The EPP Best Current Practice (BCP) described in this document should 692 be registered by the IANA in the EPP Extension Registry described in 693 [RFC7451]. The details of the registration are as follows: 695 Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled 696 Namespaces" 698 Document status: Best Current Practice 700 Reference: (insert reference to RFC version of this document) 702 Registrant Name and Email Address: IESG, 704 TLDs: Any 706 IPR Disclosure: None 708 Status: Active 710 Notes: None 712 8. Implementation Status 714 Note to RFC Editor: Please remove this section and the reference to 715 RFC 7942 [RFC7942] before publication. 717 This section records the status of known implementations of the 718 protocol defined by this specification at the time of posting of this 719 Internet-Draft, and is based on a proposal described in RFC 7942 720 [RFC7942]. The description of implementations in this section is 721 intended to assist the IETF in its decision processes in progressing 722 drafts to RFCs. Please note that the listing of any individual 723 implementation here does not imply endorsement by the IETF. 724 Furthermore, no effort has been spent to verify the information 725 presented here that was supplied by IETF contributors. This is not 726 intended as, and must not be construed to be, a catalog of available 727 implementations or their features. Readers are advised to note that 728 other implementations may exist. 730 According to RFC 7942 [RFC7942], "this will allow reviewers and 731 working groups to assign due consideration to documents that have the 732 benefit of running code, which may serve as evidence of valuable 733 experimentation and feedback that have made the implemented protocols 734 more mature. It is up to the individual working groups to use this 735 information as they see fit". 737 8.1. Verisign EPP SDK 739 Organization: Verisign Inc. 741 Name: Verisign EPP SDK 743 Description: The Verisign EPP SDK includes an implementation of the 744 unhandled namespaces for the processing of the poll queue messages. 746 Level of maturity: Development 748 Coverage: All aspects of the protocol are implemented. 750 Licensing: GNU Lesser General Public License 752 Contact: jgould@verisign.com 754 URL: https://www.verisign.com/en_US/channel-resources/domain- 755 registry-products/epp-sdks 757 8.2. SWITCH Automated DNSSEC Provisioning Process 759 Organization: SWITCH 761 Name: Registry of .CH and .LI 763 Description: SWITCH uses poll messages to inform the registrar about 764 DNSSEC changes at the registry triggered by CDS records. These poll 765 messages are enriched with the 'urn:ietf:params:xml:ns:changePoll- 766 1.0' and the 'urn:ietf:params:xml:ns:secDNS-1.1' extension that are 767 rendered in the poll msg response according to this draft. 769 Level of maturity: Operational 771 Coverage: All aspects of the protocol are implemented. 773 Licensing: Proprietary 775 Contact: martin.casanova@switch.ch 777 URL: https://www.nic.ch/cds 779 9. Security Considerations 781 The document do not provide any security services beyond those 782 described by EPP [RFC5730] and protocol layers used by EPP. The 783 security considerations described in these other specifications apply 784 to this specification as well. 786 10. Acknowledgements 788 The authors wish to thank the following persons for their feedback 789 and suggestions: Scott Hollenbeck, Patrick Mevzek, and Marcel Parodi. 791 11. Normative References 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, 795 DOI 10.17487/RFC2119, March 1997, 796 . 798 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 799 DOI 10.17487/RFC3688, January 2004, 800 . 802 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 803 Provisioning Protocol (EPP)", RFC 3735, 804 DOI 10.17487/RFC3735, March 2004, 805 . 807 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 808 the Extensible Provisioning Protocol (EPP)", RFC 3915, 809 DOI 10.17487/RFC3915, September 2004, 810 . 812 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 813 Specifications: ABNF", STD 68, RFC 5234, 814 DOI 10.17487/RFC5234, January 2008, 815 . 817 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 818 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 819 . 821 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 822 Domain Name Mapping", STD 69, RFC 5731, 823 DOI 10.17487/RFC5731, August 2009, 824 . 826 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 827 Security Extensions Mapping for the Extensible 828 Provisioning Protocol (EPP)", RFC 5910, 829 DOI 10.17487/RFC5910, May 2010, 830 . 832 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 833 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 834 February 2015, . 836 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 837 Code: The Implementation Status Section", BCP 205, 838 RFC 7942, DOI 10.17487/RFC7942, July 2016, 839 . 841 [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the 842 Extensible Provisioning Protocol (EPP)", RFC 8590, 843 DOI 10.17487/RFC8590, May 2019, 844 . 846 Appendix A. Change History 848 A.1. Change from 00 to 01 850 1. Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 851 reference from examples. 852 2. removed block from example. 853 3. added SWITCH Automated DNSSEC Provisioning Process at 854 Implementation Status 856 A.2. Change from 01 to 02 858 1. Ping update 860 A.3. Change from 02 to REGEXT 00 862 1. Changed to regext working group draft by changing draft-gould- 863 casanova-regext-unhandled-namespaces to draft-ietf-regext- 864 unhandled-namespaces. 866 A.4. Change from REGEXT 00 to REGEXT 01 868 1. Added the "Signaling Client and Server Support" section to 869 describe the mechanism to signal support for the BCP by the 870 client and the server. 871 2. Added the IANA Considerations section with the registration of 872 the unhandled namespaces XML namespace and the registration of 873 the EPP Best Current Practice (BCP) in the EPP Extension 874 Registry. 876 A.5. Change from REGEXT 01 to REGEXT 02 878 1. Filled in the acknowledgements section. 880 2. Changed the reference from RFC 5730 to RFC 5731 for the transfer 881 example in section 3.1 "Unhandled Object-Level" Extension. 882 3. Updated the XML namespace to 883 urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0, which 884 removed bcp from the namespace and bumped the version from 0.1 885 and 1.0. Inclusion of bcp in the XML namespace was discussed at 886 the REGEXT interim meeting. 888 A.6. Change from REGEXT 02 to REGEXT 03 890 1. Converted from xml2rfc v2 to v3. 891 2. Updated Acknowledgements to match the approach taken by the RFC 892 Editor with draft-ietf-regext-login-security. 893 3. Changed reference of ietf-regext-change-poll to RFC 8590. 895 Authors' Addresses 897 James Gould 898 VeriSign, Inc. 899 12061 Bluemont Way 900 Reston, VA 20190 901 United States of America 903 Email: jgould@verisign.com 904 URI: http://www.verisigninc.com 906 Martin Casanova 907 SWITCH 908 P.O. Box 909 CH-8021 Zurich 910 Switzerland 912 Email: martin.casanova@switch.ch 913 URI: http://www.switch.ch